Re: [eclipse.org-planning-council] More about license files

[Ed Merks <merks@xxxxxxxxxx>]

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