Re: licencing
- From: Jamal Mazrui <empower@xxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Mon, 14 Jul 2008 16:01:56 -0400 (EDT)
I was curious about the question raised by Octavian. It was a legitimate
question that he had evidently tried to answer for himself, so did not
deserve an unhelpful rebuke on this list. It took several web searches
before I found the answer, so it is understandable that it was not easy to
find.
As was later explained in a more helpful response, the Java license
includes an exception to GPL2 called Classpath, which operates similarly
to the LGPL (an application can dynamically link to Java libraries in
binary form). Below are relevant excerpts I found.
Jamal
From the web page
http://www.sun.com/software/opensource/java/faq.jsp
The Classpath exception was developed by the Free Software Foundation's
GNU/Classpath Project (see
http://www.gnu.org/software/classpath/license.html
). It allows you to link an application available under any license to a
library that is part of software licensed under GPL v2, without that
application
being subject to the GPL's requirement to be itself offered to the public
under the GPL.
Q:
Why do you need the Classpath exception?
A:
If an application is distributed with an implementation of Java such as
the JDK under GPL v2, that application could be subject to the
requirements of the
GPL that all code that is shipped as part of a "work based on the [GPL]
program" also be GPL licensed. Accordingly, a GPL license exception is
needed that
specifically excludes from this licensing requirement any application that
links to the GPL implementation. The Classpath exception accomplishes
this.
Without the Classpath exception, a Java SE implementation licensed under
GPL v2 could not practically be distributed with non-GPL licensed Java
applications.
This could present a serious barrier to adoption, for example by
OpenSolaris or GNU/Linux distributions if left unaddressed.
Q:
Why did you choose this licensing method?
A:
This is the licensing paradigm in common use within Free software
communities such as GNU/Classpath and Kaffe for the components of a Java
technology implementation
including the virtual machine and class libraries. We consciously chose
the same licensing method so that there would be no temptation to second
guess
Sun's intention to make its Java SE implementation available under a
genuinely Free and open license and to allow easy collaboration with these
existing
communities.
Q:
Doesn't GPL v2 + Classpath exception offer very similar licensing terms to
the LGPL? Why not use LGPL instead?
A:
Yes, from a practical perspective the Classpath exception establishes
similar terms to LGPL. However, the Free software Java technology
communities haven't
chosen to use LGPL, and so we at Sun decided to follow their lead and use
the Classpath exception.
Q:
Does this mean Sun is abandoning CDDL?
A:
Not at all! Sun has developed a broad and pragmatic approach to Free and
open-source licensing, and uses several different licenses to meet the
varying
needs of the communities it has started.
Q:
Are you licensing the entire JDK under this method?
A:
Yes. Note that some of the code included in the OpenJDK project is not
part of the Java Runtime Environment, but rather is part of the tools and
documentation
that let developers use the JDK to create and test code, as well as some
demo and sample application code. See below for specifics on how each of
these
modules is licensed.
Q:
What about source code in the JDK that originated outside of Sun and is
incorporated into the JDK under its own license? Can you relicense this
code under
the GPL?
A:
Where such licenses are compatible with the GPL, then this code is
licensed under the GPL in the OpenJDK code base. There are some code
modules that Sun
may not have the right to release under the GPL. We're still investigating
some of the license compatibility issues and hope to resolve them as
quickly
as possible. In the mean time this code will be released only as binaries
if the source is proprietary or as source under its original open source
license.
Q:
How can you ship the JDK with binary-only elements then? You said there
were encumbrances.
A:
Well spotted! Because there are encumbered components that must be shipped
without source. The Software Freedom Law Center and the Free Software
Foundation
have helped us craft a special exception to the GPL, called the Assembly
exception, to allow the full JDK to be built. This exception will be
applied temporarily
until the encumbrances are removed to these binary plugs. We would welcome
your help to make this happen as soon as possible. In addition, the
Assembly
exception is needed to allow Sun to combine in a single collected work
components under both GPL, and GPL plus the Classpath exception. Without
the Assembly
exception, the entire OpenJDK code base would have to be licensed under
GPL without the Classpath exception.
Q:
Is there anything else besides encumbered binary plugs and files subject
to the Classpath exception that are covered by the Assembly exception?
A:
Yes, there are a number of open source code files under licenses that may
be incompatible with the GPL. In these cases we ship the source code under
its
original license, covered by the Assembly exception.
Q:
Can I take my non-GPL code and combine it with the OpenJDK code base to
create a combined work if I apply the Assembly exception to my code?
Doesn't this
get around the GPL's requirement to license the entire combined work under
GPL?
A:
No. The Assembly exception applies only to specifically designated files
that are described in a document called "Designated Exception Modules". As
holder
of the overall JDK copyright, only Sun is able to designate such exception
modules, so you aren't able to apply the Assembly exception to your own
arbitrary
source code modules. This preserves the requirement to license combined
works under the GPL.
Q:
So, what if I work on the OpenJDK code base and make a change to a module
covered by the Classpath exception or that is a designated exception
module with
a different license? If Sun is the only one that can designate exception
modules, won't my derivative work no longer be covered by the Assembly
exception
and thus unable to be distributed subject to the Classpath exception or
applicable open source license?
A:
The language of the Assembly exception covers derivative works. So as long
as you continue to license your changed code under its original license,
whether
that be GPL v2 + Classpath exception or under another license as a
designated exception module, you can apply the Assembly exception and
retain the original
license terms for the modified file. Please be aware that you can't modify
the encumbered binary plugs. You can only create derivatives of source
files
that are designated exception modules.
Q:
Will all future implementations based on the OpenJDK source code require
the Assembly exception?
A:
The Assembly exception serves two purposes. It allows us to ship code that
includes binary plugs for encumbered components. It also allows us to
create
a combined work that includes components licensed under the Classpath
exception and other open source licenses that are not compatible with GPL.
If you
want to create a binary from the OpenJDK code base and retain the
Classpath exception for components that Sun has licensed using this
exception, you will
also need to retain the Assembly exception. Sun is looking forward to
clearing all of the encumbrances as quickly as possible and to minimize
dependencies
on non-GPL open source licenses, to eliminate the need for the Assembly
exception for any purpose other than to allow for the Classpath exception.
Q:
This seems like a very complex licensing scheme, with exceptions applying
to exceptions. Why is it so complex?
A:
Sun is very respectful of the intellectual property of others and is
scrupulously careful not to violate licenses to the best of our knowledge.
We have
studied the detailed implications of the GPL v2 license and the Classpath
exception and based on this careful analysis, have devised this approach
toward
delivering a buildable JDK implementation that includes a small number of
encumbered modules as binary plugs. The Software Freedom Law Center and
the Free
Software Foundation agree with Sun's analysis of these licenses and helped
us develop this approach.
Q:
Why didn't you choose a license like BSD or Apache v2?
A:
Sun had several objectives in mind in choosing the license for the JDK
source code. We wanted to:
list of 4 items
Drive more adoption of Java SE, especially within GNU/Linux
distributions.
Minimize the likelihood of incompatible forks.
Engage a broad cross-section of the open-source communities.
Protect and enhance the investments of those who have licensed and chosen
to support the Java platform.
list end
After extensive analysis and consultation with experts both inside and
outside of Sun, we determined that of the choices available, the GPL v2 +
Classpath
exception license paradigm is most likely to achieve these objectives. We
know that this choice is unlikely to please everyone but we believe it
offers
the best balance of opportunity for developers and Sun.
Q:
Why is the license different for Java ME than for the JDK? Why no
Classpath exception for Java ME?
A:
Sun chose GPL v2 without the Classpath exception for the phoneME software
because the method of bundling and distributing applications together with
platform
implementation code (which is practiced in the Java SE space) does not
apply to Java ME.
Q:
What are the advantages of GPL v2?
A:
As well as fulfilling its original purpose of promoting Free software, the
GPL v2 is designed to help advance projects and code commons by requiring
innovation
sharing with the commons. By design, it minimizes proprietary forks by
requiring any modifications be shared with the project. GPL v2 is the
right license
to preserve Java's trademark "Write Once, Run Anywhere" value proposition.
Q:
What rights do developers have under GPL v2 + Classpath exception?
A:
The best source for answering this question is the
license itself
. In addition, there have been numerous analyses of the GPL license and
its terms, not least by the license stewards, the
Free Software Foundation
. Sun recommends studying these interpretations, and consulting legal
counsel as necessary to understand your rights under this license.
Q:
What are developers' obligations under this license?
A:
Once again - the best source for understanding Sun's chosen license for
the JDK source code is the license itself.
Q:
How can someone use the open-source code base to create a derivative work?
A:
Sun's Java platform implementations are now Free software. Developers can
use the open-source OpenJDK and phoneME code bases in any way that a GPL
v2 licensed
code base may be used. These implementations are not "special cases".
Q:
Can someone create and distribute an implementation that isn't compatible
with the Java specification using this code?
A:
Yes. We do not recommend or endorse that action, however. In addition,
they cannot label that implementation with the Java Compatible or Java
Powered (for
Java ME) brand and logo. These brands are your assurance that an
implementation has passed the relevant TCKs.
Q:
Can someone create software that doesn't even implement Java, but uses
pieces of the OpenJDK code commons? What are the limitations, if any?
A:
Yes. There are no limitations. But there is an obligation to meet the
requirements of the GPL (plus Classpath and Assembly exceptions if
appropriate).
Q:
Can I call the resulting software "Java"?
A:
No.
Q:
What must I do to call my software based on code from the OpenJDK or
phoneME projects "Java"?
A:
The requirements for the use of the "Java" trademark and name have not
changed with the open sourcing of the JDK and Java ME source code. The GPL
v2 does
not include a trademark license - no OSI-approved open-source licenses do.
Sun does not currently have a licensing program that permits the use of
the
"Java" mark in your product or company name, and as owner of the
trademark, Sun reserves the right to use the mark "Java" for its own
products. You can
use a truthful "tagline" however associating your product or company with
Java technology, according to Sun's standard terms for use for trademarks.
Please
see
http://www.sun.com/policies/trademarks/
for more details.
Q:
What must I do to use the "cup and steam" logo? Does Sun license it?
A:
Sun offers several logo programs featuring the distinctive Java "cup and
steam" logo design. To see whether you qualify for one of these programs
and to
learn how to participate, please visit
http://java.com/brand
for more details.
Q:
How do I know which components in the OpenJDK project are under just the
GPL, and which are under the GPL + Classpath exception?
A:
Each source file is individually licensed. The key difference is the
presence of the sentence:
block quote
Sun designates this particular file as subject to the "Classpath"
exception as provided by Sun in the LICENSE file that accompanied this
code.
block quote end
in the "+ Classpath" version. So basically if you see the word "Classpath"
in the license header then you know that the exception applies.
Q:
How do I know which components in the OpenJDK project are covered by the
Assembly exception?
A:
The Assembly exception covers all files under the Classpath Exception, as
well as all files described in the "Exception Modules" document which can
be found
at http://openjdk.java.net/legal/assembly-exception.
Q:
How are the tools that are a part of the JDK, but that are not part of the
JVM or class libraries licensed?
A:
Tools such as jconsole, javadoc, javac, and others are licensed under GPL
v2 + Classpath exception.
Q:
How are the regression tests you have released as part of the buildable
OpenJDK code base licensed?
A:
GPL v2 only. There are a small number of files that have no license in the
file itself. These files are all licensed under GPL v2 only, as the entire
combined
work constituting the OpenJDK code base is under GPL v2. These files are
mostly data files used in certain tests, for which no provision has been
made
for comments, and thus which cannot be modified to include the GPL v2
header.
Q:
What about non-Java language files such as manpages, readme files,
scripts, and other elements of the JDK? How are these licensed in the
OpenJDK Project?
A:
These components are licensed under GPL v2 only.
Q:
Are there any other licenses used in the OpenJDK code base besides the
ones you've already described?
A:
Yes. The demo and sample code modules are released under the BSD license.
These code elements are intended to be very widely distributed, freely
modified
and used. Accordingly, we've chosen the BSD license as most appropriate
for these uses. Because these components are not part of the JDK but
rather are
application programs, they need not be under the GPL license because of
the Classpath exception.
Q:
What about GPL v3? Have you considered using that license?
A:
At this time Sun is not planning to distribute the OpenJDK code under GPL
v3. That said, Sun has been deeply involved in the development and review
of the
GPL v3 license. This license has a number of interesting and positive
characteristics. Using GPL v2 does not indicate anything negative about
GPL v3.
From the web page
http://openjdk.java.net/legal/gplv2+ce.html
OpenJDK: GPLv2 + Classpath Exception
"CLASSPATH" EXCEPTION TO THE GPL
Certain source files distributed by Sun Microsystems, Inc. are subject to
the following clarification and special exception to the GPL, but only
where
Sun has expressly included in the particular source file's header the
words
"Sun designates this particular file as subject to the "Classpath"
exception
as provided by Sun in the LICENSE file that accompanied this code."
Linking this library statically or dynamically with other modules is
making
a combined work based on this library. Thus, the terms and conditions of
the GNU General Public License cover the whole combination.
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. An independent
module is a module which is not derived from or based on this library. If
you modify this library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not wish to do
so, delete this exception statement from your version.
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
