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.
FAP FAP FAP
WERD
Does anyone have a moist towellete?
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.
OGG guys dual licensed their libraries and SDK's under GPL and BSD for the same reason.
http://www.vorbis.com/faq.psp#flic
are a sticky subject. LPGL'ing anything in itself is a tricky subject.
60623
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.
I wonder if somebody at Linn reads /.!
Totally off topic, I know, but Slashdot won't post the damn thing. The "Ginger/IT" invention is to be revealed next week on Good Morning America. Here is the wave file of Diane Sawyer telling about the unveiling. http://jedstar.com/ginger/
+5 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
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
Even trolls occasionally make nice posts.
Firstly, if it's your project, you can license and re-license it however you want.
Secondly, you can't have your cake and eat it too.
It sounds to me like you basically just don't know what you want. Do you want any changes made and distributed to be shared with everyeone, or do you want peopel to be able to take it and do whatever they want with it, even if it's proprietary and closed? IT's pretty simple.
If you want something in between, write your own license terms.
Nothing is stopping you, as copyright holder, from keeping it under lgpl, but licensing it under a royalties scheme to a 3rd party commercial entity.
The question doesn't make much sense, but neither does your site. You can't release something into the public domain (the specs for the codec) AND 'retain the right to change the specification and certify compliance.'
I would encourage the embedded people to write their own implementation and stay far far away from your supposedly 'free' implementation.
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
let them negotiate a separate license contract with you.
I'm sure that will clear up any questions, ambiguity or doubt.
Codifex Maximus ~ In search of... a shorter sig.
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.
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
Why not do what Linus does with Linux and make "clarifications" (aka exceptions) that allow limited slack on linking requirements for embedded systems?
That way, you can demand all distributed modifications, while removing the barriers that are troubling you.
-Peter
"I want the codec to remain Free...
If they use something else, it's quite likely to be some form of hackery that's only available with Windows and/or SDMI support.
In the end, more accessibility is likely to come to free software by taking the approach that's less "free" on the surface. Take it with a grain of salt, but in my opinion this is one of those cases where the BSD license is more "free" than the GNU license.
nice try...
Concievably, a company like micro$oft would be able to take a BSD-licensed codec and incorporate it into Media Player to take away the freedom of the viewer in both the form of a restrictive EULA and also a content "protection" system that revokes the fair-use rights that the user has been promised.
Is your company running tools written by ma
Can we get back to KDE v GNOME wars? They're generally much more interesting.
If you have someone who is running into problems with certain sections of your license perhaps you should have them come up with a proposal for a license. After all if they want to use your code but have problems with certain sections of the code then they will know how to rewrite it so they can use it. Your probably not going to find a license that gives you everything you want(without some heavy searching) so collaborate and create your own. Maybe release it under the BSD license in the mean time. Think about what parts you want them to be able modify without sending it back and what parts you want to be feed back to you. It's tough but if you have someone already blocked by the license you can shift the work onto them.
Is this a shameless plug to get people to d/l (or contribute) to his open source project?
Sure he -sounds- sincere, but you have to to get a good ask slashdot posted...
I think you people have been had.
Just like Ximian is going to license their Mono stuff under GPL *and* another license specifically for embedded usage, you might do the same. You should mail Miguel on this, he usually is most responsive.
Fire up team:
We need to start a pool for how long it will be before we have a new JonKatz "article" regarding the Columbine-like conspiracy in Boston.
I say, the submission will appear by 4:30pm, today, 28-Nov-2001. If I win, I get to kick Katz's lilly white butt.
A few people have pointed out that if you're the sole contributor, you're free to licence the software as you see fit. However, even if this is the case, I don't think it solves the problem. Essentially what the author wants is to keep the codebase Free and have all changes come back to the community. What the author doesn't care about that the LGPL does is the ability to relink with other libraries, since that can be pretty diffecult with hardware.
After a little exploration at gnu.org's Free licence list i saw the "licence of Guile" (third one down) that looks like exactly what you're looking for. The licence is not on the web, though, so you'll have to download Guile and see for yourself. It says it's essentially the GPL only with a blanket statement allowing linking with non-free software.
Hope that helps,
ben.c
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."
Scope is an Open Source HMVC Java thingy developed by someone at the company where I work. The license he uses is BSD like and was accepted as okay by the lawyers here, so we rely on his work both OSS and internal with no issues. It also means we can invest company resources in building up the OSS project while mainting our differentiator in the company.
An Eye for an Eye will make the whole world blind - Gandhi
Doesn't the BSD license allow other companies
to use your code without compensation? I understand that parts of the windows TCP stack are actually from BSD.
I believe sleepycat software http://www.sleepycat.com uses GPL for people who want it free and their own license for companies
who need it.
Consider this: if 1) It is implemented in the hardware itself, and not merely as software in the embedded system, then it's a new implementation of a free algorithm, and there is no conflict. OTOH, 2) if they are just putting your lib on a rom, then the LGPL ought to apply. My opinion in this case is of what the LGPL should do. One, you get credit. Two, Anything they change, obviously must be given back to the community. Now, I think they should be allowed to do this, Sure, it might bring it into contact with non-GPL software, but that really shouldn't make a differance here, even if it does. Why not just append a new clause onto the license? Modify it so the requirements are only dynamic linking when possible, and static is ok in embedded devices? It's the right way: it allows people to use it.
Dual license the project code under the LGPL and your own license, that you feel frees up the embedded system work while making sure improvement code comes back to you and can be put under the dual licensing scheme. And you might even be able to get some development funding from the embedded hardwaare people who want to use yer codec if you write the dual license to allow for licensing fees.
In any event a dual license scheme,if you can get away with it, is the way to go...but you'd have to get permission from all the developers in your project to agree to that arrangement. If its a one man project at this point...its easy to get the legalese of the matter resolved...you just have to have a long discussion with yourself and then you just have to make it clear that any code submitted to the project must be cleared for dual licensing before yuou will merge it in.
If it ends up being that there isn't much interest in the second license you create yourself you still have the option of dropping the second license from future releases and just releasing it under the LGPL again.
This way the code from your project will always be out there under the LGPL for people to use in other LGPL compatible projects...and you can negotiate special circumstances with a the second license...so that the codec can be used in situations the LGPL really wasnt designed to address, like embedded systems.
-jef
-jef
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.
Yet another crppling bombshell hit the beleaguered *BSD community when recently IDC confrmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in th recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. FreeBSD is the most endangered of them all, having lost 93% of its core developers.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS hobbyist dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dead
take a look at the licensing for divx 4.11. The mac version says it uses an open source license (I'm not sure which since I don't have a mac), but the Windows and Linux versions both use the following EULA: DIVXNETWORKS, INC. END-USER LICENSE AGREEMENT YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING THIS PRODUCT. IT CONTAINS SOFTWARE, THE USE OF WHICH IS LICENSED BY DIVXNETWORKS, INC., TO ITS CUSTOMERS FOR THEIR USE ONLY AS SET FORTH BELOW. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT USE THE SOFTWARE. USING ANY PART OF THE SOFTWARE INDICATES THAT YOU ACCEPT THESE TERMS. LICENSE: DivXNetworks, Inc. grants you a personal, limited, non- exclusive license to use the accompanying software program(s) (the "Software") subject to the terms and restrictions set forth in this License Agreement. You are not permitted to lease or rent (except under separate mutually agreeable terms set forth in writing), distribute or sublicense the Software or to use the Software in a time-sharing arrangement or in any other unauthorized manner. Further, no license is granted to you in the human readable code of the Software (source code). Except as provided below, this License Agreement does not grant you any rights to patents, copyrights, trade secrets, trademarks, or any other rights in respect to the Software. The Software is licensed to be used on any computing device. You may reproduce and provide one (1) copy of such Software for each computing device on which such Software is used as permitted hereunder. Otherwise, the Software and supporting documentation may be copied only as essential for backup or archive purposes in support of your use of the Software as permitted hereunder. You must reproduce and include all copyright notices and any other proprietary rights notices appearing on the Software on any copies that you make. NO ASSIGNMENT; NO REVERSE ENGINEERING: You may transfer the Software and this License Agreement to another party if the other party agrees in writing to accept the terms and conditions of this License Agreement. If you transfer the Software, you must at the same time either transfer all copies of the Software as well as the supporting documentation to the same party or destroy any such materials not transferred. Except as set forth above, you may not transfer or assign the Software or your rights under this License Agreement. Modification, reverse engineering, reverse compiling, or disassembly of the Software is expressly prohibited. Analyzing the input to and output from the Software is expressly prohibited except when this is done solely to evaluate the subjective quality of the Software's visual and audio processes. You may not otherwise modify, alter, adapt, port, or merge the Software except as specified in this License Agreement. EXPORT RESTRICTIONS: You agree that you will not export or re-export the Software or accompanying documentation (or any copies thereof) or any products utilizing the Software or such documentation in violation of any applicable laws or regulations of the United States or the country in which you obtained them. TRADE SECRETS; TITLE: You acknowledge and agree that the structure, sequence and organization of the Software are the valuable trade secrets of DivXNetworks, Inc. and its suppliers. You agree to hold such trade secrets in confidence. You further acknowledge and agree that ownership of, and title to, the Software and all subsequent copies thereof regardless of the form or media are held by DivXNetworks, Inc. and its suppliers. TRADEMARKS AND COPYRIGHTS: "DivX" is a trademark of DivXNetworks, Inc. You may not remove, alter, deface, overprint, or otherwise obscure any DivXNetworks, Inc. trademark, service mark, or copyright notices included with this Software. NO COMMERCIAL USE: This License Agreement grants you the right to use the Software for personal use only. Commercial use of the Software or of the work products resulting from its use is not permitted under this License Agreement. Such use may be permitted under another license, which must be separately agreed to by you and DivXNetworks, Inc. INTELLECTUAL PROPERTY: All intellectual property rights in and to this Software are and shall remain in DivXNetworks, Inc. TERM AND TERMINATION: This License Agreement is effective until terminated. You may terminate it at any time by destroying the Software and documentation together with all copies and merged portions in any form. It will also terminate immediately if you fail to comply with any term or condition of this License Agreement. Upon such termination you agree to destroy the Software and documentation, together with all copies and merged portions in any form. GOVERNING LAW: This License Agreement shall be governed by the laws of the State of California and by the laws of the United States, excluding their conflicts of law principles. The United Nations Convention on Contracts for the International Sale of Goods (1980) is hereby excluded in its entirety from application to this License Agreement. LIMITED WARRANTY; LIMITATION OF LIABILITY: EXCEPT AS EXPRESSLY PROVIDED OTHERWISE IN A WRITTEN AGREEMENT BETWEEN DIVXNETWORKS, INC. AND YOU, THE SOFTWARE IS NOW PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THE WARRANTY OF NON-INFRINGEMENT. WITHOUT LIMITING THE FOREGOING, DIVXNETWORKS, INC. MAKES NO WARRANTY THAT (i) THE SOFTWARE WILL MEET YOUR REQUIREMENTS, (ii) THE USE OF THE SOFTWARE WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE, (iii) THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF THE SOFTWARE WILL BE ACCURATE OR RELIABLE, (iv) THE QUALITY OF THE SOFTWARE WILL MEET YOUR EXPECTATIONS, (v) ANY ERRORS IN THE SOFTWARE WILL BE CORRECTED, AND/OR (vi) YOU MAY USE, PRACTICE, EXECUTE, OR ACCESS THE SOFTWARE WITHOUT VIOLATING THE INTELLECTUAL PROPERTY RIGHTS OF OTHERS. SOME STATES OR JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES OR LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY MAY LAST, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. IF TEXAS LAW IS NOT HELD TO APPLY TO THIS AGREEMENT FOR ANY REASON, THEN IN JURISDICTIONS WHERE WARRANTIES, GUARANTEES, REPRESENTATIONS, AND/OR CONDITIONS OF ANY TYPE MAY NOT BE DISCLAIMED, ANY SUCH WARRANTY, GUARANTEE, REPRESENATION AND/OR WARRANTY IS: (1) HEREBY LIMITED TO THE PERIOD OF EITHER (A) THIRTY (30) DAYS FROM THE DATE OF OPENING THE PACKAGE CONTAINING THE SOFTWARE OR (B) THE SHORTEST PERIOD ALLOWED BY LAW IN THE APPLICABLE JURISDICTION IF A THIRTY (30) DAY LIMITATION WOULD BE UNENFORCEABLE; AND (2) THE SOLE LIABILITY OF DIVXNETWORKS, INC. FOR ANY BREACH OF ANY SUCH WARRANTY, GUARANTEE, REPRESENTATION, AND/OR CONDITION SHALL BE TO PROVIDE YOU WITH A NEW COPY OF THE SOFTWARE. IN NO EVENT SHALL DIVXNETWORKS, INC. OR ITS SUPPLIERS BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER, INCLUDING, WITHOUT LIMITATION, THOSE RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT DIVXNETWORKS, INC. HAD BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OF THE SOFTWARE. SOME JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE OF ANY LIMITED REMEDY. SEVERABILITY: In the event any provision of this License Agreement is found to be invalid, illegal or unenforceable, the validity, legality and enforceability of any of the remaining provisions shall not in any way be affected or impaired and a valid, legal and enforceable provision of similar intent and economic impact shall be substituted therefor. ENTIRE AGREEMENT: This License Agreement sets forth the entire understanding and agreement between you and DivXNetworks, Inc., supersedes all prior agreements, whether written or oral, with respect to the Software, and may be amended only in a writing signed by both parties. For information about commercial licensing please email licensing@divxnetworks.com DivXNetworks, Inc. 10350 Science Center Drive Building 14, Suite 140 San Diego, California 92121 16 July 2001 Now, this is only the license for the non-commercial codec so that people can actually watch the stuff. Licencsing for commercial uses is different and information on it can be obtained by emailing licensing@divxnetworks.com. Considering Blizzard just got a license to use DiVX to distribute their trailers and say they only keep QT arround for the Mac users, it seems that whatever license DivX is using for commercial application in proprietary and non proprietary systems might be exactly what you are looking for.
I'm out of my mind right now, but feel free to leave a message.....
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.
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.
If you choose a BSD style licence, think about patents.1 09 .2/0805.html
The BSD licence doesn't prevent an author from
applying for a patent, and distributing the
code "for free".
A few years later you can come and sue for patent
infringement.
That's a known problem for Linux kernel drivers,
and I assume that media codecs are a large patent
minefield.
Example:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0
Continue to release your library under the LGPL. Then, create complete codumentation for the codec, complete with code or pseudocode examples, to aid in reimplementation, and release this under a license which allows for commercial development. Consider adding a clause to the license which forces readers who modify and don't redistribute to use a different name. Perhaps something similar to the MAME license would work for this.
The idea is to make reimplementation of the codec easy, while keeping your own code free. While this isn't an ideal solution, it may be a workable one.
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.
--
I like the way the MAD MPEG audio decoder is
licensed. It's GPL code, but the author is open about licensing it to commercial closed-source projects. I think this is a nice arrangement:
http://www.mars.org/home/rob/proj/mpeg/
jeff
Commercial, closed source products, have been made from both PLIB and SDL, which are both LGPL, and without any legal problems.
Got Freedom?
Thinking?
FreeBSD allows even proprietary (closed-source) developers to contribute to open-source projects and still use the results in their own work/projects. This is a win for everybody.
If the code is GPLed only other GPL programmers can use and contribute to it.
FreeBSD is the "lets all share and co-operate as much as possible" license
GPL is the "lets all try to stop/ban proprietary software" type of license. If you don't believe me, go read the GNU Manifesto and all the other literature on www.gnu.org. GPL is NOT about SHARING. You can share without GPL.
i misspelled it. here correct one. sorry.
Got Freedom?
Thinking?
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.
You could change the license to require imbedded versions to be made available via a website yours, theirs or both) but allow proprietary packaging and deployment of the code in products. To address Concerns about competition, a reasonable delay between deployment and public availability could be worked into the the license (say 6 - 12 months) that would allow a developing company to stay well ahead of their competitors.
The way I see it, the interest of third parties simply illustrates the need for a imbedded version of FLAC that would be available under LGPL.
People who sacrifice beauty for efficiency get what they deserve. - The Woodpecker
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
take a look at the licensing for divx 4.11. The mac version says it uses an open source license (I'm not sure which since I don't have a mac), but the Windows and Linux versions both use the following EULA:
DIVXNETWORKS, INC. END-USER LICENSE AGREEMENT
YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE
USING THIS PRODUCT. IT CONTAINS SOFTWARE, THE USE OF WHICH IS LICENSED
BY DIVXNETWORKS, INC., TO ITS CUSTOMERS FOR THEIR USE ONLY AS SET FORTH
BELOW. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS
AGREEMENT, DO NOT USE THE SOFTWARE. USING ANY PART OF THE SOFTWARE
INDICATES THAT YOU ACCEPT THESE TERMS.
LICENSE: DivXNetworks, Inc. grants you a personal, limited, non-
exclusive license to use the accompanying software program(s) (the
"Software") subject to the terms and restrictions set forth in this
License Agreement. You are not permitted to lease or rent (except under
separate mutually agreeable terms set forth in writing), distribute or
sublicense the Software or to use the Software in a time-sharing
arrangement or in any other unauthorized manner. Further, no license is
granted to you in the human readable code of the Software (source code).
Except as provided below, this License Agreement does not grant you any
rights to patents, copyrights, trade secrets, trademarks, or any other
rights in respect to the Software.
The Software is licensed to be used on any computing device. You may
reproduce and provide one (1) copy of such Software for each computing
device on which such Software is used as permitted hereunder. Otherwise,
the Software and supporting documentation may be copied only as
essential for backup or archive purposes in support of your use of the
Software as permitted hereunder. You must reproduce and include all
copyright notices and any other proprietary rights notices appearing on
the Software on any copies that you make.
NO ASSIGNMENT; NO REVERSE ENGINEERING: You may transfer the Software and
this License Agreement to another party if the other party agrees in
writing to accept the terms and conditions of this License Agreement. If
you transfer the Software, you must at the same time either transfer all
copies of the Software as well as the supporting documentation to the
same party or destroy any such materials not transferred. Except as set
forth above, you may not transfer or assign the Software or your rights
under this License Agreement.
Modification, reverse engineering, reverse compiling, or disassembly of
the Software is expressly prohibited. Analyzing the input to and output
from the Software is expressly prohibited except when this is done
solely to evaluate the subjective quality of the Software's visual and
audio processes. You may not otherwise modify, alter, adapt, port, or
merge the Software except as specified in this License Agreement.
EXPORT RESTRICTIONS: You agree that you will not export or re-export the
Software or accompanying documentation (or any copies thereof) or any
products utilizing the Software or such documentation in violation of
any applicable laws or regulations of the United States or the country
in which you obtained them.
TRADE SECRETS; TITLE: You acknowledge and agree that the structure,
sequence and organization of the Software are the valuable trade secrets
of DivXNetworks, Inc. and its suppliers. You agree to hold such trade
secrets in confidence. You further acknowledge and agree that ownership
of, and title to, the Software and all subsequent copies thereof
regardless of the form or media are held by DivXNetworks, Inc. and its
suppliers.
TRADEMARKS AND COPYRIGHTS: "DivX" is a trademark of DivXNetworks, Inc.
You may not remove, alter, deface, overprint, or otherwise obscure any
DivXNetworks, Inc. trademark, service mark, or copyright notices
included with this Software.
NO COMMERCIAL USE: This License Agreement grants you the right to use
the Software for personal use only. Commercial use of the Software or of
the work products resulting from its use is not permitted under this
License Agreement. Such use may be permitted under another license,
which must be separately agreed to by you and DivXNetworks, Inc.
INTELLECTUAL PROPERTY: All intellectual property rights in and to this
Software are and shall remain in DivXNetworks, Inc.
TERM AND TERMINATION: This License Agreement is effective until
terminated. You may terminate it at any time by destroying the Software
and documentation together with all copies and merged portions in any
form. It will also terminate immediately if you fail to comply with any
term or condition of this License Agreement. Upon such termination you
agree to destroy the Software and documentation, together with all
copies and merged portions in any form.
GOVERNING LAW: This License Agreement shall be governed by the laws of
the State of California and by the laws of the United States, excluding
their conflicts of law principles. The United Nations Convention on
Contracts for the International Sale of Goods (1980) is hereby excluded
in its entirety from application to this License Agreement.
LIMITED WARRANTY; LIMITATION OF LIABILITY: EXCEPT AS EXPRESSLY PROVIDED
OTHERWISE IN A WRITTEN AGREEMENT BETWEEN DIVXNETWORKS, INC. AND YOU, THE
SOFTWARE IS NOW PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR
THE WARRANTY OF NON-INFRINGEMENT. WITHOUT LIMITING THE FOREGOING,
DIVXNETWORKS, INC. MAKES NO WARRANTY THAT (i) THE SOFTWARE WILL MEET
YOUR REQUIREMENTS, (ii) THE USE OF THE SOFTWARE WILL BE UNINTERRUPTED,
TIMELY, SECURE, OR ERROR-FREE, (iii) THE RESULTS THAT MAY BE OBTAINED
FROM THE USE OF THE SOFTWARE WILL BE ACCURATE OR RELIABLE, (iv) THE
QUALITY OF THE SOFTWARE WILL MEET YOUR EXPECTATIONS, (v) ANY ERRORS IN
THE SOFTWARE WILL BE CORRECTED, AND/OR (vi) YOU MAY USE, PRACTICE,
EXECUTE, OR ACCESS THE SOFTWARE WITHOUT VIOLATING THE INTELLECTUAL
PROPERTY RIGHTS OF OTHERS. SOME STATES OR JURISDICTIONS DO NOT ALLOW THE
EXCLUSION OF IMPLIED WARRANTIES OR LIMITATIONS ON HOW LONG AN IMPLIED
WARRANTY MAY LAST, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. IF
TEXAS LAW IS NOT HELD TO APPLY TO THIS AGREEMENT FOR ANY REASON, THEN IN
JURISDICTIONS WHERE WARRANTIES, GUARANTEES, REPRESENTATIONS, AND/OR
CONDITIONS OF ANY TYPE MAY NOT BE DISCLAIMED, ANY SUCH WARRANTY,
GUARANTEE, REPRESENATION AND/OR WARRANTY IS: (1) HEREBY LIMITED TO THE
PERIOD OF EITHER (A) THIRTY (30) DAYS FROM THE DATE OF OPENING THE
PACKAGE CONTAINING THE SOFTWARE OR (B) THE SHORTEST PERIOD ALLOWED BY
LAW IN THE APPLICABLE JURISDICTION IF A THIRTY (30) DAY LIMITATION WOULD
BE UNENFORCEABLE; AND (2) THE SOLE LIABILITY OF DIVXNETWORKS, INC. FOR
ANY BREACH OF ANY SUCH WARRANTY, GUARANTEE, REPRESENTATION, AND/OR
CONDITION SHALL BE TO PROVIDE YOU WITH A NEW COPY OF THE SOFTWARE.
IN NO EVENT SHALL DIVXNETWORKS, INC. OR ITS SUPPLIERS BE LIABLE TO YOU
OR ANY THIRD PARTY FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER, INCLUDING,
WITHOUT LIMITATION, THOSE RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER OR NOT DIVXNETWORKS, INC. HAD BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN
CONNECTION WITH THE USE OF THE SOFTWARE. SOME JURISDICTIONS PROHIBIT THE
EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL
DAMAGES, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. THESE
LIMITATIONS SHALL APPLY NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE
OF ANY LIMITED REMEDY.
SEVERABILITY: In the event any provision of this License Agreement is
found to be invalid, illegal or unenforceable, the validity, legality
and enforceability of any of the remaining provisions shall not in any
way be affected or impaired and a valid, legal and enforceable provision
of similar intent and economic impact shall be substituted therefor.
ENTIRE AGREEMENT: This License Agreement sets forth the entire
understanding and agreement between you and DivXNetworks, Inc.,
supersedes all prior agreements, whether written or oral, with respect
to the Software, and may be amended only in a writing signed by both
parties.
For information about commercial licensing please email licensing@divxnetworks.com
DivXNetworks, Inc.
10350 Science Center Drive
Building 14, Suite 140
San Diego, California 92121
16 July 2001
Now, this is only the license for the non-commercial codec so that people can actually watch the stuff. Licencsing for commercial uses is different and information on it can be obtained by emailing licensing@divxnetworks.com. Considering Blizzard just got a license to use DiVX to distribute their trailers and say they only keep QT arround for the Mac users, it seems that whatever license DivX is using for commercial application in proprietary and non proprietary systems might be exactly what you are looking for.
I'm out of my mind right now, but feel free to leave a message.....
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
That's the end of your licensing problems as long as all outside contributions to your code tree are in the PD as well.
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.
>FreeBSD is the "lets all share and co-operate as much as possible" license
BSD is the license that let Microsoft steal your various IP utilities (FTP, et al.) and integrate them into their proprietary OS without giving back.
Do a grep for "regents" sometime in C:\windows (or wherever you find a windows install).
>GPL is the "lets all try to stop/ban proprietary software" type of license.
Yup. That's because GPL programmers don't want MS (and others) to lift sections of their code verbatim and call it theirs.
Do you notice that the level of difficulty of finding out who wrote ftp.exe on windows is way beyond the abilities of anyone who is a windows sysadmin? May as well be written by MS for all they know.
>FreeBSD allows even proprietary (closed-source) developers to contribute to open-source projects and still use the results in their own work/projects. This is a win for everybody.
That's interesting. Is MS working on Windows for BSD as co-operation for "using" BSD code?
Clearly, the BSD license is a big win for corporations, not such a big win for the "little guy".
>GPL is NOT about SHARING. You can share without GPL.
GPL is about HONESTY in sharing. Dishonest companies can lift BSD code without the slightest worry. Only honest companies committed to open source can use GPL.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Yeah, and this is what the Ogg project does. Their code is released under a BSD license, but the spec is in the public domain (though they reserve the right to say which systems conform to the spec, which is a very vice decision).
Then, what license you use for the your own software is of minor importance. But since the Ogg project made a decision to go BSD after thinking about it long and well, and your situation seems to be very similar to theirs, I guess it is a good choice.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
What level of compression does FLAC offer for audio? AKA, we know it is a lossless scheme -- but how small does it get the files compared to a WAV or AIFF.
That's not to say that the lgpl doesn't have its problems too. There's a lot of grey area for things like static linking versus dynamic, for example. Back when I was working at the Evil Satellite company, about the only way to get the project to run, due to different library levels on all the developer's workstations, was to do static linking. Of course, they were also looking at using GNU Gettext (A GPLed project) for their translation when I left, too...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
Sound like you need exactly what Qt is doing. Qt has two licenses: GPL and a Qt license. If you want to use Qt to build proprietary apps, you use the Qt license. If you want it to build GPL'd apps, you use the GPL license. (KDE is using the GPL license)
Basically, it boils down to this: "You make money, we make money. You don't make money, we don't care."
eCos is a RTOS published by Cygnus (now Redhat) that targets the very systems you are describing. It is licensed under the Red Hat eCos Public License Version 1.1.
e coslicense.html
I don't know if it's fully "free" (especially since the end-user can't reasonably upgrade many of these products), but it's reasonable for the kind of situation you are running into.
See http://www.redhat.com/embedded/technologies/ecos/
You could offer it under such a license only if the environment does not support dynamic loading of libraries, etc.
SKG
"I really want it to remain free" are you suggesting it has to be an either or proposition?
What makes you think that if it remains free it won't have any chance at adoption?
I suspect that the "GNAT Modified GPL" (GMGPL) solves your problem, since it specifically allows non-dynamic linking of libraries without infecting a program using the GMGPL'ed library.
Jacob
Atheism is a non-prophet organisation.
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.
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.
I think the GPL/LGPL makes the most sense for systems, the least sense for libraries which support programming activities, where the BSD license is just fine.
In a similar context, I decided to create a GPL conformance suite for a protocol implementation under the BSD license.
I'm strongly against monomaniacal unitarianism. My bible is the book "In Praise of Diversity" by Freeman Dyson.
A conformance suite is useless unless everyone contributes back their extensions / additions. A protocol is useless unless it is widely adopted. I license is useless if it makes a political statement without making the world a better place. In situations like this, a little common sense goes a long way.
I think people might have problems with LGPL software due to the changes that may be required for various embedded operating systems. Take a look at zlib for how to make a library embedded friendly. In zLib, all of the OS related code is in a single file which makes porting very easy. Remember, in embedded systems, functions like malloc and printf might not be available.
I worked on a project where I had to change the boot loader to use zLib so the image would fit into the flash memory. zLib was very simple to use due to the excellent abstraction layer. I had *no* operating system to rely on.
Now zLib is under a BSD-style license instead of LGPL. For a LGPL library to work, just make the OS wrapper files BSD but the core LGPL. If it is written properly, anyone embedding the code should only have to change the OS wrappers, or if any changes are made to the core they would not reveal the internal workings of their product (unless they want to add some feature they want to remain proprietary to the core).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
What do people think of the license for VP3. It has some weird provisions about derived software always being compatible with the original codec and some weird patent language.
VP3 is a codec that will be supported by Realplayer and Quicktime, the source was released a few months back.
A key question is exactly how you deal with your codec. If you have a definitive external specification for the codec, so that your code is just a reference implementation, I'd recommend a BSD-style license. In that case, any implementation of the code must comply with the specification. That limits the ability of companies to create proprietary extensions and damage users of the free version, so a permissive license makes sense. I'd only go to a LGPL-type license if the code is the only specification for the codec.
This is what I've done for the handful of software that I've released. All of my programs are associated with papers that describe the function of the program in enough detail that a motivated, competent programmer could re-implement them without looking at my code. Since anyone could rewrite them from scratch and avoid any license I put on the code, I don't see a whole lot of point in putting on a restrictive licence in the first place.
There's no point in questioning authority if you aren't going to listen to the answers.
It's easy. As the copyright owner, you may issue other licences that are outside the LGPL. How about this:
Company A wants a licence but doesn't want the hassle of the LGPL. Company A pays you $X for the right to use the codec in an embedded system, but you insert a clause in their licence that states that they may not change the codec, and if they do, they must release the changes to the codec (but not the whole of their work), or they must send the changes to you for possible inclusion in the LGPL version, releasing their copyright on those changes in the process.
This would mean:
1) You would get paid for their non-LGPL use of your property.
2) They would get the opportunity to use the codec in a non-free device, if they don't modify the codec.
3) If they modify the codec, the community would get the changes back in a free manner.
4) You could provide a list of licencees in the codec documentation, as in, "These people have the right to use the codec in a non-free way." This eliminates charges of stealing LGPL code (which has popped on on Slashdot in the past), and provides a little good advertising for the company as a good-faith player who went out of their way to do things right. As a proponent of free software, that might make *ME* more likely to buy their product to reward their good behavior.
5) If you don't want the money on some strange principle, you could either donate it to some worthy cause, or just issue the licences for free.
The key here isn't the money, it's the license. Just because you've issued the software under an open license doesn't mean you can't issue the software again under a closed license, because even under the LGPL, YOU remain the copyright holder, and you may use or reuse the copyright in any way you choose.
Remove the caps and hold to a mirror.
If these people want to do a hardware implementation, isn't that by definition a separate implementation of the FLAC standard? Why is there a license conflict at all? Or do you mean they want to create a small system that runs your code? In that case, if they use the unmodified source, there again shouldn't be a problem. But why do that instead of a hardware implementation?
there was a Slashdot article on how sleepycat does their licensing not long ago. It may not be a perfect match to your situation, but it is worth a look.
He's already considering switching from the lesser GPL to BSD-style. If he could do that, he can sell the priviledge of implementing using it in a proprietary system to whoever he wants. (AFAIK, it's likely that doing _either_ of those things will be a challenge, for the reasons you point out.)
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Please, forgive my having referred to FLAC as a GPL'd product although it is LGPL'd; I did so out of conversational habit rather than rhetorical malice -- honestly, I did.
Also, I wish to commend FLAC's maintainer for seeking the opinion of his community before making a decision; regardless of his final decision, praise is due to him for his having made this consultation in good faith and in a public forum. I hope other maintainers, too, will meet this standard when faced with similar situations.
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
IANAL, but I keep re-reading your post, then re-reading the license, and I don't see a problem. The "Lesser" GPL was designed to allow combining free software with proprietary software. All the gyrations in point 5 regarding compiling vs. linking and uses vs. derives are just technical ways of keeping the free software distinct and free. Point 6 was written for situations such as yours. Since you expressed the desire to keep FLAC free, go for 6c or 6d and you should be home free.
GPL in general is good to ensure that all of the improvements made upon an open-sourced code are reintegrated back into the community code. This prevents forking by allowing all conflicting versions to be united into one if a standard is desired; it also allows for variability because anyone can make a variation.
BSD license is good to allow anyone to contribute to and improve open-sourced code, but does not require that the improvement be resubmitted back into the community pool. This allows for slightly quicker development when it comes to businesses being involved. However, it also leads to the possibility of unresovable forking. Look at what happened with the variations of UNIX; they forked in different proprietary directions, each fork unresolvable with its neighbor because everyone licensed their code under "can't touch this" mentality.
As another alternative license I've proposed, one may want to say: "Any modifications to this code may be distributed under any open-source license," with provisions to ensure that businesses don't use this as a way to make one version, release it under open source, then EULA updates.
The idea that people who rely on open-sourced code to make an improvement or product should have to resubmit that to the open-sourced pool is justified and reasonable: "If I can see farther than others, it is only because I have stood upon the shoulders of giants." The vast majority of accomplishments possible today, are possible because decades and centuries ago, people contributed to public knowledge openly. In deference to those contributions, progress made on the "back" of such contributions should be available for all of society.
social sciences can never use experience to verify their statemen
>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.
Huh? Go look at the changelogs, particularly the number from apple, and try saying that again. It just wouldn't make economic sense for apple to not return the bugfixes--they then have to separately maintain their base.
hawk
A couple of weeks ago, here in /., there was a
thread about
making money in open source...
In the
interview, Michael Olson mentioned something
about the business model they adopted and its
adoption in other library-related projects...
I think it could be an interesting way to have
commercial AND Free adoption... :-)
It has occurred to me repeatedly that this is a positive model for the open source community, but I really would like to see a license that really pulls it off. I think it was the MPL that I was looking at that was almost appropriate, but it's not GPL-enough. Maybe I'm spewing smoke. I'll look into it. However, if anybody knows of a GPL-with-the-copyright-clause style license, I would love to be sure.
Now that we know that the GPL realy has an effect -- use it.
I find it vaguely amusing that you chose to license FLAC under the LGPL, but do not seem to be aware of the possibility of dual-licensing. This just goes to prove my theory that most people license software under (L)GPL because it's the "cool" thing to do, not because they actually believe in the principles for which the GPL stands, let alone understand the consequences of their choice.
If these unnamed businesses that find even the LGPL onerous are legitimate, they should have no problem paying you serious money to switch to the new BSD terms. They support the proprietary model, and you've worked hard on this project.
If they do not pay, then, your sticking with LGPL will help the development of the core free version (although perhaps hindering proprietary forks) by ensuring that future enhancements to libFLAC are incorporated, which is particularly important in the case of something that is likely to be incrementally improved by tinkering or where standardization and interoperability may be affect adoption.
Although I personally prefer LGPL'ed libraries, I would be remiss in not mentioning that, by similar argument, you might could go further and set up a "FLAC consortium" that companies would pay a small amount of money to in order go get the right to use libFLAC under something like LGPL (but which would not conflict with the requirement to pay dues).
Well I would move to a bsd license but allow the source code to be viewed look at enlightenment as an example. They were gpl at first but grappled the same issues that my project experienced
after reading up on the GPL, you have the right, as copyright holder, to make exceptions. So if company X for PDAy needs a more aggreable lience just add LGPL.legalObsucifyer("Company X has the right to include unmodified versions compied into there application PDAy");
CS!
Insightful but Overrated Troll
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
This is kind of funny because just today my lawyers told me to rip Vorbis support out of the Ultima Online client because of it's license. I know that their FAQ says that it uses BSD but apparently it is out of date. So the UO client will stick with MP3 support only. Too bad for Ogg.
What are my options? I could stick to my guns, which might limit the adoption of the format, or change the license.
If you own the copyright on the codec and on your software, you can release it under the LGPL and simultaneously license it for use in embedded projects.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
The copyleft code could be put in a seperate memory device and accessed by a list of pointers simular to a dll.
Two points:
1 -- There is a tradition in the BSD community for the companies involved to give back. Perhaps MS didn't give anything back, but Apple released their derivative work (Darwin) under an open source license and there are plenty of other companies who have also given back to the BSD community. Just because some company favors the BSD license doesn't mean their out to steal your work and give you nothing in return.
2 -- GPL is often not a realistic option, even for companies that want to support open source. A lot of commercial products contain software licensed from multiple parties. Even if a company wants to GPL its code, they may not be able to because it's linked against proprietary code licensed from another party.
The BSD license is "business friendly" because it gives people freedom to combine free software and proprietary software, so that a company can participate in the community (both taking and giving) and license critical proprietary technologies that they need to make their product work. The GPL is all or nothing. For example, if your product depends on incorporating some proprietary, patented color conversion technology, then you can't link GPL code. For every company that the GPL prevents from taking & not giving back, there is another company that wants to participate in good faith but can't.
I'd get a lawyer to discuss this with immediately. Explain your goals and show them the GPL and LGPL. Ask what your options are. Ask them about dual-licencing. They'll give you the legal answers you need.
At the same time, keep this in mind (you wrote, and I quote):
Does this mean someone could read the specs and make their own implementation without any licensing issues at all? Perhaps this would be a good solution - you could provide consultation for a fee and get some money for your work...
If those things are important to you, you'll work out solutions that allow both the format to be used widely in commercial products, while retaining the requirements of the [L]GPL.
Have you considered talking to the people interested in using FLAC in their products, or are just just listening to people who speak hypotethically? Who says the LGPL isn't fine for them?
I don't really see you have a problem with LGPL in this case. But if you do you might consider the Mozilla Public License which simply states that all changes to files within the covered code must be made public. It has no restrictions on linking with any such files or libraries built on them that I am aware of. Also a dual LGPL/MPL license is fairly common. BSD on the other hand provides no production at all for continued software freedom.
Assume they don't patent it and yet popularise a modified version of the code... WHAT DO YOU DO?
There is a comment on the ogg site, explaining a lengthy email exchange they had with RMS.
They all came to the conclusion that such a basic building block of the Internet like open audio needed a BSD-style license.
If it worked for them, it can work for you.
Sleepycat does this for their Berkeley DB software. They use (their version of) GPL and you can obtain a commercial license as well for commercial, redistributed, proprietary software. That's how they make a living.
Bas
GPL is often not a realistic option, even for companies that want to support open source. A lot of commercial products contain software licensed from multiple parties. Even if a company wants to GPL its code, they may not be able to because it's linked against proprietary code licensed from another party.
To link GNU GPL 2 licensed code to proprietary code in an embedded environment, use a pair of pipes and a simple filesystem. The GPL requires only that everything linked into one "executable" be GPL compatible, and if you have all your proprietary stuff isolated in one area of flash memory and all the GPL software in another (perhaps using some sort of simple filesystem), and you limit communication between GPL code and proprietary code to a pair of pipes, you can obey the GPL.
It becomes even easier with the GNU Lesser GPL 2.1, as LGPL code such as FLAC can run in-process with proprietary code, but you still have to provide a method to relink and reflash.
Will I retire or break 10K?
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.
And exactly why can't you dynamically link code on an embedded system? The vtable for a lossless audio decompressor would take what, eight machine words? See also my previous comment that gives a way to run even GPL software on an embedded system.
Will I retire or break 10K?
you are almost right, there's no how to recompile embedded software.
But you also said:
Fork LGPL and build your own version with a special paragraph for embedded systems.
The Guile scripting engine and the Linux kernel have a similar exception in their licenses. However, I like the following method:
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.
Bulls-eye. It's just a matter of
Will I retire or break 10K?
License it LGPL. If they want to link it into something proprietary, have them explicitly ask permission, and grant it on a case-by-case basis. If you want, you could even charge a small licensing fee to make it worth the hassle.
Oops, just kidding. :)
/. bug.
Seems like this will post to the wrong part of the thread again -- I dunno if this is an Opera problem or a
If it's a BSD license and you just want to see your superior code out in the big wide world, you win the grand prize! Your code lives on and is doing Useful Things! Maybe their implentation is better, but you can be proud of getting something off the ground. Chances are that's not the case, though -- I doubt many corporations have developers who are as bright and motivated as the people that start and maintain these labors of love. BigCorp would probably rather pay the original developer to extend the tool.
If it's a GPL'ish kind of thing, sic some law-boys on their butts (on a contingency basis, so the bigger the target, the better). Furthermore, send a news release to every rabidly pro-GPL site you can find and watch the offender get DDoS'd, h4x0r3d, spammed, and immolated in the court of public opinion. Just because you're not BigCorp doesn't mean that you are powerless.
--------------- Murphy was an otpimist.
Consider the use of this codec in a portable digital music player -- all the code would be burned into ROM, and there is no way for the user to replace/update the code
Two words: Flash memory. See also my previous comment.
Will I retire or break 10K?
Also known as "GPL plus Library Exception", where the "exception" is:
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.
Code licensed under the GPL or LGPL is not free in any sense of the word. It's not free "as in speech," because there are major strings attached. And it's not free "as in beer," because the GPL and LGPL force the developer to forfeit any reward he or she might get from improving the code. (He or she must also forfeit all rewards for a product which incorporates even one or two lines of GPLed or LGPLed code, even if the overwhelming majority of the code is his or her own work.)
A truly free license does not limit what you can do with the code, but only what you can do to the author who generously released it to the world. (For example, you can't sue for bugs.) This is true freedom. The GPL's preamble makes deceptive claims that it creates freedom in an attempt to persuade hackers to sign onto Stallman's anti-business agenda. But the fact is that the GPL makes software anything but free.
--Brett Glass
a flame war over Linux vs *BSD, why did you just say so
A real life BSD zealot.
They could fork the codebase still, making a LGPL only version, but they could not sell a private non-LGPL license.
How could you forget:
"Can you imagine a Beowulf Cluster of these?"
--
CNN declares War on Islam!
Left-wing America declares War on its Civil Liberties!
Even if you allow others to change the code and not release the source (BSD style license), you may wish to restrict what they can to with the code.
e.g
1. disallow changes to the file format to prevent the creation of an encrypted file format that other players can't use.
or
2. require backwards compatibilty with FLAC files if they change the format. This might allow for embedded players that can use still use an encrypted FLAC files, but must also play standard flac files.
otherwise someone might create an embedded system that only plays encrypted FLAC files. This would be not free and not useful to most users.
Chris
The fact that you can do something doesn't mean that you should, and I think (I hope?) most companies know better than to do something that would almost certainly unleash the ire of the free software troopers and perhaps even the fearsome wrath of those notoriously villainous Slashdot users (amongst whom I may be counted, I suppose) whose ferocious Web activity is feared by site administrators the world over!
I agree with the parent, which I would moderate as insightful if I could. I, too, have often suspected that the ample resources available in a modern computing environment make it feasible to violate the spirit of the GPL, if not the letter, by writing a message-passing interface to the desired functionality into the GPL'd code and then implementing the corresponding client as closed-source. Perhaps it is time for something like a "Greater" GPL that would address these issues and thereby satisfy the more aggressively militant free software advocates.
If the companies find bugs or extend the core, you can be almost certain that they will post changes back to the maintainers even if they aren't forced to do that by the license. Lagging behind the official releases and updates will otherwise put an increasing load on the developers that they want to avoid.
Using BSD will get you more commercial users, thus a wider audience and more people that are likely to use it and find bugs.
The Fear of Exploitation is often greatly exaggerated.
It's not as simple as you make it out to be. If I decide to incorporate a GPL product into an internal effort, I've unilaterally made the decision for all other members of my company when they wish to adopt my product. They have no real choice but to use the GPL as well.
C//
In my view, the proper order of things is to look at the licenses first and the products second; that is, if the terms of a particular license are unacceptable to you or to those who depend on you to make the decision, you ought not to be looking at the software products covered by said license. Your company ought to have a strategic policy statement regarding acceptable licensing terms; this would give you a framework within which to evaluate the suitability of a particular license and spare you the agony of second-guessing everybody else who might depend on your decision. Assuming I have understood you correctly, the real problem you are (hypothetically) facing is that your company does not have an adequate strategic policy statement concerning licensing terms for outsourced products; once your company has addressed that issue, whether or not to incorporate a GPL product into an internal effort is either a non-issue (i.e., the GPL just doesn't mix well with your company's strategic policy) or decidable based on the particular product's technical merit alone.
While you are quite right about the situation, that really emphasizes my point: adopting a BSD-style piece of software doesn't require me to consult with a corportate attorney, and if no "acceptible use policy" is present, no problem.
GPL introduces a great deal of difficulty for commercial workers.
C//