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
