Update legal documentation requirements for Eclipse Platform Features and Plug-ins
Submitted by Wayne Beaton @wbeaton
Link to original bug (#525401)
Description
I've taken a first pass at documenting legal document requirements for Eclipse Plug-ins and Fragements [1], starting from the original documentation [2].
With the adoption of the EPL-2.0, we've decided to do away with the SUA. The actual license text can be used in its place for most content. In most cases, this is pretty straightforward and should require no more work than would be required to replace content with an updated SUA. It gets a little weird with Feature Update Licenses which require that the union of licenses in the corresponding plug-ins also be listed.
I've created this bug as a focal point for discussion regarding the content. The exist content is marked as a draft. I'll close this bug after we've decided to remove that mark.
[1] http://www.eclipse.org/projects/handbook#legaldoc-plugins [2] http://www.eclipse.org/legal/guidetolegaldoc-EPL-1.0.php
Blocking
Activity
@geniesaid:Gerrit change https://git.eclipse.org/r/112090 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/org.git/commit/?id=f34db4d717fc3c607f35e36ddbfcf1a414758243
@wbeatonsaid:(In reply to Wayne Beaton from comment 0)
With the adoption of the EPL-2.0, we've decided to do away with the SUA. The actual license text can be used in its place for most content. In most cases, this is pretty straightforward and should require no more work than would be required to replace content with an updated SUA. It gets a little weird with Feature Update Licenses which require that the union of licenses in the corresponding plug-ins also be listed.
Eliminating the SUA will be more challenging that I had originally thought. Requiring that project teams use actual license text will mean extra work for project teams to sort out the various licenses embedded in a feature, assemble the licenses, and then combine them into a single license "file" (actually a entry in the feature metadata).
Doing this work will result in confusing installation dialogs for our users as the current implementation just displays the license text; with a mix of licenses in arbitrary order and format, installing a collection of features would be jumble of entries that would not be helpful for our users.
I will likely revisit this in the future, but in the meantime, I'm updating the SUA for the EPL-2.0 in the following ways:
- Update the "updated" date;
- Change the reference to the EPL-1.0 to EPL2.0
- Add EPL-1.0 to the "other licenses" list.
The SUA text is actually copied in a few different locations; I've updated: /legal/epl/notice.html /legal/epl/notice.txt /legal/epl/notice.php /legal/epl/feature.properties.txt
The notice.php file displays the content from the HTML file. I've added a README that shows how to generate the notice.txt and feature.properties.txt from the notice.html (so that next time we update, we can ensure that the content matches across the different formats).
(In reply to Eclipse Genie from comment 2)
New Gerrit change created: https://git.eclipse.org/r/112090 Note that I pushed a commit that adds /org/documents/epl-2.0/notice.html (I'd originally thought that we might have different SUAs for different versions of the EPL). I'm going to revert that change to avoid having the content represented in multiple locations.
@scorbettsaid:Capturing the fact About File Templates[1] require updating to EPL-2.0 as well.
[1] https://www.eclipse.org/legal/epl/about.php
@wbeatonsaid:(In reply to Sharon Corbett from comment 5)
Capturing the fact About File Templates[1] require updating to EPL-2.0 as well.
Got it.
I think that we're done here. Let's open a new bug report if we find any stragglers.
