|
Tobias,
The legal nuances and motivations of the LGPL policy are likely
beyond the purposes of this thread. Reasonable people can make
arguments both pro and con on this topic. If you and your
colleagues in the Science Working Group would like to have the
policy changed, I would suggest that by far the best approach is
to talk to your elected Solutions Member and Committer Member reps
and ask that they bring the topic to the Board. I assure you that
those elected reps are listened to and respected in the Board
discussions. If anyone needs email addresses for them, please let
me know off list, as I don't want to post their addresses on a
public list.
Thanks.
On 2016-06-24 05:17 PM, Tobias Verbeke wrote:
Dear Jay, Mike,
Thanks for sharing your thoughts and discussing in the
open. Comments inline.
Thanks Mike. This is indeed helpful.
We'll put the addendum wherever you want - just
let us know. I think what you have written here is a
really good start on it, in fact. How do we move forward
on putting this together?
As for the revised TLP, I'm happy to move
forward with it once we can amend it to reference this
separate LGPL document.
Jay
On Jun 23, 2016 4:58 PM, "Mike
Milinkovich" < mike.milinkovich@xxxxxxxxxxx>
wrote:
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 practice you can find many examples of commercial
software products that are based on LGPL e.g. the JBoss
Enterprise Application Platform which is based on Wildfly
or, in the ECM world, Alfresco whose Enterprise Edition is
based on an LGPL Alfresco Community Edition.
- I recently heard an interesting vision on the software
business according to which (1) software is eating the world
and (2) open source is increasingly predominant; as a
consequence it is for me an open question whether in a world
that says goodbye to the ancient models of proprietary
software product development, an open source foundation
should still put as much weight on protecting that model
(and dogmatically rejecting LGPL), or whether it can find a
balanced approach that also takes into account and fosters
open source projects that can be easily used in open source
software products e.g. by bringing more nuance to the LGPL
discussion. Especially in the business of scientific
software, rejecting LGPL is making it unnecessarily complex
to develop open source software products. By means of
example the recent board decision more or less bombs our
proposal
( https://projects.eclipse.org/proposals/statet-tooling-r-language),
even though we have been very careful to restrict LGPL use
to the amount necessary to properly interface with the R
language.
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.
IANAL either, but this is
definitely not black and white. IIUC this is only the case for
a derivative work, not for works that use the library.
- The LGPL does not permit the re-licensing of
binaries under terms other than the LGPL. (The EPL
does.)
For my education, is this
important for works that just use the library?
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.
This sounds promising! Many thanks in advance for your
efforts!
Best,
|
