| [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 |