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 Tue, 05 Feb 2013 14:25:24 GMT

On 2/5/2013 8:19 AM, Peter Klügl wrote:
> 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>"

ok; now fixed in svn.  (Also added Apache UIMA trademark)

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