Open sunweaver opened 11 years ago
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: "...The license is also GPL-compatible, meaning that the GPL permits combination and redistribution with software that uses the MIT License." IMHO we're fine with licensing here. Dulwich and Mercurial used in VCS are both GPLv2, we asked Mercurial guys when we were releasing VCS and they said it's ok.
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:
""" [...] To elaborate on the weirdness; it is due to compatability with the GPL being one sided. As in GPL software can include MIT software, but MIT software cannot include GPL software - this is as GPL requires projects using GPL software to also be GPL - this restriction is removed with the LGPL which allows you to use your LGPL in any software. – balupton Jul 27 '10 at 0:11 """ http://stackoverflow.com/questions/3336161/mit-gpl-dual-license-in-commercial-software
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).
@lukaszb:
Quoting form the GPL-2 full text license:
""" If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. """
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 sunweaver@debian.org)