User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
Dear All,
A friendly reminder that we can ask permission for Science
projects to use specific LGPL prerequisites today. It requires
board approval, but that is an avenue available to us today.
If the volume of requests is small, maybe we're just fine with
this process.
If the volume passes a certain threshold, it helps make the case
to consider broader pre-approval of LGPL in Science.
Also, I'll be sending out the vote requests today... just got held
up this morning. The 10 day countdown will start from my email
& announcing here that polls have opened.
Kind regards,
Andrea
On 30/06/16 10:47, Philip Wenig wrote:
Thanks Tobias to re-emphasize that LGPL, historically, is a
widespread used license in the scientific ecosystem.
It would make things much easier, if we can find a way for the
Eclipse Science projects to use LGPL libs.
Best,
Philip
Am 30.06.2016 um 16:39 schrieb Tobias
Verbeke:
Thanks for the clarification, Mike.
That helps indeed.
Regarding dual licensing (and focusing on the rationale
behind, not necessarily on the policy as is), it seems to me
that the concerns of the board you listed can be covered by
the EPL part of the dual license.
To provide some context: it seems desirable for the
science working group to welcome as much good scientific
software projects as possible. Some of these projects have
historically been distributed under LGPL licenses. If they
become Eclipse projects it is perfectly legitimate to
require distribution under the default license Eclipse feels
comfortable with (EPL) and which enable particular business
models for downstream usage of these projects or project
components.
If, however, the original license (in this example LGPL
which is popular in the science world) cannot be maintained
in a dual licensing model, it can kill the ecosystem around
the software project and may constitute a considerable
barrier for bringing projects to the science TLP.
The draft provided is not a
proposal. It's what the Board has approved. You can
either accept or reject it in its current form.
FWIW, no I don't think that the
Board would accept dual-licensing with the LGPL at this
time. Please see my previous comments about the current
stances regarding the LGPL.
I assumed that this was the board
trying to make sure that entities could use the
codes under the EPL too since may companies feel
like it a kind of preferred license. I could
also see them having little interest in a bunch
of non-EPL codes at Eclipse.
I'm fine with it. Personally I think
it isn't necessary, but IANAL.
That's a good question regarding the EPL +
other license. I'll have to defer to Mike
on that as I wasn't at the meeting and
don't know the reasoning.
Kind regards,
Andrea
On 29/06/16 16:48, Tobias Verbeke wrote:
Hi Andrea,
No objection, but besides the
already discussed veto against LGPL
licensed third party dependencies,
there have also been changes to the
TLP text that enforce dual licensing
(EPL and *) whereas in the previous
version science projects could also be
licensed under * only e.g. Apache 2.0
only or MIT only.
I am wondering (open question)
whether SWG people have any opinions
or comments on this?
Baring any objections articulated
on the list or to me in private by
tomorrow morning (EDT), I'll send
out an email to all Science WG
members to ask them to support
(+1) abstain (0) or vote against
(-1) accepting this Science Top
Level Project Charter.
Members will have 10 days maximum
to vote.
Once the results are in, I'll
report on them to the Steering
Committee & group as I
proposed.
Kind regards,
Andrea
On 29/06/16 11:19, Torkild U.
Resheim wrote:
Thanks Andrea,
Yes, I’d go for option B too.
Simple majority decides. And we
need to publish the amended TLP
proposal somewhere. I cannot
seem to find it.
Option A: The
Foundation does have
infrastructure for
this but it's a bit
heavyweight for this,
in my opinion.
Option B: I'd be happy
to run the vote on
behalf of the group.
What I'll likely do is
just email all the
member representatives
and ask them to please
reply with their vote,
and then I'll report
on the outcome. For
transparency's sake, I
can share the who
voted what with the
Steering Committee.
Option C: If we wanted
a completely public
vote, we'd simply ask
for +1/0/-1 here on
the list.
I recommend Option B,
for what that's worth.
Andrea
On 28/06/16 16:53,
Torkild U. Resheim
wrote:
Hi all,
If we’re going to
make all 15 members
vote I think we
should make the
voting process a bit
more formal and also
make some effort to
ensure that members
with voting rights
are aware of what is
going on. I think
several
representatives
could be on vacation
already. It starts
early, in northern
Europe at least.
Andrea, do the
Foundation offer any
infrastructure we
can use for this
purpose?
In general I
would agree
with you, but
having the
steering
committee get
the sole
deciding votes
on something
as important
our own TLP
seems unfair.
I mean,
honestly, I
think everyone
will vote
"Yes," but I
think everyone
would like the
chance to say
they voted on
"our TLP" just
like they
voted on "our
charter." Just
seems more
fair to me,
that's all.
Greg, I
think
institutional
votes for
participating
and steering
committee
members will
be fine. It
would be one
vote per
organization
in that case.
If there
are no
objections I
say that we
start the vote
by roll call?
--
~~~~~~~~~~~~~~~~~~~~~~~~
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@xxxxxxxxxxxxx » http://www.openchrom.net
~~~~~~~~~~~~~~~~~~~~~~~~