Bug#469397: RFS: xbmc
On Thu, Dec 17, 2009 at 12:42 PM, Andres Mejia <mcitadel@gmail.com> wrote:
> On Wednesday 16 December 2009 21:15:40 Paul Wise wrote:
>> 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".
You cannot satisfy both the GPL and these clauses at the same time,
which prevents distribution of XBMC in binary form at least.
> 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.
With an LGPL/BSD XBMC you can satisfy the license of both XBMC and the
non-free stuff at the same time.
> 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.
They conflict with the GPL, so they keep it from being uploaded to
Debian at all.
>> 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.
Good to hear, but until that work is complete, XBMC is not
distributable by anyone who doesn't want to violate the GPL (which
includes Debian ftpmasters).
>> 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.
Ah, that means you will be adding the 447th copy of md5.c to Debian.
Could you instead dynamically link against one of the crypto libraries
(Fedora prefer libnss, Debian doesn't have a standard crypto lib) and
use the implementation from that?
> 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.
Good to hear.
> I really don't want to resort to having to change the source tarball anymore
> from the original than it already is.
It would be good to get these removed upstream too. For OSes without
adequate packaging/repository systems you could create a separate
tarball containing tarballs with code from all the projects you depend
on. An example of this is warzone2100's devpkg:
http://download.gna.org/warzone/development/devpkg/
>> 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.
I see from the get-orig-source script that you removed them from the
tarball too, great.
> 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.
Ah, sorry for looking at the outdated copyright information.
>> > 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.
That was how it was presented during initial discussions of the field,
seems like that policy was never written down where the relevant
persons would see it and current practice is to add it wherever
possible, sigh :(
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: