NAMIC Wiki:Community Licensing

This page discusses software licensing in general. For a discussion of precedents at NA-MIC sides and related institutions see the page on Institutional Experiences.

Slicer Licensing

The discussions on this page summarize research and decision making that resulted in a new slicer license in 2005.

Other groups have been influenced by this license wording (and discussions with the NA-MIC personnel involved). These include:

• the BIRN License
• the XNAT software license
• the I2B2 Workbench license

Open Source Software Licensing

"Open Source" is a widely accepted practice in the world of software developers. It is particularly popular among academics, researches and software engineers with quality assurance background. Unfortunately, the term "Open Source" is interpreted differently by different people. Here are some of the common popular conceptions that people bring to their minds when they hear "Open Source"

1. Free (gratis) Software
2. Software that "anybody" can modify
3. Socially responsible software
4. Software produced by spontaneous generation

Of course none of these connotations apply to Open Source software in itself.

The use that you can make of a piece of software is entirely determined by the license the accompanies the software. There are many variants of licenses and they state very different rights and impositions. Users and developers of Open Source software must get educated on the issues involved in the licensing of software since this determines in legal terms how this software can be used.

What is Open Source ?

The accepted definition of Open Source is given by the Open Source Initiative

http://www.opensource.org/

Full text here

http://www.opensource.org/docs/definition.php

The 10 points of compliance as defined by OSI are worth reading in full, along with their rationale for each point.

Note that the OSI definition is based on a the "social contract" adopted in the Debian GNU/Linux distribution:

http://www.debian.org/social_contract#guidelines

Attorney Lawrence Rosen, in his book Open Source Licensing (see reading list), applies his legal expertise to boil down these 10 points of compliance to 5 principles:

1. Licensees are free to use open source software for any purpose whatsoever.
2. Licensees are free to make copies of open source software and to distribute them without payment of royalties to a licensor.
3. Licensees are free to create derivative works of open source software and to distribute them without payment of royalties to a licensor.
4. Licensees are free to access and use the source code of open source software.
5. Licensees are free to combine open source and other software.

"Open Source Software" versus "Free Software"

http://www.gnu.org/philosophy/free-software-for-freedom.html

• Note: The two terms refer to the same thing (scroll down to diagram near top of page)
• "Free Software" is based on a philosophical/ethical stance that the world would be better off without any proprietary (closed-source) software.
• "Open Source" is based on a pragmatic (engineering and business) observation about an effective methodology for producing high-quality software.

Why do we care about the License

The term "Open Source" itself only gives a general allowances for seeing and modifying source code and redistributing software, while leaving flexible the terms of allowable modification and redistribution. It is the License which precisely defines these terms. Because modification and redistribution is the life blood of open source software, the issue of Licensing fundamentally structures the development and usage patterns of the software. Licensing issues take on increased importance in the context of NAMIC because of the diverse combination of collaborators and goals, both long-term (improve healthcare) and short-term (improve research).

We have to ensure that:

1. The goals of NAMIC (including eventual commercialization) are not hampered by the terms of a license
2. The licenses used for contributed works are all mutually compatible with each other
3. The licenses embody to each contributor's goals

What is Derivative Work and why do we care ?

Definition

http://en.wikipedia.org/wiki/Derivative_work

Derivative work From Wikipedia, the free encyclopedia.

In copyright law, a derivative work is an artistic creation that includes aspects of work previously created and protected.

In the United States, "derivative work" is defined in 17 USC 101, section 101:

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work".

The concept of derivative works is a logical extension of the framework of copyright protection in the United States. It prevents others from misappropriating the original work of a creator and redistributing it with "trival" changes without permission. If a derivative work is created with the permission of the original creator, the secondary creator maintains a copyright interest in only the aspects of the derivative work that are his or her original creations.

Lawrence Rosen provided some opinions on the meaning of derivative work in this Linux Journal article.

Why do we care ?

The importance of the concept of Derivative Work in the context of software development results from the fact that a software product is built using other pieces of software, and that each piece of software often requires adjustments in order to create a well-functioning whole. Since this can be the opportunity for taking advantage of something that has been provided in a context of good will, most software licenses stipulate what conditions they want to impose to Derivative Work in order to grant the benefits of the redistribution of their software.

To borrow terminology from Lawrence Rosen's book, a central distinction between licenses whether they are "Academic" or "Reciprocal". With a reciprocal license, a derived work is necessarily governed by the same license as the original work. In a sense, the license "propogates" to the derived work. Others use the term "viral" for this characteristic. Rosen makes a compelling argument for using "reciprocal" instead of Stallman's "copyleft", but they refer to the same thing. The term "reciprocal" emphasizes that in modifying or redistributing the software, a licensee strikes a reciprocal bargain with the licensor: the licensor grants the licensee the freedom to modify and redistribute, provided that licensee passes that freedom on to further (sub)licensees. In other words, "share and share alike".

On the two extremes of the Academic versus Reciprocal spectrum are the BSD and GPL licenses, respectively. BSD says (very roughly) "do you what you want, but don't claim you wrote it". The GPL, on the other hand, forces the licensee to redistribute derived works under the GPL, and also assumes a very broad definition of what constitutes a derived work: anything which uses or includes the original work in source or (compiled) binary form, including an application created by dynamic linking with a GPL'd library. In between BSD and GPL is a range of licenses that govern to a greater or lesser degree different kinds of derived work.

There have been long-standing and passionate debates about the merits and drawbacks of Reciprocal licenses. While the past and future experiences of NAMIC contributors and software are apt to provide real-world context and data, it is not NAMIC's responsibility to wholly resolve the debate. The current need is to develop a list of licenses that are compatible with NAMIC's charter.

Common Licenses

A Full list of "Open Source" approved licenses is available at

http://www.opensource.org/licenses/

The success of Open Source has resulted in a proliferation of Licenses:

http://www.opensource.org/docs/policy/licenseproliferation.php

Sourceforge is a popular repository for open-source development, and their breakdown of projects by OSI-approved license indicates that the percentages of license use are (as of June 28 2005) as follows. The links are to the full text of each license.

• GNU General Public License (GPL): 69%
• GNU Library or Lesser General Public License (LGPL): 11%
• BSD License: 7%
• MIT License: 2%

One long-standing issue with the LGPL is its insistence that distribution of compiled applications (that use the LGPL'd library) permit the licensee to swap out the LGPL'd library with a modified version of the library. This has serious implications for the distributor of such an application: either dynamic linking (to a shared library or DLL) is used, or statically linked application are accompanied by all the constituent object files, so that the licensee can re-link the app with a modified version of the library. This is clearly an annoyance for people who wish to create proprietary software which leverages open source packages (even though some view this as a good thing).

Because of this, there are at least two open source licenses which lessen the reach of the LPGP by providing a statement of Exceptions to the terms of the LGPL:

• wxWindows License: This greatly reduces the reach of the LGPL, by saying that as long as the derived work is in binary form, you can both modify and link to the library, and distribute the result under the terms of your choice.
• FLTK License: This only slightly reduces the reach of the LGPL, by saying that anything (source or binary) created by modifying the source stays under the terms of the FLTK License, while a binary which merely uses an FLTK-License'd library can be distribed under the terms of your choice.

In the context of C++, the idea of a "library" is complicated by templating, and header files defining (not just declaring) functions. Thus, for example, GNU's GNU Standard C++ Library is governed by the GPL, but with a "runtime exception", which allows usage without reciprocal terms, as described here.

The GPL/LGPL versus BSD Fight

The GNU Position on BSD

http://www.gnu.org/philosophy/bsd.html

The BSD Position on GPL/LGPL

http://www.softpanorama.org/Copyright/License_classification/index.shtml

Eric Raymond: "We Don't Need the GPL Anymore"

http://www.onlamp.com/pub/a/onlamp/2005/06/30/esr_interview.html

Microsoft's Opinion

http://www.microsoft.com/resources/sharedsource/Articles/LicensingOverview.mspx

Reading List

The following two articles were published at IBM online by the editor in Chief of Linux Magazine

• Open source licensing, Part 1: The intent
• Open source licensing, Part 2: Academic v. reciprocal

The following is a list of recommended book that address the issues involved in Licensing Open Source Software

Title	Author	Price	Link
Open Source Licensing: Software Freedom and Intellectual Property Law (also available for free online!)	Lawrence Rosen	$28.37	Amazon
Government Policy Toward Open Source Software	Aei-Brookings	$ 14.95	Amazon
Understanding Open Source and Free Software Licensing	Andrew M. St. Laurent	$ 16.47	Amazon
Copyrights and Copywrongs: The Rise of Intellectual Property and How It Threatens Creativity	Siva Vaidhyanathan	$ 19.00	Amazon
The Future of Ideas: The Fate of the Commons in a Connected World	Lawerence Lessig	$ 10.20	Amazon
Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity	Lawerence Lessig	$ 10.20	Amazon
Free as in Freedom: Richard Stallman's Crusade for Free Software	Richard M. Stallman	$ 15.61	Amazon
Free Software, Free Society: Selected Essays of Richard M. Stallman	Richard M. Stallman	$ 15.61	Amazon
The Business and Economics of Linux and Open Source	Martin Fink	$ 19.79	Amazon
Open Source Software Law	Rod Dixon	$ 88.71	Amazon
Shamans, Software, and Spleens: Law and the Construction of the Information Society	James Boyle	$ 39.29	Amazon
Open Sources: Voices from the Open Source Revolution	Chris Dibona (editor)	$ 16.47	Amazon
The Success of Open Source	Steven Weber	$ 29.95	Amazon

Summary of June 28 2005 discussion at Programming Week (Boston)

• Intellectual property law is complex because of three major kinds of law and their intersections: patent, trademark, and copyright. We're only talking about copyright.
• Thanks to the Berne Convention, a line drawing of a two-headed duck is copyrighted as soon as its put on paper. Copyright notices declare the copyright date and holder, but are not necessary to obtain copyright.
• Open source software licenses leverage the rights granted by copyright law (to the copyright holder) to choose the circumstances and restrictions on when and how software is modified and/or distributed. Software licenses don't empower the licensor to control works that the licensor doesn't hold the copyright on unless the licensee agrees to such control as a condition for the grant of the license.
• "Open source" is given specific meaning by the Open Source Initiative, see links above.
• Point 3 of OSI's definition says that the licensor must allow the license to apply (propagate) to derived works. Both BSD and GPL allow propagation. The GPL absolutely requires propagation.
• Point 6 of OSI's definition (No Discrimination Against Fields of Endeavor) is important for NAMIC because it means that you can't call yourself "Open Source" and at the same time qualify how the software may be used in commercial versus non-commercial contexts.
• There is a spectrum of licenses which can be categorized in terms of "Academic" and "Reciprocal" (terminology thanks to Lawrence Rosen's book), and there are various shades of Reciprocal licenses.
• The benefits of "Academic" licenses like BSD and MIT is that they are easy to understand, and very broadly grant freedom to use and modify the software in any context.
• Reciprocal licenses implement some notion of "share and share alike".
• Note that except for the GPL, the reciprocal licenses only apply to the code that was modified. So, the developer of a proprietary application can modify and use an LGPL'd library, provided that the modifications are also released under the LGPL.
• Reciprocal licenses are not the end of commercial development. Case study: Apple wanted to use KDE's HTML engine in their own Safari browser. They (heavily) modified it, called it WebCore and re-released it under LGPL, and then built their propriety Safari browser on top of that. Now, Nokia is also going to use WebCore. Note, however, that open source licenses can not prevent forking.
• Some companies have refined the Mozilla Public License (MPL), which is the reciprocal license governing Firefox, such as Sun's CDDL (governing Solaris 10) and IBM's CPL.
• From the discussion tonight and previously on the namic-eng list, FLTK-type licensing is allowed, because it avoids annoyances with static linking. ITK and VTK are under BSD-style licenses and will continue to be so.
• NAMIC should develop and publicize a list of licenses that are allowed for contributions to the NAMIC toolkit.