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
Comments
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:
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). |
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 😇. |
@xolox you can also emulate ini file and parse headers using configparser :) |
Thanks @imanhodjaev for the suggestion, that is indeed another option. |
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 😞. |
@xolox btw I created my own parser it should work the same way with archive as deb822 did https://github.com/imanhodjaev/pycran |
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.
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).
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! |
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 advanceThe text was updated successfully, but these errors were encountered: