[Top][All Lists]

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

Re: Classpath future?

From: Etienne M. Gagnon
Subject: Re: Classpath future?
Date: Thu, 12 Jul 2001 12:30:55 -0400
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.6-586tsc i586; en-US; rv:0.9.1) Gecko/20010620

Aaron M. Renn wrote:

As a GNU project, it is then appropriate for us to provide
a heightened level of support for that target environment, so long as
it doesn't preclude other people from using us.

This is fine, as long as you make sure JNI support doesn't lag behind, and no classes are added with a CNI counterpart and no JNI counter part.

At some point classpath has to be built.  It isn't realistic to expect
that each VM will have a custom method of compiling classpath.  Instead,
Classpath will come with its own automake/autoconf compilation system
with appropriate flags to set the necessary options for each VM.  This
will then probably be automatically invoked from the VM vendors top
level configure file, if indeed a full environment is being distributed.

That's fine. But maybe hte process should be streamlined a little? Have you ever tried to compile Classpath from CVS without Japhar?

I personally think that the Classpath code should be broken in two (or three, for CNI) parts:

1) Java source code with jakarta-ant build procedure
2) Native libraries (.so/.la) part with autoconf/automake
[3) CNI libraries with autoconf/automake]

Or maybe 2&3 could be together and dependent on a compile flag.

There could be a dependency between compiled .class(es) and (3) for generating .h headers (for JNI code), but this is probably best done once when any "native" method is added (or its prototype modified) in the CVS repository, instead of being regenrated at every build (and causing all sorts of ugly dependencies).

In summary,
  -- Can be linked to proprietary code
  -- You must distribute the source code to the library (ie, classpath)
     if you modify it in any way
  -- You must supply linkable object code for your proprietary portions,
     so that if someone else wants to take advantage of their freedom to
     modify the library, they will be able to relink.

GPL + Exception (Classpath):
  -- Can be linked to proprietary code (this is the exception)

  -- You must distribute source code to the library (ie classpath)
     regardless of whether you modify it or not.

I do not see this obligation to distribute in the exception text:

"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."

Maybe my knowledge of English is lacking, but to me this says:
"the resulting executable to be covered by the GNU General Public License". So, if the resulting executable (that constains some of my work) is NOT covered by the GPL, then you can redistribute it without source code. Nothing forces you do to distribute the source code to that executable!

I have discussed these license matters at length with RMS (CC'ed to Paul Fisher), and it seems RMS agrees with my interpretation. For this reason, he wrrote for me the current exception to the GPL used in SableVM. Read it carefully, and you'll notice the subtle differences, where SableVM's license does, in fact, imply both objectives you (or others) had when opting for the GPL+exception.

I want as many people as possible using my VM, as you do for Classpath, even to run proprietary programs on embedded systems, but I do not want any company to be able to redistrubute an executable without distributing the source code of "my work". I don't care of they distribute the source code to their's or not (unless it is a modification to SableVM itself, not an external module).

| Étienne M. Gagnon                    mailto:address@hidden |
| Professeur adjoint            Téléphone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930                        Télécopieur: (514) 987-8477 |
| Département d'informatique, UQÀM |
| Auteur de SableVM                 |
| et de SableCC                     |
| Etienne M. Gagnon                    mailto:address@hidden |
| Assistant Professor                Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930                                Fax: (514) 987-8477 |
| Department of Computer Science, UQAM |
| Author of SableVM                 |
| and SableCC                       |

reply via email to

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