Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] 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
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
Projects must follow the IP Policy.

The usual how to do a Release Review (2.11)
item 1 first bullet "that the about files and use licenses are in place as per the Guidelines to Legal Documentation" legal documentation (4.0)
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 ( 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
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

Back to the top