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