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:19:04 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 file "uima-eclipse-user-agreement.txt" has some html at the end:

"<small>Java and all Java-based trademarks are trademarks of Oracle 
Corporation in the United States, other countries, or both.</small>
</body>
</html>"

Peter


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