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?"
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.
"And like that
you could release the current version of the library to them under a different license (a contract giving them special permission to use the current version of the library in their proprietary product).
You might even be able to make a couple bucks off it.
The library - current and future versions - would still be free.
Stupid sexy Flanders.
He has said that what he wants to do is keep the format free (as opposed to selling licenses)
I believe that BSD would be a better choice of license; I don't think I could explain it better than Zeev Suraski did when he announced PHP moving to a pure BSD license at the PHP developers conference (apologies if I misquote, this is from memory):
GPL is based on the concept that software should be free; BSD license is based on the concept that people should be free
I think that sums it up wonderfully. RMS is so obsessed with licenses protecting the freedom of software that he seems to have made it to restrictive for the people using it.
Oh shit, on previewing, it looks like I'm trying to start a flame war.
>Bastes self ready for roasting<
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.
--
"It is now safe to switch off your computer."
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.
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.
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:
Enjoy.
JOhn
Campaign for Liberty
I personally like the BSD liscense for this issue. The problem is that comapines or individuals can repackage your code in their product (they still have to give copywright, credit info though).
In all, that's the main problem, but not that specifically. The developer says that he wants FLAC to gain usage, but it's quite possible that by letting some firm use it in their code base, that they make something codec incompatible with the FLAC spec.
What he needs to do is Copyright the format and the code (music cd's all have the DigitalMusic CD logo on them, indicating compliance with the redbook CDDA spec.) This is to insure that even if they modify the code, the audio must still be decoded by any FLAC compliant decoder. Take MP3 for example: There's a great range of encoders and decoders, each having their own benefits. According to the spec, however, any MP3 should be able to play on any decoder, even if they don't reproduce it exactly the same.
Of course, this means that you have to make future versions foward compatible too. You can't change the API once it is started. Change the internals, sure, NOT THE API. This is the feature that made MP3 big, and it's the keystone in creating a new format that wants to be prevasive.
Several of the posts here imply that Josh's intent is to find a way to sell FLAC to vendors for use in embedded systems. Those posts suggest a mix of open-source and fee-based licensing, and seem to view the embedded system vendors as folks who should essentially be paying a tax to subsidize development.
/. thread, and it has raised some key issues.
But my take on the original question is quite different. I believe that Josh's goal is to make this software available for free, to all, including embedded system vendors; but he sees(correctly) that such vendors generally have a hard time using open source components, because of the nature of how their systems are sold, distributed, and supported. It's not necessarily practical or reasonable to compel a hardware vendor to provide the means for recompilation/relinking etc. -- even though all parties may feel that an open-source component is the best technical solution, and that using it would help to establish good industry-wide standards. (This is also true of device drivers and other components where, even if the vendors don't conform 100% to open source requirements, a watered-down standarization is still far better than if each vendor rolls his own solution. Many 'benign' proprietary software vendors would love to use open source tools and components in a non-exploiting way, i.e. as a way to improve industry-wide interoperability and standardization -- as opposed to 'evil' vendors who would seek to put a private label on open source components and sell the result -- but of course even with good intents this can't be done, since a software vendor is committing the sin of trying to get paid for its R&D costs. But that's another argument.)
There are many good suggestions here. I think this is an extremely interesting
The bottom line for me is a basic problem with many open source licenses: Licensing restrictions often prevent a developer from making software available to folks who common sense says should be able to use it; and they often prevent a product vendor from incorporating software in ways that common sense says is consistent with the open source philosophy and would improve the overall quality of products and range of choices available to end-users.
Thanks to all who have made thoughtful posts here.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld