Here's a link to a thread from Riovolution which is a site dedicated to Rio audio products.

http://forums-riovolution.com/index.php?showtopic=7500

Quote from developer, "I eventually found a decoder source download and it's licensed under the LGPL. This rules it out for Karma irrespective of patent issues."

This is a topic about supporting MPC for the Rio Karma and it got a developer of the Rio Karma involved. Plainly for the Rio Karma or any of it's products to support MPC it needs to be BSD licensed. If this is the case for all manufactures of DAPs, then here's more proof that MPC's DAP support looks more grim by the day.

LGPL requires publishing changes made to the library - it would probably expose confidential stuff to get a working hardware decoder.

Yeah, exactly right Garf. That developer just explained...

"As with most embedded operating systems, Ecos, used in Karma, requires the whole application to be linked as one monolithic binary. The licensing conditions of the WMA DRM stuff require us to forbid reverse-engineering of that binary; the licensing conditions of the LGPL forbid us from forbidding reverse-engineering. We thus cannot incorporate both in the same firmware build, and we believe that WMA DRM is considerably more popular.

The BSD licence used by Vorbis does not have this conflict."

I'm no licensing expert, but isn't it possible (for the author) to offer software/code under multiple licenses? Perhaps Klemm could exclusively grant RIO a BSD license for the decoder.

so let me get this straight. the decoders all have to be put into one big file. WMA requires that the decoder not be open-sourced. MPC requires that it be open-sourced, thus the problem. so it's a minor legal problem, not a technical or copyright problem.

wow, that's terrible. that MS is getting exactly what they want with their cr**y format.

Even if there were no DRM issues, I doubt they would like to opensource their firmware.

Wouldn't it be possible to offer two firmwares (one with MPC but no WMA and one with WMA but no MPC)? AFAIK, iRiver has MP3 and WMA support in one firmware and MP3 and Ogg Vorbis in another firmware.

an easier solution would be for MPC to make an exception for the LGPL

The decoder sources this guy had a look at is probably not the normal L-GPL decoder, but the ARM version written by this Chinese MPC friend.

I am not 100% sure, but IIRC he was using large portions of the MAD decoder lib for ARM for his MPC decoder, and this makes it impossible to relicense the complete decoder under the BSD ....... someone with a better knowledge than me to clarify please .....

It migh also be Peter's decoding library. The same limitation applies, since his lib is under LGPL.



It's worth noting that the developer said that "This rules it out for Karma irrespective of patent issues." (my emphasis). So, even if the software licensing is changed to BSDish, they would still want patenting and technology licensing information. Is there anyone able to provide this information to them?

BTW, yes, it's copyright problem, since only the copyright owner can change the license or license the code under different terms to selected parties.

You don't know that. It's like ogg, when you find patents in the code, let us know.

Anyway the few patents that may be in MPC would be covered in mp2 licencing, Frank has stated this in the past.

Nobody knows that. That's precisely why hardware developers are afraid of supporting MPC.

Even though Xiph doesn't guarantee Vorbis' patent-freeness, it was coded with an effort in mind to avoid all known patented techniques. The same can't be said about MPC.



First, that is not guaranteed. And Frank isn't a patent lawyer.

Second, that doesn't matter. Even if Rio already licensed the algorithms for MP2, that doesn't protect them if the very same algorithms are being used in MPC.

The reason: As per the MPEG's determination, patent holders of technologies used in their standards that are WG members are forced to license these technologies in fair and non-discriminatory basis - for standard compliant applications only. For non-compliant applications (that is the case with MPC), they can go nuts on price, or refuse to license at all.
That is a dispositive created by the MPEG to allow technology contributors to license their technology on different terms for applications not related to MPEG. Otherwise, they would be locked to a licensing scheme that might not be interesting depending on the situation.

Indeed original author can do this.

Cheers,
cartman

It does, I am certain for devices shipped in large numbers (ie half a million players) they will be paying just a one off license fee, which allows them as a company not to infringe on that long list of patents they have (if we are talking mp3), I am guessing mp2 is pretty much the same stuff.

Actually, the whole point of the LGPL is to avoid this kind of problem. If it was GPL licensed, they would have to release the source for everything but with the LGPL they should only have to release the source for the actual LGPL licensed the library, not the other parts of the application that link to it.

Even if that's not correct (and if it's not, I don't know what the point of the LGPL would be), Peter has the option of making a special license for the Rio folks (and I encourage him to do so). He could even make a license that preserves the spirit of the LGPL just for his code while explicitly excepting all other code they would link to it.

On the other hand, I suppose it's the WMA license that's the real viral troublemaker here. Does it require that all code linked to it (even stuff that's unrelated) be covered under the same restrictions?

Right, but they will probably have to make modifications to the library that would expose confidential internals of their hardware if they released it under an upen source license. That's what Garf meant with his first post in this thread.

rjamorim:
That doesn't actually seem to be the problem, as the first post talks about it.

The LGPL states this in section 6:
"6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."

In other words, you have to allow reverse engineering in your terms of any work that uses the LGPL libraries.

And like he says:
"The licensing conditions of the WMA DRM stuff require us to forbid reverse-engineering of that binary"

So there's an instant incompatibility. One requires you to not forbid it, the other requires you to forbid it. Bam, can't use both.

This is one reason I dislike the LGPL. It claims to be compatible with closed source software, only requiring changes to the library itself to get re-relased and shared, but that is in fact not true at all. Section 6 of the LGPL prevents most companies from using LGPL'd libraries, no matter how much they want to do so, because there is often no way to get the lawyers to not forbid reverse engineering in the licensing for the final product.

All this trouble can be avoided if we can get a BSD licensed decoder. If that does happen next comes the patent issues concerning mp2.



If this was the case all it would take would be for Rio to implement a BSD licensed decoder to their firmware. I'm going to ask the developer if, granted a specially BSD licensed decoder what would come next in the chain of accepting the format support. Patent issues? Or just acceptance? Or something else?

We still don't know if only MP2 patents apply, or if they apply at all. We only have the opinion of a non-lawyer that didn't even develop the format himself. Asking Andree might shed more light on the issue, but I guess it would still be insufficient.

Well yeah, which is why I asked the Rio developer what comes next if granted a specially licensed BSD decoder. Either they won't care about patent issues (very doubtful) or, like Spoon said, their array of patents already includes any mp2 specifications. The most likely case regarding patents is format support would not be granted on the basis of patent uncertainty.

Right. I bet they aren't willing to take risks for a format that isn't even on high demand.