Open-source Licensing: BSD or GPL?
BSDForums.org writes "Mark Brewer of Covalent Technologies argues BSD is better for the enterprise. As open source licensing models, both the Berkeley Software Distribution license and the General Public License have advantages and disadvantages. But in the end, the BSD offers more benefits to enterprise customers. Matt Asay of Novell makes the case for GPL. He says, no one open source license is ideal in every circumstance. Different licenses serve different ends. Berkeley Software Distribution-style licenses have been used to govern the development of exceptional open source projects such as Apache. Clearly, BSD has its strengths. However, all things being equal, he prefers the General Public License (GPL ). The GPL is one of the most exciting, innovative capitalist tools ever created. The GPL breaks down walls between vendors and customers while enabling strong competitive differentiation.
Which is a better licensing model for open-source applications: BSD or GPL? What do you think?"
The GPL is one of the most exciting, innovative capitalist tools ever created. The GPL breaks down walls between vendors and customers while enabling strong competitive differentiation.
;-)
Buzz word overload! Take cover! Buzzword overload! Take cover! Buzz...
* Robot's head EXPLODES in a shower of sparks!
Would it kill people to speak in normal sentences instead of Market Speak(TM)? This entire article is just silly. Of course businesses prefer the BSD license. It places fewer restrictions on them, and allows them true ownership of derivitive works. That gives them something to later sell or use as a barganing chip.
Of course many OSS authors prefer the GPL. It forces companies and other users to help pay for development by giving back. The benefit to OSS authors is very clear. The benefit to businesses, however, is still questionable in many circumstances.
In the end it comes down to the usefulness of the software. If a business can't build upon BSD licensed software, they'll go with GPLed software. But if they can help it, they'll just go for the public domain stuff.
Javascript + Nintendo DSi = DSiCade
The GPL license is perfect for developers.
The BSD license is perfect for everybody else.
I swear to god my jaw dropped when I read the article summary, at first I was excited by the idea of some differing views being presented on the different license models, but then I hit the last line
"Which is a better licensing model for open-source applications: BSD or GPL? What do you think?"
Please for the love of god remember the children when you post.
The rock, the vulture, and the chain
I wish to edit my open source license files. Which is a better editor for this purpose, Emacs or Vi?
First you say they work to different ends and then ask which is better. Isn't that like comparing swiss cheese to nuclear physics?
I pretend to know more than I really do by mooching off google and wikipedia.
The purpose of the GPL is to ensure that the code will always be open.
The purpose of the BSD license is to ensure the authors are given proper credit, not necessarily to keep the code open.
X(7): A program for managing terminal windows. See also screen(1).
Why not mark the entire post and resulting thread as -1 flamebait now and get it over with? While it's an interesting question and I'm sure there are places where people could have a nice mature and rational discussion about it, /. is just NOT one of those places...
Anyways, as an encore, I think the next posting should be "VI vs. Emacs: Which is the best text editor for your needs?"
Furthermore, software containing embedded GPL-based code must be licensed under the GPL.
This is incorrect. The GPL does not require that derivitive works be GPLed. The key is that the restrictions placed on derivitive works (you must give up the source code and exclusive rights to redistribution) makes the resulting code effectively like the GPL. You can still use some other license for the derivitive code, and once you stop redistributing you can stop giving out the source code. Plus, nothing prevents you (as the copyright holder) from reusing the source that is yours in a non-GPL-derived product.
Clear as mud? Good.
Javascript + Nintendo DSi = DSiCade
Vi or emacs
Windows or Linux
Replublican or Democrat
Development or Systems
Apache or IIS
Apple or Intel
Oh wait.... geeze...
Bet this
The BSD license is great if you are a big company and lots of little folks like me are contributing BSD software that you can use in any proprietary way you wish. But it's not so great for those little people, because they are functioning as sort of unpaid employees. GPL gives the whole situation a balance.
If you take the range of GPL, LGPL or GPL + exception, and BSD, you have a range of licenses for essentially any business purpose. Each has their strong and weak points.
Bruce
Bruce Perens.
I'll get beaten down for posting this again, but having used FreeBSD, OpenBSD, Redhat, and SuSe extensively over the last ten years:
The Linux distro cloud is like an English garden - wild stuff going on all over the place, very easy for someone with a new idea to break in and produce a distro, and in general there is a frenetic level of innovation.
The BSD systems are more like the lawn of the base commander at Camp Pendleton - each blade named, serial numbered, and rarely do they get out of line.
I'm running FreeBSD most everywhere because I don't have to jack with it. I've got SuSe on my desktop because I've got a captive Windows thingy with accounting data and people around here pay me to touch SuSe, so its worthwhile to be up to speed.
Each has their place - I love the massive amount of GPL stuff in
Yes, I've heard of portage, no, I haven't touched it yet - consider enlightening without flaming if you're a guru
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
It is not logical to expect (IMO) that a company contracting another company is always going to want (or be willing to accept) a GPL style license, so GPL'ing something limits its use in corporate sectors (again IMO).
Now many times if you go and ask the library authors' they'll grant special permission especially in a case like this, but it's a hastle to work with. And you can argue that you should fight for free software all over, but it doesn't make business sense in every case, especially when your company is not in the business of providing support.
Also the LGPL solves this sort of issue to some extent, but I'd say the LGPL is more BSD then GPL, but that's a bit of an overstatement...
The BSD license offers more advantages to companies looking to sell software derived from existing software. They can take BSD-licensed code, do what they wish with it and treat the results as their own proprietary code.
The GPL license offers advantages to end-users long-term. Anyone wanting to take advantage of the starting point GPL'd software offers has to return the favor in the form of their code. Essentially it makes developers let other people take advantage of their work in the same way they took advantage of others' work. It also guarantees that, as an end-user, you're never in a position where you can't get fixes and modifications to the software.
Which one is better for you as the author of the software who has to decide on the license to release it under depends on your goals for the software.
An enterprise can always approach the author of a GPLed software component and license it. Then they can do whatever they want, according to the alternate license, like shipping binaries with no source. He would be a fool who would not take money from someone who wants to ship proprietary binaries containing his program or library, under alternate licensing!
But, if there are are too many joint authors, that's a problem. It may be impractical to get everyone to agree to set up the alternate licensing.
If all the authors have assigned their copyright to some organization that is politically against proprietary software, that's also a problem for you. (That's why those FSF people want copyright assignment. They know too damn well that the GPL by itself isn't enough!)
These aren't inherent problems with the GPL, though, only with the specific situation involving the GPL.
Under the right conditions, when there are only a few authors or maybe just one, the key difference between the GPL and BSD is that you have to obtain permission from the authors of the GPLed program for proprietary use. When you do that, you have a bit of advantage too, because that program remains non-free to your competition. If they want the technology, they have to approach those authors and buy it separately from you. Heck, you could even buy the complete, exclusive rights to the GPLed program. Afterward, none of your competitors could make proprietary use of the technology, only the uses permitted by the GPL'ed public releases (which you can continue to make, as the new owner!) So you see, it's pretty damn smart to write GPLed software: you leave yourself open as a nice acquisition target for someone who wants the technology.
That's what kind of makes the BSD license stupid; the authors have just given away the permission to everyone to do anything. It's a good license to put on the smallest possible piece of code that will make a name for you as a great hacker and help you secure future contracts. It's also good for your reference implementation of some spec that you are trying to push onto everyone else, whether it be a data format, protocol, or what have you. Otherwise you're just doing free work for some software venture capitalist, which is stupid. I mean, if you want to help people, go spend time with sick children or something. Doh!
My biggest problem with the GPL is the FSF's position that even dynamically linking against a library under GPL is enough to make the resulting code a derivative work (and thus also subject to the GPL). The BSD license affords much more flexibility. The LGPL is also not so encumbered. (http://www.fsf.org/licensing/licenses/lgpl.html)
Note also that the FSF's interpretation may not be binding, but it hasn't been tested in court (that I'm aware of, and I recently attended a symposium on this very topic). So, in my mind, it creates an unacceptable exposure for anyone who wants to develop software but not adopt the GPL. The BSD license is substantially safer.
More discussion on this point: http://www.oslawblog.com/2005/01/static-linking-gp l-and-lgpl.html
geek. lawyer.
The article submitter should be flayed alive. The /. editor should be drubbed soundly.
Use the GPL if you're going to get upset if someone uses your code commercially without paying you. GPL won't quite prohibit that kind of thing, but it will make most business models involving it impractical.
Use the GPL if you have strong philosophical objections to the basic idea of intellectual property. If, eventually, a sufficiently large portion of code is GPLed, then it might become prohibitively difficult for anyone to make non-GPLed code without re-inventing the wheel. Dream on.
Use the BSD license if you just want your code to be useful to as many people as possible.
...as providers of code, they hardly want to release under the BSD license. A GPL license is often acceptable where BSD is not. As consumers of code, they love the BSD license. As for OSS authors, I think the requirements of the GPL are excellent at promoting OSS. So I think the contributors should be release under the GPL (except where reasonable such as standards you want everyone to follow). What the consumers want is really irrelevant since they don't contribute in the making. Why should you aim to please someone where you have nothing to gain?
Kjella
Live today, because you never know what tomorrow brings
How many companies, as opposed to not-for-profit organisations have actually released software as BSD? For a company, *releasing* software as BSD makes no sense. Here, take my work. Oh, Mr Competitor, of course you can use my money and research to help you compete against me. No, you don't have to give me any improvements you make. With the GPL the company is assured of getting any improvements back. It's taking the gamble that while its money could be used to help its competitor if they use the code for anything it has to release *that* as GPL so that it can use it. Also if its competitor makes an improvement it will be able to use that improvement itself. For a company *releasing* software under an open-source license BSD has no real advantages and many disadvantages.
For a company that *consumes* open-source software - and by this - I don't mean using Linux on the desktop but say taking open-source software and using it in their own programs or repackaging it, BSD is obviously superior as they can take as much as they like for free, profit from it and not give anything back.
Personally I think if BSD was the predominant open-source license you won't be seeing nearly as many companies releasing their work as open-source. For for-profit companies, BSD gives all the benefits to the selfish companies and penalises the generous companies. GPL is more fair from a for-profit perspective.
Alas, I can think of many programs being released by big corporations under the GNU GPL.
Enterprises just wants other's software released under BSD.
If individual developers/small groups want to make any money from their work or get enterprises collaborating in their project, they should go with the GNU GPL as well.
Of course, sometimes the LGPL will be preferable. And -rarely- the GPL+linking exception.
Windows users:
Internet Explorer is obsolete. Please upgrade to Google Chrome or Mozilla Firefox.
"Please for the love of god remember the children when you post."
So should we license our children under the BSD license, or the GPL one?
Really depends on the source I think. My fiance doesn't let me share my source anymore, and I certainly don't contribute it back to the tree, shudder.
The rock, the vulture, and the chain
Around Y2K, I worked for a company called Cyrano.com. It produced testing
.org domains set up. The project is still running, and
software. We had done very well in the run-up to Y2K - lots of people wanted
to perform regression testing on their database applications. We were a small
company - much smaller than e.g. Rational.com (Now borged by IBM), but felt
that we had a good product. The management decided that the best way to help convince
customers to buy our product, in the face of arguments that Cyrano might not
be around in a couple of years time, was to open source the code. In these
circumstances, the obvious license to choose is the GPL: it ensures that
the company benefits from any changes anyone else makes.
I spent a very long time going through the files, adding the appropriate
header comments, and removing any comments naming individuals, especially
individuals who were no longer with the company, before setting up the
project at SourceForge: http://opensta.sourceforge.net/. There were
also OpenSTA.com and
I believe that several ex-employees, made redundant after the company went
tits-up, are now self-employed and using the application.
At the very least, open-sourcing the project meant that the codebase was not
lost when the company folded.
Flame On!
Today's Sesame Street was brought to you by the number e.
This is piss funny. Whoever wrote the answer to that FAQ must have gone on to a long career in politics.
How we know is more important than what we know.
(That has be said many, many times on this article)
. . . . is of the subset of companies willing to consider opensourcing their software, very, very few would be willing to BSD license their code, as opposed to GPL licensing it.
At least with the GPL, they 'feel' like no competitor will 'abuse' their property (i.e. take it and not contribute it back).
That should tell you something about why most companies prefer the BSD license. It have very, *very* little to do with code they themselves are releasing.
This doesn't mean that John Q. programmer shouldn't ever use the BSD. But think carefully about what it means when someone says most companies prefer the BSD license.
Microsoft has said they prefer the BSD license. How many BSD licensed Microsoft packages are there?
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Which is the best flamefest?
BSD License vs. GPL
Linux vs. FreeBSD
Emacs vs. vi
C++ vs. Java
Python vs. Perl
PHP vs. Ruby on Rails
Microsoft vs. SCO
TROLL
Because:
1) It offers *zero* real protection, *especially* for *small developers* with no legal team to back them up.
2) For people that *are* honest, it causes a hell of a lot of interworking problems.
These are quite simply the facts, regardless of all the religious beliefs that are continously being flaunted above by misguided GPL zealots.
END TROLL
I marked this as a troll because that is how most people will percieve it. Nevertheless it's the truth.
"Frankly, we resent the air our programmers use up; how come that's not mentioned in thet Coyote agreement thing we hear about?" said a spokesman.
In other news, it was found that people like to be given free money and have sex with beautiful people.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Unless you subscribe to the loony definition of "derivative code" that RMS does, the GPL encompasses a hell of a lot more than "derivatives of their code".
One of our core products is the YAZ toolkit for Z39.50 communications. That is under a BSD-style license, since it is in our interest to increase the use of Z39.50, and with it our potential market. In that we have succeeded well, we guess that about half of world's Z39.50 products are based on our tools, and we have made ourselves a name in the community of Z39.50 users.
Another core product, the Zebra search engine is licensed under GPL, because we don't mind small businesses and universities playing with it, but we don't want to see it absorbed into a competing product. We also sell commercial licenses for it, should someone want one.
Of course, we also do some custom work that remains closed source.
The difference for us is not the amount of patches we receive - that is about equal, and small in any case - but the different licenses serve different purposes.
In Murphy We Turst
They're not designed for the same purpose. The GPL is designed to exert pressure on other people to behave in a certain way (mainly, to contribute back their changes) and to grant them fewer rights if they do not. The BSD license was designed to allow the code to be used by just about anyone for just about any purpose, so it grants its freedoms a bit more freely.
If you are implementing something like a networking protocol or file format reference implementation, then your most important goal is widespread adoption, and in that case you need to go with a BSD-style license (or just plain public domain). This allows vendors to roll your implementation into their proprietary products.
For an end-user application, such as a music player, that concern is less important, and so other considerations become relevant. At that point you ask yourself, "Am I comfortable with allowing FooCorp to incorporate my music player into FooMedia Center and distribute it under a proprietary license?" If you are comfortable with that, you can go with a BSD-style license, but if not, you will want to opt for a more restrictive license, such as the GPL (or LGPL, if you want to allow non-GPLed code to link against yours).
Ask yourself: if Microsoft or Apple incorporates your code into some portion of their operating system, do you rejoice because it's seeing widespread adoption, or do you get angry because they're stealing your work? In the former case, you want the BSD license, or something very like it; in the latter case, the GPL is more your cup of tea.
Also for a smaller project you may ask yourself this: if other people contribute patches, and then you go get a new job, do you want to ensure that you have the freedom to roll this code (that is mostly yours but contains others' patches) into one of your new employer's proprietary products? If you want to leave yourself that option, you consider the BSD license; if you would prefer, OTOH, that the code you've worked on *not* be rolled into a future employer's proprietary products, you would probably be happier with the GPL or perhaps LGPL (again, depending on how you feel about linking).
Cut that out, or I will ship you to Norilsk in a box.
The vast majority of enterprise level corporations, and smaller companies, don't produce software that is distributed outside of the company. Below enterprise level companies an even larger percentage doesn't distribute software.
For these companies the license doesn't matter. Both licenses are equally free on the end-user. The licenses differ in what developers have to do if they distribute their works outside of a corporation.
For a corporation that does distribute software, wanting to build a standard the GPL would seem better to me. Under BSD a competitor can take your work, add to it and distribute it without releasing code -- competitive advantage to the competitor. Under GPL any changes must be available, they can't keep secret their modifications. Level playing field.
Freedom is not being able to do whatever you want. I cannot go and kill someone, but I have no doubt that the society in which you are not allowed to murder is the freer society. There is both "freedom to" and "freedom from". That said, BSD, LGPL, and GPL all have their place. All my work has been BSD so far, but I could see myself using LGPL (or maybe even GPL) in some cases.
The BSD licence focuses on freedom for the developer. Do what you want with it -- change it, sell it, close source it.. Whatever. Once you have the source code, (if it's still free) you can do whatever you want with it.
The GPL focuses on freedom for the source code. Do whatever you want -- change it, use it sell it, whatever -- as long as people continue to have access to the source.
The problem with the GPL is that some companies may be unwilling to use GPL code in a product if it meant that they have to make their changes publicly available.
The problem with the BSD license is that, for any company that faces real competition, releasing code changes is potentially a zero-sum game. If your competition takes your BSD code, improves it and closes off the changes, they gain from your work, and you lose.
In other word, each license has a potential cost for businesses. For GPL, the cost comes when you choose to use it. For BSD, the cost comes when you look at releasing your changes back to the community.
Given these associated costs, I'm not at all surprised to see that companies like SUN are willing to use BSD code all over their own products, but unwilling to contribute back to the community -- Contribution is where BSD costs a company. Of course, this refusal to contribute back has a cost for companies, as well. It places an intrinsic limit on the vibrancy of the community that created the product that you're so happy to use. The BSD license feeds into the environment of greed, and suffers from the costs of that approach.. The irony is that it depends on a commitment to contribution for the BSD codebase to continue growing.
This is where I see that companies like IBM prefer the GPL. Using the GPL means that you can contribute back to the community that gave you your product without having to worry about your changes being hijacked by your competition. Any changes that your competition make are required to be returned to you. The GPL enforces a share-alike attitude among it's redistributors and thus allows a company to justify contributing code back into the community. This creates an environment where the code, if it is of any use to the commercial community, it is highly likely to increase in an almost viral pattern anybody who likes it enough to use it tends to contribute to it's growth (either directly or indirectly).
This, for me, is why I'm willing to contribute to BSD code, but prefer GPL licenses. The BSD license needs a culture of contribution, but the GPL creates a culture of contribution.
Free Software: Like love, it grows best when given away.
I understand that some of you may only have heard of the open source movement. I'm grateful that you would consider using the GPL for your projects. However, the GNU General Public License (or GPL) predates the open source movement by many years by the founder of a movement with different goals than the open source movement. Therefore it is not fair or accurate to credit the GPL as an "open source license" merely because the Open Source Initiative (which started the open source movement) placed it on a list of approved licenses.
The GPL was written by Richard Stallman, most notably. Version 1 of the GPL was released in January 1989, and version 2 (the current version) in 1991. So, two major releases of what has come to be the most important and popular free software license were released well before the Open Source Initiative was founded in February 1998. The OSI has yet to write a license that compares with the popularity or strength of the GPL.
The GPL speaks repeatedly about software freedom, not "open" anything, and for very good reasons. First, the term "open source" didn't exist when the two revisions of the GPL were written. But even if the OSI existed, the open source movement doesn't want to frame any issue in terms of software freedom because it gets in the way of addressing businesses, their chief audience. Talking about software freedom means talking about something beneficial to users, not addressing more efficient means of connecting cheap programming labor with businesses. Philosophically and historically, the FSF and OSI are not the same, nor are the free software and open source movements. Stallman and Eben Moglen, chief counsel for the FSF, confirm this in every speech they give and virtually every essay they write. The Free Software Foundation has published an essay describing the differences between the two movements and why they see the free software movement as better. To this list of differences I'd add that free software guarantees private derivatives, unlike the open source definition.
The upcoming GPL (version 3) in this regard because it will be the first version of the GPL where anyone from the OSI may have editorial say in. The final word (and framing of the issues surrounding the GPLv3) still comes down to Stallman and Eben Moglen.
Thus, with all of this history, I think it is fair to call the GPL a free software license, not an open source license. The GPL existed well before and independantly of anything to do with the open source movement and does not embody the values of the open source movement. I encourage you all to stop misleading people into giving the OSI and the open source movement an undeserved primacy.
Digital Citizen
Any social system have a form of property, if i think in socialism i also think in colective property, like GNU and GPL software.
But how is GPL software "collective property"? There's nothing "collective" about the ownership rights involved in the GPL. If I write a piece of software, and license it to Al under the GPL, I still own it; meanwhile, Al owns it *too*. We don't own it "jointly" or "collectively", we *each* own it, and we can *each* do what we want with it.
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
That's exactly why the LGPL exists.
You shouldn't be copying from the headers anyways. You should be #include-ing them.
It's really not that big of a deal to make most programs dynamically linked... it's standard industry practice.
That the user can replace some libraries is actually a good thing... for example, the SDL shipped with Neverwinter Nights does not work with some recent versions of nvidia-glx, but newer versions of SDL do, so I just replaced the SDL in NWN with a symlink to my more recent SDL library. If I couldn't do this, I wouldn't be able to run the program, and I wouldn't have bought the expansion packs.
The whitespace grows on you
Once you realize how much block-close-character noise it saves you (because you do indent anyway), you love it.
The colons are openers of nested code. They serve important purposes:
Also, in a 4 line program, 2 colons doesn't seem like a "lot" to me, and they contribute greatly to readability.
You cannot undefine primative procedures like car/cdr to mean something else. But there is nothing preventing you from defining my:car and handling any combination of arguments and types you want. This is a lot nicer than C++ where you have to use clunky templates. In Scheme, procedures that smoothly handle multiple types and numbers of arguments are built right in.
Well, this is a problem. In Python, almost all access to objects is done through methods of the object. When converting the object to a string in order to print it, its __str__ method is called. When trying to evaluate it as True/False for a conditional, its __nonzero__ method is called. When an attribute in the object is looked up, __getiter__ is called. This allows me to "hook" those operations, and manipulate the way the object is accessed.
This is a very powerful feature, that enabled me to write PyInvoke, for example.
I can create Proxy objects that redirect almost all operations done with them to a server. With Scheme, I would not be able to implement this, because I couldn't Proxy a list object, as a (car proxy) access would not be interceptable in order to forward to a server.
This means transparent RPC is possible in Python and not in Scheme.