| Re: [science-iwg] Science Top-Level Project Charter |
Andrea,
I say we put it to a vote of the members.
I'm not personally inclined to move forward without some documented LGPL strategy. It is a very, very, very important license for science, and we need to know what we can and can't do with it. But, if others feel differently then I am happy to wait on the document.
Jay
Jay, & Everyone
I recommend we don't wait... let's move forward with the TLP now. We can update it later with the LGPL doc is ready, and that could be months.
Tobias, we'll work to request board permission for the LGPL prereqs you need. For this reason, I feel your proposal is likely still OK.
Kind regards,
Andrea
On 23/06/16 17:26, Jay Jay Billings wrote:
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 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
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________ science-iwg mailing list science-iwg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg