Live data from Hacker News

LLVM relicensing update and call for help

blog.llvm.org

21–30 of 198 posts

Re: LLVM relicensing update and call for help

#21
post #15

Earlier quoted context omitted.

Is the distinction here really germane? If someone else holds an exclusive, transferrable, perpetual, sublicensable license to a work you produced, that's more or less the same as holding the copyright from LLVM's perspective. Of course all this only matters if they encounter a situation where it is difficult to determine the rightsholder, and they are not able to obtain agreement from all potential holders, and ther…

In such jurisdiction, copyright attributions/assignments are simply not legally possible. We've had to scrap the one in place for on of our projects. The type of contract you should have contributors from such jurisdictions sign is a license to use. If you haven't, getting 'permission' is meaningless; the author possibly (in my experience: probably) doesn't know they're actually not legally able to agree to such a ch…

I imagine if this ever comes to bite projects in a big way, they'll move to the legal agreement of the type you suggest, and/or cease accepting contributions from the relevant jurisdictions.

That being said, LLVM is not asking for a copyright contribution here. They are asking the contributors to sign an agreement, the meat of which is, "The Contributor authorizes LLVM to include the Contributions in the LLVM project, and the Contributor hereby licenses the Contributions under the terms of the Apache Software License, version 2.0, with the LLVM exception." That's not a copyright assignment.

Other groups also do not ask for a copyright assignment. Here's from Google's CLA: "Subject to the terms and conditions of this Agreement, You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works." In this agreement, you still own the copyright, but you've given Google a perpetual, worldwide, royalty free and sublicensable license, which means that Google could basically reexport your contributions under whatever license they want. Facebook/Meta's CLA is almost identical. They aren't excluding any countries from contributing, so presumably this type of language is sufficiently enforceable everywhere.

Re: LLVM relicensing update and call for help

#22
post #15

Earlier quoted context omitted.

Is the distinction here really germane? If someone else holds an exclusive, transferrable, perpetual, sublicensable license to a work you produced, that's more or less the same as holding the copyright from LLVM's perspective. Of course all this only matters if they encounter a situation where it is difficult to determine the rightsholder, and they are not able to obtain agreement from all potential holders, and ther…

In such jurisdiction, copyright attributions/assignments are simply not legally possible. We've had to scrap the one in place for on of our projects. The type of contract you should have contributors from such jurisdictions sign is a license to use. If you haven't, getting 'permission' is meaningless; the author possibly (in my experience: probably) doesn't know they're actually not legally able to agree to such a ch…

But if you grant a license that's sublicensable and exclusive (with all the extra legal rights granted), that's effectively transferring copyright since you can do everything you could as if you had transferred copyright.

Re: LLVM relicensing update and call for help

#23
post #17

Once again the FSF is shown to be prescient. Their copyright assignment policy completely eliminates this problem.

It eliminates this problem by creating another one. That you need to jump through a couple of hoops before you contribute.

It is arguable which method is better.

Re: LLVM relicensing update and call for help

#24
post #6

why not gpl it D:

Because that would make llvm a lot less useful and a lot more restrictive on the kind of places the compiler infrastructure could be used in. LLVM would not easily be able to be used in places like mesa if it were under the GPL, for example.

Re: LLVM relicensing update and call for help

#25
post #16

>m8r-9yw8a5@mailinator.com "/dev/humancontroller" That one should be fun. An anonymous mail account service.

Looking at the spreadsheet, it looks like his only commit is one that changes a bunch of %lu to %zu? I think that's trivial enough that it's not copyrightable.

Re: LLVM relicensing update and call for help

#26
I opened the spreadsheet, and now I can't remove it from my list of Google Sheets (unlike most shared spreadsheets). Am I missing some obscure way to remove it, despite the Remove option being grayed out? (It does respect the "Owned by me" filter so this isn't the end of the world.)

Re: LLVM relicensing update and call for help

#27
This kind of thing feels like such a waste of humanity's time. Is there an approach you can choose early in a project on that prevents ever getting in trouble later?

I guess if I start some big library I will hope that everyone assigns the copyright for their contributions entirely to the project so that I never have to go through that nonsense. But I guess that has other ramifications.

Re: LLVM relicensing update and call for help

#28
post #27

This kind of thing feels like such a waste of humanity's time. Is there an approach you can choose early in a project on that prevents ever getting in trouble later? I guess if I start some big library I will hope that everyone assigns the copyright for their contributions entirely to the project so that I never have to go through that nonsense. But I guess that has other ramifications.

> 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 conditions. Works for lots of projects.

4. Force contributors to assign copyright to an entity that people will trust forever. Ostensibly works for FSF folks, academia, etc.

5. Don't worry about it. Let others pay for lawyers doing law stuff. You can delay making the decision until you have at least a dozen of actual contributors.

Re: LLVM relicensing update and call for help

#29
post #15

Earlier quoted context omitted.

In such jurisdiction, copyright attributions/assignments are simply not legally possible. We've had to scrap the one in place for on of our projects. The type of contract you should have contributors from such jurisdictions sign is a license to use. If you haven't, getting 'permission' is meaningless; the author possibly (in my experience: probably) doesn't know they're actually not legally able to agree to such a ch…

But if you grant a license that's sublicensable and exclusive (with all the extra legal rights granted), that's effectively transferring copyright since you can do everything you could as if you had transferred copyright.

However, in most jurisdictions where copyright is non-transferable, the original holder also permanently retains a right to cancel any such licensing agreement, at any time without cause. They cannot grant a license in perpetuity, and any language in the license to that effect has no legal weight whatsoever.
Post reply on HN