3 ms·

I have an incredibly oversimplified way of thinking about things that I'm wondering if somebody can poke holes in: GPL is for applications (ie. complete produc

I have an incredibly oversimplified way of thinking about things that I'm wondering if somebody can poke holes in: GPL is for applications (ie. complete products), BSD/MIT-alike are for libraries (ie. standalone components used to build complete products.) Most of the language in the GPL is incredibly problematic for library use. What does linking really mean? Is a "derived work" of a library anything that uses the library? Or is it a derived work only if I change the library itself and not release the patch? Ok, so there's the LGPL to disambiguate that... so for the common case of libraries, use the LGPL, got it. But wait, that doesn't really make sense. What is the LGPL guarding against that make it any better than MIT/BSD? Are they thinking corporations are going to do something like patch GTK and not release the patch? That's incredibly unlikely. It's a huge burden to maintain a downstream patch of a library. Moreover, any patch you're likely to make to a library like (for instance) GTK is probably general purpose, and would be an abstraction violation to place any of your business logic in it, right? If I'm a library writer, what is the motivation to use LGPL or GPL? LGPL doesn't seem much more protective than MIT/BSD in this case, except it prevents the contrived scenario of someone wanting to create proprietary patches to the library itself. And GPL only makes sense if I want to ensure nothing other than other GPL software can link against it (maybe useful for dual licensing like Qt? Or libraries that want to only exist in linux distros...) Now on the application side, all the language in the GPL starts to make a lot more sense. Linking doesn't really make sense for complete applications like web browsers and photo editors, so it's ok that it's ambiguous (nobody's likely to link to the GIMP.) The GPL seems to be written with the assumption that a derived work would look like a re-distribution of some existing open source product with some proprietary changes, which is certainly evil. Generally it's a really good idea to use GPL here to prevent that. For complete products like applications, it's hard to imagine why you wouldn't want those protections if you're the copyright holder. You could go even farther with the logic by saying the only real point of using GPL for libraries would be to help cause more proliferation of GPL'd applications, which is what the vision of the GPL seems to be aimed towards: protecting the user by ensuring they can see the code behind the applications they run.

wolfgke 10y ago
>But wait, that doesn't really make sense. What is the LGPL guarding against that make it any better than MIT/BSD? With LGPL you can replace the shared library by a version that you built/updated/... (thus gives freedom) which is not possible for MIT/BSD libraries.
- _ph_ 10y ago
  Of course you can do the same with MIT/BSD libraries. Nothing in those licenses prevents that. To be fair, in contrast to the LGPL, the BSD/MIT licenses do not explicitly require the ability, this does not remove it. And whether an user is actually able to rebuild and replace a LGPL library in practice is another question.
loup-vaillant 10y ago
As a library writer, the most important question is very simple: do you want to allow others to distribute proprietary applications build with your library? Answering this question may be very difficult, but once you do, the choice is simple: If you want to allow, you probably want a permissive licence. If not, you probably want a copyleft licence (I'd suggest GPLv3).

wolfgke 10y ago

>But wait, that doesn't really make sense. What is the LGPL guarding against that make it any better than MIT/BSD? With LGPL you can replace the shared library by a version that you built/updated/... (thus gives freedom) which is not possible for MIT/BSD libraries.

_ph_ 10y ago
Of course you can do the same with MIT/BSD libraries. Nothing in those licenses prevents that. To be fair, in contrast to the LGPL, the BSD/MIT licenses do not explicitly require the ability, this does not remove it. And whether an user is actually able to rebuild and replace a LGPL library in practice is another question.

loup-vaillant 10y ago

As a library writer, the most important question is very simple: do you want to allow others to distribute proprietary applications build with your library? Answering this question may be very difficult, but once you do, the choice is simple: If you want to allow, you probably want a permissive licence. If not, you probably want a copyleft licence (I'd suggest GPLv3).