LGPL or BSD-Style License for Media Codecs? 203
"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?"
Oh don't worry about licensing... (Score:5, Interesting)
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.
Re:Oh don't worry about licensing... (Score:2, Interesting)
The best way to keep control and yet get a wide distribution is to write your own specific license that allows use and modification within certain conditions - e.g. that all changes are provided back to you. Making money is also a very healthy idea. Finally, I don't believe that individuals and small organisations can seriously follow-up on license breakers. If someone wants to steal your product, idea, or code, they will. You simply need to make it easy for the honest majority to use your work.
Re:Oh don't worry about licensing... (Score:2, Insightful)
Or, better yet, get a lawyer to write it for you.
Very good Idea (Score:5, Insightful)
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.
Re:Oh don't worry about licensing... [NOT SO FAST] (Score:5, Insightful)
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.
Perhaps... (Score:2, Interesting)
You might even be able to make a couple bucks off it.
The library - current and future versions - would still be free.
If the code is yours... (Score:5, Informative)
Re:If the code is yours... (Score:3, Informative)
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 [slashdot.org].
Re:If the code is yours... (Score:2, Interesting)
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<
Re:If the code is yours... (Score:4, Insightful)
The problem with the BSD approach of "people should be free" is that it gives people the freedom to destroy the work upon which they are building. What if MS had realised early enough that the Internet was the Next Big Thing and had incorporated the BSD TCP-IP stack in from Dos 3 (for example) but they had modified it slightly so you could work on the MSNet or the Internet? Who would have won the war? Would the net have split? It seems ridiculous now, but then it could have been fiery if they had done early enough!
The GPL is far more than a BSD licence, it imposes a simple (in theory and concept but maybe not practice yet) set of rules which say that anyone who receives the work under it cannot undermine the project by releasing closed incompatible versions. What if MS now pick up Ogg Vorbis and use a minorly modified but incompatible version for their prefered audio format from now on? These new users will be orphans from the existing user base, benefiting from its work, but unable to benefit from the Freedom they would have had were it still GPL. So BSD does not make people free past one generation (each BSD receiver is free to do what they want, but their users are not free) whereas the GPL makes the software Free and all the users free, the developers are as Free as is possible while preventing them from having the opportunity of reverting some of the benefits of the Freedoms the GPL is designed to uphold.
Re:If the code is yours... (Score:2)
If MS had realized that early enough, they would probably have written their own TCP-IP stack if they had to anyway.
Re:If the code is yours... (Score:5, Insightful)
Of course, contributers could agree to let their contributions be dual-licensed as well, but it strikes me as unfair that you'd get paid by proprietary licensees for those contributions and the contributors get nothing. This would discourage dual-licensed contributions and lead to a license-based fork soon enough. This would be less of a problem, I suppose, if you received no compensation from proprietary licenses, but that would be unfair for you.
There is a way out, though, that would (I think) let you GPL the code, and still be able to use it in proprietary products, but it is one hell of a kludge, and relies on a fair amount of trampoline code.
The GPL requires all statically, and depending on who you ask, dynamically (RMS, of course, says "yes, dynamically too" [my paraphrase]), linked code to be GPL if the result is distributed (an exception is made for libraries normally provided with the O/S, but what is O/S and what is app gets sticky in an embedded environment). However, non-complex communication with non-GPL code via pipes or sockets is O.K. "Non-complex" here is a matter of interpretation, but a classic server or filter utility is generally fine.
It strikes me that a codec can be interpreted as a filter, or simple server, in a loop-backed TCP/IP networked environment, so this could work. Is this overkill? Sure, but it would avoid the licensing issue completely: embedded systems could just ship with the source. I suppose that even that would not be necessary if the system were ordered on-line -- then an FTP server would suffice.
From a technical standpoint, this does introduce a lot of pressure on the embedded side: you need a whole TCP/IP stack and ROM and RAM tend to be precious in such systems. The overhead of packetizing and unpacketizing will require a bit of a beefier CPU to boot. I tend to think that even the smallest embedded systems today could handle that, but it is a concern. Of course, the network type the sockets use doesn't have to be AF_INET, permitting some short-cuts.
As a bonus, the pipe- or socket-based codec would be useful in a processing stream on non-embedded systems -- if you provided a traditional library instead, someone would quickly write such a filter (in the Unix sense, not the audio sense) app anyway.
Re:If the code is yours... (Score:2)
Therefore, I would encourage the use of soem well-known license.
OGG dual licensed (Score:1)
http://www.vorbis.com/faq.psp#flic
Ogg Vorbis Went Through This (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.
Interesting timing (Score:2)
I wonder if somebody at Linn reads /.!
You can have several licenses (Score:2, Informative)
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.
Ogg Vorbis Example (Score:5, Informative)
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.
Re:Ogg Vorbis Example (Score:1, Interesting)
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.
Be friendly to those who would be friendly to you. (Score:2, Insightful)
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 [slashdot.org] 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 [slashdot.org]. 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.
Re:Be friendly to those who would be friendly to y (Score:2)
>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
Re:Be friendly to those who would be friendly to y (Score:2)
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//
Re:u need a strategic policy statement about licen (Score:2)
GPL introduces a great deal of difficulty for commercial workers.
C//
Use pipes and a simple filesystem (Score: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.
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.
Argh. Well, what is it YOU want? (Score:2)
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.
Change your business model (Score:3, Insightful)
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
Re:Change your business model (Score:2, Funny)
Re:Change your business model (Score:2)
Mod parent up
Re:Change your business model (Score:3, Interesting)
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.
Re:Change your business model (Score:1)
If they want your codec in proprietary systems... (Score:2)
I'm sure that will clear up any questions, ambiguity or doubt.
BSD won't let you sofware free. (Score:4, Insightful)
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)
BSD license all the way... (Score:3, Insightful)
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
Re:BSD license all the way... (Score:3, Insightful)
IIRC the Kerberos protocol had similar problems at one point.
What's the problem with LGPL? The code you write remains yours, you don't have to give it to anyone, and if you really want to change the codec, then you have to publish your changes. Seems like a damn fair deal.
This BSD approach is nice and kind, but if you have to compete with Microsoft, that approach is doomed to failure.
Re:BSD license all the way... (Score:2)
Think about that for a minute. TCPIP stack is in the same boat. All the initial recipiants of it extended it a little BUT the fact we're still using it today should indicate something to you. They were good extensions.
Re:BSD license all the way... (Score:2, Insightful)
That's a risk, yes, but how often does it really happen? I will grant that the old BSD license was actually better in some ways since it required acknowledgement of the original authors of the code -- not a terrible onerous requirement. Still, if the company in question is, say, a certain large evil empire(tm) (or even a malignant barony), do you really think the GPL is going to prevent them from grabbing whatever code they feel like grabbing?
I'm sure it happens all the time, but it's kind of a karma thing: $DIETY will eventually make them pay for their sins.
I can give a good example of how some businesses look at this sort of thing, and why: I found some source code on the net for a really useful piece of microcontroller code that would save a lot of development time in a project my company is working on. The "free" license spelled out in the source is restricted to "personal use" -- use in a commercial product is subject to a $.25/copy royalty. We modified the code to suit our purposes and could have just gone ahead and used it without saying a word. Instead, I contacted the author and let him know what we were going to do and actually paid him nearly a kilobuck more to do a code review of our modifications.
Why?
- It's the right thing to do. Yes, there are a lot of people who feel this is a good guide for doing business and value the ability to look at themselves in the mirror with a clear conscience every morning.
- It's the responsible thing to do. As a manager, I have a serious responsibility to the company I work for to not break the law or expose the company to lawsuits, however slight the likelihood of fallout may be.
- It's the smart thing to do. If I tell my engineers to go ahead and rip off code, I'm probably also telling them that it's OK to rip off lots of other things. It's bad for morale, too, and morale is THE most valuable thing in any business; you don't do things to hurt it if you can possibly help it. Nothing is worse than an apathetic, demoralized developer -- their pr0n collections go up, their output goes down, and the source begins to resemble a roach motel.
It's just good business all the way around.If they want they can throw a patent in, too. However even with just a trade secret they can lock you out effectively, thanks to the DMCA. IIRC the Kerberos protocol had similar problems at one point. What's the problem with LGPL? The code you write remains yours, you don't have to give it to anyone, and if you really want to change the codec, then you have to publish your changes.
Well, they have to publish their methods in a patent, so it would be pretty easy to figure out it it's a derivative work and show prior art. No DMCA sillines required.
Seems like a damn fair deal. This BSD approach is nice and kind, but if you have to compete with Microsoft, that approach is doomed to failure.
Umm, yeah. BSD is dead. Has been for a long time. I've read about it several times over the past few years, so it must be true. Oddly, the URL at the top of this post still works. Maybe they prepaid their Web hosting service and it's just running on autopilot...
LGPL. Absolutely. (Score:4, Informative)
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!
Re:LGPL. Absolutely. (Score:2)
It's an embedded systems issue, though. Proprietary application dynamically linked to an LGPL library on a regular PC? No problem. Proprietary application dynamically linked to an LGPL library on an embedded device? Resource problems. Proprietary application statically linked to an LGPL library on an embedded device? License problems.
Even though people are doing what's identical in overall intent/spirit to a permitted activity, technical limitations shoot it down.
Re:LGPL. Absolutely. (Score:1)
I do not think so - as long as you provide possibility to re-link proprietary (object) code to the (modified) library. Anyway he can always clarify that in "his" license that statical linking is OK. This is what FLTK guys do
Roman
Re:LGPL. Absolutely. (Score:2)
A copyleft license is probably the most effective way to prevent forking of your project, but it's not the only protection. A well-known name can be used as a protection as well, by allowing use of the name only for compatible implementations.
Either trademark the name and license it only to those whose software is compatible. The problem is that in order to prevent the mark from becoming unenforcable, you'll have to enforce it against everyone who uses it without license (even against other free software projects). I don't know if you can grant a license for the trademark to anyone who uses an unmodified version of your code. Ask a lawyer about this if you like this idea.
The other option is to deny usage rights for the name in the software's license, similar to what the Apache license is doing. This is probably less safe than what trademark protection can offer, but it's also less work for you. Maybe you can rewrite that part of the Apache license so that users of unmodified versions of the library may use the name.
Note that either of these methods requires some marketing to be effective. Denying people to use the name is effective only if not using the name is a marketing disadvantage to them, which it is only if the name is well-known.
Re:LGPL. Absolutely. (Score:2)
You are making the assumption that forking is bad and that keeping everything in one source tree is good. I'll argue the opposite. The ability to fork is a Good Thing(tm). Show me a software project that is not allowed to fork and you'll be showing me a proprietary software project.
FreeBSD and NetBSD forked off of 386BSD because the latter project had stagnated under its maintainer. OpenBSD forked off of NetBSD because of a difference in goals. None of the non-free forks of the BSD code base (SunOS, BSDi, Darwin, etc) has harmed any of these projects, and there is ample evidence that cross pollination occurs even there.
RMS makes an argument that software should be free because its nature allows it to be exactly copied without harming the original. If that is true, then what harm can come of the original if someone forks the codebase? What harm can come of the original if someone creates a proprietary derivative? None!
Both copyleft and unrestricted licenses have their place in the development world. Copyleft is great if the author wishes to retain ownership of the software while pretending to not own it. Unrestriced licenses, on the other hand, are great if you merely want to share your code with other people.
"Clarifications" (Score:2)
That way, you can demand all distributed modifications, while removing the barriers that are troubling you.
-Peter
Go BSD (Score:2)
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.
GPL, of course. (Score:1)
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.
Licenses (Score:1)
2 licenses (Score:1)
A Different Licence (Score:1)
After a little exploration at gnu.org's Free licence list [gnu.org] 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
use the BSD license (Score:5, Interesting)
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.
Re:use the BSD license (Score:1)
Re:use the BSD license (Score:3, Insightful)
Re:use the BSD license (Score:2)
I'll have to punt here, since if you have to ask, you obviously haven't "been there" before.
device drivers, ip-stack, kernel - all need changing to be tuned to your special hardware and features offered. its not only the hardware that's the value-add, it is the software as well.
I'm all for submitting back software updates that don't "give the store away". no problem here. but to say that ALL changes must be kicked back - that's extremely naieve.
That argument is about as stupid as companies (like NVidia) who refuse to support Open Source drivers
a $100 device and a $1M device are quite quite different, wouldn't you agree? high end router companies (like the ones I was referring to) will simply NOT release source to anything that they've put significant value-add into. sorry if that reasoning escapes you.
And since you're talking routers, security matters. I would gladly pay a little more for a router based around GPL-free software.
when you wake up from your dream, do let us know. million dollar software/hardware devices are in a different class from commodity hardware-based systems.
Re:use the BSD license (Score:2)
there's a little minor detail known as 'keeping one step ahead of competition'. releasing your value-add software patches will give them an edge that you may not want to give them (most of us are stock owners and do care about getting to the top before the competitors).
why is NOT giving out hardware info well understood, but giving out software info NOT well understood? an edge is an edge. if you're working 12hr days to get to market first with a quality product, why should it just be given out free? (this is the problem I have with crazies like RMS - they don't seem to live on the same planet as the rest of us).
your competitors couldn't use it in their product unless they also released their sources.
in theory, yes. but in practice, even just delaying a few months (tangling things up in legal work) could give them an edge. just like M$ - they'll eventually end up being found guilty of strongarming; but by the time they pay their penalty, all the competition has been long crushed and out of business.
us geeks can argue^Hdiscuss this subject all we want. but I'll put dollars to donuts that no major company that is pricing their toys at this stratosphere will EVER consider anything but BSD. the bean counters won't take the chance, the VC's wont authorize it and even the customers might not like it (long long story; and sounds counter-intuitive, but I assure you there's a truth to this that I just can't go into for various reasons..)
Re:use the BSD license (Score:2)
Or you could just release the 'value-add' GPL'edsoftware patches only after the product is ready to ship out. And if the patches are really that specific to your hardware, what advantage are they to competitors anyways?
why is NOT giving out hardware info well understood, but giving out software info NOT well understood? an edge is an edge
I don't believe in holding back hardware detail either if they may be valuable to the customer in some fashion. Sure, you can have your trade secrets. But if your competition is really that desperate, they'll reverse engineer your products whether they're open or not.
the bean counters won't take the chance, the VC's wont authorize it
Of course they won't. Because they think only inside the box of what they learned in business school. Doesn't mean we geeks have to let them push us around. Unfortunately, not enough geeks have the motivation or self confidence to strike out on their own. But that's a whole 'nuther can of worms.
Re:use the BSD license (Score:2)
the problem is, you can't be selective when you write software. if it touches this or that, you're compelled to release (under regular GPL) your goods. so while some hardware handlers might not be immediately useful to the competition, some other code that exists entirely in pure software space might also have to be released; and this isn't desirable for obvious reasons.
I firmly believe there are places for totally free software, totally closed-source software, and stuff in between. there isn't a one-size-fits-all license - and there shouldn't be! just allow the freedom to choose your license based on your own special circumstance. in our case, bsd fit the bill and was the only license that we were able to realistically consider. this is the real world, like it or not.
Re:use the BSD license (Score:2)
which part of 'stratosphere' didn't you understand?
Re:use the BSD license (Score:2)
Case in point: TiVo [tivo.com] (At its heart lies the Linux kernel.)
Re:use the BSD license (Score:2)
With the death of Walnut Creek CD Rom, the last significant commercial player in the BSD field died. The BSD license is partly to blame.
Walnut Creek was a distributor of other people's software. Among their offerings were GPL Slackware, BSDL FreeBSD, and a shitload of proprietary shareware CDs. The BSD license wasn't a part of their business model. BSD licensed code was a part of their infrastructure, and if I'm not mistaken, their FreeBSD based ftp server still holds a record.
Walnut Creek CDROM went out of business because their services were no longer needed. They made money by selling CDROMs, and the more people with access to the internet and especially broadband, the less profitable they became. At one time the only way I could get Slackware or FreeBSD was by paying $39.95 to Walnut Creek. Now all I have to do is spend two hours of download time and I can burn off as many copies as I want. The *only* reason I kept Slackware and FreeBSD subscriptions going was because I wanted to support those projects financially.
One of the reasons BSD is struggling is because the license does nothing to restrict code hoarding, while also not encouraging code sharing.
BSD is struggling? Hah! To the contrary, it seems that the Great WindRiver Dumping of FreeBSD was the best thing that ever happened to the project. The world now knows that FreeBSD isn't dependent upon commercial sponsorship, and it has become much more viable.
FreeBSD 4.4 came out only a couple of months ago. OpenBSD 3.0 came out this week. NetBSD now runs on the PS/2. These are vibrant and growing projects.
There is not social agenda attached to the BSD license. You take that as being a negative, but to a lot of people that's a positive. There is a time and a place to preach, pontificate, argue, and try to change the world. For many of us, a software distribution is not that time or place.
The BSD license is about what the author has done with the software, not what he or she wants you or anyone else to do with the software.
The saddest irony is that the BSD license was entirely accidental, it was not intended to be a "philosophy".
That's the best part about it! You don't have to read a political diatribe at the beginning of the license. You aren't required to redistribute social opinions contrary to your own. It's politically neutral. That may offend you, but for many people in the Open Source world, it's a breath of fresh air.
BSD like... (Score:2)
Scope [sourceforge.net] 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.
BSD license? (Score:1)
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.
Patented algorithm? (Score:1)
Netscape Public lIcense or similar perhaps (Score:2)
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
First, what are your goals? (Score:4, Informative)
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. [opensource.org]
If not, I suggest the MPL/GPL/LGPL [mozilla.org] 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.
Re:First, what are your goals? (Score:2, Insightful)
I found your How to choose a free software license [dina.kvl.dk] to be well written, and it is probably helpful to a lot of people.
Take a look at the DiVX 4.11 licencse (Score:1)
Reformated Repost of DiVX Licencsing (Score:1)
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 [mailto]. Considering Blizzard [blizzard.com] 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.
Just remember one thing... (Score:3, Interesting)
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.
Embedded software is different - look at Tivo (Score:3, Insightful)
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.
Re:Embedded software is different - look at Tivo (Score:4, Informative)
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.
Re:Embedded software is different - look at Tivo (Score:2)
I maintain my point. The reason people could add an ethernet card (and driver ?) to the tivo is that they are familiar with the OS, not because it is GPLed. If the Tivo's OS was Windows NT (embedded) ((uck)), or, more probably, Windows CE, which lots of hackers are familiar with, I bet that same ethernet driver could have been added.
Re:Embedded software is different - look at Tivo (Score:2)
Actually, yes. Back when the first HD hacks were being performed on the TiVo someone hacked the kernel to fix a bug that prevented support of >40 GB drives. I believe the kernel in the current software release on the TiVo (2.5) already has this fixed, or they've found a different workaround, since you can now create 225+ hour TiVo's (previously the 40GB issue limited you to ~80 hour ones (2 40G drives)).
Sorry, can't provide the links or verify that the above numbers are dead on since my employer blocks AVS Forum [avsforum.com].
That said, I'll abstain from commenting on the real issue of the thread. I'm not sufficiently familiar with the ins and outs of MPL/LGPL/BSD licenses. The BSD license is more real world friendly, and many other posters have good points about the downsides of a company deciding to privately fork development off.
Think about patents (Score:1)
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
This would be my solution... (Score:2)
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.
"Embedded" is the crux of the problem (Score:2, Insightful)
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.
Look at GPL like MAD MP3 decoder (Score:1)
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/ [mars.org]
jeff
What is so restrictive about LGPL? (Score:1)
god dammit! don't click on the plib link (Score:1)
keep it free, if you can afford to (Score:1)
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.
Individual Function Linking (Score:3, Interesting)
However, there is an elegant solution. The solution, which I discovered by using some ThreadX [threadx.com] 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
Re:Individual Function Linking (Score:2)
JOhn
BSD vs LGPL (Score:3, Insightful)
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.
Public Domain + whatever (Score:2)
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.
My Concern with BSD... (Score:2)
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...
GPL with exception (Score:3, Informative)
Re:GPL with exception (Score:2, Insightful)
The specific paragraph we add to the GPL is:
"As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."
Be aware that if your software is useable in non-embedded systems, you might want a more
pure version of the GPL. Someone mentioned allowing the exception on systems without dynamic linking.
We have tried very hard over the past 10 years to walk a fine line between being free software for embedded systems and placing undue restrictions on those using our software. It is a tough balancing act but we like this solution. Making your own strange license requires that you explain it which is no fun either.
Check out the eCos license.. (Score:1)
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
A possible solution (Score:1)
I suspect that the "GNAT Modified GPL [earthlink.net]" (GMGPL) solves your problem, since it specifically allows non-dynamic linking of libraries without infecting a program using the GMGPL'ed library.
Jacob
Embedded friendly LGPL (Score:2)
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).
vp3 license? (Score:2)
What do people think of the license [vp3.com] for VP3 [vp3.com]. 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.
Reference Implementation (Score:2)
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.
Relicense It (Score:2)
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.
wxWindows license. (Score:3, Insightful)
I'd recommend this over the BSD license because it removes the opportinity for certain crooked companies [microsoft.com] 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.
What's the problem? (Score:2)
Sell LGPL exceptions? (Score:2)
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).
Misunderstanding of intent? (Score:2, Interesting)
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.
3rd Option (Score:2)
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.
MPL (Score:2)
GUILE License == "LGPL Done Right" (Score:3, Informative)
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.
Re:This is why you should never GPL anything(or LG (Score:1)
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.
GPL is no more "honest" than BSD (Score:1, Informative)
Under the BSD, anyone who lifts the code is following the licensing terms in a perfectly acceptable way - there is no "dishonesty" involved.
Re:Vorbis uses LGPL. (Score:2, Informative)
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.