[Tahoe-debian] debian/copyright

[bertagaz at ptitcanardnoir.org]

Hi,

Glad you had the courage to have a look at this licenses issues.

On Wed, Jun 15, 2011 at 05:53:14PM -0400, micah wrote:
> 
> I poked around in debian/copyright and found a few things that I think
> may cause the package to get rejected from Debian's NEW queue, I've made
> a couple changes, but I think we need to decide what to do about some
> things. I've CC'd Zooko on this email because there are some questions
> for you.
> 
> First, here are the changes to the debian/copyright:
> 
>  . updated Copyright to span 2011 after finding some file that declares
>    it
>  . removed duplicate pointer to the GPL
>  . removed pointer to the LGPL, since the source never declares that
>    license
>  . re-ordered things to be more clear
>  . removed the section on mac/fuse.py and mac/fuseparts/subbedopts.py as
>    those files don't seem to exist anywhere in the source we have
>  . removed the section on src/allmydata/util/figleaf.py as that file
>    doesn't exist anywhere (and it declares a BSD license, which would need
>    to be clarified about which BSD license)
>  . removed the copy of the BSD license, which was a bit strange because
>    it said Copyright (c) <YEAR>, <OWNER>, and didn't say what source
>    fell under that license.
> 
> Now the problems:
> 
>  . there is an embedded setuptools (setuptools-0.6c16dev3.egg), which is
>   licensed under the PSF or ZPL. I'm not sure I know what the PSF
>   license is, and ZPL is probably Zope Public Licnese? Can someone
>   clarify? Whatever these are it needs to be declared in the
>   debian/copyright file.
> 
>  . setuptools_darcs-1.2.12.egg is licensed under "BSD" - but it doesn't
>    say what BSD, I believe we need clarification if this is the
>    two-clause, three-clause, or million-clause BSD :)
> 
>  . worse than above is that these are modified and embedded setuptools,
>    and it appears, based on my poor reading of setup.py, that they are
>    used for the build process. embedded code copies are frowned on in
>    Debian, and modified versions of code copies are even worse. if tahoe
>    is going to fork setuptools for its own purposes, the changes should
>    be set upstream, or a proper fork maintained. How are updates to this
>    embedded copy managed? What about security fixes?

Actually, the Debian package patches setup.py so that it doesn't use the
setuptools egg or darcsver egg shipped in the tahoe sources. I think this
trick was already used in the ubuntu package.

I'm not sure the tahoe package will be rejected though, as for exmaple the
python-zfec package ships the same .eggs and has been accepted. Same for
the python-pycryptopp package. But we'll see...

bert.