Slashdot Mirror

← Back to Stories (view on slashdot.org)

LGPL or BSD-Style License for Media Codecs?

Posted by Cliff on from the stuff-to-discuss dept.

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?"

12 of 203 comments (clear)

  1. If the code is yours... by Molech · · Score: 5, Informative

    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.

    1. Re:If the code is yours... by Arethan · · Score: 3, Informative

      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.

  2. Ogg Vorbis Went Through This by gagravarr · · Score: 3, Informative

    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.

    --
    This post will enter the public domain 70 years after my death, unless Disney buys another extension.
  3. You can have several licenses by famebait · · Score: 2, Informative

    You own the copyright. There's nothing to stop you from licensing your code under different terms to select users in
    parallel with your main LGPL distro. What that license would be is a subject of normal negotiations between you and your 'clients', and could even be a custom-written license to make sure that even the changes made in order to embed are released to the public.

    --
    sudo ergo sum
  4. Ogg Vorbis Example by jeriqo · · Score: 5, Informative

    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.

    --
    Alexis 'jeriqo' BRET
  5. LGPL. Absolutely. by DG · · Score: 4, Informative

    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!

    --
    Want to learn about race cars? Read my Book
  6. First, what are your goals? by Per+Abrahamsen · · Score: 4, Informative
    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.

  7. Re:Embedded software is different - look at Tivo by Fnkmaster · · Score: 4, Informative
    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.

  8. GPL with exception by Wesley+Felter · · Score: 3, Informative

    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.

  9. GPL is no more "honest" than BSD by Anonymous Coward · · Score: 1, Informative

    Under the GPL, anyone who lifts the code is dishonest.

    Under the BSD, anyone who lifts the code is following the licensing terms in a perfectly acceptable way - there is no "dishonesty" involved.

  10. Re:Vorbis uses LGPL. by jmoffitt · · Score: 2, Informative

    It does not use LGPL. The license file in both the libogg and libvorbis distributions, as well as the top 20 lines of every source file clearly state that it is licensed under the BSD license.

    Not only that, but I have several contacts at EA and have met personally with many of the audio people there and they are all aware of this to the best of my knowledge.

    One of the primary motivators for this decision was EA asking for an easier license.

    Please contact me directly or give me the info to talk to your lawyer. I can easily straighten this out.

  11. GUILE License == "LGPL Done Right" by Big+Jojo · · Score: 3, Informative

    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.