classpath
[Top][All Lists]
Advanced

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

Inspecting [L]GPLed non-FSF code -- was: java.util.logging


From: Sascha Brawer
Subject: Inspecting [L]GPLed non-FSF code -- was: java.util.logging
Date: Tue, 5 Mar 2002 21:50:36 +0100

Mark Wielaard <address@hidden> wrote on Tue, 5 Mar 2002 00:19:30 +0100:

>The reason we normally warn people not to look at the source code (and
>don't accept contributions of people that do) of a different
>implementation  such as Suns source code are that 1) proprietary
>software developers don't like people to look at their code without
>agreeing to terms that normally forbid you to contribute to GNU and 2)
>sometimes to be compatible with the API spec you will write some code
>that looks remarkably like some other (compatible) implementation and
>then it would be hard to prove that you didn't just copy the code you
>just looked at (remember that to be serializable compatible you
>sometimes even need to use the same variable names). 

>See also <http://www.gnu.org/software/classpath/doc/hacking.html#SEC2>

I fully understand the importance of this.  The reason for my confusion
is that the code in question is not licensed under some proprietary
license, but under the Lesser GPL.  My assumption was that [L]GPL was
unproblematic.  But it surely makes sense to avoid any legal risk,
whenever possible.

So, should doc/hacking.html be amended by a clarification that the term
"proprietary" means anything whose copyright has not been assigned to the
FSF, including GPLed and LGPLed code? However, in case GPL/LGPLed code
was fine to inspect, it might be worth mentioning, as well.

As of java.util.logging -- by now, I've read Brian Gilstrap's code quite
extensively.  However, I did *not* change anything in my code so far,
with one exception: a date format string in XMLFormatter.java, line 77.

In case inspecting [L]GPLed code was decided to be unacceptable, I think
I should abstain from any future contributions to java.util.logging
(besides Mauve testlets).  The Classpath task manager now has a sub-
project for the logging API; it lists the open tasks.

Thanks for the clarification, and best regards,

-- Sascha

PS: I'll be glad to leave debugging the package to someone else. It just
seems a bit unfair to the next person.





reply via email to

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