Let’s start with the assumption that
Bjorn is trying to do what is right for the community.
We need correct legal documentation; he is
trying to make sure that happens.
The documents should reflect the reality
as of the date they are written.
Ideally, we should be able to use
something to automate checking that they have actually been updated, because
our release trains are only going to grow and we have limited resources and we
all want to ensure that our downstream consumers have the correct information
in their hands. Bjorn has put something together and together we can help
shape the parameters of that.
There’s a call in a half an hour, I
plan to attend. Let’s stop the rapid emails back and forth
and have a constructive conversation on next steps. Email has value to a
point, but I think we have hit that point. Time to focus on constructive
solutions to the benefit of the community as whole.
Janet Campbell
Phone: +1.613.224.9461, x.229 (GMT
-5)
Fax: +1.613.224.5172
janet.campbell@xxxxxxxxxxx
From: Ed Merks
[mailto:merks@xxxxxxxxxx]
Sent: Wednesday, May 30, 2007 7:35
AM
To: eclipse.org-planning-council
Cc: eclipse.org-planning-council;
eclipse.org-planning-council-bounces@xxxxxxxxxxx; 'Janet Campbell'
Subject: Re:
[eclipse.org-planning-council] More about license files
Bjorn,
Let
me start by saying that I tracked down all the about.htmls I could find and
changed them to May 29, 2007. It's not as if I want to grind the wheels
of motion to a halt. However, I continue to disagree strongly with the
execution of the policy and I'm particularly taken aback by advice to put
future dates in a legal document because it seems fundamentally misguided and
counter to the goal we are trying to achieve. I personally would have
zero confidence in a legal document that is post dated. In fact, I find
it hard to believe that such a document has any credibility at all and it's the
credibility of the content of this document that's the only reason for changing
the date in the first place. I would expect such a document would be
invalid at least until the actual date is reached and that implies we are
publishing legally questionable results for Europa up until we release. The
statement that putting 2010 in the date is okay, which was my attempt to show
that rules that reduce to an absurdity are themselves absurd, seems too far
fetched to be true. But hey, I'm not a lawyer. Maybe this makes
perfect sense to someone...
I
also read the referenced document http://www.eclipse.org/legal/guidetolegaldoc.php
but I could find no basis for the current rule that the about.html must change
its date at certain well-defined points in time or as a result of anything
other than changes to the license due to the addition of code with a different
license. I think you acknowledged there's nothing explicit in the
document that requires updating the date on each release, but if I've
misunderstood, please point out the relevant passages. So I stick to my
assertion that the current execution of the policy does not derive directly
from an existing document, i.e., there's no way to deduce the rules being
enforced for Europa from the website documentation as it is written today. This
implies that the board itself must have passed a resolution explicitly requiring
the current process, so if that's the case, we should be able to point to the
minutes of the board where the board voted to approve that. Does that
documentation exist? Without this, there doesn't appear to be a credible
basis for stating that board policy and direction is being enforced but rather
one could argue convincingly that since the about.html files aren't broken we
don't need to fix them.
I
must say that you mince words rather well yourself. :-) I'm also
appreciative of the amount of work you do to help things run smoothly, so I
hope that no one takes my criticism of this particular issue as a personal
criticism of you. I think having a more automated way of tracking IP
contributions, collecting that information, and making it available in the
distributed results is a worthwhile goal. In EMF we mark every commit
with [<bugzilla#>] and if that bugzilla involves a contribution, we
include a [contrib email="<email-of-contributor>'] append in the
bugzilla. By following a rigorous process, we try to ensure that the
chance of overlooking important IP changes is minimized and that an automated
tool can always be applied to recreate the most relevant aspects of our IP log.
On
general suggestion I would make is that future changes to the process be
discussed first and that blocker bugzillas be opened only after that
discussion. It would also be good to begin such discussions well in
advance of the issue becoming critical. I know we generally do this, so
that's why a seemingly new issue coming to my attention in the form of a
blocker bugzilla was so surprising and frustrating...
Ed
Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
|
Bjorn Freeman-Benson
<bjorn.freeman-benson@xxxxxxxxxxx>
Sent
by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
05/29/2007 09:26 PM
|
Please
respond to
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
|
|
|
To
|
"eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>
|
|
cc
|
"'Janet Campbell'"
<janet.campbell@xxxxxxxxxxx>
|
|
Subject
|
Re: [eclipse.org-planning-council] More about
license files
|
|
Ed, (and everyone who is following along this exciting story of chaos and
intrigue)
You'll note that my conclusion
is that a build can change the date in the file
for each build and although
that provides no value to anyone, it does satisfy
the process.
Yes, I suppose that is true. Of course there are many such situations in life.
We (the EMO) would be happy to listen to suggestions for better processes that
provide value to more people as long as they satisfy the IP Policy that the
Board has given us.
Also note
that without a link to an existing document on
Eclipse website, I get the
feeling process is being defined on the fly.
The Europa must-do's were
clearly document at the beginning of the cycle and
this was not in that
list...
That would be a good point, were it true :-) However, the documents have
existed on the Eclipse website for longer than Europa has been a gleam in our
collective eyes...
Europa Must Do #15
http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release#Must_Do
Projects must follow the IP Policy.
The usual how to do a Release Review (2.11)
http://www.eclipse.org/projects/dev_process/release-review.php
item 1 first bullet "that the about files and use licenses are in place as
per the Guidelines to Legal Documentation"
Eclipse.org legal documentation (4.0)
http://www.eclipse.org/legal/guidetolegaldoc.php
4.1 Software User Agreement
4.2 Abouts
4.3 Features Licenses
<em>The downstream user is relying on many
things, one of which is that if
we were to add material based on another license
that we would document
this in our IP log and update the about.html.
It's very easy to change a
date without the associated work that would
provide a real sense of
security rather than an artificial one.</em>
It is true that one could change the date without actually double checking the
contents of the file. Perhaps for Ganymede we could convince the Board to
change the IP Policy so that we can have a single XML format IP log file for
each project along with a standard set of about files that point to the IP log
file for all licenses. But we don't have that right now.
<em>Could you please provide a link to a
specific document that describes
this requirement and the process?. If it's a
large document, please
describe how to find the reference to the relevant
parts of it.</em>
See above.
<em>This is good in principle, but you are
of course aware that we will
just blindly stick in a new date and move on to
bigger and better things.
So appears to be no real value in this, other than
window dressing.</em>
(*) The only recourse we (the EMO) have to stop you from doing that is that if
learn that a project is attempting to subvert the IP process, we can shut that
project down until the IP issues are clarified. As you know, Ed, we've done
exactly that for some smaller projects already.
<em>Oh dear. What's a
"significant" change? This does imply incrementing
the date for each and every change, which is even
more onerous than
incrementing plugin versions which happens only
for the first change.</em>
(#) The IP process poster (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)
defines "significant" as greater than 250 LOC EPL or anything
non-EPL. Janet and I agree that LOC is a bad measure and are leaving the
definition of "significant" to the discretion of the project teams.
You know when something is significant and you know when it is not. I don't
think there is any way to provide an airtight algorithmic definition of
significant.
<em>Doesn't 2b talk about only signficant
changes? This wording is talking
about absolutely any change and contradicts
2b.</em>
"Almost" and "hmmm". Let's consider a few dates:
A - the last significant change to the plug-in
B - the last release date
C - the last insignificant change to the plug-in
T - today
P - the previous assertion date in the about file (clearly P <
B)
Q - the assertion date in the about file
R - the next release date
(i) If A > B then must have A < Q < R.
(ii) If A < B and C < B then may have Q = P.
(iii) If A < B and C > B then what I've said is that A < Q < R.
But perhaps Janet will say that (iii) is the same as (ii).
<em>Is this documented in a document you can
reference or is this something
we are defining as we define the process?
I.e., why is this requirement
more strict than the copyrights in the source
files?</em>
Because that's what Janet told me about legalese.
<em>It can't even be slightly correct to put
a future date in as an
assertion that nothing can change between now and
then. Otherwise we can
put a 2010 in there. Is there a rule that
says we can't put 2010 in there
and be done for a few years? :-)
When defining rules, keep in mind that
we are programmers and rules with bugs, like code
with bugs, can lead to
crashes.</em>
Sure it can be. If you put in June 5, 2007 (today being May 29, 2007) because
you know that no significant changes are going to be made between then and now
- your project's process says "only essential bug fixes are allowed at
this point". Similarly, if you put in 2010, then you are saying that you
are going to make non-significant changes (no API changes, no additional
features, etc) between now and 2010.
<em>I think this is an onerous burden.
Not only do we need to increment
the version for the first change, but we need to
increment the about.html
date for every change, or at least for the last
change before a roll-up.
As part of releasing software under the Eclipse IP Policy, as defined by the
Board, as we've been told to implement, yes, you have to review and update your
about.html files. I'm sure that we (collectively) find a better way to do this
in the future. But that's a discussion for another day (perhaps a day next
week?). I doubt that any of the Europa projects want to try to change the
process at this late a date.
We've certainly never made a commitment to carry
this burden, so I really
do want to see a document that clearly spells out
that we did indeed
somehow commit to this without actual prior
knowledge due to our inability
to find the document that describes this
process.</em>
Well, you did because you agreed to follow the Committer Guidelines and the IP
Policy when you became a committer, but I will concede that the exact details
of what that implied were not explicitly spelled out. In fact, I don't think
any of us (Janet and Mike and the Board included) quite understood the entire
consequences of the IP Policy.
<em>Were's using the term significant again,
but only in this case. I
think this is poorly defined. Why is it only
significant changes for a
maintenance release but absolutely any change for
a point release?</em>
See point (#) above.
As for the second part: "I don't know".
<em>So we could automate this with the build
process and therefore provide
assurrance without really doing any of the
underlying work that would give
that assurance? At lease we won't need
monkey to do that work. :-)</em>
Again, see point (*) above.
Ed, I'm just not sure what you want me to do here? The Board tells the EMO
"enforce these rules". I/we (the EMO) are enforcing these rules. I
realize it's sort of a cop-out to say "I'm just following orders",
but what's my other option? I/we suppose could ignore the incorrect license and
about files. Unfortunately, that exposes the Foundation and the members who
adopt the frameworks to a greater legal risk. Not a huge risk, but a risk that
the founding members and the Board have chosen not to take.
I think our collective experience (yours, the PMCs, the project leads, the
committers, Janet and her team, even me) with the Eclipse IP process this year
demonstrates that there are definite areas for improvement. My problem is that
I, personally, can only change certain things. I cannot change the Software
User Agreement or its requirement that there be about files and license files.
I could help by writing a tool that generates those from a standard XML format
IP log, if that kind of tool would help you. I can help (and am doing so) by
applying the portal/workflow software to the CQ/IP process. I can help (and am
doing so) by identifying pain points in the current process and bringing those
forward to the Board for revision and improvement. But Janet and I are not able
to say "don't bother to fix the about files"; we just can't do that.
So, in conclusion, Ed, I understand that you don't agree with these policies (ref 189548#c7).
I'm not wild about the way the whole thing is turning out either. Given that
and the restrictions I'm under, what can I do to help you (and everyone else)
with Europa?
- Bjorn
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
