uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: [VOTE] Apache UIMA TextMarker RC3 AND Composite Repository
Date Tue, 05 Feb 2013 13:06:33 GMT
On 05.02.2013 00:08, Marshall Schor wrote:
> 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.

The files look fine.

I must admit that I do not fully understand your proposal.

So, I put uima-eclipse-user-agreement.html in the root of the feature 
and uima-eclipse-user-agreement.txt in the properties. The LICENSE in 
META-INF just covers the feature.jar and, therefore, contains only the 
ASL stuff. The plugins contain LICENSE files with the other licenses 
like CPL.

Is that enough?
Do we need to mention the other licenses in the click-through license 
(first line)?
Do we need to provide link to the other licenses in the user agreement?

Peter

PS: I thought the plain-text license is the click-though license and not 
the html version.

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


Mime
View raw message