Choose a License

Choosing a license is a complex decision because of all the different issues you need to consider. Licenses can address both the rights and responsibilities of the original owner of source code, as well as those of contributing developers. Issues such as intellectual property rights, copyrights, allowances for creating derivative works, and internal use and redistribution requirements can be covered under the license, in addition to standard warranty, liability, and termination legalese. As an original owner of the source, it is helpful to have a clear idea of your own business model and long-term goals for your project, and understand the benefits and drawbacks of these licenses before you make your final decision. While the license is only part of a total product's equation, you'll need to understand how it fits into your strategy. If you are at all unsure of your choices and their implications, you should consult your lawyer.

Available Licenses

Here is the list of licenses for use with projects developing source code on java.net. Each includes a link to the full text of the license. When selecting a license for your project it is important to read and understand all of the terms included within the license.

Open Source licenses

• Apache Software License
• Berkeley Software Distribution (BSD) license
• Mozilla [TM] Public License (MPL)
• Sun Industry Standards Source License (SISSL)

Free Software Foundation licenses

• GNU General Public License (GPL)
• Lesser General Public License (LGPL)

Community Source licenses

• Sun Community Source License (SCSL):  for Java[TM] platform,  for Jini[TM] technology
• Java Research License (JRL)

Please note that if no license is specified, then the default license for source code found at the end of the web site Terms of Participation will be used. It is a BSD-style license.

For documents such as user manuals, tutorials, course materials, marketing materials, and whitepapers you may also choose a license.

Document licenses

• Creative Commons license
• Sun Public Documentation License (PDL)
• Open Publication License
• GNU Free Documentation License (FDL)

Please note that if no license is specified then the default license for documents specified by the website Terms of Participation allows anyone to freely "use, reproduce, modify, distribute, transmit, display, perform, adapt, resell and publish" any document provided on the java.net website.

Some licensing background

To help you get up to speed on the basics of licensing and to understand some of the relevant issues, below is an excerpt from a forthcoming book. In addition here are several pointers to relevant web pages that discuss various licenses:

• Open Source as a Business Strategy, Brian Behlendorf---see the section on "What License to Use?"
• The Open Source Definition, Bruce Perens---see the section on "Choosing a License"
• Open Source Initiative (OSI) website
• Various Licenses and Comments about Them, Free Software Foundation
• Evaluation of Public Software Licenses, Donald K. Rosenberg
• Sun Community Source License Principles, Richard P. Gabriel and William N. Joy

The following material is excerpted from the forthcoming book, Innovation Happens Elsewhere---How and Why a Company Should Participate in Open Source, by Ron Goldman and Richard P. Gabriel, Morgan Kaufmann Publishers, 2003.

Licensing
What the license does
What the license does not do
Choosing a license
Table: Summary of licenses

Licensing

A variety of licenses have been created to meet the different needs of open source projects---the original Berkeley Unix was released under the Berkeley Software Distribution (BSD) license, Linux and Emacs use the GNU General Public License (GPL), while Netscape created the Mozilla[TM] Public License (MPL) for its browser. Companies like IBM and Sun have written a variety of licenses including the Common Public License (CPL), Sun Industry Standards Source License (SISSL), and Sun Community Source License (SCSL). Over 40 different licenses have been certified as meeting the criteria for open source by the Open Source Initiative, a nonprofit corporation dedicated to managing and promoting the Open Source definition (http://web.archive.org/web/20081119062201/http://www.opensource.org/), and it is unknown how many additional licenses have been created for use by other open source projects.

This large number of possible licenses creates confusion for people considering participating in an open source project. When choosing a license for your project it is best to use one of the few, well-known existing licenses rather than trying to create a new one. Which license is best for your project will depend on your reasons for choosing to do open source development.

Many people equate open source with the various open source licenses, but the license is only a gate that people pass through. If people are not willing to agree to the terms of the license, then they don't pass through the gate. However for those people who do accept, the license doesn't specify how they will work together; it merely defines some very basic ground rules.

What the license does

The license grants outside developers certain rights that establish what they can and cannot do with the source code. The licenses we consider here grant the developer the right to use and modify the source code. Some licenses also include the right to use any Intellectual Property (IP), such as patents, that is required for the source code. Most licenses do not grant developers the right to take that IP and use it in a different application.

Each license also requires developers to assume certain responsibilities. For example, some licenses require that any bug fixes a developer makes to the source code must be contributed back to the original author. Another common requirement is that any IP used in the source code that a developer contributes must be made available to other developers who use that code.

A major difference between licenses is what, if anything, the developer must do in order to redistribute executable binaries built from modified versions of the source code. Many open source licenses require that the modified source code also be made available, at no or nominal cost, to anyone who wants to see it---this being the whole point of open source. Some of the licenses created by Sun---SCSL and SISSL---include compatibility requirements in the license.

Some licenses allow the source code to be incorporated into a larger work that is not subject to the terms of the license, though the original source code that is included still is; other licenses consider any additions to just be extensions of the original program and, as such, subject to all of the license terms. This is a key factor if you plan on combining open source code with proprietary code.

Finally all of the licenses deal with various legal matters: warranty (there is none), liability (it's limited), termination of the license (if you violate any of its terms), dealing with brands and trademarks (they are not included with the license) and several other boilerplate issues that are also to be found in typical licenses accompanying commercial software (e.g. clauses about governing law, dispute resolution, U.S. Government use, international use, and severability).

What the license does not do

It is just as important to realize what the license does not do. The license describes certain boundary conditions, but does not speak about how developers will actually work together. It is up to other documents or traditions to describe the process of contributing code, making a new release, and deciding what to do when disagreements arise.

The license may not automatically apply to changes contributed by outside developers. Many open source projects require anyone wishing to contribute code to first sign a contributor's agreement before their code will be accepted. This agreement often includes an assignment of the copyright on all contributed code to the project.

One other matter that most licenses do not touch on is how to ensure that modifications to the source code maintain compatibility with established standards. One way this can be done is to require that any distributed code pass a compatibility test in order to be granted the right to use a logo or brand. If there is an established brand then this can be enough of a carrot for developers to keep things compatible. Most often, compatibility is maintained because the community values it and will not accept code contributions that deviate from the standard---anyone who wants to create an incompatible version is thus forced to fork the code and start a new project.

* * *

Choosing a license

When choosing a license for your project it is best to use one of the few, well known existing licenses rather than trying to create a new one. Even a short, clearly written new license will be an additional hurdle that will decrease outside participation---and most new licenses tend to be neither short, nor clear.

The goals of your project will determine which license is most appropriate for you. Where possible we suggest using a Berkeley Software Distribution (BSD) style license since it is the simplest license and has the fewest restrictions, which makes it easy to share your code with other projects. Be sure to read the full text of any license you are considering and to consult a lawyer before making your decision.

Here are some questions that will help you to pick which open source license to use:

• Does your project currently use any open source code? If so, then you may need to use the same license that the open source code uses, or another license that is compatible with it.

• For projects using or modifying the source code for a technology such as Java or Jini made available using a gated-community license like the Sun Community Source License (SCSL) or the Java Research License (JRL), you will also need to release your code using SCSL or JRL.

• Will your project need to work with any other existing open source groups or code? If so, then you need to use a license that is compatible with theirs. For example, working with GNOME or Linux groups will be easier if your project uses the GNU General Public License (GPL), or Lesser General Public License (LGPL). Similarly if working with an Apache-related project it would be best to use the Apache Software License or possibly a Berkeley Software Distribution (BSD) style license.

• Who do you see as your potential contributors: companies or individuals? Many companies are still reluctant to use a GPL style of license; instead they commonly use the Mozilla Public License (MPL) or BSD so it is possible to build proprietary products. Many individuals and small projects favor use of the GPL.

• Are you mainly trying to establish a standard? If so, then you may not need to develop any source code, and so don't need any license. Instead you need to establish a standards group. If the standard already exists and you want to promote it, then using a license similar to the Sun Industry Standards Source License (SISSL) may be appropriate.

• Will your company or others want to include your source code in commercial products? Both the MPL and any BSD-style licenses support creating proprietary larger works, but LGPL can also be considered.

• Does your code define a platform or infrastructure where compatibility and interoperability are crucial? If so, then a gated-community license similar to the Sun Community Source License (SCSL) that requires derivative works to pass a compatibility test may be appropriate. Alternatively, the license could not try to control the technology at all, but rather you could require that any products pass a set of compatibility tests before they can use the trademarked name or logo.

• Are you worried someone will try to embrace and extend the technology? If so, then using the GPL or SISSL would force them to reveal any extensions they might make. Using something like the SCSL would not even allow them to release an incompatible product.

• Do you plan to sell software developed by your project? Many companies do sell software developed under an open source license. For example, Red Hat charges for their version of Linux. Other companies use an open source code base and create their own proprietary product on top and charge for that application. Whatever you choose as a business model, remember that with open source licenses, your base code will be publicly available for anyone to view.

• Is there any IP that you do not want to make publicly available? It is possible to make your source code freely available using open source, but require people to license your patents before they can distribute any software based on the source code. If you want to limit the technology to only be used by the project, then you need to use a license that is explicit about IP such as MPL, SISSL or SCSL.

• For sample code that you make available primarily to help people get started using some technology, you want to use the most minimal license that you can. In such a case a BSD-style license may be best.

• If you are willing to let anyone use the technology, and instead want to control or charge for the use of a trademarked name or logo, then you can use any license for the technology and have a separate logo license for anyone who is willing to pay to use the logo.

• Are there two disjoint communities that you need to work with? If so, then you may need to use a dual license, so each community uses the license best suited to it. However this will complicate your life, so if at all possible try to use a single license.

Note: you also need to decide on what a developer must agree to in order to contribute source code to your project.

If you are thinking of joining an existing open source project, then a license has already been selected by the project. You need to consider if you can achieve your business goals under that license. If you are planning to combine the open source code with proprietary code, then GPL would not work, but any of the other licenses, including LGPL, would be ok.

* * *

Summary of licenses

Notes:

1. Only if the IP is required by a modification that does not comply with the standard.
2. All bug fixes must be published.
3. If a modified or new interface specification (API) is shared with any third party, then the API must be published for all to see.
4. Only changes that do not comply with the standard must be published.
5. Only changes to files containing the original code or community contributions must be published.
6. May only be distributed to those who have signed the SCSL.