license issue in your dependency graph caused by dulwich with tests enabled

Issue #244 closed
Former user created an issue

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: 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.

Comments (15)

  1. Former user Account Deleted

    The problem might be with geventhttpclient and not dulwich, I'll investigate this.

  2. Former user Account Deleted

    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.

  3. Mads Kiilerich

    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.

  4. Former user Account Deleted

    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: it can not be simply circumvented it seems. Fixing licenses downstream is the way to got (geventhttpclient in this case)

  5. Former user Account Deleted

    Is this really the correct "Extension" module I am looking at? at

    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.

  6. Mads Kiilerich

    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).

  7. Søren Løvborg

    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.

  8. Former user Account Deleted

    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.

  9. Former user Account Deleted

    I'll mark it as fixed as soon as I'm past this issue. I'm doing lots of parallel work.

  10. Log in to comment