On 5 Mar 2016 23:30, "Justin Mclean" <[email protected]> wrote: > > Sorry but I just voted -1 on your release on the incubator list due to > licensing issues, namely Category B licensed files in a source release. [1] > > This will need to be fixed before graduation but as long as you raise JIRAs > for the issues and follow up on legal discuss I’d be willing to change my > vote. Unless that is you think the issue is serious enough to not make the > current release candidate a release. > > Of course you still may get 3 +1 votes from other IPMC members.
Thank you for your thorough review! We have already identified a similar issue with the bundled OASIS opendocument schemas, which also affect the ODF Toolkit incubator. https://issues.apache.org/jira/browse/TAVERNA-925 I started tracking what you highlighted on https://issues.apache.org/jira/browse/TAVERNA-927 and added some initial thoughts - feel free to comment in Jira! I think we have a path forward: a) Check with w3c what actually is the license of those XSD and ontology files, as it's not explicit in the upstream files. (the one that is explicit, uses the permissive w3c software license) https://issues.apache.org/jira/browse/TAVERNA-928 b) Check with w3c what is the license for *using* artifacts donated to w3c under the W3C Community Contributor License Agreement https://issues.apache.org/jira/browse/TAVERNA-932 .. and then follow-up with LEGAL if that is permitted or not. A rough reading of https://www.w3.org/community/about/agreements/cla/ makes it seem like a BSD license: 2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, without any obligation for accounting to me, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement any Contribution to the full extent of my copyright interest in the Contribution. 2.2. Attribution. As a condition of the copyright grant, you must include an attribution to the Specification in any derivative work you make based on the Specification. That attribution must include, at minimum, the Specification name and version number. but who is that CLA given *to* ? c) or.. Move those to a non-Apache Maven artifact, so it can be a binary dependency JAR https://issues.apache.org/jira/browse/TAVERNA-929 Of course they don't have to be JARs, it could just be a wget straight from something under http://github.com/taverna-extras/ (to avoid W3Cs tar-pit and have an archive) .. but if they are in Maven central then they would also be cached in Maven repositories - ODF need something similar for the OASIS schemas d) Avoid depending on them at all.. by: hand-coding ontology constants: https://issues.apache.org/jira/browse/TAVERNA-930 hand-coding clean-room schemas as non-derived JAXB beans (this is more work): https://issues.apache.org/jira/browse/TAVERNA-931 What do you think folks - is this enough to cancel the release candidate, or can we deal with this as we move towards graduation? I think there could be similar issues in taverna-server schema files. We might be able to do some quick-and-dirty move of the "possibly offending" files to the taverna-extras github - which of course adds a download dependency on another third-source during build (but under the control of multiple of the Taverna committers).
