I've put drafts of the click-thru licenses for features here: http://svn.apache.org/viewvc/uima/build/trunk/uima-build-resources/src/main/resources/licenses-eclipse-plugs-features/
These, like the Eclipse "feature-update-licenses" are completely generic... and refer to things in the plugins. Let me know what you think. -Marshall On 2/4/2013 4:58 PM, Marshall Schor wrote: > On 2/4/2013 3:59 PM, Peter Klügl wrote: >> Am 04.02.2013 18:17, schrieb Marshall Schor: >>> On 2/4/2013 5:21 AM, Peter Klügl wrote: >>>> <snip> >>> I noticed that the additional license.txt doesn't match the LICENSE in the >>> META-INF spot. It would be better to only have one. Are you sure the >>> version >>> of this at the top level is needed by Eclipse? (Other features we have, >>> e.g. >>> uimaj-eclipse-feature-tools_2.4.0.jar, don't have a license.txt file at the >>> top >>> level.) >> The License.txt file is an externalized version of the license in Eclipse >> covering all bundled plugins. I think there is a spot in Eclipse where the >> user can take a look at the license after the feature is installed. > Yes, thanks. The fine point is: which license etc. covers "just" the feature > artifact (isolated, without any plugins) and the whole set of things > represented > by the Feature - which includes all of its plugins. I missed that. > > I took a look at how Eclipse uses these, itself, and I think it works like > this: > > The feature.xml file has a spec for a "user agreement" (which is confusingly > also called a license), to be applied to the whole installed feature. This > spec > has 2 parts - the license "url", and the license itself. In Eclipse (and in > textmarker), these are %style variables, that refer to same named properties > in > the feature.properties files. > > In Eclipse, the features use the url pointer to point to a top level xxx.html > file, which is an html-formatted version of the "user agreement" for > installing > and using the feature. This is what you called the click-thru license. There > is also a plain text version of this "user agreement", embedded in the > feature.properties file itself. > > The "user agreement" is fairly generic, and contains pointers to full > licenses. > The pointers are both to web sites, and to things packaged with the whole > installed feature (meaning the feature and all of its plugins), somewhere. I > think it is important to have a local copy (in case the website goes away at > some point in the future). It's generic in that it says the license/notices > are > included but doesn't say exactly where (in the set of the feature/plugin > artifacts). > > So, it seems to me the right organization for us might be: > > 1) put into the top level an html form of an equivalent to their "user > agreement". I'll take a crack at making one of these... modeled after both > Eclipse's and our previous attempt at this (in uimaj features for example). > This will be "generic" and reference by name other Licenses and Notice files, > just like Eclipse does it. > > -- putting this into the top level follows the Eclipse convention > -- it's meant to cover the feature plus all the plugins that go with it in > the > distribution of the feature as packaged in the update site. > > 2) put into META-INF the full text (minus the how-to-apply-appendix) of the > ASF > license > > -- putting this into the META-INF directory follows Apache conventions > -- this covers just the feature artifact itself. So the plain Apache > License/Notice files should work here. > > 3) set the feature.properties for licenseURL to point to (1). > > 4) put the plain text form of (1) into the existing feature.properties file > > 5) set the feature.xml as you now have it: > > <license url="%licenseURL"> > %license > </license> > > Then, we'll have everything (the full, standard ASF license, the shorter > user-agreement (plain text & html) ) in one place, in the spots expected by > the > ASF and Eclipse, with the right coverages for each one. > > The one other thing to insure is that any additional licenses needed are > indeed > packaged somewhere among the plugins included with the distribution. > > How does that sound? > > -Marshall > >> The license in META-INF is that one for the feature.jar. The name >> "License.txt" is maybe missleading and can be changed (there is a pointer in >> the feature.xml). >> >> Summarizing, there is a difference between the click-though license (update >> site) and this one, which can be provided in html. At least, this is how I >> understood it. > I think there is no difference between the feature > Any pointers to this info on the web? > >> Should I rename it to, e.g., "BundleLicense.txt"? > I don't think so- I would still advocate for removing it and putting it into > the > META-INF directory and having just one. > > -Marshall > >
