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.

If the code is yours...

[Molech]

IANAL, This may have been said already, but if the code is all yours(or if contributors have signed over the copyright), its yours to do with as you see fit. That includes relicensing(maybe for a fee, maybe not) with companies doing embedded systems. Now what gets sticky is if you have accepted patches not written by you, then you are bound by LGPL on that code, and thus can't do that, but if all the code is yours go for it.

Re:If the code is yours...

[Arethan]

This is exactly what Sleepycat Software does with Berkely DB.
They will accept patches to their code, but not many of them ever make it in, and the ones that do make it in have the requirement of having the copyright signed over to Sleepycat. Effectively making them the sole owner of the codebase. Which, in turn, allows them to sell a relicensed version of their code to embedded manufacturers. Using this model, they've kept a positive income since day 1.

Re:If the code is yours...

[renehollan]

If there is a free version, and your code is useful (and flac looks like it is), you will get patches. It would be a pain to not be able to include them in the non-free version if only because of the maintenance difficulties that a license-based fork would cause.

Of course, contributers could agree to let their contributions be dual-licensed as well, but it strikes me as unfair that you'd get paid by proprietary licensees for those contributions and the contributors get nothing. This would discourage dual-licensed contributions and lead to a license-based fork soon enough. This would be less of a problem, I suppose, if you received no compensation from proprietary licenses, but that would be unfair for you.

There is a way out, though, that would (I think) let you GPL the code, and still be able to use it in proprietary products, but it is one hell of a kludge, and relies on a fair amount of trampoline code.

The GPL requires all statically, and depending on who you ask, dynamically (RMS, of course, says "yes, dynamically too" [my paraphrase]), linked code to be GPL if the result is distributed (an exception is made for libraries normally provided with the O/S, but what is O/S and what is app gets sticky in an embedded environment). However, non-complex communication with non-GPL code via pipes or sockets is O.K. "Non-complex" here is a matter of interpretation, but a classic server or filter utility is generally fine.

It strikes me that a codec can be interpreted as a filter, or simple server, in a loop-backed TCP/IP networked environment, so this could work. Is this overkill? Sure, but it would avoid the licensing issue completely: embedded systems could just ship with the source. I suppose that even that would not be necessary if the system were ordered on-line -- then an FTP server would suffice.

From a technical standpoint, this does introduce a lot of pressure on the embedded side: you need a whole TCP/IP stack and ROM and RAM tend to be precious in such systems. The overhead of packetizing and unpacketizing will require a bit of a beefier CPU to boot. I tend to think that even the smallest embedded systems today could handle that, but it is a concern. Of course, the network type the sockets use doesn't have to be AF_INET, permitting some short-cuts.

As a bonus, the pipe- or socket-based codec would be useful in a processing stream on non-embedded systems -- if you provided a traditional library instead, someone would quickly write such a filter (in the Unix sense, not the audio sense) app anyway.

Re:If the code is yours...

[bfree]

Traditional Flamebait, traditional response :-)

The problem with the BSD approach of "people should be free" is that it gives people the freedom to destroy the work upon which they are building. What if MS had realised early enough that the Internet was the Next Big Thing and had incorporated the BSD TCP-IP stack in from Dos 3 (for example) but they had modified it slightly so you could work on the MSNet or the Internet? Who would have won the war? Would the net have split? It seems ridiculous now, but then it could have been fiery if they had done early enough!

The GPL is far more than a BSD licence, it imposes a simple (in theory and concept but maybe not practice yet) set of rules which say that anyone who receives the work under it cannot undermine the project by releasing closed incompatible versions. What if MS now pick up Ogg Vorbis and use a minorly modified but incompatible version for their prefered audio format from now on? These new users will be orphans from the existing user base, benefiting from its work, but unable to benefit from the Freedom they would have had were it still GPL. So BSD does not make people free past one generation (each BSD receiver is free to do what they want, but their users are not free) whereas the GPL makes the software Free and all the users free, the developers are as Free as is possible while preventing them from having the opportunity of reverting some of the benefits of the Freedoms the GPL is designed to uphold.

Ogg Vorbis Went Through This

[gagravarr]

Initially, ogg vorbis was GPL/LGPL. They to wanted lots of people to use the format, implement it in hardware etc. The result is that sometime around Beta 3, they went over to the BSD style license.

Ogg Vorbis Example

[jeriqo]

Maybe you should use both licenses, like OggVorbis did.
The bundled OggVorbis utility software is released under the terms of the GNU GPL, and, the libraries and SDKs are released under the more business friendly BSD license.

Note that developers are still free to use the specification to independently write closed-source implementations of OggVorbis which are not bound by these licenses.

Change your business model

[Walter Bell]

As somebody who has worked on a few commercially available embedded devices, I would like to comment on this:

The LGPL gives your users quite a few freedoms that they would not ordinarily have under the GPL. To take advantage of this, you will need to change your business plan so that it is based on selling or giving away support, not selling or giving away a scarce product. If the codec is superior and the source code is available, there is no reason why anybody would balk at it being LGPLed.

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. I don't think they're the ones you want to please; your users are more important.

Just my 2c.

~wally

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.

BSD won't let you sofware free.

[famazza]

By using BSD-type license you let your code to every software house uses it as they want. It can even release a version using your "free" code using a non-free license.

Perhaps as you said LGPL will be very restrive for embedded systems, you are almost right, there's no how to recompile embedded software.

I think you have 3 choices. Fork LGPL and build your own version with a special paragraph for embedded systems. Build a special version of your library with another license.

Or you can ask every potencial "user" (the library user is the programmer/projectist) to find a way to easily update the firmware and allow the user to compile it.

I think that the second option is the best, but you can choose. :o)

BSD license all the way...

[DrBoom]

It meets every definition of "free" that matters.

Sure, someone can take the source and do things to it without feeding it back to the community, but they then run the risk of making their implementation incompatible with everything else. They also bear the burden of maintaining their own fork of the code. Speaking as someone who is considering using flac for internal use in a commercial setting, I can tell you that these are powerful disincentives to doing silly things with the code.

The (L)GPL's virus-like qualities make it a hard sell to the PHB's ... even PHB's like me that believe in free software.

Re:BSD license all the way...

[Asic Eng]

Yes, and if the company taking the code is big enough, they can push their derived implementation on the market. For example by making a nice tool to generate files which use the (slightly modified) codec, and giving the tool give away for free. Then they make the changes a "trade secret" making sure *your* player can't play the files using their derived format. If they want they can throw a patent in, too. However even with just a trade secret they can lock you out effectively, thanks to the DMCA.

IIRC the Kerberos protocol had similar problems at one point.

What's the problem with LGPL? The code you write remains yours, you don't have to give it to anyone, and if you really want to change the codec, then you have to publish your changes. Seems like a damn fair deal.

This BSD approach is nice and kind, but if you have to compete with Microsoft, that approach is doomed to failure.

LGPL. Absolutely.

[DG]

Any piece of software, in order to be forever useful, needs three essential freedoms:

1) Universal availibility of source

2) Freedom to modify that source

3) Freedom to redistribute that modified source, under any terms you (as the modifier) wish, as long as those terms do not infringe any of these three freedoms.

Lose any of these Three Freedoms, and the project is irrevocably harmed.

Using a "looser" licence may help the adoption rate, initially, but you run the signifigant risk of having one of these adopters modify the code and refuse to fold those modifications back into the main tree. Once you have done that, then the project has forked, and it's whole purpose (a common standard that is sure to work anywhere) has been compromised.

Far better that the adoption rate be slower, if by doing so it ensures universal compatibility and the retention of the project's Freedom.

Go with the LGPL. The leading "L" allows those who would use your library to remain proprietary, if they so choose (ie, the use of your library does not force the GPL on them - the freedom to choose not to adopt the GPL at project start is important too) but ensures that the library itself remains Free and useful.

Good luck!

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:use the BSD license

[Ogerman]

Sounds like it's your company, not the GPL, that is out of balance. If you're developing routers, then you're trying to sell hardware, not software. Why the heck should the software be proprietary? That argument is about as stupid as companies (like NVidia) who refuse to support Open Source drivers for their hardware because PHB's think it will magically protect them from competitors reverse engineering (as if the time-consuming process reverse engineering is actually a smart market move in the first place!) If your company instead used entirely GPL code, not only would you have a larger base of code to work with and incorporate into your own, but you might get some helpful community feedback. And since you're talking routers, security matters. I would gladly pay a little more for a router based around GPL-free software.

First, what are your goals?

[Per Abrahamsen]

There is no right license for all purposes, it all depends on your goals.

In this case, if you find it acceptable that people make changes to your code and distribute the result without sharing them, use the (new) , it is small, simple and give you the minimal legal protection against getting sued.

If not, I suggest the MPL/GPL/LGPL tripple license used by Mozilla for new code (actually the GPL part is unnecesary, but it is safest to use the text pointed to by the link, since it has been proffread by lawyers). The MPL part will make it useful for embedded and most other purposes, the (L)GPL for use in (L)GPL projects, and it still means changes to your files will be made public.

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.

Embedded software is different - look at Tivo

[GGardner]

L/GPL wasn't written with embedded software in mind, and it shows. Consider the use of this codec in a portable digital music player -- all the code would be burned into ROM, and there is no way for the user to replace/update the code or libraries within the code.

Even if all the code in the gizmo is under the GPL, the end-user has none of the freedoms to fix/update/hack it which RMS likes to talk about.

Just look at the Tivo -- what benefit does a Tivo owner have because the kernel is GPL'ed -- has anyone rebuilt their Tivo linux kernel to fix a bug in it? I doubt it. Certainly the Tivo people benefit from having a robust, stable, flexible, royalty-free kernel. But the freedoms the GPL and LGPL theoretically give to the tivo owners seem hypothetical at best.

Re:Embedded software is different - look at Tivo

[Fnkmaster]

I will beg to differ entirely on the Tivo. I've gained lots of benefits from the fact that the kernel is GPLed. For example, people were able to build loadable modules for TivoNet, a hacked together ethernet card for Tivo, because of it. If it used some weird proprietary kernel, it would be tons harder to do all the great stuff I've done. Admittedly, nobody has gone around recompiling the kernel, though there is a fishy issue with their 2.5 software - they added some nasty filesystem checksum checks to the kernel to prevent hacks. Some people were waiting for them to release source, but we ended up getting around the problem with a bit of hex editing before the 2.5 Tivo software kernel source was ever released.

So you are partially right, but there have clearly been huge benefits in comprehensibility and hackability which have contributed significantly to the market success of the Tivo in the "geek" crowd, which has driven adoption among a lot of others, even if they gain nothing per se from the use of Linux on the Tivo.

Very good Idea

[Srin Tuar]

Charge them a reasonable one-time relicensing fee that gives them an non-exclusive unlimited license to the code base with the exception that they may not patent any algorithms derived from the codebase. Also make sure the price is reasonable and small.

You can keep the main release LGPL, and anytime you take on a new code contributor ask them to agree to a release saying that FLAC may be privately relicensed upon those specific terms above and that all proceeds will go towards the development of FLAC.

So you can eat your cake and have it too. And if the company comes back wanting a license to a more recent version of the code- which has been evolving with LGPL contributions, then they can pay another one-time relicensing fee (a form of recurring funding if development keeps up)

Now this probably wont get you as wide distribution as a BSD license, because of the small hassle, but its the next best thing if you want to keep your copyleft. And your guaranteed to get compensated by anyone who wants to develop FLAC, either with LGPL code or hard cash.

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

BSD vs LGPL

[WebBug]

A lot of interesting replies, and since this is going to take me some time to articulate clearly there'll be more by the time I'm done.

The BSD style license is a good license because it allows the end user a good deal of flexibility.

The GPL is a good license because it protects the code base from proprietary obfuscation.

The BSD may be bad because it does not force the end user to report back to the original author, though it does not forbid this. My experience in working with BSD style licensing is that MOST changes find their way back to the developer.

The GPL may be bad because it does not take into account the reliality of the commercial market. It simply prohibits the end user from making those changes that they may require to make their product a commercial success.

Having said all that, my personal choice has always been to make my code PUBLIC DOMAIN if I want it freely available, otherwise I retain FULL copyright.

Afterall, if freedom is what you want then you MUST allow freedom. I do not feel that it is legitimate to say that something is free if you want to place restrictions on its use.

If you want to retain COMPLETE control then look at some sort of realistic license that fits your business model. Otherwise, I'd say, if you want your code to be FREE then make it FREE, without restriction of any sort.

Which is probably the big advantage of the BSD style license.

Re:Oh don't worry about licensing... [NOT SO FAST]

[ryanvm]

Why don't you just re-license it to specific companies that you want to see use it?

Although it would be nice, this is probably not going to be as easy as you suggest.

The problem is that FLAC is an open source project hosted on SourceForge. As such, it is probably very likely that the project owner has accepted code from various contributors. This means that unless these contributors have explicitly granted him the copyright ownership of their code, he is in no position to re-license it.

At this point, he has two options:
1 - Replace all contributed code with his own; and do so without infringing on the anyone's copyright.
2 - Get everyone who contributed to grant him copyright ownership. Which, depending on how many people contributed, can be quite difficult.

I've always liked this idea for making money from Free software. You basically charge only those people who have no intention of giving back to the community. Unfortunately, unless you have planned ahead, it can be pretty difficult to pull off.

Good luck, buddy.

GPL with exception

[Wesley Felter]

The GCC project has gone through this exact problem with several of their libraries (libgcc, libgcj), and the solution they settled on is the GPL with an exception that using the library doesn't make the main program subject to the requirements of the GPL. Thus the libraries can be statically linked into proprietary embedded systems, but all modifications still have to be released.

wxWindows license.

[MAXOMENOS]

If you haven't done this yet, I'd strongly recommend you look over the wxWindows license. It's basically a modified LGPL that has no restrictions on distribution of derived binaries.

I'd recommend this over the BSD license because it removes the opportinity for certain crooked companies to "embrace and extend" your CODEC. You still retain control of the CODEC design.

Another possibility you may want to explore, is having two licenses: GPL for free download, and closed-source proprietary for closed-source, commercial projects. Trolltech does this and they're apparently quite successful.

Just my two cents.

GUILE License == "LGPL Done Right"

[Big Jojo]

Also known as "GPL plus Library Exception", where the "exception" is:

As a special exception, if you link this library with other files to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.

The effect is that it gets rid of the static linking constraint of LGPL, but it's still a CopyLeft license so that it can't be proprietized.

This is used in the GNU runtimes for Java (libgcj, classpath, classpathx, etc) as well as GUILE, an embedded Scheme interpreter.