Right, many of those excludes must go. We still need distribution rights for the test workflows etc as they go into the source distribution. I would try to keep those to be just Manchester ones to avoid growing the NOTICE file with creative commons attributions.
I've added headers to the ttl ontologies (#) and t2flow that I know are our (OK as t2flow is XML). To .wfbundle and .bundle.zip examples/test data we can copy in NOTICE and LICENCE directly as they are zip files. Not sure if this makes sense? There are after all other files inside that are saved out and don't have headers.. (Resarch Object wise probably the wfbundle should have a slot for license field in the manifest.json, like below) JSON is tricky as no comments are allowed. In our JSON-LD files you could do something like "http://purl.org/dc/terms/license": { "@id": "http://apache...LICENSE-2.0"} .. But including the header text is trickier as newlines need to be escaped, and so would not satisfy RAT. On 9 Feb 2015 15:25, "Donal K. Fellows" <[email protected]> wrote: > On 09/02/2015 14:57, Stian Soiland-Reyes wrote: > >> Great stuff! >> >> Am I correct in interpreting this that we now should be "IP clear" for >> release of taverna-language? >> > > No, not quite. :-) We're at the stage where we've got a fairly clear > description of the files that are exceptions, but not yet where we've > handled the IP issues. > > The exclusions section currently reads: > > <!-- Following excludes needed for taverna-scufl2-rdf, > taverna-scufl2-integration-tests and taverna-scufl2-validation- > integration > subfolders that should be modules but are not. --> > <exclude>**/.classpath</exclude> > <exclude>**/.project</exclude> > <exclude>**/.settings/</exclude> > <exclude>**/target/</exclude> > <!-- Text and Markdown files are typically used only for > documentation > purposes and license declarations are usually spurious in these > files since > often they will refer to the LICENSE/NOTICE for users to find the > actual > licenses --> > <exclude>**/*.md</exclude> > <!-- META-INF services files can include comments but a license > header > would be unecessarily clutter so we exclude these --> > <exclude>**/META-INF/services/*</exclude> > <exclude>**/*.xsd</exclude> > <exclude>**/*.rdf</exclude> > <exclude>**/*.owl</exclude> > <exclude>**/src/main/resources/jarcache.json</exclude> > <!-- Various files used for testing and test support only. --> > <exclude>**/*.t2flow</exclude> > <exclude>**/*.ttl</exclude> > <exclude>**/mimetype</exclude> > <exclude>**/src/test/resources/*starterpacklist</exclude> > <exclude>**/src/test/resources/**/*.txt</exclude> > <exclude>**/src/test/resources/**/workflow*.xml</exclude> > <exclude>**/src/test/resources/**/*.json</exclude> > <exclude>**/resources/sample-output/outputs/**</exclude> > <exclude>**/src/test/resources/win8.url</exclude> > <exclude>**/src/test/resources/full-example/**</exclude> > > I think the various eclipse and maven generated files can be ignored. Of > the rest, the main concern are XSD, RDF and OWL files outside the > **/src/test/resources sections of the codebase, as they tend to be of > schemas that are definitely *not* APL licensed, yet are difficult to obtain > for one reason or another (whether because they are not available as a > consolidated file, or because they're in the W3C tarpit). Everything else > is either test data (in some cases in a project only used for testing) or > in a format that does not support comments (e.g., I'm uneasy about putting > comments into t2flow or ttl files, and mimetype files *must not* contain > anything, though the mimetype files are also hardly things that anyone > could claim meaningful intellectual property rights over). > > What's the process for dealing with these cases? > > Donal. >
