How is that compatible with the BSD license your code is released as?
Pyphen is released under the GPL 2.0+/LGPL 2.1+/MPL 1.1 tri-license. See COPYING.GPL, COPYING.LGPL and COPYING.MPL for more details.
It seems to be OK, isn't it?
It seems to be OK, isn't it?
No
No
Why?
Have you read the GPL v2 license? Specifically section 2(b):
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Multi-licencing, in the case of Pyphen, means that users can chose the license they want when using or redistributing the software. They can thus choose to use WeasyPrint with Pyphen-distributed-under-the-LGPL.
I'm not sure you understand the legality of the GPL v2 license and how it applies.
https://en.wikipedia.org/wiki/Multi-licensing
When software is multi-licensed, recipients can typically choose the terms under which they want to use or distribute the software, but the simple presence of multiple licenses in a software package or library does not necessarily indicate that the recipient can freely choose one or the other. In some cases, especially when the software has multiple origins, all the accompanied licenses apply at the same time. The applicability of the different licenses has to be individually checked. The distributor may or may not apply a fee to either option. The two usual motivations for multi-licensing are license compatibility[1] and market segregation based business models.
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
3.1 Requirements of the GPL
We consider first the GPL side of the question. The GPL is a copyleft license; it formally requires that modified versions of GPL鈥檇 programs be distributed under the terms of the GPL. Although the issue of the breadth of the GPL copyleft on modified versions is beyond the scope of this document, it is significant that most GPL licensors have refused to adopt a narrow view of what causes added code to fall under the copyleft requirement. Developers incorporating permissive-licensed code into a GPL鈥檇 project can generally assume, then, that the totality of the modified project is covered by the GPL.
but the simple presence of multiple licenses in a software package or library does not necessarily indicate that the recipient can freely choose one or the other. In some cases, especially when the software has multiple origins, all the accompanied licenses apply at the same time.
So: it depends. In the case of Pyphen's code, I'm sure that it means that the recipient can freely choose one or the other, because I'm the one who wrote the code and I'm the one who decided to set these licenses. The original project (Pyphen is a fork of Python-Hyphenator) is distributed under LGPL, so that shouldn't be a problem.
If you use GPLv2 property in your software. Then your software is also automatically GPLv2.
https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility
That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole
That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole
Of course, when you combine a program with code under the GPL, the GPL applies to the whole.
It doesn't mean at all that code distributed under multiple licences (including GPL) makes other programs using this code under GPL.
A number of businesses use multi-licensing to distribute a GPL version and sell a proprietary license to companies wishing to combine the package with proprietary code, using dynamic linking or not.
That's a very common case of multi-licensing. People using the proprietary version of the code obviously don't have to respect the GPL, they can use it in proprietary code.
That's exactly the same for people using the LGPL version of Pyphen.
(And I don't find your quote in the page.)
(And I don't find your quote in the page.)
I updated the link sorry.
I updated the link sorry.
No problem :wink:.
It doesn't mean at all that code distributed under multiple licences (including GPL) makes other programs using this code under GPL.
This is exactly what it means.
https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL
This is exactly what it means.
I disagree.
If you were right, it would mean that it would be impossible to distribute the same code under both a proprietary license and the GPL.
it would mean that it would be impossible to distribute the same code under both a proprietary license and the GPL.
Proprietary licenses are a separate subject. There are process boundaries that make this possible and also statically linking vs dynamically linking.
You can distribute code under multiple OSS licenses though. That means I could pick up the python code that is not GPL and copy and paste it (with your BSD license attached) in my project. (e.g. https://github.com/Kozea/WeasyPrint/blob/master/weasyprint/html.py)
But if I use a library, WeasyPrint, that uses a library, Pyphen, that is licensed under the GPLv2. Then my code _and_ WeasyPrint must also be licensed under GPLv2.
Proprietary licenses are a separate subject. There are process boundaries that make this possible and also statically linking vs dynamically linking.
I disagree. Why would it be a separate subject?
From the Wikipedia page:
A number of businesses use multi-licensing to distribute a GPL version and sell a proprietary license to companies wishing to combine the package with proprietary code, using dynamic linking or not.
Dynamic vs. static linking doesn't change anything about that.
From Wikimedia Commons:
Multi-licensing means releasing content under multiple licenses. Doing so gives more freedom to users of the content, as they can choose which of the licenses best suits their needs.
Users can choose the license they prefer. When they choose LGPL for Pyphen, Pyphen is under LGPL, not under GPL.
You can distribute code under multiple OSS licenses though. That means I could pick up the python code that is not GPL and copy and paste it (with your BSD license attached) in my project.
I agree.
But if I use a library, WeasyPrint, that uses a library, Pyphen, that is licensed under the GPLv2. Then my code _and_ WeasyPrint _must_ also be licensed under GPLv2.
Again, that would be true if Pyphen was only licensed under GPLv2. But it's also licensed under the LGPL, and people can use it as distributed under the LGPL if they want.
This discussion is probably useless. I think I'm right, you think you're right. We're not lawyers, we won't be able to settle this.
Moreover, I think that the only person whose rights have been trampled is Pyphen's developer, aka. me.
If anyone wants to put me on trial, then no problem, I'm ready :smile:. If I lose, I'll find an arrangement
with myself to release Pyphen only under LGPL.
Moreover, I think that the only person whose rights have been trampled is Pyphen's developer, aka. me.
The authors of the dictionaries that were released as GPL might disagree.
The authors of the dictionaries that were released as GPL might disagree.
You're back :smile:.
Let's take another example, very close to our case. Libreoffice use Hunspell for spell checking. Sometimes, Hunspell is even bundled with Libreoffice.
Hunspell is distributed "under GPL/LGPL/MPL tri-license", just as Pyphen. Libreoffice is not distributed under GPL, it's distributed under MPL.
Other software also use Hunspell and are distributed under other licenses. For example, Chromium is distributed under BSD, MIT, LGPL, MS-PL, MPL+GPL+LGPL.
So Chromium is distributed under BSD, it uses Hunspell distributed under GPL/LGPL/MPL tri-license, and it can use dictionaries distributed only under GPL.
WeasyPrint is distributed under BSD, it uses Pyphen distributed under GPL/LGPL/MPL tri-license, and it can use dictionaries distributed only under GPL.
The dictionaries distributed with Pyphen are distributed under their own licenses. It's written in Pyphen's README, I'm not hiding anything.
I'm closing this issue now.
If the authors of the dictionaries don't want to have them distributed with Pyphen, then I'll remove them without a problem. Please send them a mail and tell them what I'm doing, I'll be happy to talk with them, thank them for their great work and apologize if they think I've done anything wrong. I don't want to fool anyone.
https://en.wikipedia.org/wiki/Chromium_(web_browser)
The Google-authored portion is released under the BSD license.[8] Other parts are subject to a variety of licenses, including MIT, LGPL, Ms-PL, and an MPL/GPL/LGPL tri-license.
Which means I couldn't legally use Chromium in my commercial software project/library.
The same as I am legally unable to use either WeasyPrint or Pyphen in my commercial project.
Which means I couldn't legally use Chromium in my commercial software project/library.
Hunspell is "used by proprietary software packages, like macOS, InDesign, memoQ, Opera and SDL Trados." And in the proprietary Google Chrome too :wink:.
Seems like it might be a grey area because they're dictionaries:
https://lwn.net/Articles/481386/
Hunspell dictionaries
Last year, I was asked an interesting question by a client: Can I include Hunspell and the Czech dictionary in a proprietary application?
The answer, of course, is "maybe".
Hunspell changed its license in 2006, to the MPL/GPL/LGPL tri-license to enable inclusion in Mozilla. It is used as the spell-checker for OpenOffice.org/LibreOffice as well as Mozilla Thunderbird and Firefox. Of course, the tri-license enables the embedding of Hunspell in proprietary applications. So where's the problem? It turns out that some Hunspell dictionaries, including Catalan, Danish and Czech, are licensed under GPL only. It's a bit curious why anyone would use the GPL, a license intended for use with source code, for a dictionary. Regardless, the question is: does including Hunspell in another application, with a GPL dictionary, constitute a derivative work, or an aggregation?
At one level, the question is whether it even makes sense for a dictionary to have a license. Thanks to Feist v Rural, copyright only applies to a "work" if there is significant creativity involved in it. If a Hunspell dictionary were just a list of words in alphabetical order, then at least in the US, copyright would not apply. However, in other jurisdictions, there are laws covering the constitution of databases, and some form of protection is afforded to the author. In addition, a Hunspell dictionary isn't really just a list of words - it also contains grammatical and hyphenation information, which involves some creativity. So there's a solid argument that the dictionary is copyrightable.
The second question is whether including the dictionary with Hunspell and other software makes a derivative work, or an aggregate work. One part of that is whether the component is useful without the Hunspell spellchecker. Since it's just a dictionary, it can be used with other spell-checkers, including aspell. Hunspell could easily use another Czech dictionary released under another license. So, since the two bits are easily dissociable, Hunspell with the dictionary probably makes an aggregate work, and the license of the dictionary does not impose any requirements on other software shipped with it. This is the advice that the OpenOffice.org project received from the FSF licensing list, and so the GPL dictionaries are included in the LibreOffice and OpenOffice.org distributions.
Mozilla, on the other hand, do not ship any GPL dictionaries. When I asked Gervase why, he answered:
It is arguable whether the GPL would cross the dictionary->application boundary. But again, we prefer to respect people's intentions, and it seems to us that if someone licenses their dictionary GPL-only, then they probably only want it used in GPL apps.
In other words, the intent of the author trumps all in this case, for Mozilla.So - maybe.
Most helpful comment
I disagree. Why would it be a separate subject?
From the Wikipedia page:
Dynamic vs. static linking doesn't change anything about that.
From Wikimedia Commons:
Users can choose the license they prefer. When they choose LGPL for Pyphen, Pyphen is under LGPL, not under GPL.
I agree.
Again, that would be true if Pyphen was only licensed under GPLv2. But it's also licensed under the LGPL, and people can use it as distributed under the LGPL if they want.
This discussion is probably useless. I think I'm right, you think you're right. We're not lawyers, we won't be able to settle this.
Moreover, I think that the only person whose rights have been trampled is Pyphen's developer, aka. me.
If anyone wants to put me on trial, then no problem, I'm ready :smile:. If I lose, I'll find an arrangement
with myself to release Pyphen only under LGPL.