I don’t necessarily think AGPL is the best license, but I am very glad it’s AGPL catching on and not SSPL and friends. I’ve spoken my piece in recent threads already, but I just think this is more friendly to the FOSS community even if it’s not perfect.
I don't think AGPL is a perfect license, but I do think it's the best.
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.
Except of course the corporate folks who are licensing under AGPL who can and do then take contributors code and make available a commercial version that no one else is allowed to make available.
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.
> Except of course the corporate folks who are licensing under AGPL who can and do then take contributors code and make available a commercial version that no one else is allowed to make available.
This is only true if there is a CLA, and contributors sign it.
The work around folks use is to claim just new stuff is agpl and skip contribs sign off. After stuff is mixed gets harder to pull apart. AWS just had to go through that exercise with elastic search
It's pretty ironic that the person talking about commenters not contributing to open source responded directly after Drew Devault criticized the sudden nature of the change.
I've seen companies automatically patch software (there was a CI pipeline that would clone upstream, automatically apply a patch file, and ship the result), so it's certainly possible to pull+patch without looking at specific changes, let alone watching for a relicense.
And? What's the point? That companies can be stupid?
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.
The entire CNCF apparently has a no AGPL policy. We just found out this week that we cannot update and redistribute Grafana anymore with our CNCF projects, (or if we do we will be on very shaky legal footing.)
> 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
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:
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.
> 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.
Minio's development culture has a very self-interested feel to it, like it's their thing moreso than the community's thing. Combine that with the corporate pandering it's designed for, and this was a long time coming. Back in February I remarked on IRC "I feel like minio is always one bad day away from changing to some bullshit proprietary license." I'm glad that it's the AGPL and not one of the nonfree fad licenses going around.
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.
Is sublicensing and relicensing the same thing? Sublicensing to AGPL should definitely be OK, but does that mean they can just relicense all contributed code and remove all mentions of Apache2? Seems doubtful to me.
This GNU article [1] explicitly mentions that subsumed licenses still need to be mentioned in the source.
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?
> 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.
Let's say I use Minio in a SaaS app and allow my end users to upload directly to it. With this AGPL license change, is this now considered to be a form of distribution, that would then require me to open source the rest of my SaaS app?
If my layman's reading of the affero license is accurate (ha!), I think it only affects you if you run minio with (your) custom modifications, in which case you would have to make the source of your custom minio fork available. It shouldn't affect the source of other services on your system.
it's unclear what counts as derivative work (which would "infect" your closed source program). I'd say only clarifiable by having case laws or precedents, which currently dont exist yet.
> You only have a problem if you modify anything in the source code of minio that you host.
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.
A lot of companies I've worked for had a blanket ban on AGPL. This is not a problem with the license, it's a problem with those companies. But it's still going to be a pain for the people who work there.
I drove a revisiting like this in more than one organization.
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.
I don't agree it is a problem with the companies. The issue most companies (and their lawyers) have is that this has not (afaik) really been tested in court. So, sure _you_ may state that we should be fine if are are not modifying the code or directly linking, etc, etc, but the interpretation of the license is still _very_ open. Until legal precedent is set, most companies are not willing to take the risk. And why should they?
Many companies (our included) consider AGPL to be a poison pill. and until someone gets sued and the courts set precedent...
Most companies who publish AGPL software also offer a paid commercial license, so it is accept AGPL (and contribute in kind) or pay (and contribute in money).
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.
Based on [1] it sounds like even if you "link" to AGPL licensed code over a network, unmodified or not, it would require you to also license your own code as AGPL? That sounds pretty far reaching, if I'm reading it correctly.
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.
I don't think that essay supports what you said. (It's incredibly well written by the way, thanks for linking it.) Near the end it asks:
> 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?
To comply with the license, the Evil Corp would be required to share their modifications giving anybody who sees this as their market advantage the ability to do exactly the same thus diminishing the advantage. The Evil Corp would not be required to share the code which talks to the modified GPL'd library.
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.
Correct - you would need to open source your entire app (or at least a strong arguement can be made that you must do so).
"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 -
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.
> 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.
> 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.
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.
> this is only relevant when you have modified the copylefted code
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 ...
IANAL, but this may be illegal. I noticed that they have a large number of contributors yet seem to have no contributor agreement with ownership assignment. This generally means that any license change would need the agreement of every past contributor (as it should). There are good reasons (for the primary author(s)) to enforce copyright assignment for contributions.
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.
The AGPLv3 and Apache 2 licenses are compatible. The maintainers are welcome to relicense their own contributions under the AGPLv3 and distribute the whole subject to that license (and the Apache 2 license), but that doesn't magically make contributed source AGPL. Removing the Apache license is suspicious because there are a heap of commits that are still covered by this license and without it the core MinIO devs have no right to use it. This is a full on cluster.
What's more concerning IMO is that despite the fact that I can't find a CLA, their pricing page claims that if you buy their support contract that they'll give you the software under a "Commercial" license: https://min.io/pricing
GPLv3 is compatible with Apache 2.0. This copyright statement should have addendum which indicates that portions of the code (written by contributors) are under the Apache 2.0 license. This could be addressed.
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.
IANAL also, but since Apache is considered compatible with GPL3 and AGPL3, I think they have the ability to, since they can simply relicense their parts of it, and the resulting work is de facto AGPL3 taken as a whole. They might have to drop a 'portions are licensed under the Apache...' blurb somewhere, but the overall idea should be OK.
Would it be possible to simply fork an MIT-style license and relicense the new fork as AGPL? The pre-fork version can continue with its old license, but the new fork is AGPL.
IANAL. The lack of forking isn't the issue here. When someone writes code they (or their company) owns the copyright to it. They then contribute the code to the project using the terms of the project's license. Eg, for GPL, it allows others to modify, build, and run the code. However those modifications must be released to the public under the same license. (skipping over some minor technical details)
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.
You can't just change the license of code contributed by someone else without approval. But you can relicense your own contributions, which - unless that code can be trivially ripped out - would basically have the same effect as placing the whole thing under the AGPL.
You can't really just 'slap a new license on it' AFAIUI. What you can do is fork and license any new derivative work under a new license (which is one-way compatible with the old one). Effectively that means that the fork can only be used under the new license.
I'm not sure it's "illegal"... but according to [0] the Apache license is subsumed by AGPL3, so I think this means they can add AGPL3 code freely and the result still makes sense to lawyers. They may also relicense code fully authored by themselves as AGPL3. Perhaps it may be even possible to relicense contributor code given these specific licenses? I don't know. They can push to that repository, so it's their prerogative to add whatever. Of course, people could use their own forks without these commits, not upgrade, etc.
The rationale for doing this escapes me. Is minio concerned about one or more cloud providers forking minio and then going closed source with their modifications?
I generally only run minio from the official docker image, so I don't reckon this would affect "normal" usage?
> forking minio and then going closed source with their modifications?
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.
Correct, but that misses the point I was making entirely. Running S3/Elastic/API-X wherever you'd like is a separate issue to the kind of problem that Elastic faced with AWS. AWS soaked up a huge amount of Elastic's potential market, because they are so big and entrenched. Only AWS, Azure, and GCP are big enough to do that - and I don't see anyone "stealing" a reasonable degree of S3 customers from AWS by using Minio (let alone any business model that Minio might be exploring).
> I noticed that they have a large number of contributors yet seem to have no contributor agreement with ownership assignment.
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:
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.
How does “reimplement contributions” work in practice? For trivial changes there’s often no alternate implementation (e.g. correcting a typo) and for anything substantial anybody currently involved in the project would be tainted with exposure to the implementation.
I would expect that in the limit it would follow clean-room design (see https://en.wikipedia.org/wiki/Clean_room_design) -- you only have to do enough to prove to a court that you or someone you got to rewrite something according to your spec weren't sufficiently tainted by the original code to rise to copyright infringement (even if the result is bitwise identical due to primarily one obvious way to do it).
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).
I honestly don't know, but I would have to imagine something like fixing typos would fall under "this is obvious" and you can't claim copyright on it. And likewise, if your algorithm that you contributed was obvious, it would fall under the same rule.
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.
I suppose we'll see a fork this weekend if they don't come to their senses, because it very much appears like there was no discussion about relicensing, nor is there a CLA
An interesting side point is that the founder of Minio was also the founder of Gluster, which was also briefly AGPL (just before the Red Hat acquisition IIRC). I think it makes even more sense for Minio, as an install is more likely to be made directly accessible to users. AFAIK nobody ever did that with Gluster - I used to be a maintainer BTW, and thus know a bunch of people who followed AB to Minio - because it would have been insane.
Is there a CLA or similar? Maybe I missed it, but I couldn't find anything in the CONTRIBUTING.md document. Or did they literally get every past contributor to agree?
Probably not necessary if they stack the licenses, since Apache 2.0 and AGPL are apparently compatible. That is, they can just add the terms of the AGPL in addition to Apache 2.0.
Remember, AGPL does not stop you from self-hosting or running a business on the software! It only requires you to share changes if you modify the software, which is a very reasonable requirement.
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).
True, but who's going to sue you? Developers? More likely the EFF, but they can't go after everyone. Legal recourse is increasingly becoming only possible for the most motivated or well endowed participants.
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.
Could you please stop posting unsubstantive and/or flamebait comments to HN? You've done it repeatedly, and we ban that sort of account, as we are trying for something different here.
Not sure about what he means, but I've written this https://medium.com/@henvic/opensource-and-go-what-license-f6... in the past mostly about the impact of permissive vs. non-permissive licenses on Go code (because Go programs are statically linked; not sure about Rust).
AGPL is a “weak” copyleft license, not strong. It basically means not all derivatives need to be open sourced. If you modify AGPL code but never distribute it or provide it as a service over a network to users, you don’t have to provide source.
No free or open source license requires private modifications to be shared. Doing so would violate your privacy, and goes against the 'you can use this software for any purpose' requirement.
> or [never] provide it as a service over a network to users, you don’t have to provide source.
Hell, AGPL is one of the few licenses that does require you to share modifications, if you provide it as a network service. Again: strong copyleft.
- 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.
relicense the file based on a small change and also having two licenses on the same file?
I'm not so sure, if the go authors are happy about that.
Looks like the original is under a permissive ("BSD-style") license, in which case they almost certainly can distribute it under any license they want.
They can distribute it, but this looks like it's changing the license. I thought that only the owner can change the license of the copyrighted file?
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.
(IANAL) BSD-style licenses generally only require that the file and its derivatives retain the original authors copyright notice. Distributing it under a different license still allows you to fill the original requirements, so there's no conflict there. Or from a different angle, what exactly is the difference between including a BSD file in a GPL file vs including a BSD file in an empty file and then licensing the result as GPL?
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.
When people say BSD-style licenses are "more permissive" than GPL - this is what they mean. You truly can do whatever you want, as long as you observe the license requirements (i.e. retain the BSD license notice). One can close-source a fork (but keep the notice), or add an additional compatible license like the GPL or AGPL (but keep the BSD notice), or add a license that bars use by cat-lovers (but keep the BSD notice).
> 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.
Why are most software engineers so terrible at basic comprehension? Licenses are just a set of instructions, how do we consistently fail to follow them?
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!
IANAL, but you're obviously not one either. A lot of what you said is false.
You don't read legal text like a piece of code. Contracts and licenses don't work like that. It took me a long time to wrap my head around this.
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.
"You can't relicense something that is Apache 2.0 as AGPL. You need explicit approval of every single contributor" is false.
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.
> Anyone can take an existing Apache 2.0 project and change the license to AGPL 3.0.
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.
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.
> 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.
On the topic of software engineers exhibiting poor comprehension...
> 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.
Most of this is nonsense, but I'll point out a few things:
> "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.
Stop intertwining complete nonsense with tropes in order to try add credibility to your outrageous claims.
- 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.
I'm not seeing an obvious license issue here. Apache 2.0 is GPLv3 compatible (but not V2 compatible.) Both Apache and the FSF agree on that, and the AGPLv3 is compatible with GPLv3. So I don't see why they'd need explicit approval to use the AGPLv3 going forward.
I read your edits and still don't see a problem. You can still "pluck" out Apache code from minio and use that under that license. The license for Apache code hasn't changed.
What you can't do is use the minio without adhering to the terms of the AGPL (and Apache 2.0).
As of 2021-04-24T00:14:57Z, your edits don't appear to answer what problems you have with Apache 2.0? You've only said that people should read it and talked about its interactions with AGPL.
I asked people to read the license, it's all explained in the license. There's no ambiguity, it's really clear cut.
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).
Because "re-licensing" isn't a thing. If you (or anyone else) can point me to a single piece of legislation in any jurisdiction that has a concept of "re-licensing" I'll be very surprised.
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.
Now I'm just confused. Do you believe it is okay for minio to unilaterally - and without prior permission from contributors - change the license of their project to the AGPL while also preserving the license of thirdparty Apache-licensed contributions?
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?
He gets an F for effective communication from me, but he's technically correct by my reading. They can sublicense (which creates a weird franken-license) but they can't (unilaterally) relicense.
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).
> In fact, one requirement is the very fact you can't remove the license text itself
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.
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.
And FYI their contributor documentation[€] doesn't mention anything about using a CLA[¥] which usually would allow an organisation to relicence code contributions.
