Bug#469397: RFS: xbmc
On Wednesday 16 December 2009 21:15:40 Paul Wise wrote:
> On Thu, Dec 17, 2009 at 8:59 AM, Andres Mejia <mcitadel@gmail.com> wrote:
> > XBMC is licensed under the GPL-2+. There are various third party code and
> > libraries used as well, documented in the copyright file. There are also
> > various files and third party code used with licenses that have non-DFSG
> > clauses. None of the licenses makes XBMC undistributable however, which
> > is why the xbmc packages are being placed in non-free. Work is being done
> > to resolve these licensing issues. See [1] for more details.
>
> ...
>
> > 1. http://xbmc.org/trac/ticket/7983
>
> Sounds undistributable to me (not even non-free), unless the XBMC
> license is changed to the LGPL or there is a GPL exception for linking
> against non-free code.
Which license/issue are you referring to? Last I checked, all these
problematic licenses had clauses like "you can't use this for commercial
purposes", "you must send us patches upon request", or some other stupid
clause like "you must not code on any Monday at 3:05pm in someone else's
bedroom".
Even if XBMC were changed to LGPL, BSD, or whatever, I don't see how that will
help with the third party code with these other restrictions.
So as far as I know, XBMC is at least distributable. It just unfortunately has
some code that contains other restrictions like these nagging non-commercial
clauses, which is keeping it from going to main.
> There are several bits of code that are free software but GPL
> incompatible, you need to replace/remove these.
Ok, yes. I did say it's being worked on.
> For the RSA MD5 implementation replacement you should use the
> implementation from whatever crypto library you link against, instead
> of introducing the 447th[1] copy of md5.c into the archive:
>
> http://source.debian.net/source/search?path=md5.c
Alright, my fault for overlooking that. :/ I'll simply use the public domain
implementation from dpkg.
> >From what I can tell from the copyright file, there are also vast
>
> amounts of embedded code copies, please have them all removed from the
> upstream tarball before seeking sponsorship again. If that isn't
> possible, please consult the security team to ask if it is OK to have
> this amount of embedded code copies in one package, even Mozilla isn't
> quite this bad. For stuff that isn't in the archive yet, you should
> package that instead of creating an embedded code copy.
Yes, there are third party libraries in the source tarball. Most however is
not used at all (at least when the proper configure switch is set to make XBMC
build against system libs). At least for Debian/Ubuntu, the default would be
to have XBMC use system libs. We (as XBMC upstream) eventually want to make
use of system libs where available, and not just for Debian/Ubuntu.
I really don't want to resort to having to change the source tarball anymore
from the original than it already is.
> libdvdcss isn't available from Debian for good reason, it should
> definitely not be available in xbmc.
And it's not. It's was included in the copyright file as a way to give credit.
I suppose I'll remove it to avoid confusion.
> Another WTF was a non-free implementation of CRC32 of all things!??!!
>
> This indicates XMBC is not yet ready for Debian: "Copyright Microsoft
> Corporation. All rights reserved. License: UNKNOWN", please withdraw
> this RFS and remove the package from mentors.debian.net until the
> copyright/license issues are resolved.
Ok. This was clarified in the Trac bug log as already being resolved. I guess
I'll clarify it here too. That copyright file is somewhat outdated. I only
included it in the bug log to make it somewhat easier to find the issues I
found. I changed the copyright file seeing that it was becoming harder to read
by humans.
So, there isn't any use of a non-free implementation of CRC32, or anything
that's copyright to Microsoft.
Again, as far as I know, XBMC is distributable. It unfortunately contains some
code that's keeping it from entering main.
> > The 'DM-Upload-Allowed: yes' field is set. I am a DM and also one of the
> > upstream devs for XBMC. I would like to keep this field set so that I may
> > be able to upload this package myself. If any potential sponsor
> > absolutely has a problem with this, I would be willing to unset it (or
> > have it unset), of course after some negotiation.
>
> The DM-Upload-Allowed field is for sponsors to set after they are
> satisfied that you can maintain the specific package well. You should
> never include it in your first RFS.
I can't find any information that states the field should be set by sponsors.
Seeing that I have been sponsored before for other packages with the field set
(after I told my sponsors), I would rather wait for a sponsor who's willing to
upload with the field set.
> > The package also appears to be piuparts clean, although some dependencies
> > of xbmc is causing the piuparts test to fail. Relevant log message.
>
> ...
>
> > Packages causing this are 'fontconfig', 'python-support', and
> > 'python-apt'.
>
> It would be helpful to file bugs here if they don't exist yet.
Ok. Will do.
--
Regards,
Andres
Reply to: