Seems every time I write a piece suggesting open source as an option, I get a couple of comments warning readers about the scary complexities of open source licenses. So I decided to ask a guy who knows free and open source (FOSS) exactly what the deal was regarding FOSS licensing and whether they were really any more or less complex than their commercial counterparts.
Joe 'Zonker' Brockmeier, who is Community Manager for openSUSE and has been working with FOSS in one way or another since 1996, says the bottom line is that you should always check the license language carefully, so that you are keenly aware of the terms, but you should never let the license scare you away from open source.
RM: Every time I write about opens source, I get comments about watching out for the licenses, that they can be confusing and get companies in trouble if they don't pay attention. Are open source licenses in general any more complex than their commercial counterparts?
JZB: Not really. The only difference is that open source licenses allow redistribution and modification -- and since there are a lot of different licenses with different conditions, companies should pay attention when they engage in those activities.
As a general rule, though, use of open source is no more complex --and is typically less complex -- than use of proprietary software.
RM: Comments also suggest open source users should be careful about altering the software, which you can do under many open source licenses, What are the conditions under which companies can alter the software?
JZB: It depends on the license, but open source means companies can always alter the software -- what changes is the conditions that you need to meet after doing so. If you're altering for internal use only, typically there's no requirement to do anything. If you alter the software and redistribute, then it depends on the license whether you need to make changes available or not, how you need to acknowledge the original software, and so forth.
RM: When companies make changes to open source software, what are the general rules, about giving back and sharing with community? Does this differ across products and communities?
JZB: Well, that depends on the license, and the communities. Software under the GNU General Public License and copyleft type licenses requires that changes be made available when you distribute the software. There's also the matter of the so-called 'viral' nature of the GPL, which means that if you incorporate GPLed software into your product, you may need to distribute the entire thing -- not just the original GPLed product.
This can get a bit complex, and a company should consult a lawyer and/or the Free Software Foundation for advice on this kind of thing. (The GPL also has an extensive FAQ, which, sadly few people read!)
Note that mere aggregation doesn't mean you have to GPL the entire thing. So, for instance, if you have a program that does its own thing distributed with a bunch of other software, that doesn't mean all the other software has to be GPLed. But, if it's 'derived' from the GPLed software, then you need to GPL the entire lot.
An additional note - a lot of people like to use scare tactics to try to convince companies to avoid "tainting" their software with GPLed software, claiming that it could force a company to open all of their software. Not true -- the worst case scenario is really that a company may be forced to cease distribution of the GPLed software if they're not willing to comply with the license. Now, this may be inconvenient, but if a company feels that its code will lose value to the company if distributed under the GPL, they can opt to not distribute the GPLed code and retain their copyrighted code under whatever license they choose.
Proprietary companies want money for their code, projects that GPL software simply want code in lieu of money. (Of course, it's not unheard of for authors to dual-license software too - so companies have the option of asking to pay licensing fees for GPLed code.)
BSD/MIT style licenses require very little - so companies are allowed to keep the code under whatever license they choose and may even keep their changes proprietary -- though they may have some notification requirements.
RM: How do communities incorporate ad-hoc changes into the core offering?
JZB: It depends. One of the sad things is that many companies choose not to collaborate effectively with the communities that produce the code -- and therefore tend to just deliver "code bombs," which is to say, a tarball of code without any revision control history or other assistance that would allow a project to easily consume the changes.
So, sometimes a company makes valuable changes to a code base that are not easily incorporated because of the way the changes are delivered.
The process works best when a company becomes part of the community of the software they are consuming and the company's developers work hand-in-hand with the rest of the project, so that the code stays in sync with the development trunk.
Related TechTreasures Posts:
Joe 'Zonker' Brockmeier Discusses openSUSE 11.1
Gartner Report Exaggerates Open Source IP Concerns
