Description of problem: There are some ambiguities about the license of the Python binding in https://download.libguestfs.org/python/guestfs-1.40.2.tar.gz - setup.py has a GPL-2.0+ notice as well as a license='LGPLv2+' tag and a "License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+)". - ignore-value.h, c-ctype.h have a GPL-3.0+ notice which may conflict with (or subsume) the LGPL-2.0+ or GPL-2.0+ declaration above What is the actual license LGPL-2.0+, GPL-2.0+, GPL-3.0+? Could this license be clarified in these files to remove the possible ambiguities? Version-Release number of selected component (if applicable): 1.40.2 (though all versions seem to have a similar issue) Thanks!
The ignore-value.h and c-ctype.h files are from gnulib which has a weird licensing system (to say the least). The TL;DR is you have to check https://github.com/coreutils/gnulib/tree/master/modules to find the real license of these files, which is LGPLv2+ in both cases. You can ignore what it says in the header file itself. The rest of the libguestfs Python bindings are LGPLv2+. setup.py is GPLv2+ because it's a program run as part of the build and is not combined with the library so does not affect the LGPLv2+ license of the final bindings.
Thank you ++ for the details! gnulib has indeed a rather byzantine configuration system. I did a quick test using their tool with the error module; 'gnulib-tool --lgpl=2 --import error' and this creates an error.h with an LGPL-2.1+ header notice rather than a GPL one. It seems to be the case also with the c-ctype module. May be this is something you could use to get the correct notice in your codebase which would remove the ambiguity entirely?
Richard W.M. Jones wrote: > setup.py is GPLv2+ because it's a program run as part of the > build and is not combined with the library so does not affect > the LGPLv2+ license of the final bindings. That's fair enough yet license detection tools may get tripped by this: there are both GPL and LGPL notices and references in one file and there is no easy to determine which is which automatically (I happen to maintain such a tool at https://github.com/nexB/scancode-toolkit ). So my 2 cents for your kind consideration are that if the setup.py license could be aligned with the package license this would make things much clearer for everyone in the future and avoid flagging license detection tools to flag inconsistencies between the declared package license and the license notices of the files found in the package.
Recently we removed gnulib from libguestfs, and as part of this I copied the few headers we are actually using. I fixed up the copyright notices in those headers to reflect the actual license of the files: https://github.com/libguestfs/libguestfs/blob/master/gnulib/lib/c-ctype.h https://github.com/libguestfs/libguestfs/blob/master/gnulib/lib/ignore-value.h So this should be fixed upstream. (By the way, please build the Python bindings from upstream sources) I will change the license of setup.py as you requested shortly.
https://github.com/libguestfs/libguestfs/commit/2883fc2acc11e711380f0d3843043c4482707cf7
Richard: You rock! Thank you ++ FYI, for now I spawned guesfish here https://github.com/nexB/extractcode/blob/aa5da29014ce4fbffca53c09689a2623e2b78196/src/extractcode/vmimage.py And I will adapt this to use the Python binding.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.
Reopening because Virtualization Tools has not been discontinued.