Change how? What kinds of changes does this help with?
Conversation
The LLVM relicensing comes to mind. That’s still ongoing and is tricky. Some think that’s a positive thing.
Biggest one for me would be changes in laws / application of laws. You can’t plan for those, and contributors literally die eventually so you’d need to replace their work
3
5
How does that actually matter with sufficiently permissive licensing? The LLVM relicensing stuff does not look like anything normal ppl should see as desirable, and if it had been impossible the corporate overlords wouldn't have been able to waste folks' time on it...
2
1
I don't know the whole story, but the original license was permissive and the new license is permissive but many pages long.
2
1
Apache 2 isn't complicated. It's longer because it leaves much less unsaid and open to interpretation. The explicit patent grant from contributors is probably why companies like Google are so fond of it. It's cleaner than having a separate patent grant.
apache.org/licenses/LICEN
1
3
I don't understand why they treated it as something so urgent to the point that code rewrites are needed for permissively licensed code.
AOSP mostly uses Apache 2 but happily imports a lot of BSD/MIT and other permissively licensed code. Why are LLVM's needs so different?
2
1
3
1st: LLVM is a compiler, it embeds some of its code (runtimes) into compiled binary. That's a novel constraint.
2nd: LLVM is used w/ GPLv2 software. Whether or not you agree, some claim ASL2 is incompat.
1st & 2nd para of exceptions address those resp.:
spdx.org/licenses/LLVM-
1
2
We worked our butts off to make those paragraphs *super* short, and minimize diff from Apache2.
2nd is still longer than I'd like, but it was *hard*. Some concerned about incompat, others swear they were already fine. How do you reconcile? That para was *magic* to get agreement.
1
1
I wasn't talking about the LLVM exceptions added to Apache 2 in twitter.com/DanielMicay/st but rather the urgency in moving away from the existing permissive license. I don't think there were compatibility concerns with the existing license. Why is it so crucial to fully replace?
Quote Tweet
Replying to @DanielMicay @RichFelker and 3 others
I don't understand why they treated it as something so urgent to the point that code rewrites are needed for permissively licensed code.
AOSP mostly uses Apache 2 but happily imports a lot of BSD/MIT and other permissively licensed code. Why are LLVM's needs so different?
2
1
I do fully understand wanting most of the code licensed as Apache 2. The part that I struggle to understand is rewriting / replacing the existing permissively licensed code if permission couldn't be obtained to relicense it. It's a lot of effort to avoid an BSD/MIT-style license.
BSD/MIT licenses don't have the nice, clear runtime exceptions.
And we actually had significant issues sharing code between runtimes and other parts of the project. Whole patch series blocked on that nonsense. Getting to a clean baseline fixed.
But we didn't delete code (yet).
2
Just working to get it all relicensed.
Eventually, if there is stuff that we just can't get under the new license, maybe it'll get replaced, but that's the last resort.
Once majority is moved, a big win to finish is license simplicity: exactly *one* license for users.
1
Show replies
Here is a hypothetical example.
Super annoying to re-implement your fav. compression algo that's BSD. So you just import it.
Debug info really benefits from compression, so you use that algo to compress it in the final binary.
All this is fine...
1
... but then you want your runtime profiling library that LLVM automatically decompress these sections to get accurate profiles.
Now you are linking BSD code statically into final binary. User binaries might be fully closed source, they may not want that!
Now you're stuck. =[
2
Show replies