Minio Changes License to AGPL(github.com) |
Minio Changes License to AGPL(github.com) |
The flaws it has are things like the poorly-written patent clause, verbosity, ambiguity on concepts like linking, and general lack of elegance. It runs into a lot of corner cases around where code looks like data or data looks like code; there isn't a clean separation.
GPLv2 was a brilliantly-drafted license.
For all those failings, AGPL seems like the right choice for people who want their code feeding into an open ecosystem, rather than coopted by corporate giants.
Isn't the AGPL based on the GPLv3? I thought the GPLv3 had a very clear stance on patents.
AGPL is a poison pill license that creates a very distorted open source model - better example is "shared source" - you can look but can't really use it in you own ops.
The whole AGPLv3 / GPLv3 thing was such a mess - a big move towards trying to tell people how to use the code. I think long term GPLv3 and AGPLv3 die out.
And last time I checked there doesn't seems to a A-LGPL or L-AGPL type of license.
For those wondering if they can relicense other people's changes without a CLA, the answer is yes. Apache 2.0 is compatible with the AGPL, so it can be relicensed with it (though the original contributions remain available as Apache 2.0). This does not work backwards, however - this is a one-way change. All of MinIO's code is today and forevermore available under the terms of the AGPL.
They've done a pretty shitty job of it, though. No one should have a license change sprung on them like this. Further indicates that Minio does not value their community's input.
This GNU article [1] explicitly mentions that subsumed licenses still need to be mentioned in the source.
[1] https://www.gnu.org/licenses/license-compatibility.en.html
now the AGPL is designed to block "Application Service Provider" hole. (closed source shops from using modified GPL source code without publishing their changes, as it is only hosted on a single network destination)
Can someone please explain the differences between AGPL and GNU AGPL in this respect? Things are now very fragmented in the land of licenses; is there a resource that compares what they all imply?
[1] https://en.wikipedia.org/wiki/Affero_General_Public_License
[2] https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
[3] https://stackoverflow.com/questions/2127246/difference-betwe...
> Compatibility with the GPL
> Both versions of the AGPL, like the corresponding versions of the GNU GPL on which they are based, are strong copyleft licenses. In the Free Software Foundation's judgment, the added requirement in section 2(d) of Affero GPL v1 made it incompatible with the otherwise nearly identical GPLv2. That is to say, one cannot distribute a single work formed by combining components covered by each license.
> By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses. These clauses explicitly allow the "conveying" of a work formed by linking code licensed under the one license against code licensed under the other license,[4] despite the licenses otherwise not allowing relicensing under the terms of each other.[5]
> To establish an upgrade path from Affero's original AGPLv1 to the GNU AGPLv3, Affero, Inc. published the Affero General Public License version 2 in November 2007,[6] which is merely a transitional license that allows recipients of software licensed under "AGPLv1 or any later version as published by Affero, Inc." to distribute the software, or derivative works, under the GNU AGPLv3 or any later version.
Besides legal issues, I consider changes like this to be very slimy since you are kind of pulling the rug out from under people. I would expect a huge discussion to take place before doing something like this to try and let people move off of the platform if AGPL does not work for them for whatever reason.
(IANAL)
You can add your own license to any changes you make and add your own license headers, but absolutely cannot change any existing license headers, etc.
I'm planning on launching a managed S3-alike service later this year and Minio is going to be what I use, it remains to be seen if they'll go to SSPL/BSL or anything else when enough people do this (maybe most wouldn't because of AGPL FUD so that's my uncommon advantage?).
On a wider note though, is this going to be the projects/companies now?
- Start permissively F/OSS project
- Entice the community to contribute/produce content/market
- (optional) Sell the project/cash out some how/get acquihired
- Change the license of the project
- Make all the new stuff source-available but not F/OSS to encourage people to get commercial licenses
- ???
- Insert ads/subtle advertisements/banners into the OSS product so people are discouraged from hosting it (this is speculation, I assume this is what comes next)
I sure do wish projects would be SSPL/BSL from the beginning, I want the freedom to be able to build a business on my freely obtained immensely valuable software, including hosting it, without worrying about rent seeking activity later.
PS: yes, I'm aware of how incredibly selfish that last bit sounds, but I want to be honest about it -- this is what everyone is doing and why F/OSS software won. There's a world where we can build sustainable F/OSS software that runs on something other than donations, and IMO it looks like what Let's Encrypt's managed to do, where organizations that gain immense value from something do revenue-share style deals, but that's a discussion for another time.
[EDIT] I just want to soften this -- I am NOT against companies making money from software. IMO AGPL is a great license because it actually maintains that freedom and requires contribution back (or monetary support). I just find that I am increasingly on edge whenever I see projects advertised as "open source" (but not free) and wonder if I'm just walking into a very nice, free-for-me mouse trap.
BSL is a very nice license as well, it's straight forward, and IMO a great way to build an open source software company -- no one gets mad at Sentry for their license terms, because it's straight forward and obvious, and still giving a way value for free, just on a time delay.
[EDIT2] I could have sworn there was a license that was like BSL but required anyone making over 1MM/year using the software to make some sort of contribution back, licenses like that might be cool too.
- https://github.com/minio/minio/blob/master/pkg/argon2/argon2.go#L38
- https://github.com/golang/crypto/blob/master/argon2/argon2.go
> forked from https://golang.org/x/crypto/argon2
> modified to be used with MinIO under GNU Affero General
> Public License 3.0 license that can be found in
> the LICENSE file.
they should probably consult a lawyer...
Now, you can include BSD-style files with GPL ones without issue--that's true. But I thought you can't change the license of a file from BSD to GPL unless you are the original owner.
> I'm not so sure, if the go authors are happy about that.
Then they should probably switch to a different license - one that more closely mirrors their intent. The cat's out of the bag for all released versions though.
You can't relicense something that is Apache 2.0 as AGPL. You need explicit approval of every single contributor (whose code still exists in the project).
You can also attach the AGPL, but it is not a superset of Apache 2.0, which for example contains constraints that require you to clearly indicate each and every time a file is modified.
Incidentally, the Apache 2.0 is a terrible license for modern open source, and it probably shouldn't be used.
EDIT: To people responding, my advice is to read the licenses. Don't read a dot point summary, read the licenses. Seriously, read the licenses!
Sorry, this drives me a little mad.
Of course you can include Apache 2.0 code in an AGPL project. The point is contributors contributed their code under the terms of the Apache 2.0 license. To use that code, you must meet the terms of that license. You can slap additional requirements on, you can't remove requirements.
In fact, one requirement is the very fact you can't remove the license text itself!
And even in that case, you only need to share your modifications of minio, not anything about the rest of your system. Doesn't seem too much of a problem, to begin with.
[1] https://softwareengineering.stackexchange.com/a/107931/28221
"The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. "
Almost all larger places have very strict bans on evening touching AGPL -
https://opensource.google/docs/using/agpl-policy/
The contributors can of course license commercially, so this has made it a popular sort of "shared source" type license - you can look at the code, but can't use it in your own projects unless they are open source too or pay for the commercial license.
Please, stop spreading ridiculous FUD.
You can use copylefted code in your own projects without any restriction. It is only when you distribute this copylefted code (e.g., by letting users run it in your computer) that you need to publish your modifications to it. And then, this is only relevant when you have modified the copylefted code; otherwise you just need to distribute code that is public elsewhere, which is a non-issue.
A license is only as strong as the likelihood and severity of consequences.
There's no pulling the rug under people here: it's not like the previous releases, under the Apache license, are rescinded. Someone can still fork the project and keep it under the Apache license.
If they are using a proprietary license for their commercial offering, they will probably require future community contributions to be donated under the Apache 2.0 license.
You’d think they would have thought of this first. The fact that we’re having this conversation isn’t a good sign.
Unless you get everyone who has contributed code to also release their code under the new license, the old license is the only one which all of the code has.
It is possible to start contributing code to a project under a new license (effectively re-licensing the project in the eyes of the community), provided that the new license does not violate the old one. Specifically the Apache license REQUIRES that the code be distributed with a copy of the Apache license. Just removing or changing that license without the copyright holder's permission is in violation of that copyright.
A lot of projects avoid potential future issues by having a contributors agreement in addition to the project's distribution license. Essentially, you give an extremely permissive (possibly up full ownership) of the code you write to the project. That is, some legal entity such as a person (the head maintainer) or a foundation. This legal entity then distributes the project to the community using the license of their choice.
[0] https://www.gnu.org/licenses/license-compatibility.en.html
I generally only run minio from the official docker image, so I don't reckon this would affect "normal" usage?
Which is somewhat bizarre given that aims to MinIO emulate a closed-source system. Open source businesses usually use AGPL or similar to prevent "Big Cloud" from stealing their business, this is a very strange inverted approach and I can't figure out why.
I did a quick analysis of the project and there were 41 contributors in the last year that contributed more than 10 lines of code churn to go files. See the following for an analysis:
https://public-001.gitsense.com/insights/github/repos?q=file...
If you switch to the impacts view, you can see that of the 41 contributors, there was 1 frequent contributor, 3 occasional contributors and 37 seldom contributors.
I can't tell how many of the contributors are Minio employees, but I'm guessing in the worst case scenario, they could look at re-implementing contributions by non Minio employees, since the vast majority of code changes were by Minio employees. I know re-implementing previous contributions is a strategy that some use when they change their license, but I'm not sure how practical this is for Minio.
As a side note, do not install my tool as the docker image has expired license that I need to update.
> - Entice the community to contribute/produce content/market
> - Change the license of the project
You can't really do that without every contributor agreeing or using a compatible license (unless people sign CLAs, but even then you can only re-license further work).
Also CLAs are pretty common these days, the legalese is written in a very non-offensive manner, and the youngsters that are new to open source probably don't think twice about signing it (assuming you should think twice about signing it in the first place, of course, some people may not agree with that).
Free bootstrapped money-printer startup idea for someone -- software for managing CLAs (projects, signatures, revocation, etc) would probably be a no-brainer for most of the companies looking to get into OSS. Making this easier for companies may damage the ecosystem (essentially enabling more of the behavior I've outlined), but it could also be good because it brings sunlight, if you know the playbook (and it's obvious when someone asks you to sign a CLA), then the community as a whole can avoid those companies' projects, or know what they're buying into, and the shift between Free software, open source software, and source-available software will widen.
Contracts and licenses are built on:
1) Things need to be substantially the same. If I offer to build a house for you with Brand X super-plywood flooring, and it's sold out, I can build it upgraded to Brand Y corkwood flooring since Brand X plywood was sold out, and it's substantially equivalent for the purpose, and that's okay. On the other hand, if Brand X introduces a new low-cost plywood flooring that technically qualifies but obviously isn't what we meant, you've got a case.
I can't imagine any court will care about 4b being on a per-file versus per-repo basis.
2) Damages. There isn't a magic genie which throws contract-breakers or license-breakers in jail. The extent to which these matter is damages. If I break an agreement with you, you need to care enough to sue me. Beyond that, a court will award damages, and you'll need to show you were harmed somehow, or entitled to statutory damages.
I'm not sure how you'd show you were somehow damaged by a change like whether license text is per-file or per-repo.
Contracts are written by lawyers who keep all this in mind. That's why I hire lawyers to help interpret contracts; a plain language read is often misleading. My advice is read the licenses with a lawyer, or at least someone with a basic background in contracts and licenses. Goodness knows there are bad lawyers out there, but even those will give better advice than a stranger on the internet.
Disclaimer: This is specific to common law systems, and perhaps not all of them. But that's how the US works.
I'm not interested in sea lioning. So I'll just ask for one specific claim that is false.
> IANAL, but you're obviously not one either.
That ought to have been clear from the first two sentences of my comment.
> I can't imagine any court will care about 4b being on a per-file versus per-repo basis.
You can imagine all you like. I'll leave that to the courts themselves.
Suggesting people (even with a superfluous IANAL disclaimer) make legal decisions based on what you imagine courts will do is just poor advice; legal or otherwise.
> 2) Damages [...]
I haven't mentioned damages because it's not relevant. If you think the concept is new to me, you're quite welcome to peruse my recent HN comments.
Infringement and damages are unrelated concepts. Will someone have to pay substantial damages for infringing in the way described? Probably not, but that doesn't change the fact infringement took place. It also is going to vary wildly depending on the circumstances involved.
Some jurisdictions have minimum damages that are owed simply if an infringement takes places, irrespective of any other details of the infringements.
It's just outright poor advice to suggest people make legal decisions based on what they can imagine.
There's also a very big difference between what I'm suggesting and what you're suggesting. You're telling people to go ahead and do something. I'm telling them not to do something.
Perhaps I'm being overly conservative, but you're quite right, unless you're sitting down with a lawyer (which let's face most open source projects are not) then don't make assumptions. Just follow the license precisely to the best of your ability, until you've got specific legal advice (and insurance) to protect you if something goes wrong.
EDIT: This really shouldn't be relevant. Because honestly it shouldn't add any credibility to my statements.
No I don't sit down with lawyers every time I make decision that has legal implications - that's impossible. However, I do have first hand experience dealing with copyright/licensing lawyers specifically over IP infringement due to a third-party violating the license of software I wrote. No, it wasn't just a discussion. Lawyers took action, and infringement stopped taking place - it did not reach the courts.
Again, that shouldn't add any credibility to my claims. I have zero credibility here, as does mostly everyone else. Just read the damn license.
It's been a while since I've paid attention; what's wrong with it? It's just a permissive license with some patent stuff added, isn't it?
The same section with that requirement also says you may use a different license terms for that notice as long as it complies with the terms of the Apache 2.0 license. In this case since the AGPLv3 is a superset of the Apache 2.0 license it can be substituted for the Apache 2.0 license per these terms.
It's not, and I already covered this.
AGPLv3 has nothing that is a direct superset of Apache 2.0's requirement 4b.
The closest is the section "5. Conveying Modified Source Versions." However, the terms are not the same. Section 5 is a subset of 4b, not a superset.
Specifically, 4b pertains to individual files, 5 pertains to the "work" as a whole.
The requirement to mark each modified file is not present in AGPLv3, ergo it's not a superset.
Also worth noting, in section 5 of the AGPLv3:
> Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
The AGPLv3 is very explicit that it's on terms do not replace the terms of its aggregate components.
i.e. You can license a whole work as AGPLv3, but the components are still Apache 2.0. To use those components, you must adhere to those terms.
In this case, if you modify Apache 2.0 files, you must still indicate you've done so. So Minio should not be removing the Apache 2.0 from the repository, doing so is a violation of the Apache 2.0 and may cause contributors and users to also unknowingly violate the Apache 2.0.
Edit: Does it help if I tell you that more precisely they aren't relicensing the file but merely stacking licenses on the file? The process is purely additive.
[€] https://github.com/minio/minio/blob/master/CONTRIBUTING.md
[¥] https://wikipedia.org/wiki/Contributor_License_Agreement
The GNU project offers a bit of guidance for what counts as "legally significant changes" to them: https://www.gnu.org/prep/maintain/maintain.html#Legally-Sign... They use about 15 lines rather than the GP's 10 lines, but point out there could be context where even many lines of repeated change (renaming a symbol) is not legally significant. My opinion is there's no hard line, like always you need to weigh the risk of getting sued (some contributors might even be unreachable or identifiable) against the cost of reimplementing even things legal counsel says are insignificant (at the end of which you still might get sued anyway and have to prove you did clean-room/changes were insignificant/it's fair use/whatever).
Note, I'm just speculating of course, but I do know changing license is something that does happen and I'm sure Minio is probably looking at getting people to sign off on previous contributions. And if they can't get the contributor's consent, will look at re-implementing things or just not use previous contributions, since it is possible that the previous contribution is no longer used.
IANAL, but simple changes like these likely don't meet the threshold of copyrightablity.
This is only true if there is a CLA, and contributors sign it.
The world does not run exclusively on AWS, Azure and GC.
> "Infringement and damages are unrelated concepts"
No. They're the same concept. Infringement is okay if there are no damages. That's how a lawyer reads a contract. You're merely confusing types of damages. There are many ways to calculate damages. You're describing statutory damages. You usually run the calculation all ways, and take the greatest number which applies (but not always). That's how you might get into hundreds of thousands of dollars of damages for an MP3 collection.
> "unless you're sitting down with a lawyer (which let's face most open source projects are not)"
No, this isn't right. Most major free software projects do have access to lawyers. I've worked on several, and what I did was always reviewed by in-house counsel (and not just one organization). Even if there isn't a corporate sponsor, that's what a lot of the free software / open source not-for-profits do. I've had conversations with volunteer counsels too. Most minor projects generally won't need a sit-down session with a lawyer, but if they want access for whatever reason, it's not rocket science either:
1) Look into your social network. I have 3 or 4 lawyers who went to the same college I did. When I have a legal question, I do call them up. For something as simply as the nonsense you're spouting, any lawyer can set you straight.
2) If you are doing work at a company above a hundred people, it will have an in-house counsel. Shoot them a quick email. Most are friendly; that's what they're there for.
3) If you're not (1) or (2), you probably have someone like me in your network.
4) And if all else fails, you can go to the right meetup.
My experience is that for a volunteer project, open source, or similar, most lawyers are glad to chat.
> "Just read the damn license"
This is just about the worst advice on HN. Your options:
1) Read the license with a lawyer
2) Read the license as well as articles from actual lawyers about the license
3) Learn enough about law to read the license correctly.
You're misreading the licenses, and that's what's dangerous. It's kind of like referring people to WebMD over a doctor.
- IANAL.
- Get a lawyer.
- You probably know a lawyer.
Thank you for adding absolutely nothing to the conversation. The only common theme is that you think you shouldn't interpret a license yourself and act upon that.
What little substance is present in your comments is however in direct contradiction to that. You proceed to interpret a license, and tell people that violating it is fine, because the courts will probably think it's fine.
What? I just really hope anyone reading this can see through the tropes and realise you're in no position to be giving out advice.
The only advice I've given is read the licence, and to the best of your ability, act with accordance with the license. I'm 100% okay with that.
EDIT:
> Look into your social network. I have 3 or 4 lawyers who went to the same college I did. When I have a legal question, I do call them up.
> My experience is that for a volunteer project, open source, or similar, most lawyers are glad to chat.
These claims are highly dubious.
There are several lawyers in my extended family. I went to school with many more. They most certainly are not "glad to chat" about legal matters. Giving out any advice that may be construed as legal advice is a huge deal for them. You either know highly unprofessional lawyers, or you're making this up.
What you can't do is use the minio without adhering to the terms of the AGPL (and Apache 2.0).
> a Linux Foundation project that was founded in 2015 to help advance container technology[1] and align the tech industry around its evolution.
> It was announced alongside Kubernetes 1.0, an open source container cluster manager, which was contributed to the Linux Foundation by Google as a seed technology. Founding members include Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, IBM, Docker, Univa, and VMware
-- https://en.wikipedia.org/wiki/Cloud_Native_Computing_Foundat...
I haven't read the details, or ever seen this policy before (I'm new to both projects) but it was summarized by one of our counterparts at the Linux Foundation here:
https://twitter.com/cra/status/1384859663615864833
Tl;dr: licenses must be approved for use, and the CNCF has this list of allowed licenses, AGPL is not on it. The CNCF is in the business of distributing permissively-licensed software is the short version I guess. I don't understand, I don't work on the legal side, I am a dev and I support end users.
It seems if your Apache 2.0 licensed project needs to modify and distribute as modified an AGPL project, (which for Grafana it seems likely we will need to do at some point, the Linkerd project already has needed to do this if I understood correctly) then you cannot distribute them together, or something about this becomes much more complicated. Chris says they are going to try to work something out, but when a component has made a decision to re-license with a restrictive-copyleft license such as AGPL,
I don't know what there is that can be done to fix it. I hope they come up with something.
Maybe the CNCF adopts AGPL too, (which would mean that then all those "viral-GPL" FUD-spreaders will have been right...) that seems counter-productive if that is the outcome. (So I hope they come up with something else than that!)
Everyone is within their own rights to do whatever they want with the output of their own labor, I just wanted to help dispel the notion that only exploitative companies are affected by this change.
If the "why" rather than the mechanical/legal "what" is what you're after, this is the CNCF position paper on the topic: https://www.cncf.io/blog/2017/02/01/cncf-recommends-aslv2/
> Proponents of copyleft licenses have argued that these licenses prevent companies from exploiting open source projects by building proprietary products on top of them. Instead, we have found that successful projects can help companies’ products be successful and that the resulting profits can be fed back into those projects by having the companies employ many of the key developers, creating a positive feedback loop.
I don't know if that was a typo, but letting users run the software on your computer, isn't 'distribution' in the usual sense. What you said sounds true of the GPL, but doesn't give a complete account of the AGPL.
From the FSF: [0]
> The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
If I write a program that uses a GPL licensed library but never modify that library, it still infects my entire program. I have created a derivative work under copyright law. It doesn't matter that I never modified the original code that I received.
So if my proprietary SaaS web app makes use of an unmodified AGPL licensed library in order to perform a single computation ...
Basically, if you ever need to use agpl stuff, do not embed or add your proprietary ip to a modified version. Use a sidecar. Only embed features you don’t care about.
> If you build a larger web service by combining network services that call each other over HTTP, rather than libraries or snippets of code linked or pasted together, does “Corresponding Source” include the source for those other services? What if each service is containerized, encapsulated in its own operating system? Do those operating systems count as “System Libraries” or “generally available programs” shield the application code they run?
Note that the author is asking a question here. It's not entirely clear (AFAIK, IANAL, etc) what precisely constitutes "linking" when it comes to the (A)GPL.
A thought experiment. Evil Corp takes a GPL licensed program and modifies it to communicate via file descriptors instead of linking with it at compile time and directly calling its functions. They proceed to distribute a separate proprietary product that makes use of the GPL program for many of its core functions. They claim that this isn't a violation of the GPL because they haven't "linked" with any GPL'd code. This is clearly a violation of the spirit of the GPL, but is it a violation of the letter?
That's the spirit of this license and everything is working as intended.
But it's a good line of thought. Here's another thought experiment. When compiling say golang or Rust program, all dependencies end up being compiled into a single standalone binary. If a dependency of a dependency pulls in an unmodified GPL module, what impact does it have on our resulting binary? The common understanding is: if we're asked to share the code of the GPL dependency, we can share the original unmodified dependency and we're not required to share our code using the dependency.
Until we're proven otherwise, we should stick to that common understanding.
Anyone can take an existing Apache 2.0 project and change the license to AGPL 3.0. This does not require the approval of any prior contributor. Of course people can continue using versions released under Apache 2.0 under the terms of that license, but even then "approval of every single contributor" is irrelevant. See https://www.apache.org/licenses/GPL-compatibility.html
The situation where you do need the approval of past contributors is when you want to switch between incompatible licenses. For example, if they had previously released it as AGPL 3.0 and wanted to move to Apache 2.0.
(also not a lawyer)
No, you cannot. The very page you've linked to makes this clear:
> Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works
This is precisely what I've written. You can also apply the AGPLv3, you cannot remove the Apache 2.0. The contributions made under Apache 2.0, are still under Apache 2.0. The Apache 2.0 allows sub-licensing, so any contributor who uses those contributions from now is accepting them under the AGPLv3 and Apache 2.0. The former does not supplant the latter.
If we were to read this like a piece of computer code, the incompatibility would be mutual. GPL code does not permit further restrictions. "You cannot remove Apache 2.0" would be a further restriction. Ergo, you couldn't incorporate.
It's just that this isn't how you read or interpret legal text.
The linked page is correct. You can incorporate/sublicense Apache code into GPL code. You can't do the reverse.
Seems as that's apparently an unreasonable expectation, I'll quote a previous HN comment I've made in regard to Apache 2.0:
> I think this is a common misconception. The Apache 2.0 license isn't all that similar to simpler licenses BSD/MIT/X11.
> Apache 2.0 has some clauses which (most people tend to ignore and which) make it somewhat incompatible with modern open-source fork and pull request workflows.
> In particular 4.b)
> > You must cause any modified files to carry prominent notices stating that You changed the files;
> For the most part, people just throw their name in the file, in an attempt to "meet" this requirement without massacring the file header/notice.
> However, if the Apache 2 license is taken at face value, when you fork and modify a file, you have to mark it as such. Then when you submit back, the project (in adherence with the Apache 2.0 license) has to retain this notice. Technically the project may even then need to add their own notice to indicate they modified the file since you did.
> Clearly, that's not tenable, so most (small) projects just offer leeway. Larger projects instead have contributor agreements (AOSP and alike).
its your responsibility to know that it has changed when you upgrade.
If you don't upgrade literally nothing will change. If you have upgraded and noticed the license change - downgrade. Or just use it anyway, if the value of Minio is worth it.
Please, please stop telling people they can go ahead and do something.
Also, please stop suggesting that reading a license is a bad idea. That's horrible advice. (For readers, see comment below).
We're expected to sign/accept agreements near daily. The very nature of legal agreements is such that they must be written in a fashion that is clear in it's meaning, or else there's ambiguity in its interpretation, which means courts are not going to enforce it.
Of course it's ideal to sit down with a lawyer when doing so. However, it's pathetically idealistic to pretend that every open source project on Github has done just that.
The Apache 2.0 is its own license. There's nothing in the Apache 2.0 license about the GPL.
GPL was written by the GNU Foundation and they have their own interpretation about what licenses are compatible. Seems as that list isn't incorporated in the license itself, they're nothing more than guidelines.
However, let's see what GNU have to say about the Apache 2.0 license (https://www.gnu.org/licenses/license-list.en.html#apache2):
> This is a free software license, compatible with version 3 of the GNU GPL.
> Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses.
Even the GNU Foundation acknowledge that extra requirements of the Apache 2.0 make the license incompatible with the GPLv2. They do however claim it's GPLv3 compatible.
Great, their interpretation is that GPLv3 software can include Apache 2.0 software. Good on them. GNU Foundation (and the Apache Software Foundation) are not involved in the legal agreement made between a contributor and an open source project. Their opinion is irrelevant. The open source project has to adhere to the legal agreements they have made!
Licenses aren't magic, they're the same as every other agreement two parties make. If you want to update the terms of an agreement you've made with someone - you need a new agreement, with all parties involved!
Note that it's not uncommon for EULAs to contain clauses stating they're free to arbitrarily alter the terms, time and time again these clauses have been ruled as invalid.
In this case, by removing the Apache 2.0 license text, and not adhering to the terms of the Apache 2.0, Minio are not adhering to agreement they've made with contributors. It's really that simple. What the GNU Foundation claim is irrelevant, they're not a party involved in that agreement.
I could write a license right now:
> By adhering to this totally legit license, you're also in adherence with all other agreements you've ever made, but like, you don't need to follow their terms anymore, just our terms. Is all good. Don't worry.
That's not how licenses work. It's complete insanity that anyone could possibly think that a third-party has the right to alter the agreement, or interpretation of an agreement you've made with someone else.
Mind you, the GNU Foundation aren't stupid, nowhere do they claim that the GPLv3 can supplant Apache 2.0. They just say they'll permit Apache 2.0 in GPLv3 software. They most certainly do not claim you no longer need to honour the Apache 2.0. That's nonsense.
Stop, just stop it.
EDIT: Just to clarify, here is what the Apache 2.0 license says about incorporating Apache 2.0 licensed software in another project with a different license:
> You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
Note that they specifically permit that, as long as you continue to comply with the conditions of Apache 2.0 license.
> The linked page is correct. You can incorporate/sublicense Apache code into GPL code. You can't do the reverse.
That's not what Minio have done! Have you opened the link?
They deleted the Apache 2.0 license from the entire repo. Removing the Apache 2.0 license is an egregious violation of the Apache 2.0 license's terms.
Fitting decisions like this around the status quo makes no sense. It's exactly actions like this which change the status quo. I'm happy to say there are dozens of organizations without AGPL bans thanks to one useful piece of code I wrote. Most are small, but one is in the tens of billions of dollars in valuation.
Blanket bans of licenses are bad for free software. More pressure to revisit them is a good thing.
Many companies (our included) consider AGPL to be a poison pill. and until someone gets sued and the courts set precedent...
This sounds like a general problem, unrelated to licensing. If you work in companies with shitty policies, you are in for a world of pain.
I don't think this is bad forcing companies to choose between these two (or abandon the software), and they are fully responsible to making lives of people who work there easier.
And if you upgrade and don't notice the change?
In fact, I'd be quite surprised to see any ruling from a country that practices common law mention "re-licensing".
It's simply not a thing. These licenses are agreements you accept in order to be granted rights that you would otherwise not have, due to intellectual property law.
If the license doesn't explicitly grant you the ability to "re-license" (and explain what the heck that actually is), then you can't do it.
The Apache 2.0 does grant you some rights regarding licensing, but re-licensing isn't mentioned, because no such concept exists.
1. Re-licesing the whole project is absolutely a thing. As authors of minio, the project has copyright over the combined work and are free to relicense code as long as they don't violate the Apache 2.0. Seeing that the AGPL does not violate this license. This is exactly what minio has done.
2. Unilaterally changing the license of files contributed under Apache 2.0 is not a thing without permission from the authors of said contributions. This is not what minio has done. If minio has tried to do this, they will be committing copyright infringement.
> 1. Re-licesing the whole project is absolutely a thing.
Again, it's really not. Seriously. I don't like the idea of asking someone else to waste their time over a simple disagreement, however you're publicly providing incorrect advice and it's harmful. Thus, please point me to something, anything with some legal bearing that mentions relicensing.
What you mean is "sublicense". They're free to sublicense.
Why are they free to do this? Because the Apache 2.0 specifically grants this right. That's it. There's no implied right otherwise.
Relicensing presumably means (again, not a thing with any legal meaning) to repeat the process somehow. They can't, they don't have that right, it was never granted to them by the contributors.
Projects do change their license. This is achieved by explicit consent of all contributors. This is frequently impossible (or at least impractical) for open source projects unless the project has a Contributor License Agreement where the IP itself (and all corresponding rights) is assigned, thus permitting the project owners a different license than what they're granting end-users.
Note: Different jurisdictions interpret assigning rights differently. Many jurisdictions state that it's not possible, and the best you can do is grant a license that's effectively similar whilst simultaneously agreeing not to utilise the IP yourself in any way inconsistent with that license.
If you read my original comment, I've explicitly pointed out they can also apply the AGPL. What I've said is they can't remove the Apache 2.0. Which they have!
People need to be able to see that those contributions were made under the Apache 2.0 license, because the best Minio can do is offer those contributions with those same terms. As mentioned above, because the Apache 2.0 allows it, they can sublicense (introduce further restrictions) i.e. simultaneously apply the AGPLv3. However, they cannot ignore the terms of the Apache 2.0.
This is relevant because the Apache 2.0 contains restrictions that simply are not present in the AGPLv3. One such restriction is to not remove the Apache 2.0 license - so Minio aren't off to a great start.
There are other restrictions too, most prominently 4b.
Why am I harping on about 4b? Because quite frankly it's an incredibly stupid clause. However, like it or not, it is a clause and a condition of the Apache 2.0 license. In my eyes, it's such a stupid clause that people should outright stop using the Apache 2.0. However, seems as people tend to not read the license, or just ignore it, then sadly I can't see that happening.
If you do, then we are in complete agreement.
If you do not, do you believe that there are two distinct copyrightable works involved here? (the individual Apache-licensed files and the whole combined work) Or do you believe there is only one single copyrightable work and each contributor has copyright over his part of that work?
Without a CLA in place Minio can't unilaterally "change the license to the AGPL" (your words). What they can do is add the terms of the AGPL to each existing file, in addition to (but not instead of!) the Apache terms that are already there. The end result is AGPL with a few extra but very permissive clauses tacked on.
Going forward, any newly created files need not carry the Apache terms at all (obviously).
The changesets prior to this event remain licensed under _only_ the Apache license. (Well, actually, they could sublicense those too but there'd be no point because you could just get an unmodified copy from someone else.) Future changesets fall under the combined terms of the Apache and AGPL licenses. To be clear, this isn't dual licensing (ie pick one) but rather "all of the above". You simultaneously have to comply with all the terms from both licenses. Which, notably, means you can't remove the Apache notice or list of contributors (among other things).