legal requirements for dual licensing #259
Comments
|
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. |
|
Thank you very much :)
Yeah, I know. But I think/hope an oral contract is sufficient in this case. |
|
which license you think of? Something like BSD? |
|
Fine with me. |
1 similar comment
|
Fine with me. |
|
Fine with me
…On Mar 28, 2017 09:52, "MRMillon" ***@***.***> wrote:
Fine with me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#259 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA9E2e9ekbgRCuT_lkt5EyjbuvVy0v3Uks5rqHXTgaJpZM4MqmqY>
.
|
|
Fine with me |
|
Fine with me.
|
|
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 ***@***.***> wrote:
Fine with me.
On Tue, Mar 28, 2017 at 11:04 AM, nnvn ***@***.***> wrote:
> Fine with me
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#259 (comment)>, 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
<#259 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACfAJQ_EtoxBIrrZlsrgQvPDlFCsdQHks5rqMe0gaJpZM4MqmqY>
.
|
|
yes 👍 |
|
yes, fine with me. |
|
@5k3105 @m8m5 @hvnsweeting @nnvn @joesis @pekim @jordanorelli @aebruno Thank you all, I really appreciate it :) |
|
@bclermont
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 |
You have my permission.
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).
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 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) |
|
Thank you, and also for the explanation :)
Yes, this is was I had in mind when I made this request.
I think/hope this is not necessary, as all I really wanted was just an approval.
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 #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. 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 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. |
|
@m8m5 Thank you, these look great :) |
|
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: 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. 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. |
I will make things more specific, as soon as I looked into them deeper. |
|
@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 :) |
|
It is fine with me~~~ |
|
done |
|
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 :/ |
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.
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.
|
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. |
Or you could statically link and also distribute the object file(s) + instructions on how to re-link.
You have to differentiate between "work that uses the library" and "work based on the library" there.
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 |
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. |
|
Yes, I mean a closed source, Go application that is distributed to the public as a normal binary and uses this library without modifying it (or with changes to it released under the LGPL if modified). I don't see how this can be done currently due to limitations of the Go compiler. |
|
Ah, sorry yes that is correct. If you want to use this binding in a closed source application and intend to distribute it in binary only form, your only option is to statically link against the Go code and then also distribute object files and instructions on how to re-link. The other possible options would be:
But both options are not available at the moment. And this is also the reason why I opened this issue in the first place, to get the consent from all contributors to create a second license to make option b) available. But this second license will probably only be available for a fee. But don't worry, I also said and still mean it, that all the early contributors I stated in the OP (and so also you), can use this binding under the terms of the second (commercial) license for free. I will also create another post where things will be more formal, once there really is that second license. And the second license will probably be just a static linking exceptions for "work that uses the library", so that you can use this library in:
|
|
@therecipe While I get to enjoy the license, I can't recommend the library to other people who don't. In fact, I'm not even interested in making closed source applications with it; but this kind of thing is a blocker for the user adoption that leads to the development of a thriving ecosystem around it which everyone benefits from, hence my insistence on a copyleft license that allowed normal Go usage now that everyone has approved relicensing. Even when plugins become a thing across platforms, they're annoying to use compared to dynamic linking since it's in the end, dynamic loading. One has to use the plugin package API, type assertion for everything and so on. It requires more boilerplate than writing Qt code in C++; which makes it hard to recommend as a solution to make Qt development more pleasant. In the end it's your project, if you want to take a fee for it it's only fair, you have put a lot of work into it and deserve it, but it does mean we fall into the PyQt situation again which nobody liked and prevented its adoption even in open source projects :( |
|
Yes, I understand your points, but I also have some concerns regarding a general static linking exception or MPL. The thing is that the library as it is at the moment (under LGPL) is already pretty permissive for open source / in-house users. Adding the linking exception or switching to MPL, will therefore only benefit closed source users. In the end it is just about the potentially risk and potentially reward. The potentially risk is clear: Losing the only "real" ability to generate some revenue. The potentially reward on the other side is not that clear: Can/do those closed source users give enough back to justify the lose of the potentially revenue though license fees? That's difficult, but I would say no they can't. At least not in regular intervals, and those are necessary to provide stability for further growth. I know that the cost for commercial licenses is a bigger problem for indie devs, but those problems can be easily solved by offering different tiers, such as a free tier for startups or indies. But adding a general static linking exception will mostly only benefit "big" businesses that want to capitalize on open source, without giving enough back. Even though they are in the perfect position to contribute, either financially or by dedicating some man power to an open source project. I know for example that a business is way more likely to pay a license fee (which can also be offset with taxes), then making a single donation. Why is that so? Because businesses are no charities and even though they say they believe/work in/with open source, in the end there is no reason other than a "moral/ethical" one to really support open source. And business don't know "morals nor "ethics" ...
Yes, "-buildmode=plugin" will probably be always unusable in this case. But what I meant was real dynamic linking with "-buildmode=shared", but it seems to only work on linux as of now.
I think there are a few reason why PyQt didn't gained mainstream adoption for "open source" use cases. One is certainly the GPL license, which was necessary because LGPL isn't suitable for Python. The other was probably the "official" LGPL PySide competition (that lead to fragmention). And there were probably a few other minor things that lead to that. But I think PyQt is still more polished/stable and therefor more suitable for enterprise development than it's LGPL counterpart. And that is probably because of the reasons I stated above. However, I will keep that in mind. Maybe there can be made a deal like TQtC did to keep this open source. And also thanks for sharing your concerns :) And if it doesn't work out, then moving from LGPL to MPL is much easier than "moving back" from MPL to LGPL. |
|
I stopped reading after a few posts... I smell a PyQt money grab coming (and PyQT hadn't been mentioned up to the point I was reading). The second i saw that this library was LGPL instead of BSD, MIT, Apache, etc. I knew that I'd find requests for assignment of copyright from the repo owner from contributors in the issues. And lo and behold, it's on page 2 of the issues. Shame on you @therecipe . I encourage each of you that contributed to the repo to retract any agreement to allow your code to be used in the PyQT money grab. If you have changed your mind, I encourage you to approach legal counsel as a few lines written on a comment thread on github may not be enough to give up your copyright, especially if you're in the USA. Very disappointed. |
Maybe you should have kept on reading ...
I don't think that's a fair thing to say, I personally think highly of PyQt.
:D If one of you contributors wants to retract from our informal agreement, then please let me know and I will purge your code from the repo. Okay, back to you.
|
|
While I am a lawyer, I don't practice in this area. So no, I'm not out to get new clients. That would also be the definition of "ambulance chasing" and is against the lawyer ethics rules in most jurisdictions. Of course you think highly of PyQT... you're mimicking their business model. And getting free work from github contributors that you are then in turn going to use to sell commercial licenses for your personal gain. I'm a disappointed potentially closed source (not necessarily commercial, but closed source, there's a distinction) user at the hobbyist level who hates seeing open source software used for money grabs under the guises of making others "give back". If you're really all about getting business to "give back", how about you pledge here and now to donate 100% of the proceeds from selling your commercial license to FSF or some other tech charity since you're moving towards being that "business"? |
Okay, I didn't want to insult you. So I hope you don't took it personal.
I was more focused on
Yeah, that's correct. But I didn't force anybody to contribute, and if people contribute, then I appreciate it. Furthermore every new contributor needs to sign the CLA now before their changes are merged.
Yeah, I know that there is a distinction, and I also try to bring these distinctions up as much as possible. But I don't want to repeat myself over and over again, if this stuff was already explained in more detail earlier. I don't think
Furthermore, I think that everything that is not used for commercial gains should also be Open Source in the first place.
I think already made clear that this going to be a business and not a charity. |
|
@therecipe can you elaborate on why you chose the LGPL instead of the GPL if you're so concerned about commercial use of the lib? It seems to me like you want to restrict users to make some money (which is totally fine with me) but for some reason can't go full-on GPL. If you're only concerned about people not contributing their modifications to your binding then leave them out of this licensing hell and use the MPL. There's far less hassle getting linking work (only Qt is still a thing, but most people got it installed anyway) and modifications still need to be publically available. I doubt there is a mod that one is willing to do legally under the MPL without disclosing source that is not possible through some reflection magic under the LGPL if someone really wants to. Again, I don't see why the choice between GPL and MPL fell in between with the LGPL which makes it worse for everyone. Just look at the licensing FAQ page, there would be no need for that with either GPL or MPL. |
|
@SimplicityApks Because he wants to make money with a dual license, where you can pay for a commercial license that doesn't care about being statically linked. |
|
Yeah I get that, just don't understand of LGPL over GPL if we can only really statically link in Go. It first looks like free to use until you remember Go's static linking and then it is kinda sometimes still free for commercial use. Very unclear and stupid if you ask me. Might as well go GPL all the way. The LGPL only makes sense in a dynamically linked Linux distribution world using C (where it comes from). |
|
I love that "tiers" approach with free tier for startups. Because, well, sometimes even $300 can be a huge amount of money for startups. I'm not speaking about already-bucked things form Kickstarter or similar sites, but about a simple person (like me) who want to try to sell his app(s). While reading whole thread I realised that some of posters doesn't understand The Meaning of LGPL (c)(r)(tm). So read it below:
The only "shit" for commercial apps here is therecipe/qt repo. It is what your application statically linking (Qt is linked dynamically actually) and that's why you will have to disclose your source, because your app isn't "using LGPL library", but "based on LGPL library". Let me please do a proposal as open-source lover and yet as person who want to make some buck on software written with this bindings in future. Please, allow small companies (for example to companies who have 5-10 employes) and to individual entrepreneurs to use your bindings for free or for really small about of buck (like $5 or $10). What I want to ask you to avoid:
That's my 2c. I'm sorry if I post it in wrong issue, but someone should do that :> |
|
You're leaving out the fact that go is currently not lgpl compatible because support for dynamic linking is poor to non existent. Maybe I'm a few years it's a moot point. But right now? LGPL means bupkis for a go developer. Might as well be full GPL. |
|
No, I'm not leaving that fact. Please, re-read my post. When there will be a commercial license for therecipe/qt - there will be no problem at all, because this is an only thing that links statically. Qt itself links dynamically and isn't a problem. Once again - LGPL isn't a problem at all. Problem - static linking of therecipe/qt repo. That's what this thread is about - another license, so proprietary projects can use this repo. We can only hope that @therecipe won't do too high price for license. |
|
I get what you mean and agree with it, though I wouldn't say LGPL isn't a problem at all. The problem with the LGPL is that using it outside of the shared lib Linux distribution world with C confuses its wording entirely. There is no difference in using LGPL with static linking compared to the much more common GPL, only unclarity about what is possible and what is not. The equivalent of the LGPL in the Go world would be the MPL, as it at least allows closed sourced projects using the lib. Granted, this does not allow you to exchange the library with your own, but I've never seen a real use case for this and it is still possible here with a modified Qt shared lib. The main point of copyleft, that modifications have to be public, still is a strong requirement of the MPL! tl;dr LGPL works but is in reality only a uselessly obfuscated GPL here. |
|
On a personal note: @therecipe if you want to be nice and make some money go MPL+commercial license for a few bucks (which someone like me will pay you after I've liked your work). Or you can be unfriendly and do GPL+commercial if that sounds better to you. I doubt the second option will be succesful (at least myself won't be using the lib) but its at least better that the current LGPL nonsense. |
I think LGPL is the best fit for this, as it's more permissive for open source users then GPL and at the same time more strict for closed source (and/or commercial users) then MPL. LGPL might be complicated to understand for closed source users, but it's relatively easy to understand for open source users. (Okay, it's not as easy to understand as MIT/BSD but people would have to learn about LGPL sooner or later anyway, when they look into Qt's licenses) Also LGPL is still much more permissive without static linking than GPL.
I won't promise nothing, but yeah I would love to offer different tiers and then keep it free/cheap for individuals/startups. |
|
@therecipe You still haven't addressed the fact that the LGPL is incompatible with statically linked binaries a la Go. |
|
@jrmiller82 |
|
The LGPL is incompatible with statically linked binaries. Statically linking an LGPL library subjects the whole project to copyleft whereas dynamically linking would not. Go in its current form is mostly statically linked. We already discussed this above. |
|
Oh, sorry thought there was some new info that I missed. |
|
Hi, it has been a while; Is a new license still planned for this project? |
|
Yes, I have no fixed date, but maybe sometime in spring/summer 2019 once everything is properly vetted and I'm comfortable handing out licenses. This also somewhat depends on #382 since the project probably needs to be rebranded first. However, I haven't had the time to update the FAQ in the wiki yet to make this clear, but it's already possible to use the binding for proprietary developments without the need for a commercial license. But there is some downside I don't want to hold back, namely that these object files contain more infos than your final binary, such as debug symbols and probably full function signatures but I haven't really looked into them that deeply. Also this currently only works for windows, linux, mac, ios and android builds iirc, but feel free to open an issue if you run into any problems or you need it to work for some other targets. Also just to clarify this again, most people won't actually need a commercial license unless they plan to create closed source application and intent to distribute the final binary out-of-house. All other people who want to use this either in-house or publish their source publicly have no restrictions whatsoever, neither for their license nor for something else. disclaimer: IANAL, TINLA and DYOR |
|
Thank you. I was unaware of the |
|
Hi! As a longtime Qt user, moving from C++ to Go, I was happy to discover this nice Go binding and I would really love to build upon it! Since my current project is required to be distributed as closed source application:
Is there any news regarding the planed dual licensing? |
|
Yeach... another confirmation that Qt is dead and the reason why Electron wins and why solutions like https://github.com/fyne-io/fyne arise and growing. My app will be open-source, but fact that no clear and simple answer for commercial apps on this binding means that technology is dead and more as a play than a serious solution... |
@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.
The text was updated successfully, but these errors were encountered: