| Re: [eclipse.org-planning-council] More about license files |
Ed, (and everyone who is following along this exciting story of chaos
and intrigue)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.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. 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...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... 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 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>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> See above.<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> (*) 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>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 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>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> "Almost" and "hmmm". Let's consider a few dates:<em>Doesn't 2b talk about only signficant changes? This wording is talking about absolutely any change and contradicts 2b.</em> 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). Because that's what Janet told me about legalese.<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> 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>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> 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.<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. 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.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> See point (#) above.<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> As for the second part: "I don't know". Again, see point (*) above.<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> 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 |