Article Summary #3: Sun Microsystems – Free and Open Source Licensing

Sun Microsystems.  Free and Open Source Licensing.  (December 2006).  Retrieved January 29, 2009, from


Sun Microsystems is a for-profit company which has done significant work in support of the open source (OS) community.  Sun is involved in many OS projects, and one of their white papers aims to make sense of the growing array of OS licenses that developers can choose from.  The Open Source Initiative (OSI) was created to steward a common definition of open source, and one of its main activities is to evaluate new OS licenses.  As of 2006, OSI had approved almost 60 different licenses.  Sun supports efforts to simplify the OS licensing decision making process, and this paper supports simplification by helping elucidate the similarities and differences between the various licenses.  In this paper, Sun argues that an OS license should be chosen based on the kind of developer community that will be built around the project.

In categorizing the different OS licenses, Sun examines the impact each license has on the development community.  OS licenses have an important effect on others by controlling what can be done with the open software.  Sun considers three aspects of the development community, and examines what it calls the “virtuous cycle” that develops between them.  These three aspects are the Source Code Commons, the Developer Community, and the Software Works themselves.  The strictest licenses create continuous interaction between all three parts of this cycle.  Less strict licenses allow developers to leave the cycle at various points.

Three categories of OS licenses are identified.  Category A licenses are the least restrictive.  These licenses, such as the Berkeley Software Distribution (BSD) and Apache Version 2 licenses, allow developers to do just about anything they want with the software.  There is no limit placed on derivative works; they may be released under whatever license the developer wishes.  Sun calls these “market-creating” licenses because new markets can be created around software released under category A licenses.  These licenses give developers the most control, but do not require developers to give anything back to the commons.

Category B licenses also allow developers significant freedom, with a requirement to contribute back to the commons in some way.  Any new code bundled with code under a category B license, which is then combined into a single binary file, must carry the same license as the code from the commons.  Any other files packaged with the same project have no such licensing requirements.  The Mozilla Public License (MPL), GNU Lesser General Public License (LGPL) and Sun’s Community Development and Distribution License (CDDL) exemplify category B licenses.  These licenses balance the desire to give developers freedom to create new works based on OS code, with the need to continue giving back in part to the source code commons.  Sun calls these “community-fostering” copyleft licenses.

Category C licenses are the most strict, and provide the most protection for the end user.  When a developer uses source code carrying a type C license, all code in the project must then carry that same license.  This is exemplified by the GNU General Public License (GPL).  These are strong-copyleft licenses, which Sun calls “project-based”.

While offering a disclaimer that it is not providing legal advice, Sun offers some guidance on how to choose an OS license:
“The key to making decisions about open source licensing for software development is to understand what kind of community is desired and then to move in the direction of the licensing that is most likely to promote that type of community.”

Sun does not advocate for the use of any particular license, but rather “takes a license-neutral, context-based approach to free and open source licensing” (chap. 6).  The paper does state, however, that Sun is moving away from using category A licenses, and tending to favor category B and C licenses.  Sun’s work “favors strength within the community and a culture of contribution to a source code commons” (chap. 6).  One final quote shows Sun’s apparent enthusiasm for category B licenses:
“Category B licenses have the capacity to hold in balance the ability to attract a variety of interest to a community with the strength and longevity of a source code commons.  They allow developers to create software inventions based upon the commons and license them as they see fit, but at the same time they compel developers to improve the commons from which their works are derived: any changes to the commons itself must be returned” (chap. 4).

Educational Relevance

Educational software developers may be tempted to give only brief thought to the particular choice of an OS license, once the decision has been made to go with open source.  However, the choice of license has significant impact on such issues as who will use the code and software, for what purposes it may be used, longevity, and other considerations.  The desire to earn some money, whether a modest or extravagant amount, and the opposite desire to make software completely open, can blind developers to more subtle community-building issues that are described in this paper.

Consider a simple piece of educational software, such as a program that assists in memorization.  Users can input questions and answers, and then run through those questions in various orders and study modes.  The program tracks which questions are being learned effectively, and gives growing emphasis to the more difficult questions while steadily reinforcing the learned pieces.  Should the software be released under a category A, B, or C license?

Release under a category A license would allow a textbook company to use the software to support their particular textbooks, and perhaps profit from sales of the software itself.  Any improvement the company makes to the software would not necessarily make its way back to the original software.  Release under a category B license would allow this same use by textbook companies, but it would require those companies to make publicly available any improvements they make to the original software.  This would free other textbook manufacturers to bundle the same software with their textbooks, thus enhancing the effectiveness of all textbooks.  In this manner, the program itself evolves every time a company chooses to develop it further.  Complementing these benefits to the source commons is the right companies have to bundle the program in a proprietary project specific to their line of textbooks.

A category C license would require that any software developed by the textbook company, packaged with the memorization software, would have to be released under the same license.  This seems good in that it requires any related software to be open-source as well, but it may simply make textbook manufacturers avoid the software in the first place.  Limiting the amount of use the software sees may relegate it to a life of obscurity, regardless of the quality and usefulness of the software itself.  Choosing a strict OS license makes the program and all of its derivative works publicly available, but it does not necessarily make the program better or more attractive to potential users.

If the open source educational software community becomes more established, category C licenses might be an easier choice.  I do not like the thought of companies running commercially with open source educational software and returning nothing to the commons, so category A licenses seem to be an easy non-choice.  Given the present state of open source educational software, I would lean toward using category B licenses to leverage the interest of educational companies until a larger body of high-quality, high-visibility software is available.


  • OSI issued a document called the Report of License Proliferation Committee and draft FAQ in 2006.  This document enumerated the problems associated with license proliferation, and recommended steps to improve the situation.  Among those steps were to identify a set of “recommended” licenses, and a set of “redundant” licenses.  This helps developers look at a small set of widely-used licenses which are developing a common interpretive framework.  Most developers will find a license that suits their needs in this small set, and there should be fewer new licenses created.
  • At some point, a closer examination of category B licenses would be meaningful.
  • For now, this is enough of an examination of licensing issues.  The next articles will focus specifically on the ways that OS solutions have been applied to education.

One Response to “Article Summary #3: Sun Microsystems – Free and Open Source Licensing”

  1. Skip Says:

    It’s easy to overlook Sun’s seminal contributions to open source software. I’ve actually met Scott McNealy (many years ago at a Supercomputer conference in Portland). He has always been a culture hero of mine and one of the very early tech visionaries. Until recently I had always assumed that he coined Sun’s motto “The Network is the Computer,” only to find out recently that that statement is actually attributed to John Gage. Still, McNealy realized sooner than just about everyone else.

    I largely agree with your assessment about licenses, and it’s going to be particularly important to you as a potential developer. Still, it’s wonderful to see Apache and BSD show up in places like Apple’s OS and server OS.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: