[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmf-dev] FW: [eclipse.org-planning-council] More about license files
|
Thanks Richard,
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-591-7037
From: Richard Gronback <richard.gronback@xxxxxxxxxxx>
To: "GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
Date: 29/05/2007 07:06 PM
Subject [gmf-dev] FW: [eclipse.org-planning-council] More about license
: files
If nobody has any objections, I?ll change all our about.html files to read
?June 5, 2007? from ?June 5, 2006? in order to comply with what?s below
(keeping the date as arbitrary as last year).
Thanks,
Rich
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215
------ Forwarded Message
From: Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
Organization: Eclipse Foundation Inc.
Reply-To: "eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>
Date: Tue, 29 May 2007 15:07:14 -0700
To: "eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>
Subject: [eclipse.org-planning-council] More about license files
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.
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.
(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.
(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.
(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).
(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.)
(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.
(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.
(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.
(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.
(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.
- Bjorn
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
------ End of Forwarded Message
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
