-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
License issue in /vcs/backends/git/config.py #118
Comments
We recently got a PR from the author of Dulwich project(org author of config.py) that this file is now not needed as of latest Dulwich release, i'll sync this official repo within few days, and this file will be removed |
Please note that dulwich (as I realize now) is also GPL-v2+. So, in order to use dulwich as a module in vcs it requires vcs to be(come) GPL-2(+) or higher or compatible, as well (AFAICT). |
MIT is a GPL compatible license: |
Quoting from [1]: ,,The license is also GPL-compatible, meaning that the GPL permits combination and redistribution with software that uses the MIT License.'' What is said above is that you can link/combine GPL'ed software against/with MIT licensed software, but AFAIK not vice versa. I have the same issue with another project I am upstream for (a GPL'ed X-Server that requires GPL'ed code in the MIT/X11 licensed X.org code). |
@lukaszb thought, should we dual-license vcs or ? |
Maybe we/you should ask someone else who may be more into the topic of licensing. However, I am fairly sure that an upload of python-vcs will get rejected by the Debian ftpmaster team due to his unclear situation. |
@sunweaver can you please ask someone? Honestly I have no idea of how to respond to the licensing problems and am not fun of dual license software (it actually introduce another layer of complexity to me). |
ok, will do! |
thank you! |
I found a post on stackoverflow black-on-white that matches my statements above: """ Does that suffice (no one was asked so far...)? If I asked someone it would end up on the debian-legal mailing list. |
This means: if dulwich was LGPL you would be fine. But as the authors chose GPL for dulwich, everything that uses dulwich has to be GPL, as well. This probably finally also applies to RhodeCode (I heard your interview on gitminutes.com and really liked it). |
Quoting form the GPL-2 full text license: """ So what else you can do is: retrieve an exception from dulwich upstream to use dulwich with vcs. |
just one side note that dulwich 0.9.1 will be released under dual license. The second one is Apache2 license, but i think that doesn't change anything due too mercurial is anyway GPLv2 and we also use it in VCS. |
Correct, then (if mercurial is GPL'ish, too) this does not change anything... |
Hi guys, any progress on this? Mike |
so @lukaszb, we change the license to LGPL ? |
Hi Marcin, as mercurial (dulwich is about to be dually licensed, so that got moved out of the focus of this discussion) is GPL-2+ and you import any module from it, then you have to switch to GPL-2+ or higher. If you invoke mercurial commands via a subprocess calls, then you can keep your currently chosen license. Same for all other modules being used. Mike |
Hi,
I am about to package this project for Debian and found a licensing issue. The file /vcs/backends/git/config.py is licensed under the GPL-v2+ whereas the code that uses it is licensed under the MIT/Expat license.
To my knowledge, library-like code that is GPL-v2+ (importing modules into python is library-like) may only be used in GPL'ish / AGPL'ish code.
I will point the author of config.py to this report, so that the issue can be quickly sorted out.
Greets,
Mike (aka [email protected])
The text was updated successfully, but these errors were encountered: