Skip to content
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

licensing question #20

Closed
aovasylenko opened this issue Mar 11, 2020 · 7 comments
Closed

licensing question #20

aovasylenko opened this issue Mar 11, 2020 · 7 comments

Comments

@aovasylenko
Copy link

hi @xolox , thank you for building the package and distribution it under the MIT license. We are evaluating it, but found, that you are using python-debian, which is distibuted under GPL2 or later. Did you evaluate, how it works together? Thank you in advance

@xolox
Copy link
Owner

xolox commented Mar 12, 2020

Hi @aovasylenko and thanks for the feedback.

To be honest I didn't think this through enough! Prompted by your question I researched the topic and it seems that by licensing deb-pkg-tools as MIT I'm violating the python-debian GPL2 license. This is rather unfortunate and was never my intention.

So it seems I have two options:

  1. Change the license of deb-pkg-tools to GPL2.
  2. Remove the python-debian dependency.

Going with the first option isn't necessarily a problem for me because I release what I do as open source software anyway, but I must admit to having a dislike for the viral nature of the GPL. Considering the other option, the only use case for the python-debian dependency is parsing of the deb822 format:

$ grep -r 'from debian'
deb_pkg_tools/control.py:from debian.deb822 import Deb822
deb_pkg_tools/tests.py:from debian.deb822 import Deb822
deb_pkg_tools/package.py:from debian.deb822 import Deb822
deb_pkg_tools/printer.py:from debian.deb822 import Deb822

Given the total scope of deb-pkg-tools this is a rather small bit of functionality, although clearly essential to the whole. Famous last words: It doesn't seem hard to implement deb822 parsing myself based on the specification (which is only 690 words).

@xolox
Copy link
Owner

xolox commented Mar 12, 2020

I'm under the impression I may be able to get away with replacing the deb822 parsing based on the python-debian package with email.parser.HeaderParser from the Python standard library. If anyone is reading along and knows I'm wrong then by all means point that out 😇.

@sultaniman
Copy link

@xolox you can also emulate ini file and parse headers using configparser :)

@xolox
Copy link
Owner

xolox commented Mar 13, 2020

Thanks @imanhodjaev for the suggestion, that is indeed another option.

@xolox
Copy link
Owner

xolox commented Mar 13, 2020

Status update: I've certainly worked myself into a uncomfortable corner here, because it turns out that deb-pkg-tools integrates with not one but two GPL2 licensed libraries:

I can't believe I never realized this before 🤦‍♂️. The deb822 parsing seems simple enough to replace but the version comparison is more involved. Of course I can also give in and change the license to GPL2 but this will ripple through the little ecosystem of Python packages that I've developed in the past seven years 😞.

@sultaniman
Copy link

@xolox btw I created my own parser it should work the same way with archive as deb822 did https://github.com/imanhodjaev/pycran

xolox added a commit that referenced this issue Apr 19, 2020
This commit contains two minor bug fixes for the merge_control_fields()
and parse_control_fields() functions which were already documented to
return Deb822 objects but in fact returned regular dictionaries before
now.
xolox added a commit that referenced this issue Apr 19, 2020
The following two things were handled rather inconsistently up till now:

- String literals being byte strings on Python 2 versus Unicode strings
  on Python 3. Despite the funky coercion rules in Python 2 this can
  and does bite. I'm pretty sure the deb_pkg_tools.control module in
  deb-pkg-tools < 8.0 can be made to raise UnicodeError exceptions for
  calls that should have been handled gracefully...

- Case insensitivity was previously an implicit feature because
  the python-debian package provides it. I was half aware of this
  but minimized deb-pkg-tools depending on this behavior. Given
  that I've now implemented case insensitivity natively I felt
  this was the right time to make things more consistent.

The intention of this commit is to get rid of these inconsistencies.

Only tangentially related to the above I also implemented a minor
performance optimization: Previously normalize_control_field_name()
constructed a dictionary on each call, but the contents of the
dictionary was static, so this "wastefulness" amounted to nothing more
than laziness on my part 😇. I've now promoted this dictionary to a
module level variable (in the assumption that looking up a module
variable is cheaper than constructing a dictionary).
@xolox
Copy link
Owner

xolox commented Apr 25, 2020

I've just released deb-pkg-tools 8.0 which resolves this issue by switching to native (Python) implementations of deb822 parsing and Debian version number comparisons. Thanks for the feedback!

@xolox xolox closed this as completed Apr 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants