Slashdot Mirror
LGPL or BSD-Style License for Media Codecs?
"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?"
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
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)
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
It meets every definition of "free" that matters.
... even PHB's like me that believe in free software.
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
--------------- Murphy was an otpimist.
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.
You could've hired me.
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.
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.
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.
Later . . . . . . WebBug
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.
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.
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.
Never underestimate the dark side of the Source
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.
Finding God in a Dog