Closed ghost closed 6 years ago
Disclaimer: I'm not legally educated and the following opinions might be totally wrong.
I would suggest we stay with GPLv2, as GPLv3 means we would have to fork this project under a new license and keep maintaining an additional fork. I also think GPLv3 is more strict with proprietary hard/software using the target software. I think this is the reason, why the linux kernel is still GPLv2.
I doubt, that we need @ccMSC's approval to change a license of a software with several different maintainers and of which the original author has disappeared on.
@fleischie
Disclaimer: I'm not legally educated and the following opinions might be totally wrong.
Neither am I, so the disclaimer applies to me as well :)
As someone has mentioned, using GPLv2.0 we are violating:
- Qt's LGPLv3 license
This is a really severe issue and in theory we have no right to use Qt libraries right now. That's why this needs to be resolved as soon as possible.
So, we cannot just stick to GPLv2.0.
GPLv3 means we would have to fork this project under a new license
Most probably. But there's another solution - GPLv2+, which GPLv2.0 can be upgraded to painlessly I believe.
I doubt, that we need @ccMSC's approval
He is still the author of 95% or more. You cannot just annihilate the copyright notice.
of which the original author has disappeared on
Everything is not that bad. One of our community members - @ZirconiumX - managed to reach @ccMSC once (in fact, the README update on ckb
project happened as a result) through the channel which I won't share here and I'm positive we can get a response from him this time too since the issue is critical.
However, I don't know whether the upgrade to GPLv2+ requires the original project to upgrade as well, or a candid disclosure from @ccMSC sent with his GitHub account somewhere over here is enough.
OK, sorry my previous post was more negative, than I intended. I have read some more about this and admit, that GPLv2+ is my preferred option now.
Another option would be to rewrite the complete frontend in another library/language. I doubt, that this is a viable option at this moment, as it would drastically increase the workload apart from maintaining the current project.
So, yeah. I'd be forever grateful, if you could get an approval of @ccMSC or someone who knows him. 🙂
@fleischie The main reason as I understand, why linux is still under GPLv2 is that Thorwalds fears that because of the ban on (not only) software patents in the v3 (the main difference to v2), Linux could become less useful for the industry. As GPL describes copy-left requirements, GPLv3 has patent-left requirements in addition.
As I understand the licence page from Qt and the video an that page, we have no problem combining different licences when we a) do only dynamic linking (as I understand we do in linux, I do not know in macOS) b) mention all used products and give the licence information and warranty disclaimer when we deliver packages
@frickler24
Please look at the compatibility table on which I gave a link.
I want to use a library under: -> LGPLv3
says NO
under GPLv2 only
.
I've just sent a message to ccMSC. I'd also like to point out that ckb-heat
is also LGPLv3.
@light2yellow This table you have to use, if you change element which are licensed under LGPLv3. We use them by dynamically linking, we do not change Qt. So we have to mention, that we use this lib (and mayby others?) and put the lincense and warranty disclaimer of Qt into the distributed package or source.
So, my understanding when I created the project was that Qt is available under multiple open-source licenses, GPLv2 being one of them. In particular, according to this page: https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
This page also: https://www.qt.io/licensing-comparison/ Seems to suggest that GPLv2 is an acceptable license, although most of the other licensing pages only mention LGPLv3, which is a bit confusing.
I'm not sure how ckb-mviz
or ckb-heat
ended up LGPLv3 though...when I had them in my repo they were BSD and GPLv2 respectively. Did that change come from the original author? It might be that they didn't notice the license was incompatible.
In any case, you have my permission to re-license the code as GPLv2+ if you feel that's the best approach. No harm in being on the safe side.
@frickler24
We use them by dynamically linking, we do not change Qt.
I could be, but the Mac binary ships with a stripped version of Qt (that's why its size is cca 20 MB after unpacking). It's somewhat a pain in the ass to download 8 GB of Xcode, then 1 GB of Qt and then build ckb. I honestly don't want to stop shipping the .pkg.
Even if so, can you proof your statements with quotations? The license creator (FSF) directly states their opinion on this by a compatibility table. As a contrary, for me Qt's page looks vague, imprecise and not on the point.
As we got the permission, I guess all prerequisites are fulfilled, except consensus between members.
If we link statically, the LGPLv3 says, that we generate a "combined work":
A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.
Combined work is chapter 4 in the document, where 2 different methods are described (one for statical, on for dynamical linking):
d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
So read carefully Chapter 4. We must install a licensing information, we must add a panel in the dialog where we desribe that we use Qt and that it is under LGPLv3 and where to find the license. Then we have to give a warranty disclamer in the distributed files and at the license panel (where we should describe the license of ckb-next also).
@frickler24
Even so, looking at the matrix once again, particularly the footnotes, particularly the footnote number 9, found on the GPLv2+
and LGPLv3
entry:
9: Because GPLv2 does not permit combinations with LGPLv3, you must convey the project under GPLv3's terms in this case, since it will allow that combination.
It explicitly states the above. As well as it explicitly states that GPLv2 only is not compatible.
To put it mildly, I'm in doubt we should, need, must and/or have to go against GNU's explanation of their own licenses, stating that we know better how to interpret them.
Qt organization seems not to bother themselves adding "and later" to "GPLv2" word on their licensing page. This is their discrepancy to address. Ours is to legalize the project with existing, legal mechanisms.
I suppose the matrix exists exactly for such cases - to disambiguate the [possibly imprecise] interpretation. I cannot agree with you because we both see what is written there. Neither can I ignore it, nor I want to.
Since MSC agreed, I suggest we relicense the code to GPLv2 and higher. That way, we will be safe both on the Qt end, and the creator of ckb-mviz/ckb-heat will not have to relicense their code.
Agreed, GPLv2+ seems inclusive and maintainable going forward without forking. Should we just change the LICENSE file or add a licence header to every appropriate file (I think this was in discussion previously, right?)?
Also:
ckb-mviz
has a LGPLv3 license from it's initial commit in 2320878 (Wed 23 2015 12:53). There is a COPYING file in it's directory, which is the license file for kiss_fft
, which ckb-mviz
utilizes. The latter has a BSD 3-term license and was comitted in 51e887d (Thu 24 2015, 09:31).ckb-heat
has changed from GPLv2 (in it's initial commit) to LGPLv3 by the original author in commit c542ade (Sep 23 2015, 12:37; which was the subsequent commit).Speaking of a license header, here is what LLVM project uses:
Every source file should have a header on it that describes the basic purpose of the file.
//===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===----------------------------------------------------------------------===// /// /// \file /// This file contains the declaration of the Instruction class, which is the /// base class for all of the VM instructions. /// //===----------------------------------------------------------------------===//
A few things to note about this particular format: The “-- C++ --” string on the first line is there to tell Emacs that the source file is a C++ file, not a C file (Emacs assumes .h files are C files by default).
(e.g. ignore string in ckb-daemon
, put it in ckb
though)
The next section in the file is a concise note that defines the license that the file is released under. This makes it perfectly clear what terms the source code can be distributed under and should not be modified in any way.
The main body is a Doxygen comment (identified by the /// comment marker instead of the usual //) describing the purpose of the file. The first sentence (or a passage beginning with \brief) is used as an abstract. Any additional information should be separated by a blank line. If an algorithm is being implemented or something tricky is going on, a reference to the paper where it is published should be included, as well as any notes or gotchas in the code to watch out for.
(reference to the paper can be safely ignored, however, gotchas shouldn't)
Also, I honestly prefer @command
to \command
. But that's not important.
The LLVM Compiler Infrastructure
-> ckb-next daemon [infrastructure]
& ckb-next GUI [infrastructure]
University of Illinois Open Source License
-> license of choiceLICENSE.TXT
-> LICENSE.md
Such header can be easily automated if you work in an IDE.
Today we revisited a license topic on IRC and I found some info not seen [by me] previously in FAQ:
Starting from Qt 5.7, Qt is licensed under • Commercial license • LGPL3 open source license • GPL2 or GPLv3 open source license
The general Qt toolkit, consisting of Qt Essential code libraries, the Qt add-on APIs, and the Qt Creator IDE are available dual-licensed for commercial and GPL licenses. Most of the Qt APIs are available also under LGPLv3 license but not all of the Qt Add-on modules.
ckb-next uses only Qt Essentials, so GPLv2.0 should be okay. Accordingly, there's another solution - animations mentioned above are relicensed instead.
@ruler501 would you relicense both animations as GPLv2.0 or compatible licenses?
Also, we need to populate sources with headers that would at least link to the main license file.
ping @ruler501
Sure is there anything specific I should do to change the license?
@ruler501
We would like you to change the license of ckb-mviz
from LGPLv3
to either GPLv2+
, which symbolically means "GPLv2 or any later version" or LGPLv2.1+
, which symbolically means "LGPLv2.1 or any later version".
Also, we would like you to change the license of ckb-heat
from LGPLv3
to either GPLv2+
, which symbolically means "GPLv2 or any later version" or LGPLv2.1+
, which symbolically means "LGPLv2.1 or any later version".
This is to ensure maximum compatibility in future.
Please, submit one pull request per license and refer to this issue in commit messages.
Thanks in advance.
ping @ruler501
Also, please leave an email which allows to contact you. I assume your real name is in your GitHub's account. I'm creating copyright headers, so you have to provide it. If you don't want to publish it, you can disclose it privately sending me an email (address in GitHub's profile).
ping @ruler501
UPD: nevermind about email address, I can grab it from commit message. I somehow forgot about such possibility!
Ping @ruler501.
If we could have changed the license ourselves, we would have done so. However, only you as a copyright owner have rights to do this. All you have to do is change two lines in two files for the project to actually legally redistribute these animations.
Both pull requests should be up now. Email is friends.devon@gmail.com the commit email I had was from an old company I used to work at. Going forward I will hopefully see github notifications more so things like this can't slip my mind for so long.
@ruler501 thanks a lot.
Last thing left to work on here is licence headers in source files.
@light2yellow Which files? I need to go to sleep now it's too late for me but make a list I'll do a pull request tomorrow. Just tell me which text for which text. I really wouldn't want to mess licenses :P
@Extarys right now the task is stalled until #281 is merged.
np. ping me if needed ;)
As someone has mentioned, using GPLv2.0 we are violating:
ckb-mviz
This is due to the fact that GPLv2.0 is not compatible with (L)GPLv3(+). See the compatibility table.
Possible solutions:
As somebody else mentioned, we will require @ccMSC's direct approval, as he is the author of the major part of this software, and since GPLv2.0 is not compatible with GPLv3(+), we cannot make an upgrade ourselves and are trapped without a consent.