Re: ORBit2 and linc - licensing?

[Sander Vesik <Sander Vesik Sun COM>]

On Fri, 25 May 2001, Matthew Copeland wrote:

> 
> 
> On Fri, 25 May 2001, Sander Vesik wrote:
> 
> > 
> > There seems to be an assumption being made here - that linc is licenced
> > under LGPL. In fact, linc contains no licencing information at all, and
> > whetever and how it was linkable to orbit naturaly depends on what licecne
> > it is available under and how it was built (with/without LGPL).
> > 
> > You also haven't considered the fact that OpenSSL is tortally OK any any
> > platforms where it is part of the platform, and yes such do exist. The
> > ability of the library linc to be built with openssl support does not
> > affect it's ability to be used by Orbit. 
> > 
> > Please refrain from trying to start a "FSF vs. the rest of the world" type
> > flamewar.
> 
> 
> Interesting that you assume I am trying to start a flame war by inviting
> people to ask the FSF.  Would not the FSF have the best understanding of

That part was not directed at you but in general - note that it has been
crossposted to several lists.

> compatability of the LPGL with other licenses?  It sounds very much to me
> like you have some personnal gripe with the FSF.  That is fine.  I have no
> problem with that at all, but don't read into what other people are saying
> assuming that they are trying to promote a "FSF vs. the rest of the world"
> mentality.    
> 
> 	Even if some people don't like the FSF, its practices, or the
> licenses it has created, the FSF can still be utilized as a resource for
> answering questions in regard to the compatability issues that arise when
> developers are making use of free software licenses and have questions
> regarding the use of those licenses.  That is why I said, if you really
> want to know the answer, check with the FSF licensing people.
> 

Well... if you really wanted to get an answer in this or any other matter,
you would go to your (company's) lawyers and ask them. Is FSF qualified to
give legal advice?

> On another note, I was not assuming anything about linc, I was assuming
> that ORBit was under the LGPL.  Thus, certain restrictions apply if you
> wish to keep it under the LGPL.  Realize, that to add a line in your
> license providing exemptions for linking with non-compatible licenses, you
> need the approval of every person who has ever contributed code to ORBit.
> Now that I have clarified which product I am referring to the use of the
> LGPL with perhaps you can actually provide commentary on the sections of
> the LGPL to which I was referring.
> 

I will tackle it from another side - I will show (by quoting LGPL) that as
LGPL allows you to do considerably less open things, of which the things
that were proposed to be done with linc, ORBit, etc. is only a subset:

---- quote 1 ----
7. You may place library facilities that are a work based on the Library
side-by-side in a single library together with other
library facilities not covered by this License, and distribute such a
combined library, provided that the separate distribution
of the work based on the Library and of the other library facilities is
otherwise permitted, and provided that you do these
two things: 

	a) Accompany the combined library with a copy of the same work based
	   on the Library, uncombined with any other library facilities.
	   This must be distributed under the terms of the Sections above. 
	b) Give prominent notice with the combined library of the fact
	   that part of it is a work based on the Library, and explaining
	   where to find the accompanying uncombined form of the same work. 
-------------

So it seems that if we created a library that contained both all of
openssl and all LGPL parts of Orbit and licenced it under some horrible
closed mutant licence all would be fine, as long as such a fact was
acknowledge and there was a pointer to the original sources. 

As for section 3 seemingly forcing you to stay GPL compatible with
depenencies, it is directly contradicted by 4, which says that you may
distributed source and binaries of the library (or derivative) under the
terms of sections 1 and 2 (note that 3 is not mentioned):

----------

4. You may copy and distribute the Library (or a portion or derivative of
it, under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you accompany it with the complete
corresponding machine-readable source code, which must be distributed
under the terms of Sections 1 and 2 above on a medium customarily used for
software interchange.

If distribution of object code is made by offering access to copy from a
designated place, then offering equivalent access to copy the source code
from the same place satisfies the requirement to distribute the source
code, even though third parties are not compelled to copy the source along
with the object code.

----------

Furthermore, please note that the provision in 3) to being able to use the
library clearly applies to the source code of the library and not
binaries, and thus using linc funtions would be ok as long as there is *a*
linc library (or one providing the same interfaces) that provides the
needed functionality with no added encumberance. Such thing does exist -
it is the same linc library compiled with no openssl support, so there is
no problem with binaries of the ORBit libaries that indirectly depend on
openssl in cases the linc library was linked against such. 

As already noted in another mail, openssl is a total non-issue on a
platform where openssl comes with the platform.

> 
> Matthew M. Copeland
> 

	Sander

One day a tortoise will learn to fly
	-- Terry Pratchett, 'Small Gods'