I'm in the middle of reviewing https://bugzilla.redhat.com/show_bug.cgi?id=751925 python-tables and came Toshio's useful link http://fedoraproject.org/wiki/User:Toshio/Unbundling_Python_Modules
The maintainer has licensed the package as multi-license BSD and AFL - on investigating it seems to included another file from a package here http://evan.prodromou.name/Software/Python/LRUCache, however the python-table developers have modified it significantly for there own use, albeit with the same file and class name.
Does this still constitute a bundled library or is it OK to include as is?
The file in question lrucache.py is released under the AFL license and is attributed correctly in the python-tables source (by way of a copy of the original lrucache license).
thanks for your help
Brendan
I'm in the middle of reviewing https://bugzilla.redhat.com/show_bug.cgi?id=751925 python-tables and came Toshio's useful link http://fedoraproject.org/wiki/User:Toshio/Unbundling_Python_Modules
The maintainer has licensed the package as multi-license BSD and AFL - on investigating it seems to included another file from a package here http://evan.prodromou.name/Software/Python/LRUCache, however the python-table developers have modified it significantly for there own use, albeit with the same file and class name.
Does this still constitute a bundled library or is it OK to include as is?
The file in question lrucache.py is released under the AFL license and is attributed correctly in the python-tables source (by way of a copy of the original lrucache license).
If it's significantly modified it may qualify for a copylib exception, but you may want to file a trac for FPC for further evaluation. Are there reasons why the modifications haven't been sent upstream?
-J
thanks for your help
Brendan
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Sat, Nov 12, 2011 at 08:41:38AM +0100, Brendan Jones wrote:
I'm in the middle of reviewing https://bugzilla.redhat.com/show_bug.cgi?id=751925 python-tables and came Toshio's useful link http://fedoraproject.org/wiki/User:Toshio/Unbundling_Python_Modules
The maintainer has licensed the package as multi-license BSD and AFL - on investigating it seems to included another file from a package here http://evan.prodromou.name/Software/Python/LRUCache, however the python-table developers have modified it significantly for there own use, albeit with the same file and class name.
Does this still constitute a bundled library or is it OK to include as is?
Yes, it still counts as a bundled library. The modification does not look that drastic (then again, the entire code of LRUCache is pretty small :-)
The three things I see are
* the removal of mtime as an attribute (a brief glance doesn't show any conflicts with the new code. Perhaps, this was just not being used so they felt they were "cutting fat".) * the addition of the pop() method. (This doesn't appear to conflict) * Substituting an incrementing integer sequence number instead of using timestamps. The reason for this is unclear. Perhaps it's a performance optimization (replacing call to time.time() with integer addition or perhaps they have external code that messes with the internals of the object or perhaps they implemented their own python extension module to take the place of LRUCache (lrucacheExtension) and they wanted both to use the same internal algorithm.
The tables upstream should send their changes to the lrucache upstream to see if any or all of their changes could be incorporated in later upstream versions. The changes look like they could benefit any users of the code.
This aside, though, there appears to be an easy out for the Fedora package. If I'm reading the python-tables code correctly, lrucache.py is only used in ./tables/file.py and only if the extension module that the python-tables authors wrote is not present (For instance, if the extension would not compile on a particular system.) So we can probably get rid of lrucache.py altogether.
This should still be brought up to upstream. They may tell us that lrucache is being used in some manner that I'm not seeing. Or they may realize that they can get rid of the bundled copy of lrucache upstream (which would allow them to drop the AFL license conditions as well :-). I see that another file in the module: ./tables/table.py is importing tables.lrucacheExtension unconditionally so that's either a bug and they need to include a fallback on misc.lrucache there or they have already decided that they must have their extension and misc.lrucache.py has simply been left in the upstream module by accident.
The file in question lrucache.py is released under the AFL license and is attributed correctly in the python-tables source (by way of a copy of the original lrucache license).
I'm glad to see that it includes a copy of the license itself -- it's licensed under the AFL-v2.1 which isn't easily available online anymore (having been deprecatd by its author who promotes AFLv3 in its place).
-Toshio
On 11/12/2011 09:28 PM, Toshio Kuratomi wrote:
On Sat, Nov 12, 2011 at 08:41:38AM +0100, Brendan Jones wrote:
I'm in the middle of reviewing https://bugzilla.redhat.com/show_bug.cgi?id=751925 python-tables and came Toshio's useful link http://fedoraproject.org/wiki/User:Toshio/Unbundling_Python_Modules
The maintainer has licensed the package as multi-license BSD and AFL - on investigating it seems to included another file from a package here http://evan.prodromou.name/Software/Python/LRUCache, however the python-table developers have modified it significantly for there own use, albeit with the same file and class name.
Does this still constitute a bundled library or is it OK to include as is?
Yes, it still counts as a bundled library. The modification does not look that drastic (then again, the entire code of LRUCache is pretty small :-)
The three things I see are
- the removal of mtime as an attribute (a brief glance doesn't show any conflicts with the new code. Perhaps, this was just not being used so they felt they were "cutting fat".)
- the addition of the pop() method. (This doesn't appear to conflict)
- Substituting an incrementing integer sequence number instead of using timestamps. The reason for this is unclear. Perhaps it's a performance optimization (replacing call to time.time() with integer addition or perhaps they have external code that messes with the internals of the object or perhaps they implemented their own python extension module to take the place of LRUCache (lrucacheExtension) and they wanted both to use the same internal algorithm.
The tables upstream should send their changes to the lrucache upstream to see if any or all of their changes could be incorporated in later upstream versions. The changes look like they could benefit any users of the code.
This aside, though, there appears to be an easy out for the Fedora package. If I'm reading the python-tables code correctly, lrucache.py is only used in ./tables/file.py and only if the extension module that the python-tables authors wrote is not present (For instance, if the extension would not compile on a particular system.) So we can probably get rid of lrucache.py altogether.
This should still be brought up to upstream. They may tell us that lrucache is being used in some manner that I'm not seeing. Or they may realize that they can get rid of the bundled copy of lrucache upstream (which would allow them to drop the AFL license conditions as well :-). I see that another file in the module: ./tables/table.py is importing tables.lrucacheExtension unconditionally so that's either a bug and they need to include a fallback on misc.lrucache there or they have already decided that they must have their extension and misc.lrucache.py has simply been left in the upstream module by accident.
The file in question lrucache.py is released under the AFL license and is attributed correctly in the python-tables source (by way of a copy of the original lrucache license).
I'm glad to see that it includes a copy of the license itself -- it's licensed under the AFL-v2.1 which isn't easily available online anymore (having been deprecatd by its author who promotes AFLv3 in its place).
-Toshio
Thanks for the thorough answer! That gives me enough to put the packager in the right direction. I'll pass on your analysis and recommend containing upstream.
Thanks again,
Brendan
packaging@lists.fedoraproject.org
-
Brendan Jones -
Jon Ciesla -
Toshio Kuratomi