therecipe
legal requirements for dual licensing
@bclermont @m8m5 @jordanorelli @akamensky @5k3105 @longlongh4 @aebruno @nnvn @hvnsweeting @KellyLSB @pekim @joesis @mixedCase @xland
Hey
I'm planning to offer the binding under a second (additional to the current) commercial license. The commercial license will be useful for people/firms who want to distribute their product in binary only form and also don't want/can't meet the conditions of the current license.
And because you directly contributed code, I have to obtain the rights from you to do so first. I also would like to compensate you for the transfer of your rights, by granting you the right to use the binding in the terms of the commercial license for free.
Please let me know if this is okay for you and if you grant me the rights for your code.
Thank you.
I'm not sure if this kind of exchange is legally valid under any jurisdiction, but fine by me.
Any code I have contributed to this repository can now be considered licensed under the Unlicense.
@mixedCase
Thank you very much :)
I'm not sure if this kind of exchange is legally valid under any jurisdiction
Yeah, I know. But I think/hope an oral contract is sufficient in this case.
Fine with me
On Mar 28, 2017 09:52, "MRMillon" [email protected] wrote:
Fine with me.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/therecipe/qt/issues/259#issuecomment-289647334, or mute the thread https://github.com/notifications/unsubscribe-auth/AA9E2e9ekbgRCuT_lkt5EyjbuvVy0v3Uks5rqHXTgaJpZM4MqmqY .
if this is okay for you Yes.
if you grant me the rights for your code Yes.
On 28 March 2017 at 09:41, joesis [email protected] wrote:
Fine with me.
On Tue, Mar 28, 2017 at 11:04 AM, nnvn [email protected] wrote:
Fine with me
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/therecipe/qt/issues/259#issuecomment-289649085, or mute the thread <https://github.com/notifications/unsubscribe-auth/ AVEXehA0uduzrfG3y1IA1JhItk8nDHbGks5rqHitgaJpZM4MqmqY>
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/therecipe/qt/issues/259#issuecomment-289702813, or mute the thread https://github.com/notifications/unsubscribe-auth/AACfAJQ_EtoxBIrrZlsrgQvPDlFCsdQHks5rqMe0gaJpZM4MqmqY .
@5k3105 @m8m5 @hvnsweeting @nnvn @joesis @pekim @jordanorelli @aebruno
Thank you all, I really appreciate it :)
@bclermont
which license you think of? Something like BSD?
I honestly didn't planned that far ahead yet, but I think it will be bases on (or maybe even be identical to) the commercial license of Qt itself.
I honestly didn't planned that far ahead yet, but I think it will be bases on (or maybe even be identical to) the commercial license of Qt itself.
then it should be ok! thanks
I approve
I'm planning to offer the binding under a second (additional to the current) commercial license
You have my permission.
I'm not sure if this kind of exchange is legally valid under any jurisdiction
That is totally acceptable. The code can be distributed under several licenses that are applied depending on circumstances. Also, current LGPL v3 does not limit the commercial use, it limits the distribution form (static vs dynamic linking).
I also would like to compensate you for the transfer of your rights
The above procedure does not require transfer of the rights. Also in situation of changing licensing model or adding extra license there is no rights transfer, but rather an approval from all rights holders on doing so.
If you would want all contributors to transfer their IP rights for the contributed code to you I would recommend to state that explicitly. Current phrasing only vaguely specifies adding a license (which again to highlight does not equal to rights transfer) and can later be used against your intention.
I would recommend creating a separate issue with writing the same things in a formal way to avoid ambiguity.
PS: Apart of writing the licensing model alterations in a formal way, would also be nice to write a compensation details in more formal way, otherwise right now it does not explicitly state what would I be permitted to do with the code based on compensation.
may be, you will be interested in https://www.clahub.com. easy to use. works like Travis CI (https://github.com/m8m5/test_CLA/pull/2).
https://cla-assistant.io also seems good. no need to fill form and gives a cla template (https://github.com/m8m5/cla_test2/pull/3)
@akamensky
Thank you, and also for the explanation :)
The above procedure does not require transfer of the rights. Also in situation of changing licensing model or adding extra license there is no rights transfer, but rather an approval from all rights holders on doing so.
Yes, this is was I had in mind when I made this request. To get the general consent from all contributors to allow me to add an extra license, that I then can possibly sell access to. I really should have phased it better and be more explicit about it.
If you would want all contributors to transfer their IP rights for the contributed code to you I would recommend to state that explicitly. Current phrasing only vaguely specifies adding a license (which again to highlight does not equal to rights transfer) and can later be used against your intention.
I think/hope this is not necessary, as all I really wanted was just an approval. I hope that my plan to "sell access to the commercial license" is still possible without the acquisition of your IP rights and an approval is sufficient for this.
PS: Apart of writing the licensing model alterations in a formal way, would also be nice to write a compensation details in more formal way, otherwise right now it does not explicitly state what would I be permitted to do with the code based on compensation.
Yes, I see what you mean. And I will write that down once I know what license I have to choose.
The reason why I wanted this "change", is because of the questions that came up for me with this issue https://github.com/therecipe/qt/issues/230
The problem is that at the current moment it's simply not possible to distribute applications created with the help of this binding in binary only form, if you don't want to also distribute the object file (*.a) file created during the compilation of your application. As the other way to comply with the LGPLv3 license (without sharing your source code) is dynamically linking, and that is currently not possible against Go libs. (but might be possible in Go 1.9)
So now, to allow this closed source (possible commercial) use without the need to distribute the object file or when available dynamically linkage against this lib. There needs to be another license that allows that or the current one needs to be changed AFAIK.
But as this limitation primarily affects users that want to distribute their applications for commercial purposes. (most other people are probably okay with open sourcing their code in the first place, I hope) I think it's then reasonable to give them the possibility to use the binding without these limitations enforced by the current license, but only if they pay for it.
I also looked into the commercial Qt license, to figure out if I could somehow leverage some parts of it. But it seems like I can't make any use of it, as it is tailored to Qt's specific needs and doesn't really reflect what I intent to achieve.
So I think/hope that the commercial license could just be a regular LGPLv3 license + a static linking exception. I don't know if this is possible, but it would be the most simple way to work around the specific issue with the current license.
What is the intent ?
Are you going to make this repo have a supported commercial side that you charge for ?
@joeblew99
What is the intent ? Are you going to make this repo have a supported commercial side that you charge for ?
Not directly, in the first place it's about:
Allowing the static linkage against this library without the need to provide a way of relinking or the disclosure of your source code, if you intent to distribute your application.
It basically is to create a new (more attractive) condition under which you can use this library. And this also doesn't alter the current conditions in any way afaik, it's just an addition. This new condition is probably uninteresting for most users, as they are already allowed to static link against this library by simply open sourcing the code.
So, as this new condition is only interesting for closed source users, who potentially want to distribute their applications for commercial purposes. It's probably a good idea to charge them for doing so. This doesn't means that there will be "home" and "pro" version or something, at least I'm not planning to create such a differentiation at this point.
i am planning to use this for a commercial project and so will be affected - hence why i am asking for clarification.
The QT company charge 300 per month for commercial use, which is the price for convenience.
Can you be more specific. my email is on my profile if you need to contact me also.
@joeblew99
Can you be more specific.
I will make things more specific, as soon as I looked into them deeper. For now I just wanted to get the general consent of the contributors to make this possible in the first place. So I didn't looked into pricing and all that other legal stuff yet. But I will ping you once things are more concrete.
@bclermont @m8m5 @jordanorelli @akamensky @5k3105 @longlongh4 @aebruno @nnvn @hvnsweeting @KellyLSB @pekim @joesis @mixedCase @xland
Hey, it's me again.
I did setup a formal CLA as akamensky suggested.
And it would be great if you could sign it off.
It can be done with just 2-3 clicks and there is also no need to fill in something.
The CLA is derived from Github's CLA and is short and readable, at least in comparsion to the others I read in the last few days ...
You can find it here: https://cla-assistant.io/therecipe/qt
Thank you very much :)
So, there's one thing I'm not so clear about... The bindings themselves (both the Go and C++ code) are under the LGPL. While qtdeploy might dynamically link against the C++ parts, isn't the Go code from this library statically linked, and thus, triggers the virality clause on all applications depending on it?
If it is your intention to allow people to use the bindings without having to LGPL/GPL their code, why not go for the MPL-2.0 or the LGPL+static linking exception? Right now I wouldn't be able to recomend the bindings to pretty much anyone because of the lack of dynamic linking in the Go compiler :/
@mixedCase
So, there's one thing I'm not so clear about... The bindings themselves (both the Go and C++ code) are under the LGPL. While qtdeploy might dynamically link against the C++ parts, isn't the Go code from this library statically linked, and thus, triggers the virality clause on all applications depending on it?
IANAL, but I think that if you just make use of a LGPL library (and don't modify it), then you are free to choose whatever license you may want for your own code. How I understand this is, that LGPL is pretty much only a problem if you want to keep your code closed and still distribute your product. Because then you might need to either dynamically link against the LGPL code (sadly not possible in Go 1.8 yet, beside on Linux) or statically link and then also distribute the object file created during compilation, with an instruction on how to relink against another version of the LGPL part of your code. If you open source your code however (I think the license doesn't matter, from LGPL's point, beside that the license maybe needs to allow your users at least to use it for the relinking purpose), then making your source available already satisfies this requirements and you are free to go.
If you however create a work based on the library, I mean if you would fork this repo and distribute a modified version, then you probably need to license this derived work under LGPL (and maybe GPL, but I'm not really sure) as well.
If it is your intention to allow people to use the bindings without having to LGPL/GPL their code, why not go for the MPL-2.0 or the LGPL+static linking exception? Right now I wouldn't be able to recomend the bindings to pretty much anyone because of the lack of dynamic linking in the Go compiler :/
Yes, I want to allow people to use this binding without them having to LGPL/GPL their code, but from what I know LGPL already allows people to do that, without forcing them to license their code under LGPL/GPL as well.
I created this table (for "work that uses the library"), which should make things a bit clearer.
| Type of use + Linkage mechanism used | Restrictions | Possible in C++ (Qt) | Possible in Go (binding) |
|---|---|---|---|
| Open Source + Any Use / Closed Source + Private Use | |||
| Any linkage mechanism | None | Yes | Yes |
| Closed Source + Public Distribution | |||
| Dynamic | None | Yes (default) | Not yet (technically) |
| Static | Distribution of object files + instructions on how to relink | Yes | Yes (default) |
| Static without restrictions | None | Yes (commercial Qt license) | Not yet (legally) |
Yes, I want to allow people to use this binding without them having to LGPL/GPL their code, but from what I know LGPL already allows people to do that, without forcing them to license their code under LGPL/GPL as well.
Unfortunately this is not the case, the way Qt allows it is via dynamic linking to the LGPL version or the commercial license. But as you mention in the table, the Go part of the binding (still under the LGPL) cannot under any circumstance (except via experimental Linux-only plugins) be dynamically linked. This means that even if software using this library were to be released under an open source license like MIT (and of course, if doing so under a non-open source license), you're forced to have an (L)GPL release because of the static linking triggering the virality clause.
From where I see it, if it is your intention for non (L)GPL code to be able to use the library, the best solution available is to release the library under the MPLv2. Projects like ZeroMQ have used the LGPLv3 with a static linking exception as an alternative, but that brings a different set of issues that hinder adoption as they explain here.
Unfortunately this is not the case, the way Qt allows it is via dynamic linking to the LGPL version or the commercial license.
Or you could statically link and also distribute the object file(s) + instructions on how to re-link. (Even if this is not explicitly stated in their FAQ) And those limitations only apply to closed source + public distribution use cases.
This means that even if software using this library were to be released under an open source license like MIT (and of course, if doing so under a non-open source license), you're forced to have an (L)GPL release because of the static linking triggering the virality clause.
You have to differentiate between "work that uses the library" and "work based on the library" there. Yes, "work based on the library" has those restrictions, but "work that uses the library" has not (regardless if the end product is open source or not).
From where I see it, if it is your intention for non (L)GPL code to be able to use the library, the best solution available is to release the library under the MPLv2. Projects like ZeroMQ have used the LGPLv3 with a static linking exception as an alternative, but that brings a different set of issues that hinder adoption as they explain here.
I'm not really familiar with ZeroMQ, but I think the reason why they want to change the license to MPL is because the low level core (libzmq) is under LGPL and therefore everything that makes use of this library is considered to be "work based on the library" instead of being "work that uses the library".
That's the difference in comparison to this library, as most use cases are considered to be "work that uses the library" here, rather than "work based on the library".
However I could be wrong, but I also haven't found something that indicates that yet.
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://forum.qt.io/topic/65116/static-builds-and-lgpl-again-providing-object-files-instead-of-open-source
You have to differentiate between "work that uses the library" and "work based on the library" there. Yes, "work based on the library" has those restrictions, but "work that uses the library" has not (regardless if the end product is open source or not).
This distinction is not legally clear since there's no clear-cut unit of "work" and different courts will interpret it differently, so this distinction does not exist in practice. Here's a good explanation: https://copyleft.org/guide/comprehensive-gpl-guidech5.html#x8-300004
The only thing people tend to agree on is that with a relinking mechanism the virality clause of the LGPL does not apply outside of the library. However, as mentioned before, this is not possible to provide with Go outside of plugins.