Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top