Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [science-iwg] Science Top-Level Project Charter

Mike/all,

Glad to hear, the "3-clause BSD" license is among those widely accepted for Science projects.
That'll make JSR 363 as a replacement for the "defunct" and risky to use JSR 275 (which also used BSD I believe 2-clause) work well with Science, LocationTech and other Eclipse projects.

Assuming the IP crew finds some time now that the annual release train is out, hopefully before JSR 363 goes Final (otherwise the SmartHome project might have to file another CQ or update the existing one;-)

Projects like Performance Co-Pilot Parfait (https://github.com/performancecopilot/parfait) have already updated to the stable Public Draft version 0.8 of JSR 363. Guess it won't remain the only one for long.

Werner 


On Fri, Jun 24, 2016 at 6:00 PM, <science-iwg-request@xxxxxxxxxxx> wrote:
Send science-iwg mailing list submissions to
        science-iwg@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/science-iwg
or, via email, send a message with subject or body 'help' to
        science-iwg-request@xxxxxxxxxxx

You can reach the person managing the list at
        science-iwg-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of science-iwg digest..."


Today's Topics:

   1. Re: Science Top-Level Project Charter (Jay Jay Billings)
   2. Fwd: Fw: Latest requirements are on github (Jay Jay Billings)


----------------------------------------------------------------------

Message: 1
Date: Thu, 23 Jun 2016 17:26:20 -0400
From: Jay Jay Billings <jayjaybillings@xxxxxxxxx>
To: Science Industry Working Group <science-iwg@xxxxxxxxxxx>,   Mike
        Milinkovich <mike.milinkovich@xxxxxxxxxxx>
Subject: Re: [science-iwg] Science Top-Level Project Charter
Message-ID:
        <CAE3ybv4UZyrthggRzXG1sMJTpFkZoiZ6xvJfq-kZ4qKbMq-wPQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

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:
>
>    1. The LGPL requires that the covering end user license agreement
>    allow reverse engineering of the covered work.
>    2. 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
> --
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxx
> +1.613.220.3223 (mobile)
> @mmilinkov
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/science-iwg/attachments/20160623/6d67fe09/attachment.html>

------------------------------

Message: 2
Date: Fri, 24 Jun 2016 10:12:09 -0400
From: Jay Jay Billings <jayjaybillings@xxxxxxxxx>
To: Science Industry Working Group <science-iwg@xxxxxxxxxxx>
Subject: [science-iwg] Fwd: Fw: Latest requirements are on github
Message-ID:
        <CAE3ybv5N1eo_6JKZWn4fXwL2Tmc8kb=2rOq6vx2o4YMH57Nu0A@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Everyone,

Several of us are involved in an effort to determine the requirements for
and implement a new Simulation Data Management (SDM) system. Our
requirements document is now on GitHub.

Please see:  https://github.com/DOE-Workflows/SDM-requirements

Special thanks to the rest of the DOE Workflows team for releasing this
publicly.

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/science-iwg/attachments/20160624/715a6e04/attachment.html>

------------------------------

_______________________________________________
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

End of science-iwg Digest, Vol 41, Issue 19
*******************************************


Back to the top