FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 11-12-2011, 06:41 AM
Brendan Jones
 
Default python bundled library question

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-12-2011, 06:39 PM
"Jon Ciesla"
 
Default python bundled library question

> 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
>


--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-12-2011, 07:28 PM
Toshio Kuratomi
 
Default python bundled library question

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-12-2011, 08:38 PM
Brendan Jones
 
Default python bundled library question

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 mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 11:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org