5 ms·
Are these new changes with LGPL 2.1? I don’t remember it containing the modification and relinking restrictions in the past. It kind of defeats the purpose of
by hedora 3y ago
Are these new changes with LGPL 2.1? I don’t remember it containing the modification and relinking restrictions in the past. It kind of defeats the purpose of the LGPL IMO.
As an aside, it really bugs me that the GPL morphed into this thing that gives developers the freedom to run privacy violating and user-abusing cloud services, but doesn’t allow manufacturers to ship the same stuff on physical (and perhaps offline) hardware the end users have physical control over.
When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time.
Anyway, I guess the above restriction means I won’t be using LGPL for stuff I write at work, even though most of what we do gets open sourced anyway.
- mort96 3y agoHuh? The whole point of the LGPL is to say, "you can use the LGPL'd code in your closed-source product, but the user must be able to replace the LGPL part of your product with their own version". The way to achieve that is to either use some kind of dynamic linking where the user can provide their own .so/.dll/.dylib of the LGPL'd library, or to provide the object files so that the user can statically re-link the application with their own version of the LGPL'd library. This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version. What purpose of the LGPL is defeated?
- hedora 3y agoI thought the purpose of the LGPL was that it could be used for libraries without tainting the stuff the library is linked against with viral GPL restrictions. Concretely, using gcc with default settings will bring in glibc and compiler intrinsic code snippets which were both LGPL last time I checked. If I use GCC to compile and statically link closed source code that I have a redistribution without modification license for, then I can’t redistribute my binary without violating my license for the closed source code. Ouch! MUSL + clang it is, I guess. (I value my users’ right to own and operate computers even higher than their right to recompile code, so I’d rather not restrict my lgpl tainted binaries so they can only run in the cloud).
- rescbr 3y agoIIRC, GCC specifically uses GPL + runtime license exception to avoid this scenario
- mort96 3y agoglibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library. However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time. The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL. I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.
- hedora 3y agoIf you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build. All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.
- mort96 3y agoYeah, the embedded Linux context is messy. I don't know how the rules play out there (and I would be surprised if anyone truly knows). I thought we were talking about the general computing device use case. Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.
- gorkish 3y ago> What purpose of the LGPL is defeated? The purpose of /which/ LGPL? And that's the thing. After GPL demonstrated that it had teeth and got some case law underneath it, the "family" of derivatives exploded, each one of them identifying as "open source" but each with their own additions, removals, modifications or other opinions on what "freedoms" they convey (mostly removals). There are those of us out here who believe that the core purpose of all of these licenses were defeated a long time ago when all of this legal swizzling first began. I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.
- mort96 3y ago> The purpose of /which/ LGPL Either 2.1 or 3.0 I guess, the difference between the versions isn't that relevant to hedora's question. The GPL exists to protect users against companies which develop proprietary software. If you prioritize the freedom of companies to restrict users over the freedom of those users, it makes sense that you'd dislike the GPL style licenses.
- freedomben 3y ago> I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined. Why do you hate them so much? Is it strictly as a developer, or as a user? As a developer I've certainly felt constrained and annoyed by them at times, and I'm very glad there are alternative open source licenses available, but as a user I can't imagine a scenario where you would hate them. After all, the freedom they guarantee is to the user, not the developer. Even as a developer though, the family has it's place. I don't think Linux would be a thing had it had a more "permissive" license. That GPL is what forces the big corps to contribute their improvements back. If not for the GPL, I think it would be in a position similar to that of BSD, and the majority of users would have no choice but to use a proprietary OS
- bombcar 3y agoNotice the lack of "GPL" in that list, and I'm partially in agreement. The GPL is amazing and wonderful, but the various "attachments" of the GPL are more weaponized (and to the detriment of users!) than the GPL ever was. I'm glad the kernel stuck with GPLv2, and I wish other things had, too. A GPLv3 Linux Kernel would likely have helped a BSD tremendously, though but I think having everyone work on the same kernel without reservations has been an unmitigated good.
- kmeisthax 3y ago> When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time. They tried that, everyone balked. You know how Linus Torvalds rejected GPLv3 for Linux specifically because anti-TiVo[0] would be "changing the deal"? Imagine that times a thousand. Furthermore, AGPL is only an anti-Google license specifically because Google is as internally afraid of it as Microsoft is of GPL. You can defeat the Affero clause by putting the software behind a proxy, for example. Furthermore, the Affero clause is only appropriate for web applications - ideally ones in dynamic languages that execute from source that remains on disk. Slapping it on all GPL software would be really, really dangerous. I've heard of people using AGPL on Ethernet PHYs - how the fuck do you offer source code to every packet that crosses an Ethernet switch? If you really want a license clause that would absolutely decimate any corporate freeloading behavior, you want OpenWatcom's anti-private-forks clause[1]. It does everything AGPL tries to do, with fewer legal loopholes. But good luck getting that past RMS. The problem with supra-GPL copylefts is that anything that is legally watertight to a corporation is also going to impinge on a lot of freedoms we enjoy. Remember: the whole point of the GPL is to reject copyright, and that specifically means lots of corporate freeloading, because the whole point of copyright is to stop corporate freeloading. [0] From what I've heard, the anti-TiVo clause in GPLv3 is actually less strict than the FSF advertised, at least relative to how TiVo used Linux. I can't find the original article I heard this in, though! [1] Specifically, the OpenWatcom license requires distribution of source code whenever you use a modified version of the software.
- freedomben 3y agoI mostly agree with you, with one exception: > Remember: the whole point of the GPL is to reject copyright, and that specifically means lots of corporate freeloading, because the whole point of copyright is to stop corporate freeloading I don't think this is true. My understanding (which could be flawed) is that the whole point of the GPL is to weaponize copyright in order to guarantee freedoms, not to reject it (a subtle but important distinction). Also the whole point of copyright doesn't seem to be to stop corporate freeloading, though that is of course part of it. It's point is to ensure that the original creator has rights to benefit from the work, whether that means getting stolen from by a huge corporation or stolen from by teenagers passing memes over the internet, or adapted by an individual/sole proprietor as part of some larger work, etc. My guess is we probably agree on this part and the debate is probably over semantics (i.e. you might have meant "business in general" by "corporate" rather than specific corporations).