Parsing output = derivative work? (was: RFS: gnetworktester)
(out of curiosity moved to debian-legal) On 2011-03-05 23:46, Timo Juhani Lindfors wrote: gnetworktester seems to parse the output of nmap and nmap upstream at http://insecure.org/nmap/data/COPYING gives me the impression that gnetworktester would thus be derivative work. IANAL, but since when parsing the output of another program constitutes a derivative work? Indeed, the forementioned file says, a program would be a derivate in the authors interpretation of the GPL, if it o Executes Nmap and parses the results (as opposed to typical shell or execution-menu apps, which simply display raw Nmap output and so are not derivative works.) o Integrates/includes/aggregates Nmap into a proprietary executable installer, such as those produced by InstallShield. o Links to a library or executes a program that does any of the above What do the legal experts think about this, especially the parsing aspect? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110306110435.ga22...@beron.tangosoft.com
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
On 2015-01-18 07:39, Riley Baird wrote: If you could make a version of python-requests with the OpenSSL parts removed, then yes. Otherwise, no. If one imports requests from Debian, OpenSSL is used. No idea how to prevent this. Also, if the writer of the module specifically states w/o OpenSSL exception, and then links to OpenSSL (like in the above example), then I would be very suspicious. No, this has been added by me just for the example. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150117223439.GC6021@fama
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
On 2015-01-18 15:09, Riley Baird wrote: Then as is, the software can't go into Debian. Maybe you could try contacting upstream to ask them for an OpenSSL exception? Upstream has been contacted. So far they seem to think, that this is a Debian internal issue and don't want to add anything to their license (GPL-3+). I'll try again. See https://github.com/xray7224/PyPump/issues/101 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150118111601.GA9456@fama
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
On 2015-01-18 12:23, W. Martin Borgert wrote: On 2015-01-18 12:16, W. Martin Borgert wrote: Upstream has been contacted. So far they seem to think, that this is a Debian internal issue and don't want to add anything to their license (GPL-3+). I'll try again. Isn't the fact that upstream does not care sufficient evidence that in this case upstream is not opposed to linking against OpenSSL? This fact must be documented in debian/copyright and should be equally valid as the formal exception, right? OK, not quite: Upstream explicitly states, that OpenSSL license is incompatible with GPL-3, but is seen by them as system library if it does provide functions via the Python standard library. https://github.com/xray7224/PyPump/issues/101#issuecomment-70409244 https://github.com/xray7224/PyPump/issues/101#issuecomment-70409569 Discussion is closed there, so I will upload pypump to Debian on the ground that upstream (= copyright holder!) does not object. OK? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015011814.GA13999@fama
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
On 2015-01-18 12:16, W. Martin Borgert wrote: Upstream has been contacted. So far they seem to think, that this is a Debian internal issue and don't want to add anything to their license (GPL-3+). I'll try again. Isn't the fact that upstream does not care sufficient evidence that in this case upstream is not opposed to linking against OpenSSL? This fact must be documented in debian/copyright and should be equally valid as the formal exception, right? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150118112351.GA9694@fama
Python GPL-3+ program w/o OpenSSL exception using python-requests
Hi, sorry, if this question has been discussed before. So far, I could not find a conclusive answer. Please Cc me. Python program or library X is licensed under GPL3+ without OpenSSL exception. X does use the python-requests library, which on load dynamically links the Python interpreter with the OpenSSL library. This is X: #!/usr/bin/python3 __license__ = GPL-3+ w/o OpenSSL exception import os import subprocess import requests if __name__ == __main__: lsof = subprocess.Popen([lsof, -p, str(os.getpid())], stdout=subprocess.PIPE) out, _ = lsof.communicate() for s in out.decode().split(\n): if /libssl.so. in s: print(s) As one can see, the process X links the OpenSSL library. Can X be distributed legally by Debian? TIA Cheers Btw.: X could also be the python-pypump library. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150117181421.GA4874@fama
