Live data from Hacker News

LLVM relicensing update and call for help

blog.llvm.org

151–160 of 198 posts

Re: LLVM relicensing update and call for help

#151

Earlier quoted context omitted.

LLVM likely doesn't want to take the risk that a court could find it copyrightable if the author decides to file a lawsuit. My guess is that regardless of the triviality of the change they're requiring these agreements. I am not a lawyer.

It is an anonymous e mail address, there is no way for anyone can actually prove that they are the contributer. not a lawyer, obviously

I think that, depending on circumstances, it _can_ be trivial to prove in court. Examples:

- If the contributor can prove they checked that specific mailbox during the period involved (for example from logs, or because the git repo of their system config shows they ran a cron script checking it)

- If the contributor can have a few others state in court that they received other messages sent from that account around the time that must have come from them.

- if the contributor mailed a few friends saying they contributed to LLVM, giving some details of the changes.

I would expect courts to accept either as enough evidence.

Re: LLVM relicensing update and call for help

#152
post #52

Earlier quoted context omitted.

Why do you call copyleft "tyranny"? If overnight, every single piece of open source software were somehow magically relicensed to AGPLv3 only, would there be any negative consequences at all for anyone besides people who wanted to write non-free software?

> besides people who wanted to write non-free software? Would there be any negative consequences besides the negative consequences? No, I guess not. Lots of people want to write non-free software, for instance for their jobs or businesses or hobbies.

But users can do even less with non-free software than they can with copyleft software, so calling the latter "tyranny" while simultaneously being okay with the former makes no sense at all.

Re: LLVM relicensing update and call for help

#153
post #134

FWIW, going with Apache 2.0 is/was a mistake. There is a clause in the license which implies that almost everybody who uses GitHub/GitLab/etc. to work on an Apache 2.0 project in the common workflows is in breech of the license. Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice. Unfortunately the license is s…

Yeah it's horrible how Apache 2.0 has become an industry standard with this clause in place. I think this industry standard status was the main reason why LLVM has chosen it.

If the corporate lawyers all agree it’s a standard and they don’t care about that clause then going with the license that the lawyers are all comfortable with seems like absolutely the right choice.

Re: LLVM relicensing update and call for help

#154
post #28

Earlier quoted context omitted.

> Is there an approach you can choose early in a project on that prevents ever getting in trouble later? 1. Never accept outside contributions in principle. Works fine for SQLite, for example. 2. Pick a well-known copyleft license and just stick with it. Works fine for Linux, for example. 3. Use a well-known permissive license that allows redistribution of modified code under a different license without burdensome co…

There is also 6. Have a CLA (contributor license agreement) that lets the project the right to change the licence. (Different from 4. because there is no copyright transfer).

CLAs are shaky, it might not be valid in some countries that e.g. do not allow reassigning copyright.

Re: LLVM relicensing update and call for help

#155

FWIW, going with Apache 2.0 is/was a mistake. There is a clause in the license which implies that almost everybody who uses GitHub/GitLab/etc. to work on an Apache 2.0 project in the common workflows is in breech of the license. Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice. Unfortunately the license is s…

While I agree the license is badly written, I think you can construct an argument that the common workflows do not violate the license:

- 4.b says, "You must cause any modified files to carry prominent notices stating that You changed the files." When you modify the file using Git (etc.), the file is stored in the Git database in such a way that it can only be accessed indirectly, by going through an object (a commit) whose entire purpose is to be a record and notice of your modification. That seems pretty prominent.

- 4.c obligates a redistributor like GitHub (etc.) to "retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work." But the prominent notice was never in the Source form of the Work, it was in the Git metadata.

Consider the analogy to the patch-based workflow: if you email a patch to a mailing list, you satisfy 4.b because the email itself serves as a prominent notice, but 4.c would not obligate the maintainer receiving the email to add the information in the email (such as the From: header) to the Source form. They could just apply the patch as given.

This is a somewhat strained reading, to be fair, and it'd be nice to standardize a fewer-clause version of the Apache license à la the fewer-clause versions of the BSDs. It seems to me that the Apache license minus 4.b, 4.c, and 4.d would clearly be a FOSS license by any standard that accepts the existing Apache license.

Re: LLVM relicensing update and call for help

#156
post #134

Earlier quoted context omitted.

Yeah it's horrible how Apache 2.0 has become an industry standard with this clause in place. I think this industry standard status was the main reason why LLVM has chosen it.

If the corporate lawyers all agree it’s a standard and they don’t care about that clause then going with the license that the lawyers are all comfortable with seems like absolutely the right choice.

Very likely.

But someday, some lawyer may litigate. Woe betide us all.

Re: LLVM relicensing update and call for help

#157
It wasn't clear to me that "the list of remaining individuals and corporations we need to get agreements from" in "Call for help" was a link since it's not underlined and styled with exactly the same color, font, and font size as normal text. The link points to https://docs.google.com/spreadsheets/d/18_0Hog_eSwES8lKwf7WJ... If you know anyone on that list, consider reaching out to them with a link to this blog post.

Re: LLVM relicensing update and call for help

#158
post #135

What happens if one of the contributors has died? I think it’s highly unlikely you’re going to get agreements from even the majority of the long tail, so moving towards the “end-game” before 2023 might be prudent.

Copyright gets passed on to their heirs.

Re: LLVM relicensing update and call for help

#159

Earlier quoted context omitted.

The number of people who refuse to commit to MIT/BSD/etc. code is almost not existing, the number of people who refuse or cannot commit to GPL is plentiful. > It makes me sad to see so much confusion, incorrect information, naiveté and paranoia going around regarding the GPL I agree, there are still too many people who think the GPL is _just_ another license. It's not and many figured this out the hard way after they…

Not being able to relicense code provided by other people without their agreement is definitely a feature of any license. Let’s not kid ourself: the main reason companies don’t like the GPL is because they don’t want to share the code they actually use in their products. Making that impossible is an intended consequence of the license not some unforeseen flaw. If you are fine with companies profiteering from your wor…

The biggest risk of the GPL is in fact not companies but to you as a creator. If you plan on commercializing your work in any capacity, accepting contributions under the GPL will be the end of that. Given the murky laws around copyright reassignment getting contributions in under a more liberal license so you retain extra rights yourself is tricky.

There are many projects which learned after a few years that their choice of license backfired on them.

Re: LLVM relicensing update and call for help

#160

Earlier quoted context omitted.

I have yet to see BSD / MIT meaningfully improving my personal life, quite unlike the GPL which pretty much made my career possible thanks to the wealth of GPL software under Linux

Have you ever used software linked against OpenSSL? It’s licensed under APL, which is very similar to the BSD family of license - it allows use in closed source projects. Or OpenSSH - it’s developed by the OpenBSD folks and licensed under a BSD style license. Or Firefox - licensed under MPL, very similar to APL. The rust compiler is dual-licensed under MIT/APL. Both ruby and python are dual-licensed with at least one…

> Have you ever used software linked against OpenSSL? It’s licensed under APL, which is very similar to the BSD family of license - it allows use in closed source projects.

well, if I could I'd definitely choose gnutls over it even before getting to licensing issues tbh. Also how much better did it being useable in closed-source projects (those I don't use unless there's really no other viable choice and doing it myself is not an option) make it ?

> Or OpenSSH - it’s developed by the OpenBSD folks and licensed under a BSD style license.

yes, though I'm not sure if I'm using any openssh-specific interface, ssh -X maybe ?

> Or Firefox - licensed under MPL, very similar to APL.

MPL is closer to GPL in spirit than MIT/BSD, no ? AFAIK you can't make a closed-source derivative of Firefox (which is what matters).

> The rust compiler is dual-licensed under MIT/APL.

I don't use it. The only Rust software I'm using is ripgrep I believe ?

> Both ruby and python are dual-licensed with at least one license from the BSD/MIT group, the python license itself is similar to BSD as well

I don't use either neither as a developer or a user, the huge majority of my direct interaction with my computer is through C or C++ software; mainly KDE stuff.

But all of this is besides my point - if there wasn't a big ecosystem of (L)GPL software existing when I was a teen (Linux, KDE, core/binutils, GCC etc) I'm not sure I could have taught myself enough computing to achieve what I seek to. If everything was BSD I doubt these software would have evolved into something good enough to make for a correct desktop experience (last time I tried a BSD it was deeefinitely not useable enough for me unless replacing most of the BSD base with the GNU one like I do on my mac machines for instance). I've also used proprietary software for instance, but I would not say they made my life "meaningfully better".

Post reply on HN