taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Taverna 0.15.1 release licensing issue
Date Mon, 07 Mar 2016 00:53:05 GMT
On 5 Mar 2016 23:30, "Justin Mclean" <justin@classsoftware.com> 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).

Mime
View raw message