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.
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.
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.
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.
(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.
> - 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.
- 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!
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.