Hacker News new | ask | show | jobs
by Benjamin_Dobell 1889 days ago
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!

4 comments

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.

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

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

(also not a lawyer)

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

You're reading it wrong.

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.

You really don't seem to understand this at all.

Please, please stop telling people they can go ahead and do something.

Also, please stop suggesting that reading a license is a bad idea. That's horrible advice. (For readers, see comment below).

We're expected to sign/accept agreements near daily. The very nature of legal agreements is such that they must be written in a fashion that is clear in it's meaning, or else there's ambiguity in its interpretation, which means courts are not going to enforce it.

Of course it's ideal to sit down with a lawyer when doing so. However, it's pathetically idealistic to pretend that every open source project on Github has done just that.

The Apache 2.0 is its own license. There's nothing in the Apache 2.0 license about the GPL.

GPL was written by the GNU Foundation and they have their own interpretation about what licenses are compatible. Seems as that list isn't incorporated in the license itself, they're nothing more than guidelines.

However, let's see what GNU have to say about the Apache 2.0 license (https://www.gnu.org/licenses/license-list.en.html#apache2):

> This is a free software license, compatible with version 3 of the GNU GPL.

> Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses.

Even the GNU Foundation acknowledge that extra requirements of the Apache 2.0 make the license incompatible with the GPLv2. They do however claim it's GPLv3 compatible.

Great, their interpretation is that GPLv3 software can include Apache 2.0 software. Good on them. GNU Foundation (and the Apache Software Foundation) are not involved in the legal agreement made between a contributor and an open source project. Their opinion is irrelevant. The open source project has to adhere to the legal agreements they have made!

Licenses aren't magic, they're the same as every other agreement two parties make. If you want to update the terms of an agreement you've made with someone - you need a new agreement, with all parties involved!

Note that it's not uncommon for EULAs to contain clauses stating they're free to arbitrarily alter the terms, time and time again these clauses have been ruled as invalid.

In this case, by removing the Apache 2.0 license text, and not adhering to the terms of the Apache 2.0, Minio are not adhering to agreement they've made with contributors. It's really that simple. What the GNU Foundation claim is irrelevant, they're not a party involved in that agreement.

I could write a license right now:

> By adhering to this totally legit license, you're also in adherence with all other agreements you've ever made, but like, you don't need to follow their terms anymore, just our terms. Is all good. Don't worry.

That's not how licenses work. It's complete insanity that anyone could possibly think that a third-party has the right to alter the agreement, or interpretation of an agreement you've made with someone else.

Mind you, the GNU Foundation aren't stupid, nowhere do they claim that the GPLv3 can supplant Apache 2.0. They just say they'll permit Apache 2.0 in GPLv3 software. They most certainly do not claim you no longer need to honour the Apache 2.0. That's nonsense.

Stop, just stop it.

EDIT: Just to clarify, here is what the Apache 2.0 license says about incorporating Apache 2.0 licensed software in another project with a different license:

> You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

Note that they specifically permit that, as long as you continue to comply with the conditions of Apache 2.0 license.

> The linked page is correct. You can incorporate/sublicense Apache code into GPL code. You can't do the reverse.

That's not what Minio have done! Have you opened the link?

They deleted the Apache 2.0 license from the entire repo. Removing the Apache 2.0 license is an egregious violation of the Apache 2.0 license's terms.

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.
Please see the EDIT.
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).

Spot on, this is precisely what I've written.
> 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?

Please see the EDIT.
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).

And how does this prevent minio from re-licensing their project to AGPL? I still don't see the issue.
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.

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

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

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://wikipedia.org/wiki/Contributor_License_Agreement