Can we put the release on hold for a few days while we debate the options, or are we up against a deadline?
On Sun, Mar 6, 2016 at 4:53 PM Stian Soiland-Reyes <[email protected]> wrote: > 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). >
