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