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.
Or, better yet, get a lawyer to write it for you.
I can't say that I don't give a fuck. I've just run out of fuck to give.
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.
Moreover, seeing as modified libraries may not always be able to be copied/loaded/uploaded to an embedded device even if the source, etc. for all the free libs are provided, how can that device fulfill the requirements of the GPLs (these devices cannot provide a "suitable shared library mechanism")? Source that you are free to modify but not free to use does not sound particularly free (or useful) to me.
--
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
I found your How to choose a free software license to be well written, and it is probably helpful to a lot of people.
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.
RTEMS (see http://www.oarcorp.com/RTEMS is an embedded RTOS that uses this approach. We got the idea from other "run-time" libraries in the GNU software suite. This is very similar to the exception used by the GNAT (GNU Ada) run-time. I believe there should be a special version of the GPL called something like the "Run-Time GPL" to address cases like this. There is no point in every project writing their own exception paragraph and possibly creating loopholes.
:)
The specific paragraph we add to the GPL is:
"As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application 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 Public License."
Be aware that if your software is useable in non-embedded systems, you might want a more
pure version of the GPL. Someone mentioned allowing the exception on systems without dynamic linking.
We have tried very hard over the past 10 years to walk a fine line between being free software for embedded systems and placing undue restrictions on those using our software. It is a tough balancing act but we like this solution. Making your own strange license requires that you explain it which is no fun either.
Please, pardon me if I have misunderstood that part of your statement, but I just have to put in my 0,02 Euros. You said:
Think for a moment about the motivation of a business for asking the developer of a GPL'd software product to change the license. The reason traditional businesses (like Apple and Microsoft) encourage independent developers to choose the BSD license is that traditional businesses (like Apple and Microsoft) can then integrate the independent developer's code into a closed-source commercial product without paying a licensing fee or even contributing to the free source code base in good faith.
If companies were willing to release the source code of the software system into which the GPL'd code was integrated, no separate licensing arrangement would be necessary and no licensing fee would be due. So, you see, for companies that support free software, the GPL is at least as "business friendly" as the BSD license; in fact, for those companies, the GPL is more business-friendly than the BSD license because it (theoretically) prevents unscrupulous competitors from appropriating the software product it protects.
The authors of the GPL sought to increase the quantity and quality of GPL'd software, as well as to guarantee the continued availability of source code for a particular software product -- and this seems to be what FLAC's author wants, too. I think tswinzing's post offers excellent advice: charge closed-source shops for their closed-source licenses. A switch to a BSD license would take away the competitive advantage that those companies who may already be willing to release the rest of the system under a GPL-compatible license now enjoy. When seen in that light, changing the license to BSD would subvert the author's goal of contributing to increasing the availability of free software and to the free software community's long-term goal of making all hardware interfaces open.
A very insightful man once warned us of how an unscrupulous company could take advantage of a community of people who believe in sharing by simply asking for a handout. We must remain vigilant, because that danger still exists. I hope, dearly, that the author of FLAC will stick to his guns even in the face of these most persuasive beggars.
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
Linkers can be told to remove unused functions if you link statically. So, you are dumb if you avoid the standard library for that reason.