[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] More about license files
|
Bjorn,
All this raises almost as many questions as it answers. My
<em>comments</em> to that effect are below. 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. 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...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
Bjorn
Freeman-Benson
<bjorn.freeman-be To
nson@xxxxxxxxxxx> "eclipse.org-planning-council"
Sent by: <eclipse.org-planning-council@eclip
eclipse.org-plann se.org>
ing-council-bounc cc
es@xxxxxxxxxxx
Subject
[eclipse.org-planning-council] More
05/29/2007 06:07 about license files
PM
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
Everyone,
The license and about files in each Eclipse release are for the benefit of
the downstream consumers: the files are there so that downstream consumers
can understand what licenses apply to the code that they have downloaded
from Eclipse. The timing of when the about.html file was checked in does
not matter to the downstream consumers - what matters is that they (the
downstreamers) can look at the build and know with comfort what licenses
apply to the code.
The dates in those files are effectively your (the project team's)
signature that the contents of that file is correct. The date is saying "I
have reviewed the material in this file and it is correct as of this date".
Thus if the date in the file is, e.g., January 12, 2005, and today is June
5, 2007, the downstreamer doesn't have much confidence that the contents of
that file is still correct. In fact, the downstreamer is pretty confident
that something has changed since January 12, 2005 (because works continues
non-stop at Eclipse) and so the downstreamer reasonably assumes that the
license risk is high because it has not been reviewed for over two years.
<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>
Having said that, let me answer a few of the concerns and questions that
have been posted to the eclipse.org-planning-council mailing list:
(1) We never had to do this before. Well, actually, you did have to do this
before, but we did not have the people time or technical infrastructure to
enforce it. Instead we used the section in the release review where "the
PMC Lead personally asserts that the IP Policy has been followed". Now that
we have more resources in the EMO, we are working to enforce the rules that
the Board (through the legal documents) has defined, and that includes
checking these things rather than just relying on the attestation of the
PMC.
<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>
(2) What date should we use? The EMO isn't concerned with the exact date in
the files as long as the date is a recent one. Because the date is,
effectively, your signature, your attestation of review, we are just
looking for a date such that no significant changes have been made since
that date: no non-EPL code contributions and no significant EPL code
modifications.
<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>
(2a) What date... how about the check-in date? For this reason, using the
date when the about file was checked in to CVS/SVN or the date when you
received the file from your corporate lawyer - neither of these dates is
sufficient for the purposes of reassuring the downstreamers and thus
neither of these dates is acceptable.
<em>Unless of course it is a recent date. So it's not sufficient to say
this date is not acceptable. Yes, I mince words as well as split hairs and
all without being paid lawyer's fees! :-)</em>
(2b) What date... how about the last changed date? You could use an earlier
date if you can attest (and demonstrate) that there has not been any
significant change between the date you've entered and the release date.
Thus if you had plug-in X whose development was complete by January 2007
and had no significant changes thereafter, then you could use "January xx,
2007" in the about files - no problem. Please do notify me of these special
cases so that I can enter them into the checker tool (my assumption is that
development has been continuous on all plug-ins of all projects).
<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>
(3) When nothing in the code has changed do we have to update the dates?
Given the above statements, if nothing, absolutely nothing, in a plug-in
has changed, then there is no need to update the dates in the about files,
etc. But if anything has changed (even something as small as the version
number or a spelling error), then the attestation of license applicability
needs to be made, i.e., the plug-in reviewed and the date changed. (Note
that this says that if you bump the version number on a plug-in to make it
consistent with the rest of a release then you must re-attest/re-date the
about files.)
<em>Doesn't 2b talk about only signficant changes? This wording is talking
about absolutely any change and contradicts 2b.</em>
(4) The date format. Legal stuff requires a date specific to the day. Dates
of the form "June 2007" (or even "2007") are not precise enough for the
about and license files.
<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>
(5) Future dates. Some people have pointed out that putting a future date
in the file is not correct either. If you feel uncomfortable about using
June 5, 2007, feel free to use today's date as your attestation that you
have reviewed the license and about files and that they are correct. Just
let me know that your plug-ins will be using May 29, 2007 (or whatever date
you choose) so that I can adjust the checker tool not to complain about
your plug-ins.
<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>
(6) Do we have to update all the files for every release? Subject to the
exceptions above (things that don't change), yes, you do. If code in the
plug-ins and features changes over a release cycle, then you, the project
team, need to re-reassure the downstreamers that no additional license
issues have been added to the code, etc.
<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.
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>
(6a) How about in maintenance releases? Yes, the dates need to be updated
for any significant changes that are rolled out in maintenance releases.
There is obviously some leeway here because of the term "significant
change", but clearly a 10k LOC contribution or a new Apache third-party
library would qualify as a significant contribution.
<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>
(6b) Is it ok to update dates even if nothing changes? Yes, it is ok to
update the dates even if nothing changes because by doing so you are
re-asserting that, as of this new date, the information in the files is
still correct.
<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>
- Bjorn
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
