5 ms·
Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or s
by OmarAssadi 3y ago
Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code?
I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind.
Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love.
For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own.
Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar.
I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software.
I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers.
Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar.
EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc.
[1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it.
[2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.
- zigzag312 3y agoTo me, CDDL/MPL 2.0-style licenses are much more sane than GPL based ones. The definition of what is a derivative work is IMHO overreaching in GPL based licenses.
- gumby 3y ago> The definition of what is a derivative work is IMHO overreaching in GPL based licenses. GPL doesn’t use the word “derive” and specifies modified work in a way that is consistent with the customary legal definition. People twist things around because they want to use GPLed code without “paying” for it, but really at the end of the day it’s just an ordinary license agreement but instead of paying cash to use it you agree to give users the freedom to modify and/or redistribute the code. Just like any other licensed code you can agree to the terms and use the code or disagree with the terms and use something else.
- zigzag312 3y agoIt doesn't really matter where exactly it is defined. There's effective definition of derivative works in place for GPL, even though it's definition is inherited. > People twist things around because they want to use GPLed code without “paying” for it, but really at the end of the day it’s just an ordinary license agreement but instead of paying cash to use it you agree to give users the freedom to modify and/or redistribute the code. You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange. Source of confusion probably comes from overuse of the word "free" by people promoting GPL, which is like you said, just an ordinary license agreement.
- aleph_minus_one 3y ago> You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange. It's not that simple. If it was just about "my" code, this would indeed your claimed barter exchange. But often, say in industry, the code that you develop is combined with a lot of third party code and libraries for which you simply do not have the permission to put them under GPL.