[valent]

Hi, first of all thank you all guys/galls for all hard work you put in this marvellous project. This project has been amazing me since 2004 when I installed it for the first time on my XBOX and I still use it and now now also have a new HD HTPC Media Center running Linxu + XBMC.

I have a question regarding XBMC source code and patent issues. I asked around on few mailing lists why XBMC isn't packaged with any of the major distros (Ubuntu and Fedora) and some of answers I got were related with patent issues.

I know that any major distro can't include any program that has some patent encumbered code like audio/video codecs. What I see that developers do is that they split source code into two parts; clean code and "dirty" code.

Clean part of source code can be used without any issues and freely distributed then with any linux distro and without fear from lawsuits.

"Dirty code" is usually packaged separately via 3rd party repositories (non-free part of repository on Ubuntu and RPM Fusion repository on Fedora).

If this could be done for XBMC then Linux distros could easily package XBMC and include it in it's repos. XBMC would have all the functionality that is usually has but out-of-the box would only decode open formats like OGG Theora and OG Vorbis.
When users would install aditional XBMC codec-package from 3rd party repository they would get full support for all media files and formats.

Could this be done? Is is already done but Linux distros aren't taking advantage of this?

Thank you once more and please give some feedback regarding this topic.

Cheers!

[outleradam]

I call taboo.

However, since everything was ported from XBOX to Linux, I believe the Linux distro should be "clean", unless it was a direct port.

[spiff]

wtf does its xbox origin have to do with anything?

this would be up to packagers. while somewhat awkward, what you suggest can be achieved.

[wstewart]

why would you ever want to package XBMC with a distro? The dev's have done an excellent job setting up package repositories that are straight forward to install from. I don't see what the advantage is.

Coupling distro releases with XBMC release schedule I don't see working well. To get the most out of XBMC, it is always best to use the latest and greatest. Once a distro is released they usually never put newer package versions in the repository, only bug fixes. Coupling it with a totally different release schedule will always put that version of XBMC behind the current.

Besides isn't XBMC-live more or less coupled with a distro?

[outleradam]

wtf does its xbox origin have to do with anything?

Well, not much now. I'm just saying that it used to be something that M$ could have shut down if it wanted to. Now it's code does not rely on M$ code.

[althekiller]

Being packaged with distros is win-win for us. We can focus on what we care about, XBMC, not what we don't, distributing binaries of XBMC. Distro maintainer's know their environment better than we care to and have the skills to fix specific problems there. This gives us better portability. Distros have their own, competent and skilled support channels. This alleviates our's of dealing with distro specific quirks which we'll, at best, be poking blindly at. Also, we'll get more quality bug reports and patches, specific to XBMC, from people striving to improve their distribution.

On the original topic, collecting a list of the so called "dirty" portions of XBMC would be helpful. Odds are most of them could easily be runtime detected. There's already a branch to clean up licensing issues (according to debian's rules) in our code. However this doesn't address distribution of codecs and what not. Just source code licensing.

[valent]

I call taboo.

However, since everything was ported from XBOX to Linux, I believe the Linux distro should be "clean", unless it was a direct port.

What do you mean by "I believe the Linux distro should be clean", I don't understand your point.

[valent]

Being packaged with distros is win-win for us. We can focus on what we care about, XBMC, not what we don't, distributing binaries of XBMC. Distro maintainer's know their environment better than we care to and have the skills to fix specific problems there. This gives us better portability. Distros have their own, competent and skilled support channels. This alleviates our's of dealing with distro specific quirks which we'll, at best, be poking blindly at. Also, we'll get more quality bug reports and patches, specific to XBMC, from people striving to improve their distribution.

On the original topic, collecting a list of the so called "dirty" portions of XBMC would be helpful. Odds are most of them could easily be runtime detected. There's already a branch to clean up licensing issues (according to debian's rules) in our code. However this doesn't address distribution of codecs and what not. Just source code licensing.

Thank you for your understanding, and I also believe that having XBMC packages of Linux distros would be a win for XBMC project.

I can give you a point in the right direction via ForbiddenItems [1] Wiki page on FedoraProject web site. There you can find a comprehensive list of that kind of software can't be included in Fedora but also in most distributions (Ubuntu, Debian, etc...)

It boils down to these three points:
* If it is proprietary, it cannot be included in most Linux distros.
* If it is legally encumbered, it cannot be included in most Linux distros.
* If it violates United States laws (specifically, Federal or applicable state laws), or European laws it cannot be included in most Linux distros.

This can be a nice starting point. If you need some more help, and if I can help in any other way I would be more than happy to help you.

[1] http://fedoraproject.org/wiki/ForbiddenItems

Cheers!

[jmarshall]

As far as patents go, FFmpeg and possibly some of the audio codecs are likely the only things in XBMC that could cause issue. As far as legality goes, libdvdcss is the main sticking point.

You can assist by going through the dependencies of XBMC and identifying any libraries that we use that may be questionable. Once we have that list, we can take it to those who know about these things to make decisions.

Cheers,
Jonathan

[TheQuestor]

Can XBMC function well without distributing libdvdcss and FFmpeg? I know it won't play 1/10th of the vids or protected DVDs without them, but you could always add a funcrtion within XBMC to download the needed codecs as they are required or a link to download the needed files manually which should allow you to "unburden" XBMC enough to make it palatable to the maintainers of those distros.

I can't see it being that hard to get this sucker included. Ubuntu seems to come with Totem which is ok, but NOTHING like XBMC I do see it being a win win for everyone if this were to happen. This and Tuner support

[fiveisalive]

Thank you for your understanding, and I also believe that having XBMC packages of Linux distros would be a win for XBMC project.

I can give you a point in the right direction via ForbiddenItems [1] Wiki page on FedoraProject web site. There you can find a comprehensive list of that kind of software can't be included in Fedora but also in most distributions (Ubuntu, Debian, etc...)

It boils down to these three points:
* If it is proprietary, it cannot be included in most Linux distros.
* If it is legally encumbered, it cannot be included in most Linux distros.
* If it violates United States laws (specifically, Federal or applicable state laws), or European laws it cannot be included in most Linux distros.

This can be a nice starting point. If you need some more help, and if I can help in any other way I would be more than happy to help you.

[1] http://fedoraproject.org/wiki/ForbiddenItems

Cheers!

Hi Valent, as you may know, I'm trying to package this for the Fedora-compatible RPM Fusion:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=1030

For reasons that I outlined in the post here:

http://lists.rpmfusion.org/pipermail/rpm...07036.html

it's unlikely that XBMC could go into Fedora-proper, at least for now. Initially it's probably better to get it into RPM Fusion, perhaps down the track it might be possible to migrate some of it to Fedora and leave the problematic audio/video codecs in RPM Fusion.

Perhaps upstream can clarify whether XBMC can read *any* audio/video content without ffmpeg support? Will XBMC even compile or run without the ffmpeg library?

[spiff]

compile yes, run, no video whatsoever.

[fiveisalive]

compile yes, run, no video whatsoever.

Right, that's what I figured. Is there a possibility that video support could be autodetected dynamically at run-time and used by XBMC when an additional package was, say, installed. i.e. in the same way that the presence of codecs in gstreamer plugins can be autodetected at runtime.

Also, does this also apply to audio? Is ffmpeg used for audio playback too?

[spiff]

some audio, but most have dedicated codecs. we can't really detect it atm, but we will fail graciously. build won't though.

[rcoops]

A silly question most distro's are able to play video and audio I assume they have some for of codec's delivered with the package. If XBMC could be set to use these by default then the not play anything and likely even the not compile at all could be resolved.

For more difficult codecs (in what ever way you like to specify difficult) could then be coming from the 3rd party location(s) that way XBMC would be able to install and do the basics the rest could be enabled by grabbing more codecs. That is pretty much the way things work anyway so why not for XBMC?