4 ms·

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 ca

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!

deleted 5y ago
[deleted]
yjftsjthsd-h 5y ago
> Incidentally, the Apache 2.0 is a terrible license for modern open source, and it probably shouldn't be used. 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?
- Benjamin_Dobell 5y ago
  Please see the EDIT.
  - yjftsjthsd-h 5y ago
    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.
    - Benjamin_Dobell 5y ago
      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).
      - hda2 5y ago
        And how does this prevent minio from re-licensing their project to AGPL? I still don't see the issue.
        Benjamin_Dobell 5y ago
        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.
papercrane 5y ago
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.
- Benjamin_Dobell 5y ago
  Please see the EDIT.
  - hda2 5y ago
    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).
    - Benjamin_Dobell 5y ago
      Spot on, this is precisely what I've written.
papercrane 5y ago
> 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.
- Benjamin_Dobell 5y ago
  > since the AGPLv3 is a superset 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.
  - deleted 5y ago
    [deleted]
  - robocat 5y ago
    And FYI their contributor documentation[€] doesn't mention anything about using a CLA[¥] which usually would allow an organisation to relicence code contributions. [€] https://github.com/minio/minio/blob/master/CONTRIBUTING.md https://github.com/minio/minio/blob/master/CONTRIBUTING.md [¥] https://wikipedia.org/wiki/Contributor_License_Agreement https://wikipedia.org/wiki/Contributor_License_Agreement
wegs2 5y ago
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.
- Benjamin_Dobell 5y ago
  > A lot of what you said is false. I'm not interested in sea lioning. So I'll just ask for one specific claim that is false.
  - jefftk 5y ago
    "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 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)

deleted 5y ago

[deleted]

yjftsjthsd-h 5y ago

> Incidentally, the Apache 2.0 is a terrible license for modern open source, and it probably shouldn't be used. 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?

Benjamin_Dobell 5y ago
Please see the EDIT.
- yjftsjthsd-h 5y ago
  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.
  - Benjamin_Dobell 5y ago
    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).
    - hda2 5y ago
      And how does this prevent minio from re-licensing their project to AGPL? I still don't see the issue.
      - Benjamin_Dobell 5y ago
        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.

papercrane 5y ago

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.

Benjamin_Dobell 5y ago
Please see the EDIT.
- hda2 5y ago
  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).
  - Benjamin_Dobell 5y ago
    Spot on, this is precisely what I've written.

papercrane 5y ago

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

Benjamin_Dobell 5y ago
> since the AGPLv3 is a superset 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.
- deleted 5y ago
  [deleted]
- robocat 5y ago
  And FYI their contributor documentation[€] doesn't mention anything about using a CLA[¥] which usually would allow an organisation to relicence code contributions. [€] https://github.com/minio/minio/blob/master/CONTRIBUTING.md https://github.com/minio/minio/blob/master/CONTRIBUTING.md [¥] https://wikipedia.org/wiki/Contributor_License_Agreement https://wikipedia.org/wiki/Contributor_License_Agreement

wegs2 5y ago

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.

Benjamin_Dobell 5y ago
> A lot of what you said is false. I'm not interested in sea lioning. So I'll just ask for one specific claim that is false.
- jefftk 5y ago
  "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 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)