4 ms·

I rather use Mozilla Public License 2.0, Eclipse Public License 2.0, or EUPL 1.2 for copyleft purposes. Strong copyleft as a concept has no legal reality. Link

I rather use Mozilla Public License 2.0, Eclipse Public License 2.0, or EUPL 1.2 for copyleft purposes. Strong copyleft as a concept has no legal reality. Linking a program to another don't produce a derivative work. https://joinup.ec.europa.eu/collection/eupl/news/why-viral-licensing-ghost https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l... FSF is full of baloney about how static or dynamic linking is different than communicating for example through sockets. To be able to use the program I have to link it. What manner I choose to do that or available to me should not matter. I should also be able to reproduce portions of a program necessary for linking. Interoperability does not interfere with the legitimate interest of the licensor, or conflict with normal usage.

ladyanita22 5y ago
That'd be more akin to the Apple Public License, right?
mustache_kimono 5y ago
I wish the FOSS community would rally around this idea. Re: GNU/FSF, I think they've done a real disservice to the FOSS community misrepresenting the state of American copyright law. I wish someone with credibility with devs/FOSS users would finally say: "This is such an illusion, it's mostly a joke."
- zokula 5y ago
rileymat2 5y ago
There is a major distinction between static and dynamic linking, with dynamic linking you are releasing the work as is, with static linking and various optimizations you are clearly creating a derivative work. It is the difference between a book citing another, and pasting large portions in. Tldr; I see a distinction but probably disagree with fsf on dynamic linking.
admax88qqq 5y ago
What? The FSF and copyright in general does not worry about static vs dynamic linking. They focus on "derivative works.". The only question that matters is "does this piece of software derive from this other piece.". How they are linked together has no meaning. Hackers like to misunderstand that and think they can work around the GPL by how they bundle the two pieces together. The CLISP case is a classic example. It bundled and dynamically linked readline, and as a result it got a significantly better command line interface. The author argued that this didn't make it a derivative works and didn't need to licence his code as GPL as a result. But that violated the terms of readline, which plainly says if you want to use readline to provide a powerful command line interface then you have to license your code as GPL. You can always opt not to use the useful libraries and code that exist as GPL, but you can't take your cake and eat it too.
- deleted 5y ago
  [deleted]
- dralley 5y ago
  LGPL absolutely does care about linking. Section 4d specifically talks about shared libraries and requires you to be able to "re-link" the application with a modified version of the library, if dynamic linking is not used. When people talk about how the LGPL isn't a good license, it's largely because A) C and C++ are really the only two systems languages for which dynamic linking is even an option and B) header-only libraries, templates/generics, and heavy use of inlining can make "re-linking" a statically linked executable basically impossible.
  - admax88qqq 5y ago
    Yeah the LGPL gets a little technical, but at ita core it's really just saying there needs to be a way for the user to replace the LGPL library that is used. If it was statically linked on then some sort of relink ability needs to be provided. It's more like advice for people who want to incorporate LGPL software.
- trasz 5y ago
  What if the readline was really libedit(3), a BSD equivalent with the same API/ABI? How is the app a derived work of readline then?
AshamedCaptain 5y ago
You may not be able to distribute the combined work without violating the copyright of the GPL part, even if the other part is not a derivative work of the GPL part. If you really just distribute your part and let the user go and fetch the GPL part by his own means, the FSF has absolutely no say (and this is kind of what most propietary .ko kind of do); but if you also distribute the GPL part to the user... I.e. if you never distribute/reproduce the GPL part, then the GPL obviously can not apply; if you distribute the GPL part, then the GPL terms apply to you, even if your work is not derivative, and even if those terms are "you must do the chicken dance so that we give permission to reproduce our software"; after all, that is how most EULAs are enforced. It just happens that in this case the chicken dance comprises some fancy definitions of linking and some extra things you may have to distribute rather than a exchange of money.
snickerbockers 5y ago
That's potentially true with respect to dynamic linking, but if it's statically linked then you are literally distributing somebody else's code alongside your own so I can't imagine how that could be anything but a derived work.
xorcist 5y ago
No legal reality? After 30 years of numerous court cases, in various jurisdictions, all holding up the GPL? After many legal scholars weighing in on the matter?
coliveira 5y ago
It does mater the way the creator of the software licensed it. If the creators of the GPL specifically made a distinction between static and dynamic linking, then you're constrained by the distinction they made, if you agree or not.
badsectoracula 5y ago
The europa.eu articles (this is only one of them BTW) are about the case in EU where, indeed, copyleft goes only as far as MPL/LGPL/etc and of course EUPL - and note that this isn't 100% certain, it is just the most likely interpretation based on previous cases about interoperability. However this only valid for the EU itself. When software is not confined inside the EU, e.g. one (even a member of EU) cares about distribution outside of it, then the difference between GPL and LGPL can matter. For example even if EU does not see a difference, US might do and unless your software isn't to be used outside of EU the distinction still exists.
- Comevius 5y ago
  Google got away with distributing 11,000 lines of code from Oracle's proprietary Java implementation. It was considered fair use. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... The conditions you put in a software license must work within a legal framework. It appears that your license can't relicense my code, it only applies to your code. However linking or reproducing portions of your code for interoperability don't create a derivative work. This is of course not a legal advice. FSF licenses are trying to take away rights from you that cannot be taken away.

ladyanita22 5y ago

That'd be more akin to the Apple Public License, right?

mustache_kimono 5y ago

I wish the FOSS community would rally around this idea. Re: GNU/FSF, I think they've done a real disservice to the FOSS community misrepresenting the state of American copyright law. I wish someone with credibility with devs/FOSS users would finally say: "This is such an illusion, it's mostly a joke."

zokula 5y ago

rileymat2 5y ago

There is a major distinction between static and dynamic linking, with dynamic linking you are releasing the work as is, with static linking and various optimizations you are clearly creating a derivative work. It is the difference between a book citing another, and pasting large portions in. Tldr; I see a distinction but probably disagree with fsf on dynamic linking.

admax88qqq 5y ago

What? The FSF and copyright in general does not worry about static vs dynamic linking. They focus on "derivative works.". The only question that matters is "does this piece of software derive from this other piece.". How they are linked together has no meaning. Hackers like to misunderstand that and think they can work around the GPL by how they bundle the two pieces together. The CLISP case is a classic example. It bundled and dynamically linked readline, and as a result it got a significantly better command line interface. The author argued that this didn't make it a derivative works and didn't need to licence his code as GPL as a result. But that violated the terms of readline, which plainly says if you want to use readline to provide a powerful command line interface then you have to license your code as GPL. You can always opt not to use the useful libraries and code that exist as GPL, but you can't take your cake and eat it too.

deleted 5y ago
[deleted]
dralley 5y ago
LGPL absolutely does care about linking. Section 4d specifically talks about shared libraries and requires you to be able to "re-link" the application with a modified version of the library, if dynamic linking is not used. When people talk about how the LGPL isn't a good license, it's largely because A) C and C++ are really the only two systems languages for which dynamic linking is even an option and B) header-only libraries, templates/generics, and heavy use of inlining can make "re-linking" a statically linked executable basically impossible.
- admax88qqq 5y ago
  Yeah the LGPL gets a little technical, but at ita core it's really just saying there needs to be a way for the user to replace the LGPL library that is used. If it was statically linked on then some sort of relink ability needs to be provided. It's more like advice for people who want to incorporate LGPL software.
trasz 5y ago
What if the readline was really libedit(3), a BSD equivalent with the same API/ABI? How is the app a derived work of readline then?

AshamedCaptain 5y ago

You may not be able to distribute the combined work without violating the copyright of the GPL part, even if the other part is not a derivative work of the GPL part. If you really just distribute your part and let the user go and fetch the GPL part by his own means, the FSF has absolutely no say (and this is kind of what most propietary .ko kind of do); but if you also distribute the GPL part to the user... I.e. if you never distribute/reproduce the GPL part, then the GPL obviously can not apply; if you distribute the GPL part, then the GPL terms apply to you, even if your work is not derivative, and even if those terms are "you must do the chicken dance so that we give permission to reproduce our software"; after all, that is how most EULAs are enforced. It just happens that in this case the chicken dance comprises some fancy definitions of linking and some extra things you may have to distribute rather than a exchange of money.

snickerbockers 5y ago

That's potentially true with respect to dynamic linking, but if it's statically linked then you are literally distributing somebody else's code alongside your own so I can't imagine how that could be anything but a derived work.

xorcist 5y ago

No legal reality? After 30 years of numerous court cases, in various jurisdictions, all holding up the GPL? After many legal scholars weighing in on the matter?

coliveira 5y ago

It does mater the way the creator of the software licensed it. If the creators of the GPL specifically made a distinction between static and dynamic linking, then you're constrained by the distinction they made, if you agree or not.

badsectoracula 5y ago

The europa.eu articles (this is only one of them BTW) are about the case in EU where, indeed, copyleft goes only as far as MPL/LGPL/etc and of course EUPL - and note that this isn't 100% certain, it is just the most likely interpretation based on previous cases about interoperability. However this only valid for the EU itself. When software is not confined inside the EU, e.g. one (even a member of EU) cares about distribution outside of it, then the difference between GPL and LGPL can matter. For example even if EU does not see a difference, US might do and unless your software isn't to be used outside of EU the distinction still exists.

Comevius 5y ago
Google got away with distributing 11,000 lines of code from Oracle's proprietary Java implementation. It was considered fair use. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... The conditions you put in a software license must work within a legal framework. It appears that your license can't relicense my code, it only applies to your code. However linking or reproducing portions of your code for interoperability don't create a derivative work. This is of course not a legal advice. FSF licenses are trying to take away rights from you that cannot be taken away.