GPL with the Classpath exception - clarification needed

[Wilson, Andrew]

Philippe Verdy [mailto:verdy_p at wanadoo.fr] wrote:

>> De : Wilson, Andrew [mailto:andrew.wilson at intel.com]
>> The reasoning in the FSF link provided by Roger
>> (http://www.gnu.org/licenses/lgpl-java.html)
>> is that instantiating a class is exactly like making a function call.
>> Well, maybe.  I'm sure there are other technical experts who
>> would say it's more like doing an #include and expanding the
>> macros -- perhaps even you.  Certainly, deriving a class has
>> macro-like qualities.
>
> Certainly not. At least not with compliant Java VM that requires a complete
> isolation of separately compiled classes (all of them being compilable
> without the source of the referenced class or interface) ....

I will trust your answer with respect to Java.  However, I will
point out that in the broader universe of O-O languages, there
is not only a conceptual similarity between deriving a class
and expanding a macro, in many instances macro expansion is in fact
how the O-O language features are implemented.

Exhibit number one would be Simula, the very first O-O language,
which was originally implemented as a pre-processor for Algol 60.
The Common Lisp Object System (CLOS) is implemented in
compile-time macros.  Abelson and Sussman in the "wizard" book show
how to use macros to program Scheme in O-O style.  There
are many other examples.

Back on topic for this list, if CLOS were LGPL, or if class
"Simulation" in the original Simula had been LGPL, I believe there
would be a case to be made that all programs using CLOS
or all Simula programs would be derivatives in the copyright sense and therefore
subject to LGPL.  It seems that one might need to know rather a
great deal about the internals of one's programming environment
to make an educated choice of license.

Andy Wilson
Intel open source technology center