classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarification to the license of Classpath (excluding the AWT code)


From: Etienne M. Gagnon
Subject: Re: Clarification to the license of Classpath (excluding the AWT code)
Date: Mon, 19 Nov 2001 23:53:04 -0500
User-agent: Mutt/1.3.23i

Richard Stallman wrote:
 > Adding this is a good idea.  However, it occurs to me that maybe we
 > should change the rest of the text to make it more like what SableVM
 > uses.  That text seems to be clearer.  Would you like to take a stab
 > at writing such a new version?

Yes, I will do.

First, some improvements have already been suggested on the Classpath
mailing-list: (1) to use the shorter form for "extending the exception
to derivative work", and (2) to make the exception generic (no
explicit mention of "Classpath").

The (first) improved exception looks like:

--- BEGIN ---
As a special exception, if you link this library with other files to
produce an executable, this library does not by itself cause the
resulting executable to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why the
executable file might be covered by the GNU General Public License.
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.
--- END ---


Personally, I find the following sentence relatively vague: "This
exception does not however invalidate any other reasons why the
executable file might be covered by the GNU General Public License."

I propose rewrite this text in a more precise language (similar to the
language used in my SableVM license proposal).

The main ideas are:
(1) The introduction of the term "independent module" defining modules
    which are NOT derived or based on the copyrighted library.
(2) Using this term to explicitly state the permissions of the exception
    to the GPL and the conditions for applying this exception. 
(3) The addition of an explicit statement about the consequence of
    statically or dynamically linking the copyrighted library in absence
    of the exception.

Here is my (second) Classpath license proposal.  I have tried to write
it in a generic language, so that it can be applied uniformly to all
the GCC support library suite (libgcj, libgcc, etc.).


--- BEGIN ---
Classpath, a set of essential libraries for supporting the Java
language.
Copyright (C) 1998-2001, Free Software Foundation, Inc.

This library is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this library in the file "COPYING".  If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.

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
independent module, the terms and conditions of the license of that
module.  An independent module is a module which is not derived 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.
--- END ---


You can note two main differences between this license and the SableVM
license proposal:
(1) In the Classpath license, the term "library" is used to describe
    the copyrighted work. In the SableVM license, the term "program"
    is used.
(2) The Classpath license allows redistribution of the combined work
    under any terms, as long as those terms do not conflict with the
    license of independent modules (which exclude the library itself).
    So, there is no requirement for the library itself when it is
    linked.  This is similar to the first proposal at the top of this
    message.  This is unlike the SableVM license which requires source
    code redistribution. (I am eagerly awaiting your comments about
    the SableVM license proposal, discussing the presence or absence
    of loopholes in it).

People, on the Classpath mailing-list, have already shown their
agreement to the first proposal.  I think they will agree to the
second proposal if you think it is clearer, while conveying the same
permissions and conditions.

Etienne

PS:  I think that most Classpath members would reject a SableVM-like
requirement of source code redistribution, as it seems to be
problematic for embedded systems people.  I personally do not
understand why it is so, but maybe you do.  Of course, others might
say that SableVM-like terms would be in some regards stricter than the
redistribution terms of a proprietary Java system (like Sun's); this
is a good argument for a less restrictive license.


-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]