[CASHeW-s] Re: Licensing issues and eclipse...

[Andrew John Hughes]

On Thu, 2005-03-10 at 00:51 +0000, Ravish Bhagdev wrote:
> Hi Andrew,
>  
> I need some help from you.  

No problem; by the way, hope you're feeling better soon.

CCing to the list, as this may be of general interest.

> I need to understand the licensing issues.  I want to know what
> exactly the differences are between GNU Public Licence and other types
> of open source licences and what type of license does eclipse
> follow.  
>  
Well, firstly:

* IANAL (I Am Not A Lawyer) so anything I say here should not be
construed as legal advice :)
* I prefer the term 'Free software' rather than 'open source', as the
latter is more easily misconstrued and removes the emphasis on Freedom
('free as in speech, not as in beer').  It's Free software as in
'software libre' rather than software that is sold for no monetary
value.  Moreover, it is perfectly acceptable to distribute Free software
for a fee, and commercial Free software exists.

Some of these points are cleared up in:

http://www.gnu.org/philosophy/categories.html
http://www.gnu.org/philosophy/words-to-avoid.html

and http://www.gnu.org/philosophy/ is a generally good source for this
kind of thing.  As to licenses,

http://www.gnu.org/licenses/license-list.html

is much more comprehensive and accurate than I could ever be.  The GNU
GPL, in particular, is noted for its copyleft status.  All GPLed
software remains GPLed, including derivatives.  This ensures a community
around the software, because people contribute back to the project.
Other licenses, such as BSD, are pretty much a free-for-all with
copyright intact (one of the few differences between it and public
domain, which is material without copyright).  The TCP/IP stack on a lot
of systems, including Windows, is BSD code.

Eclipse is licensed under the Eclipse public license, a derivative of
the Common Public License, both of which are described in the above
list.  Notably, our trouble with it was that EPLed and GPLed software
can not be legally combined (which includes plug-ins), due to certain
restrictions present in the EPL.  This is the case with a lot of
licenses, including Apache's as well.  The GPL does not allow for
restrictions over and above those imposed in its text.  This does not
necessarily mean the additional restrictions are bad, but there is a
possibility they could be which the GPL must prevent.

Some projects you may be aware of and their licenses:

Eclipse         EPL             Free Software GPL-incompatible license
Axis            Apache 1.1      Free Software GPL-incompatible license
Firefox         NPL/MPL/GPL     All Free, Software, MPL/NPL incompat.
Linux           GPL             Free Software and obviously compatible.
Sun's JDK       Sun Binary L.   Non-free.
Sun's JDK Src.  SCSL/JRL        Non-free.

> I have really been ignorant of the licensing issues but I know you are
> fully aware of these things. 

Well, to a degree.  IANAL.

>  So, if you can please summarise what all the types of licensing mean,
> it would be of great help for me.  Also if you can please explain
> important things we need to keep in mind when using different types of
> compilers.  I have heard you talking about it but haven't followed it
> fully.  And I am not in hurry, please take your time for replying. :-)
>  
Not sure what you mean by different types of compilers.  As regards
Java, any source code compiled to the 1.5 standard will fail to run with
previous VMs, due to the use of java.lang.StringBuilder for
concatenation (+).  You need a 1.5 compiler (with the option for 1.5
sometimes, as is the case with ecj, the Eclipse compiler) to compile
things like parametrically typed classes (generics, in Sun terminology),
enumerations, for..each loops and annotations.  You can get away with
things to some degree with the VM but:

* + generates java.lang.StringBuilder, so this class is needed for
concatenation (n.b. its present in GNU Classpath, even though 1.5 is
largely still unimplemented there)
* Class literals now appear in the constant pool of the class file, so
constructions using .class will fail.
* Parametric types become casts when compiled, and each is cast to its
upper constraint.  However, they survive in the class file flags, which
can be accessed by reflection in 1.5
* Similarly, annotations become interfaces, with similar reflection
capabilities.
* java.lang.Enum is required for enumerations.
* for..each is just syntactic sugar, so nothing needed AFAIK.
* Variable arguments become object arrays.

It's nothing new to hack things for compatibility; 1.1 handled inner
classes using the $ separated name of the class.  

See http://java.sun.com/j2se/1.5.0/compatibility.html for a list of some
of the other issues.  Note that @remote can be used for RMI.
> Regards,
> Ravish Bhagdev.

Hope this helps,
Cheers,
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history. 
`Don't bother us with politics' respond those who don't want to learn." 
-- Richard Stallman

"We've all been part of the biggest beta test the world has ever known
--
Windows" 
-- Victor Wheatman, Gartner

signature.asc
Description: This is a digitally signed message part