Still, some may ask, is business trying to dictate to the community, or do they have a valid point, and if they do, what is it? Why are there too many? The community has managed to function with many licenses for years, so why is it a problem now? Let me try to explain.

Why Now?

Software development is changing, thanks to Free and Open Source software, and it's a rare business today -- in any field -- that isn't using FOSS, at least to some extent. That shift, from in-house proprietary development in secrecy to combining chunks of freely available code under a variety of licenses, requires tweaking some things so that business can safely participate. The business community doesn't like unnecessary risk, and why should it? Each license brings with it conceivable risks that must be analyzed carefully, and that process, multiplied many times over for each license, is costly and time-consuming. It's like raising a flag that says: Warning. May Be a Risk for Your Business. Even if all the flag says is: This is Going to Cost a Lot, it's still a problem.

Another reason it's an issue now is because license proliferation has reached ridiculous proportions, to the point that some view it as undermining the strength of the FOSS community by balkanizing code. If important projects can't use each other's code, it undermines efficiency and the philosophical underpinnings of the community, which has as one goal the unrestricted reusability of code. That, ironically enough, can lead to FOSS programmers having to reinvent the wheel like proprietary programmers have to. It also leads to concerns about complexity and increased legal risk, from using code with licenses that are little used and understood less.

You can't mingle code under the Apache License, for example, with GPL or LGPL code, although efforts continue to try to work those issues through. Sun Microsystems' CDDL license is incompatible with the GPL, so "a module covered by the GPL and a module covered by the CDDL cannot be legally linked together," the Free Software Foundation has stated. That is a lot of code to have to keep apart, particularly when you reflect that by far the majority of all FOSS projects are licensed under the GPL, and the next largest block is the LGPL. There are real disadvantages not only to the community but to business when code can't freely be shared.

But the fundamental reason why now is the time to address this issue is a good one: it's because the business community has fallen in love with FOSS. To make it a smooth marriage, FOSS has to take into consideration the needs of the business community.

After SCO, You Need to Ask, Why Now?

The FOSS community has no real history of litigation, so that is usually the last thing it thinks of. When it was just community members interacting with one another, that worked well, and if it took years for the Apache License and the GPL/LGPL to become compatible, who really cared? Nobody was suing anybody. Everyone knew it'd get worked out in the end, flame wars notwithstanding, because that is how the community behaves.

But with actors like the SCO Group educating the FOSS community on just how nasty things can become in the proprietary world, everyone should now understand that wherever big business goes, litigation follows. Why? Litigation follows money. So we have to listen to what our new lawyer friends tell us, because the traditional community ways, while highly effective in a community based on trust, can be exploited by those who sneer at, if they think about them at all, the ethics that the community holds dear and who, seeing the success of projects like Linux, want only to block or exploit it. Is FOSS particularly vulnerable to attack?

Why FOSS Is Different

Just as there are legal pitfalls unique to proprietary software, there are some unique to FOSS. What are they?

This is a good time to tell you that you are far more likely to be sued over a proprietary license than over any Free or Open Source license, according to Stephen R. Walli, VP, Open Source Development Strategy at Optaros, Inc., and who was before that a business development manager in the Windows Platform team at Microsoft, who wrote recently on his blog:

"A company stands a larger risk of being sued over license counting issues from a commercial software vendor than they do over intellectual property issues (copyright) and open source. License management and counting users is a notoriously difficult space. Both vendors and customers can feel they're being cheated. There's no good general way to manage user license counting across diverse vendors and products. Vendors regularly litigate in these spaces. Some even wield the BSA as a stick and call for audits. Open source licensing reduces risk here."

The next time someone tries to tell you that the TCO is lower for Windows than for Linux, ask them if they factored in user license counting and related litigation.

But there are issues unique to FOSS. For one, there is very little case law to guide us, precisely because FOSS isn't known for litigation. But that means that there is very little case law, so there aren't a lot of clues as to what a court will do when interpreting problems that might arise. Just as programmers benefit from many eyeballs in searching for bugs, so lawyers benefit from prior cases. They read what happened in other cases that are similar to their case to figure out the probabilities of what will happen if they sue or are sued. Not having a rich litigation history, FOSS licenses are harder to analyze and predict knowledgeably.

Another issue unique to FOSS is that companies are used to negotiating proprietary license agreements and having a top-down process for acquiring code. FOSS acquisition can inappropriately bypass those business acquisition procedures. With so much tempting FOSS code available on the Internet, developers might simply download and plug it in, without realizing that FOSS license terms are binding, just like proprietary EULAs, or because they wrongly assume FOSS code is public domain. Savvy companies understand the need to establish policies and to educate their employees about appropriate use of FOSS code.

How the Community Traditionally Handles Licenses

A microcosm of how the community functions can be seen in the recently announced project Harmony, a project to try to create an Open Source version of J2SE 5, the latest version of the Java 2 Standard Edition specification. When it was announced on an "incubator" Apache mailing list and on LWN.net in May of 2005, the discussion prominently included how to handle various license requirements of all the projects that would be trying to work together, as well as the legal issues arising from wide exposure to Sun Microsystems source code. How can you have wide participation, some asked, if the license chosen is incompatible with the GPL? What about prior projects already working on the same goal? Significantly, the FAQ admitted that at that early point, they didn't yet know how to accomplish all the necessary legal aims:

We would like to perform continuous "surveillance" on the codebase we are building, and compare to class library and VMs from elsewhere, like Sun, IBM, BEA, Kaffe, etc to ensure that no code from those efforts become part of Apache Harmony without our knowledge. We do this to protect ourselves, our users, and of course those other efforts. We don't know yet how to do this, but are exploring ideas such as having a third party such as Black Duck or an existing licensee (or Sun!) do this for us. This, like all the topics herein, are open for discussion an[d] change by the community.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.

One poster commented that the GNU ClassPath exception undermines restrictions the FSF wanted, and anyway, it hurt his brain enough trying to figure out what the terms of the unmodified GPL mean for a Java program, let alone what they mean after major exceptions. Another comment was left that epitomizes the difference between the FOSS programmer community and lawyers:

The more open source Java there is, the better, even if we have competing projects, and especially if we have projects that use different licenses that each are good for their own intended purpose. Competition is good for us. And, why shouldn't we be able to choose the best license for the task at hand, and still have good code to use?

How Lawyers Think

The first thing you need to understand about lawyers is that they are a cautious bunch. They have to be. People hire them to figure out what to do when the worst happens. So they spend a lot of time imagining various worst-case scenarios, so they will be able to advise clients how to avoid them, or if they occur, how best to deal with them.

That is the process behind drawing up a contract, after all, where every comma can end up mattering in some litigation down the road. You must try to imagine every claim that could ever be brought, and every conceivable situation your client could end up in, and then do your best to draft the contract to try to ensure a happy outcome for him or her, no matter what happens after the contract is signed.

But thinking that way colors your mindset. It happens to paralegals, too, by the way. You naturally tend to think of what could or might go wrong in any situation. Observing outcomes for clients builds up a cautionary library, and spending your working life thinking like that affects your outlook when it comes to anything new or unexpected. If lawyers perceive a risk, they will avoid it if they can or route way, way around it.

When it comes to software, what can go wrong can be serious. You can probably figure out some of the worst case scenarios yourself. A business might be subject to litigation by someone claiming ownership of code the business thought was Open Source. Or someone might discover FOSS code mistakenly inserted inappropriately in a business' proprietary software product, with license terms that are unacceptable or incompatible with the business' aims or other software. Now what? Or a business might lose the right to sell their software, after litigation over patent infringement results in an injunction, or be forced to pay significant money damages or agree to expensive licensing demands. That isn't unique to FOSS.

Lawyers can't beg off. For them, there is no "I don't know but I'll ask my lawyer" or hiding behind "I am not a lawyer. This is not legal advice" disclaimers. They are lawyers, and it is legal advice they offer. They have to know the answer, and it'd better be right. A lot of money is riding on it. They may be interested in community input, but they are not going to let a final decision be based on a community vote. They can't. Something either is legally possible or it isn't, legally desirable or not. The larger community, so to speak, controls what laws get written, and they are interpreted by judges inside the court system. Lawyers will only support what they believe can stand up, under challenge, in a court of law. They must assume that litigation will happen somehow, someday, if only to try to avoid it.

Businesses need lawyers, then, to look at licenses carefully so as to plan effectively, and so they don't end up hitting the wall or losing their shirts. They are concerned about the bottom line, naturally, because they wish to stay in business and be successful. They simply have to pay attention to license terms very, very closely. Anything that adds to the burden of that process or even hints at increased risk or adds to the the cost of adopting FOSS slows adoption.

Where the Rubber Meets the Road

There are now 58 OSI-approved licenses, and many more licenses out there that are not on that list. Black Duck, a company that analyzes code for copyright infringement, says their database now includes 500+ licenses.

An analysis at present, then, requires lawyers to look at each and every clause of conceivably almost 600 or so licenses, to try to figure out every bad thing that could ever happen, with very little litigation history for guidance. If you wish to combine code under a new license with your code, can you? Are the licenses compatible? Can your business redistribute the combined code as it wants to? Can it modify and then distribute under its own copyright? Can it provide binaries-only or must source code be provided? Can the license author change the terms of the license at any time, and if that is possible, would all source code released under previous versions be affected by the change? What about upgrading the license, as needed by changes in the law or in business practices? What steps must be taken if an upgrade is desired? Does the license have a "governed by the state of XYZ" clause? If so, is your business in the state of XYZ, or is the business willing to have problems litigated in XYZ state? There are likely to be waivers, but do they match up? There may be a waiver to enforce patent rights in one license, but not in the other. Now what happens? What about the terms for warranties and indemnities?

Because it is now commonplace to cobble code chunks together, rather than writing it all in-house from scratch, one thing lawyers have to analyze is the issue of license compatibility. Do all the chunks go together or are the licenses incompatible?

What lawyers do when analyzing a license's compatibility with another license is look at it in both directions. That means asking if code under one license can be used with code under a second license, and then asking if code can go back in the opposite direction too. This is detailed work, as each clause in both licenses must be compared, clause by clause. If one has clauses the other lacks, the effect that might have must also be considered.

Some of the FOSS licenses out there are opaque, to put it politely, and some may not even be harmonious with the law as it stands. For example, putting your code in the public domain isn't as simple as just saying so in a license, as Red Hat's Senior Vice President and General Counsel Mark Webbink has explained in an article written for corporate attorneys, "Understanding Open Source Software," in which he explains FOSS, compares various licenses, details how the GPL really works, and lists corporate law office best practices for software:

Works, such as software, may be placed in the public domain and exist outside of the scope of copyright law. However, with changes in the copyright law in the 1970's and 1980's, including the automatic application of copyright under the Berne Convention, it is no longer an easy task to contribute software to the public domain. Software (or any other body of work) that is in the public domain cannot, by definition, assert any restrictions on who or how it can be used, modified or distributed (though other laws, such as export controls, may still restrict some software's use or distribution).

As you can already see, the analysis process is far more complex than you might think and with each license you add to the mix, it becomes worse. However, after you have analyzed code license compatibility, you are not done. There is an entirely separate category to next consider, as Shaun Connolly, VP Product Marketing at JBoss, explains:

The other GOTCHA out there has to do with IP rights around specifications. BPEL (Business Process Execution Language) is an example of a Web Services specification that has IP Rights licensing terms that complicate matters.

If you read through the above link, you'll see that the process is that you need to process paperwork with Microsoft, IBM, and SAP for the royalty free rights to use the IP inherent in the specification. Note that we are talking about a specification, not an implementation. The terms in the IP Rights paperwork then has terms/implications that affect the implementation and the license under which the source code for that implementation is licensed. The BPEL terms are incompatible with terms found in some FOSS licenses.

If you look at the specifications for WS-ReliableMessaging or the plethora of other Web Services related specifications, you will find similar processes like these; and not all are handled/processed the same way.

The end result can be even more licensing confusion . . . I basically had to submit paperwork to MSFT, SAP, and IBM to obtain royalty-free rights to implement the spec. Since the terms of the IP rights are incompatible with LGPL, we needed to package our BPEL-specific stuff separately and create an LGPL-like license for it minus the small handful of terms that were incompatible.

The various WS-XXX specs out there have terms that require careful consideration due to similar issues like BPEL above. This takes the licensing complexities to another level."

You sometimes hear businesses praise the BSD license. It's a license that doesn't require you to give back your modifications, so you might think it's perfect for business. In some cases it may seem to be, particularly if you are a large proprietary software company or in situations where you wish your code to become widely adopted. But note what Nathalie Fleury of JBOSS says about what works best for them:

Our preference at JBoss is for the LGPL because it discourages project forking and enforces a positive feedback loop on code contribution, while still accomodating OEMs, ISVs. Our "Professional Open Source" business model (the idea of open source as a stand-alone self-sustaining business--as opposed to a loss-leader) is pretty incompatible with BSD-style licenses because the big proprietary players would simply fork the code-base and it would be very hard to maintain any advantage over them product-wise. We find that product vendors love the BSD license for this very reason. It's a moot point of course for OS projects that live in the non-profit sector and depend on volunteers or subsidized development (by corporations, govts., academic institutions).

Then the business has to keep track of all the licenses they use. If you'd like to see the licenses JBoss has to keep track of, here's their collection of third-party licenses.

Examples

Let's look at one license on their list you may not have heard of, the Bouncy Castle license. It reads like this:

Copyright (c) 2000 - 2004 The Legion Of The Bouncy Castle

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Frankly, I have no idea. That's an issue that I'd want clarified prior to using any code in my business under that license. Even then, I might not want to use the code, if I was worried about how a court might understand -- or not -- the same phrase that has me scratching my head. Language that is not legally clear leads to arguments over what obligations actually are, and such arguments sometimes lead to lawsuits. Is Bouncy Castle licensed code compatible with the GPL? With all the other licenses? Just when you get it figured out, someone invents yet another license, and the process begins all over again. Is your head hurting yet? You have an idea of what lawyers are faced with now, and hopefully it will make you more empathetic.

I'm not picking on that license for any particular reason, except it was short and little known, and for illustrative purposes only. Obviously JBoss feels it can safely use code under the license, but I'm positive they didn't do so without first making sure they understood it and what their obligations were and whether the license was compatible with other licenses they use.

Lawyers are supposed to know such things, aren't they? Yes, but they can't invent the answer out of thin air. And it isn't always altogether clear how a license will play out in real life. For an example, here is what the Free Software Foundation wrote about the Open Software License, version 1.0:

The Open Software License, version 1.0, is a free software license. Its authors say it is intended to be copyleft, but we are having trouble determining whether the copyleft provisions really work. It is incompatible with the GNU GPL in several ways.

Now multiply that kind of analysis for each license you need to ask your lawyer to think about, so you can include some code in a project. If there are, say, 350 pieces of code that a business wants to use under 25 different licenses, a real world example Walli mentions, you can imagine how costly and time consuming it can be. If, on the other hand, you had 4 to 6 standard licenses, and everyone chose one of them consistently, once the foundation analysis was completed, it's done forever, except for the particular client's business aims and goals analysis.

You can see why that would be desirable from an efficiency standpoint, just as a programmer will reach for a FOSS tool, if it is available rather than reinvent the wheel. But the same paring down results in predictably fewer legal issues down the road, and that too is desirable. Anything that results in predictability and stability is desirable in business and in the law. If everyone knows what a license means, they won't normally litigate over it, because they know going in what the outcome has to be.

GPL - The Overwhelming Choice

The GPL is the majority license in the FOSS community, as you can see on Sourceforge's list of licenses chosen by projects. It is being used for 45,151 projects on Sourceforge; the next most popular license on that list is the LGPL, also created by the FSF, with 7,389 projects, followed by the BSD license, with 4,732 projects, as of July 18, 2005. You see a similar breakdown on Freshmeat, listing 67.55% GPL, 6.02% LGPL, only 3.39 as original BSD and 2.16 as modified BSD, as of the same date. David A. Wheeler has done a study of license usage, and he too reports that the GPL is the overwhelming choice.

The Free Software Foundation has a helpful list of licenses, with commentary on each, including whether they are compatible with the GPL. There are a couple of license charts showing the various licenses and which are GPL-compatible here and here that you may find useful.

They say on that page that if you want help choosing a license, evaluating a license, are thinking of writing a new license, or have any other questions about licenses, you can email them. "The proliferation of different free software licenses means increased work for users in understanding the licenses," FSF states. "We may be able to help you find an existing Free Software license that meets your needs."

License Proliferation Reduces the Common Pool of Code

There is another reason why proliferation of licenses is having a deleterious effect. A foundation principle of FOSS is reusability of code and developing a common pool of code. Having more and more licenses, some of which are incompatible with others, inevitably reduces the common pool of code, quite aside from violating the spirit and principles of FOSS development, as Richard Stallman has explained:

Being incompatible with the GPL does not make a program non-free; it does not raise a fundamental ethical issue. But it is likely to create a serious problem for the free software community, dividing the code base into two collections that cannot be mixed. As a practical matter, this problem is very important.

In summary, the legal requirements of the GPL are quite straightforward for commercial software providers: if you want to use a proprietary revenue capture model, keep your works (i.e., the code) separate from GPL'd works, keep the modifications made to each fully independent, and there will be no problems protecting your primary works. At the same time, any modifications you make to software that are already covered by the GPL will be subject to the GPL. . . .

It's one thing if Open Source is to be used as an operating system on a backoffice server, it is something altogether different if that same Open Source software is to be modified and embedded in a product. The former is not problematic; the latter may be. At the same time, make sure your IT folks are well aware of the typical proprietary restrictions which prohibit reverse engineering or modification. While some proprietary vendors may permit such activities under a special development license or a community source code license, they do not generally permit the activities under their general commercial licenses.

Please, where possible, use an existing widely-used license for your software that is known to be compatible with the GNU General Public License (GPL), such as the GPL, LGPL, original MIT/X, or BSD-new licenses. And, if you create your own license - and please try not to - make sure that your new license is compatible with the GPL. You don't need to use the GPL - not even the Free Software Foundation (FSF), the developer of the GPL and its most avid proponent, claims that absolutely all software must be GPL-licensed. (For example, see the endorsement by FSF's Richard Stallman of Ogg Vorbis license changes.) But make sure that your OSS/FS software's license is GPL-compatible, i.e., that you can combine your code with code released under the GPL into one larger program.

Why? Because if your project isn't GPL-compatible, there's a significant risk that you'll fail to receive enough support from other developers to sustain your project.

Many OSS/FS developers prefer the GPL, because they believe the GPL (1) provides a better quid-pro-quo for developers, (2 establishes collaboration between people and companies better than consortia, (3) protects their work in today's less-than-kind environment, and/or (4) encourages increasing the amount of Free Software. Even if you don't like the GPL yourself, many potential co-developers do... and your project is more likely to be successful if you accommodate them. . . . However, if your license isn't GPL-compatible, developers may create a competitor instead so they can take advantage of GPL'ed code.

And there are workarounds, such as the provision in the MPL 1.1 that allows a program, or parts of a program, to offer a choice of another license as well, and if it allows the GPL as an alternate choice, then that program or part of a program would then be GPL-compatible.

WIth a categorized process now in place, if you want your license to be used in business, then, please choose a license on the Preferred list, if possible. If you don't care about business, do as you please, but don't be surprised if your license, and your code, is then deprecated and used very little. You do still have a choice. But there will now be consequences. In a de facto sense, there always were. Now, with consolidation, it's more readily apparent, but the bottom line is this: streamline if you can by choosing a license that already exists, if possible. Forget about vanity licenses, and simplify the license process, if you wish the business world to be willing and able to adopt FOSS in even greater numbers than they already are.