On 4 June 2016 at 17:30, Gale Naylor <ga...@noventussolutions.com> wrote: > Thanks for the explanations, Stian. A vote-email script might not be a bad > idea! It certainly > seems to be a complicated thing to pull together. > > In response to Stian's email, I found some additional, related ASF > resources that support not > requiring license headers in files whose content cannot be copyrighted > (e.g., files that contain > "Hello"). Here is the link: > http://www.apache.org/legal/src-headers.html#faq-exceptions > > The exception also applies to "Test data for which the addition of a source > header would cause > the tests to fail." > > It seems that most of the files that currently do not have license headers, > including > files in the services sub-directories, meet the criteria of being exempt > from the license header > requirement.
Ah, great. So we're generally good to go with those test files then, and can just list them in the apache-rat excludes - which I think is a good way to say "Yeah, we know about this file, 's fine". > However, it sounds like we SHOULD add license headers to the > package.html files. > Do we want to do that way now, and then later convert to > package-info.java files? Just convert them right away, I think.. it's generally just rename and add the ASF header and the Java "package " line. The only tricky thing about them is that you need to use the two different Java comment blocks carefully so that the ASF header does not become the JAvadoc, that is src/main/java/org/apache/taverna/foo/package-info.java /* ASF */ /** javadoc for this package **/ package org.apache.taverna.foo; And we should have such package info for all API-like packages at least.. like in all the *-api bits in taverna-engine. (It might just have a one-liner with the description from README) Shall we do this after this release? > I also found an ASF link that confirms what Stian said about only BUNDLED > dependencies > needing to be included in NOTICE files. Good to know. > (http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled) Yes - so bundled would be when we make a binaries/ upload. Not sure if this also covers any bundling in Maven Central - e.g. http://central.maven.org/maven2/org/apache/taverna/language/taverna-tavlang-tool/0.15.1-incubating/taverna-tavlang-tool-0.15.1-incubating.jar includes bundled JARs, but the Maven plugins seem to have managed to combine the contained META-INF/NOTICE. (Thanks, Menaka) > Also, regarding 3rd party copyrighted works: I found an ASF link that > explicitly states: > -- not to modify/remove copyright headers from 3rd party works; > -- not to add the standard ASF license header to 3rd party works. > http://www.apache.org/legal/src-headers.html#3party OK, so we'll leave those BSD copyrights in place in say the taverna-engine hadoop crossproduct.java > One remaining question about 3rd party license in > src/license/THIRD-PARTY.properties: > > javax.transaction--com.springsource.javax.transaction--1.1.0 (CDDL 1.0) > > Is this an exception to the category-b license "binary only" rule because > we use only > a small amount of source code? But it's not included - we don't distribute javax.transaction in the source archive; it's downloaded from Maven repositories. You won't see it until you have built the commandline product: Directory of D:\src\apache-taverna-commandline-3.1.0-incubating\taverna-commandline-product\target\apache-taverna-commandline-3.1.0-incubating\lib\javax.transaction 2016-06-06 14:10 <DIR> . 2016-06-06 14:10 <DIR> .. 2016-05-31 16:23 15,518 com.springsource.javax.transaction-1.1.0.jar (or look in ~/.m2/repository/javax/transaction) > One observation about headers in JSON files > Most of the JSON files have the header you described (http://purl.org. > ..). Yeah.. some kind of JSON-LD-like workaround -- the key is unlikely to be used for anything but for licenses - and generally JSON consumers ignore extra keys. > Is it okay if the JSON file header uses ##? (See below). > > taverna-activity-archetype\src\main\resources\archetype-resource > \__rootArtifactId__-activity\src\main\resources\schema.json No, there are no valid comment characters in JSON. The Jackson JSON parser might be configurable to accept # though - but I don't think we want to rely on that. The resource above has ## comments because it's a Velocity template for generating schema.json in the archetype - the generated file in the user's plugin should NOT inherit that ASF header, as they might or might not want to choose to license their plugin under the ASF license. -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
