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...

[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.

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.

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.

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.

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.