Jay,
Answers are in-lined below.
On 6/23/2016 4:33 PM, Jay Jay Billings wrote:
First, what was the board's
reason for rejecting it? Everyone on this list - a bunch
of scientists who hunt for reasons - would appreciate
some information on why they LGPL prereqs clause was
rejected. Legal reasons? Direction of the wind that day?
It has always been the position of the Eclipse Foundation
that distribution of LGPL components is not allowed. This is
true code developed at Eclipse, and for dependencies
developed elsewhere. If the license is LGPL, it is not
permitted. That has also always been true for GPL code. The
difference between our position on the LGPL and the GPL is
that the LGPL is not allowed as a matter of policy, whereas
the GPL is not allowed as a matter of law. (For those
interested in learning more about the incompatibility of the
GPL and the EPL please see [1] and [2].)
Use of the LGPL is not allowed because one of the major
goals of the Eclipse Foundation is to foster open source
projects which can be easily used in commercial software
products. In this regard, our policy is the same as
Apache's[3] which says:
The LGPL is ineligible primarily due to the
restrictions it places on larger works, violating the
third license criterion. Therefore, LGPL-licensed works
must not be included in Apache products.
IANAL, but there are two restrictions in the LGPL which have
been explained to me as problematic:
- The LGPL requires that the covering end user license
agreement allow reverse engineering of the covered work.
- The LGPL does not permit the re-licensing of binaries
under terms other than the LGPL. (The EPL does.)
Note that there are a few places where LGPL prerequisites
do have some level of permission. However the two examples
that I am aware of are Polarsys and LocationTech, and the
fact that those are run under separate brands on separate
forges was a deciding factor.
As for the next steps, Mike
and I talked previously about this possibility, and
instead of just proceeding without a well-defined LGPL
strategy we want to define one. That is, although the
board has rejected LGPL prereqs, we should present the
board with a coherent picture of the Eclipse
Foundation's current policy on LGPL, and how Science
will take advantage of that.
The Eclipse Foundation has a very simple and coherent policy
on LGPL: Eclipse projects are not permitted to use it for
their own code, or for any prerequisites that are
distributed with them.
In certain cases, Eclipse projects may use prerequisites
which are licensed under the LGPL. A prerequisite is
something which is already available on a users' machine, as
opposed to something which is distributed with the Eclipse
project. One very important example of this is that the
Eclipse IDE uses GTK on Linux. The policy that describes how
this is done can be found at [4].
Mike and I thought some
official SWG policy doc on this would be a good idea
because, at the moment, everything about Eclipse + LGPL
is very scattered. If this policy document is an
addendum to the Science TLP charter/project proposal,
then it will be very clear what the SWG can and cannot
support for new and old projects.
I can imagine writing a policy document that makes this all
clearer, but not as an addendum to the Science TLP Charter.
It would be on the Eclipse website as a standalone document
that the TLP charter could reference.
Hope this helps.
[1] http://www.fsf.org/blogs/licensing/using-the-gpl-for-eclipse-plug-ins
[2] https://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/
[3] http://www.apache.org/legal/resolved.html
[4] http://www.eclipse.org/org/documents/LGPL_API_Policy.pdf