uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Apache UIMA TextMarker RC3 AND Composite Repository
Date Mon, 04 Feb 2013 23:08:13 GMT
I've put drafts of the click-thru licenses for features here:


These, like the Eclipse "feature-update-licenses" are completely generic... and
refer to things
in the plugins.

Let me know what you think.


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

View raw message