Issue #244: license issue in your dependency graph caused by dulwich with tests enabled
| Reported by: | |
| State: | closed |
| Created on: | 2016-09-05 14:42 |
| Updated on: | 2016-09-25 16:26 |
Description
I wanted to inform you about this issue in your dependency graph:
kallithea < dulwich (with tests) < geventhttpclient < extension < public < setupfiles
The python2 variant of geventhttpclient depends on extension which depends on public which in return depends on setupfiles. All files without copyright can be found here: http://russianidiot.github.io/python/ This issue can be avoided when one builds dulwich without tests enabled. How should this be handled? For now I'll build dulwich python2 without tests and inform dulwich developer(s) about this situation.
For the package manager and GNU system distribution I currently write a kallithea definition, this won't work as licenses need to exist in all distributed packages, which is why I must disable the tests (we default to running tests when possible). Kallithea is not directly affected but it is still in your build graph.
Attachments
Comments
Comment on 2016-09-05 14:56
The problem might be with geventhttpclient and not dulwich, I'll investigate this.
Comment by Mads Kiilerich, on 2016-09-05 15:09
Please clarify: What is the problem with setupfiles?
Comment on 2016-09-05 15:17
setupfiles: No license at all is included with the source.
public: Same.
extension (which pulled those 2 in): probably the same, upstream seems gone but it might or might not still exist on pypi.
Comment by Mads Kiilerich, on 2016-09-05 15:26
That should probably be fixed or worked around elsewhere in the dependency chain - I don't think there is anything Kallithea can do about that. Not using Dulwich is not an option.
But it is great to report and track it here.
Comment on 2016-09-05 15:39
I agree. Can one of your contributors get to this? I'm not so good in explaining why having no license at all is problematic for distribution, I just follow the guidelines in this regard. I figure it's in your interest, if there are no resources at the moment I'll pass this on to someone in our contributors team.
I have to test something, as simply disabling tests did not fix the situation of a dependency on 'setuptools.extensions' module. Edit: https://github.com/gwik/geventhttpclient/blob/master/setup.py#L30 it can not be simply circumvented it seems. Fixing licenses downstream is the way to got (geventhttpclient in this case)
Comment on 2016-09-05 15:46
Is this really the correct "Extension" module I am looking at? at https://jelmer.uk/code/dulwich/blob/master/setup.py#L-7
try:
from setuptools import setup, Extension
except ImportError:
from distutils.core import setup, Extension
from distutils.core import Distribution
this looks like something which exists in setuptools for me? This search for me started when the python2 variant failed to build in the dependency chain, as kallithea is still using python2 there is no alternative.
Comment by Mads Kiilerich, on 2016-09-05 16:28
I have no idea which it is. We just use Dulwich.
Dulwich is GPL and the maintainer respects GPL (even though they have considered changing to a more liberal license). I suggest taking it there (or further down the dependency chain).
Comment on 2016-09-05 16:33
Thanks.
Okay, I will update this ticket when the situation changed.
Comment by Søren Løvborg, on 2016-09-05 16:51
You seem to have confused setuptools with another package?
setuptools is MIT licensed, per their PyPI page and their LICENSE file.
I can't see that geventhttpclient depends on extension anywhere.
That said, even if it does, the packages by russianidiot (extension, public and setupfiles) are MIT licensed, per their PyPI pages (etc.), but you're right that they don't have a file stating this in the repository itself. If you're concerned about this, you should get in touch with "russianidiot" and have them add add a LICENSE file so there's no confusion.
Comment on 2016-09-06 12:43
It is possible that the error comes from something I overlooked. I can only reply positive or negative when I've tested this, I let others with more python experience on Guix look at this and get back to you.
Thanks for your feedback.
Comment on 2016-09-06 12:44
Comment on 2016-09-14 13:12
I think this was the cause of all my problems: https://github.com/gwik/geventhttpclient/pull/82
Comment by Mads Kiilerich, on 2016-09-14 13:29
;-) thanks for keeping us posted.
Please mark this issue as resolved if that is what it is.
Comment on 2016-09-15 17:33
I'll mark it as fixed as soon as I'm past this issue. I'm doing lots of parallel work.
Comment on 2016-09-25 16:26
Closed as fixed. Resolved somewhere in the dependency graph of kallithea.