Re: Classpath future?

[Etienne M. Gagnon]

Mark Wielaard wrote:

> I think this is the right list. Only for the licensing issues you might
> want to contact address@hidden or address@hidden directly.


I agree that, at some point we should ivolve RMS, but from experience, 
we should have decided on clear objectives before that, as we should not 
waste his time finding a solution to an unclear problem.  And believe 
me, you should be prepared to explain your problem very clearly.  But as 
a reward, he is very generous with his help.  As I said in another 
message, he went as far as write the text to a custom GPL exception for 
SableVM!

> I don't think there is any reason to fork classpath because I think
> you will find the Classpath hackers more then willing to listen to
> you. Yes, we might not have time to test every free VM out there,
> and yes, we might sometimes make technical decissions that are not
> ideal for all free VMs out there. But if we had enough time we would
> do it all perfectly :) Please help us make Classpath as usefull for
> your project as it is already for some other projects. We will listen!


Thanks.  I an already responsible for 2 projects, and I know the amount 
of work involved.  It was not with pleasure that I was proposing a fork. 
 In fact, very much prefer that Classpath remains a whole, gathering 
(instead of splitting) all possible efforts at building this huge class 
library, and serving the needs of as many Free VM implementations out there.


> A last note about the licensing issues that you raised.
> The GPL+exception clause is a strategic decision, there are already
> proprietary implementations that do a good job. To get the most
> help from outside we decided to use the current license which protects
> the users and the GNU project as much as possible and get as much
> help from outsiders as possible. 


My point is that the current exception is probably not achieving your goals.

> The LGPL is not practical if we need
> the help from embedded device makers because they will not accept it.


I agree that the dynamic linking and/or replacement of the library with 
a modified one is not practical in the embedded world, and it is not my 
goal to preclude using my work there (in fact, I would be very pleased 
that my VM be used in a tiny device:-).  But, I do want to protect the 
"freedom" of my code, so that any person who gets this tiny device, also 
gets the source code to my work.


> Please indicate what you think could happen to your code that would be
> bad for you or the end users if it was licensed under the GPL+exception
> clause that would not happen if it was licensed under the LGPL.


OK, here's a suggestion for what I think would be appropriate exception 
text (and then some comments on what could be changed or improved).  It 
is closely based on the exception RMS wrote for SableVM:

"As a special exception, we give you permission to link Classpath with
other independent modules (not derived from or based on Classpath), 
regardless of the license terms of these other modules, and
to copy and distribute the resulting combined work under terms of your
choice, provided that every copy is accompanied by a complete copy of
Classpath itself, being distributed under the terms of the GNU General
Public License plus this exception.

Note that people who make modified versions of Classpath are not
obligated to grant this special exception for their modified versions;
it is their choice whether to do so.  The GNU General Public License
gives permission to release a modified version without this exception;
this exception also makes it possible to release a modified version
which carries forward this exception."

Comments: Now, you might find this still a little restrictive.  Areas 
for improvement:  we could, as the GPL does, add an option of either 
distribute Classpath with the executable, or make offer to send the 
source code (something similar to section 3 of the GPL).


> Also note that if you assign your copyright to the FSF you can still
> distribute your own code under your own license. I think it is a
> good idea to assign code to the FSF for this project since that way
> the FSF can better defend it in court and they can easier make any
> license changes in the future when needed.
> (Please write to address@hidden or address@hidden directly to get
> more precise information on copyright assignment and what guarantees
> you get for how the FSF handles the code you assign and the rights
> that you keep/get back.)


The Copyright assignment is not currently my main problem, as I do own 
the copyright on all work I do at UQAM (as per the current union's 
collective agreement, which was one of my incentive to work here;-), but 
the point remains that it is not always practical.  For example, even if 
I donated the copyright to some of my work to the FSF, I would like in 
return some obligation of appropriate acknowledgment of my contribution. 
But this might not be enforceable under the GPL (as it is somehow an 
advertizing clause).  Keeping the copyright in my own name, on the other 
hand, forces a redistributor to acknowlegde my contribution because the 
license clause contains my name.

I do believe that UQAM has the financial resources to defend my 
intellectual property as well as the FSF would do (but I agree that the 
FSF might have more experience doing so;-).  I just think that you 
should consider accepting "major" contributions without copyright 
assignment. (It is OK, even though annoying, to require it for smaller 
contributions).  It would probably attract even more people to contribute.

> Thanks for your email. It is nice to know that some people find our
> work so important that they care about the direction the project
> is taking.


Yes I find your work important, and I know other people that do.  Many 
concerns I have discussed are shared by these people.

Please follow up on the "GPL exception" proposition above.

Etienne


--
+--------------------------------------------------------------------+
| É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          http://www.info.uqam.ca/ |
| Auteur de SableVM                          http://www.sablevm.org/ |
| et de SableCC                              http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| 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      http://www.info.uqam.ca/ |
| Author of SableVM                          http://www.sablevm.org/ |
| and SableCC                                http://www.sablecc.org/ |
+--------------------------------------------------------------------+