Bruce Perens: How Many Open Source Licenses Do You Need?

Open source advocates have approved a jaw-dropping 73 licenses, yet companies and individuals need no more than four, and in many cases just two.
Posted February 16, 2009

Bruce Perens

(Page 1 of 3)

About the Author: Bruce Perens is the creator of the Open Source Definition, the manifesto of Open Source and the criterion for Open Source software licensing. Perens represented Open Source at the United Nations World Summit on the Information Society, at the request of the United Nations Development Program.

The Open Source initiative has, to date, approved 73 licenses. How many do you really need? If you're a company or individual producing Open Source software, no more than 4. And you can get along with just 2 of them.

But the fact that there are 73 licenses is a problem. Many of those licenses are incompatible with each other. To understand the legal implications of mixing software under two of those licenses together in the same program, you'd have to learn 5256 different combinations!

And the worst thing about this is, it's my fault! Well, partially. When I wrote the rules for Open Source licensing in 1997, as a policy document of the Debian project, not many people took what we then called “Free Software” seriously, and it was unthinkable that 73 different licenses that complied with my Open Source Definition would ever be written.

Fortunately, you don't have to deal with many of those 73 licenses. When you need to distribute or modify software that is under one of them, you'll need to understand that one. And folks who are just users get off easy: you don't really need to read an Open Source license just to use the software, because the rules I wrote require that the license give you the right to use Open Source software for any purpose.

Understanding licenses isn't really an Open Source issue. Most software is copyrighted and under some sort of license, and the licenses on proprietary software are much more pernicious than those on Open Source.

But most companies, even large ones, aren't yet completely able to cope with the implications of software licensing. At your next departmental meeting, ask how many people have clicked “Yes” on a license of a web site or software application while at work. Then, ask how many of those folks are authorized to enter into a contract on behalf of the company.

See the problem?

To understand how many Open Source licenses you really need, it's important to set some goals. First, the licenses must all be compatible with each other. There's no point in licensing your own company's Open Source so that it’s not compatible with other Open Source from your company. And second, the licenses should fulfill the various different business purposes for Open Source.

Open Source has business purposes? If you're a business. The two main ones are:

• To get everyone possible to use your software to do things the same way:

For example, if you're creating a standard that you'd like everyone to use regardless of whether their own software is Open Source or proprietary. Some years ago, a manufacturer of circuit design software created a standard file format for circuit designs, and distributed Open Source software that circuit chip foundries could use to read that format under the BSD license, which has no significant restrictions.

Because the company's competitors could also use the same format with their software, the foundries had an incentive to implement the format and simplify their operations. Thus, the circuit design software manufacturer was assured that their software's output would be usable with essentially all chip foundries.

• To create a partnership for software development, where everybody shares in the work:

About 14 years ago, I created the Busybox embedded systems toolkit for Linux. I put in a month's worth of evenings on the project, which was to build a command-line environment that would fit on a single floppy disk, for the Debian GNU/Linux distribution's installer. I released the product under the GPL license.

Subsequently, embedded systems companies adopted Busybox because doing so gave them some time-to-market advantage in putting their product offerings together: they wouldn't have to re-do my work. Because I'd used the GPL, their extensions to my software had to be under a GPL-compatible license too, and had to be made available in source-code form.

The various embedded Linux companies shared that work with each other and the entire Open Source community. At least 5 person-years of work have been added to that program, and all of that work is available for anyone to use. Had I used a license without the share-and-share-alike provisions of the GPL, those embedded companies would have kept their additions to themselves as proprietary software. And that wouldn't have done them much good, because Busybox wasn't business-differentiating for those companies.

Next Page: Three Types of Open Source Licenses to Choose From

Page 1 of 3

1 2 3
Next Page

Tags: open source, Linux, software, GPL, policy

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.