Neil Williams wrote:
> On Thu, 2008-04-03 at 12:12 +0100, Robin Cornelius wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "xmlrpc-epi".
Hi Neil, thanks for your time on this.
>
> 2. expat - debian/copyright quotes this as being dual-licenced MPL or
> GPL but does not note that the expat code itself is neither compiled nor
> distributed in the Debian package, only in the upstream source. (It may
> be an idea to see if upstream would consider splitting it into a
> separate source tarball.) The problem is that GPL-2+ code cannot be
> compiled into (or linked against) a shared library that also includes
> code under the PHP licence and although the build does not do that, it
> also does not state that the expat code is not actually packaged. (The
> MPL is also incompatible with the GPL but that isn't a problem in your
> case. I must admit, I'm not sure if the MPL is compatible with the PHP
> licence.)
> http://www.gnu.org/licenses/license-list.html
1) It probably would be a very good idea to remove the expat source code
from upstream completely and ensure the code builds with the latest
expat from expat's upstream instead of carrying a specific copy.
2) the php licensed code is only required to use libxml2 and in fact
just provides API compatibility so that expat calls get translated into
libxml2 calls. This code could be entirely removed, thus removing all
php licences but would mean that libxml2 could not currently be used as
the xml parser. This is not necessarily an issue itself.
Its a case of either expat is used in which case no php licensed code is
required or its libxml2 which requires the php licensed compatibility file.
>
> 3. PHP-licenced code in a shared library. In effect, your package cannot
> be used by (i.e. linked against) any GPL code because it contains code
> under a licence that is not compatible with the GPL. That is a
> potential minefield for other packages wanting to use your library and
> needs to be spelt out in debian/copyright.
I think its better to remove this minefield completely upstream.
>
> All content relevant to these issues must be in debian/copyright -
> content anywhere else in the package will be ignored as far as
> acceptance by the ftp-masters is concerned. IMHO, that includes some
> statement that expat/* is not compiled or packaged for Debian and that
> there would be problems combining the expat/* code with the src/* code
> (which is why I find it strange that the two are packaged together).
>
> Files: src/expat_compat.h src/compat.c
> Copyright: (C) 1997-2007 The PHP Group
> Licence: PHP-3.01
> (src/compat.c is part of the packaged library as it is listed in
> src/Makefile.am under libxmlrpc_epi_la_SOURCES. src/expat_compat.h is
> not packaged in the -dev)
Proposal - drop these files upstream and only use expat as the xmlparser
for now.
>
> Files: expat/*
> Copyright: (C) 1998, 1999 James Clark
> Licence: Mozilla Public License Version 1.1 or GNU General Public
> License
> (files not packaged, code not compiled)
Proposal - drop these files upstream, and if necessary package them in a
separate tarball/zip for distros that don't necessary have expat available.
>
> Files: scripts/cvs2cl.pl
> Copyright: (C) 1999 Karl Fogel <kfogel@red-bean.com>
> Licence: GPL-2+
> (build tool? Robin? seems to be an upstream thing - again worth asking
> upstream not to package it in the released tarball).
This should be (will be now) dropped from the source tarball and only be
in upstream
CVS as its a CVS changelog tool.
>
> Quite a collection.
>
Ok i think we can overcome the major problems fairly easily here to get
the package into an acceptable state. Long term the package needs to be
able to nativly use the libxml2 parser *without* that php compatibility
library.
The main reason for this is php5 is a potential user of the library so
it looks like the incompatibilities between expats licence and php
licence are the reason php5 created the compatibility layer in the first
place and a reason why they use libxml2.
The ideal situation in this case IMHO is to have a xmlrpc-epi that
either php or GPL licensed code can linkto but this is going to take a
little work upstream so :-
This is my planned work flow :-
Short term i would like to remove all the php licensed code and the
ability to use libxml2. I will do this upstream then repackage for
debian. This will leave us with an xmlrpc-epi that can only be used by
GPL compatible code, which is probably the better state to be in rather
that a library that cannot be used by GPL code.
Longer term use libxml2 and remove libexpat so that php5 can use the
library if they so wish.
How does this sound?
> (On a better note, I've just got my laptop back from repair {new
> motherboard} and it's working fine - thanks for all your help with
> that!) :-)
>
Woot! thats great
Thanks once again.
Robin
Attachment:
signature.asc
Description: OpenPGP digital signature