LGPL or BSD-Style License for Media Codecs?

Josh Coalson asks: "I am the author of FLAC, an open-source lossless audio codec. The core of the project is a reference encoder/decoder library currently licensed under the LGPL. As the format grows more popular I am being been approached by third parties about implementation in proprietary hardware systems. This is natural and I don't have anything against it, but several people are voicing concerns that the LGPL is too strict for use in embedded systems. I want the codec to remain Free, but then again, wide adoption of a format makes it more useful to all users."

"More specifically, the nature of many embedded systems force them to be bound by the stringent requirements of Section 6 the LGPL. In some cases, dynamic linkage is not possible, ruling out 6(b), or causing the terms of the FLAC library to come into conflict with other proprietary libraries. In other cases, it simply is not possible to provide an environment, according to 6(a), where the user can re-link with a different copy of the library.

What are my options? I could stick to my guns, which might limit the adoption of the format, or change the license. I know Vorbis uses the BSD license, but I feel strongly about modifications that are useful for others going back into the free code base. Perhaps there is another middle-ground license that could preserve the Freedom of the code in these cases? Or maybe I am not interpreting the verbiage of the LGPL correctly? Can't I have my cake and eat it too?"

Comments

Oh don't worry about licensing...

[tswinzig]

If the people really like your media format, they will just use it however they like, even if its patented.

Just look at MP3.

Now for a more serious answer... Why don't you just re-license it to specific companies that you want to see use it? Maybe even for a re-licensing fee, so that you can make some money off your open source software.

use the BSD license

[TheGratefulNet]

speaking as a software developer who works on embedded systems (routers, in my case), there's just NO WAY we'd ever touch anything that wasn't BSD. in all the jobs I've had that used any form of unix in our product, it either was BSD style licensing or it was ignored by us.

the legal issues are just not worth messing with. case in point - we've had to go out of our way to NOT use libreadline since its so 'hardline' on being GPL. it would be great to be able to use it, but we fear having to release our own code just due to the overzealousness of GPL when it comes to touching our own proprietary code.

I can say for sure, if you care about getting your code in shipping commercial products, consider BSD licensing. be aware that there's nothing forcing a company to pay or even ask you if they can use it, then. otoh, even when we were willing to compensate the readline author, he didn't want to consider any other licensing scheme, so we 'walked away' and had to find another lib to solve our problem.

GPL is a total mess when it comes to a commercial company that wants to ship a product without fear of being told it has to release ALL its code (even its local home-grown code).

I'm a major linux fan. I like the idea of opensource. but I also have to work for a living and that means writing software that will be owned by the company and never ever given out. there IS a balance - and GPL ain't it.

Re:Change your business model

[Erasmus Darwin]

"You should also ask yourself: who would potentially object to an LGPL code base rather than one licensed under the BSD license? My guess is that the only people who would benefit from you using the BSD license in this case are parasites who seek to sell your hard work for their own personal profit."

If you reread the article text, you'll see that it emphasizes embedded systems. These are people doing things that would be 100% A-OK if they were using the same business model on a regular, full-featured PC where dynamic linking was an option. More specifically, someone can already write a closed-source, commercial player that only dynamically links with the LGPL'd codec.

However, in an embedded system, resources tend to be much more scarce. You don't always have the luxury of people able to dynamically link in the codec. It's still the same conceptual act of providing a commercial player that uses a free codec, but it violates the license due to hardware constraints.

I will agree that the BSD license would benefit parasites interested in pulling an embrace-and-extend on the FLAC standard itself, but it also benefits people who want to be able to, say, add FLAC support to an existing portable mp3 player without giving away all their non-FLAC-specific code on that system. While such a case is contrary to the hardcore free software goal (everything should be free as in speech), I don't think it necessarily violates the FLAC goals, as FLAC was obviously consciously placed under the more flexible LGPL.

Just remember one thing...

[Todd Knarr]

You own the code. Nothing says you have to license it under only one license. So, simple solution. License it to the public under the LGPL. If someone wants to use it in a proprietary embedded device, license it to them under a conventional license or whatever license you want. You can do that, you're the owner of the code. The two licenses won't interfere with each other, as long as you make sure to include in the proprietary license wording to the effect that this license is non-exclusive and does not affect your licensing of the code to other parties under other terms. You give the proprietary people what they're happy with without endangering the free nature of the code as licensed to everyone else.

Individual Function Linking

[Milican]

Embedded developers don't want to include an entire library if all they need is one function. I am an embedded developer myself and I don't use common c functions like printf or scanf unless I know I have some memory to spare. The reason is because as soon as you use one of these functions the whole dern library with all the other zillion functions is linked into your executable, and this of course makes a big executable. Sometimes you can't fit your program into the scarce memory because of it.

However, there is an elegant solution. The solution, which I discovered by using some ThreadX code, is to implement each function in a separate file. That way you only link in the functions you need on a function by function basis! The result for ThreadX is an extremely configurable kernel with very lean code size.

Therefore, I think you should keep the library licensed as LGPL and separate all of the functions into individual source files. As you guys know the LGPL only governs the library not any of the files that use the library like GPL. So if you or anyone else (embedded developers too) makes changes to the library they are required to let everyone else know about it. This has nothing to do with the application. In this case the embedded developers seem to want the BSD license so they can only put in what they need of the code, or in a worst case scenario they may want to rape and pillage the code and not give back to the community.

In summary, by keeping the code licensed under LGPL and separating your files out function by function your library will be lean for embedded developers, keep developers both commercial and non-commercial contributing to your code and prevent parasitic companies from making money off of your hard work without giving back a thing.

As an additional guide here are some links regarding the license models:

• Open Source License Quick Reference Chart
  
• Open Source Licenses
  

Enjoy.

JOhn