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?
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).