On Sat, Mar 2, 2013 at 5:08 AM, Florian Hopf
<[email protected]> wrote:
On 02.03.2013 07:50, Florian Hopf wrote:
I'm not saying it is impossible, but we do need to make sure that our
LICENSE and NOTICE files reflect what we're actually distributing. So
if we distribute additional 3rd party code (in the form of a
dependencies JAR) then we may need to add their info. But I'm not
100% certain. Maybe someone knows for sure what the policy on this
is?
Ok, this seems to be more complicated than I thought. I just had a look
at the clerezza project that we are using. They are including some of
the dependencies in the NOTICE file (among those WYMIWYG which is also
a transitive dependency for us) and some additional licenses in their
LICENSE file.
Which information needs to be included depends on the license:
http://www.apache.org/legal/resolved.html#required-third-party-notices
I guess we could obtain a lot of the required information from the
direct dependencies we have as those are all Apache projects. But I am
OK with distributing the current release without the dependencies and
have a look at this for the release after that. I'd just like to add
links to the projects to the README file.
Unfortunately I suspect we need to do this even for our current release as
we are distributing the dependencies in the validator web archive.
I am not in the position to decide on these legal issues and what we need to
do but if there are concrete steps I can help with let me know.
This page explains the Apache policy:
http://www.apache.org/dev/licensing-howto.html
As I read it, it looks like what matters is the actually bits we
include in the release. If we have a dependency that Maven downloads
or the user must download separately, it does not go into the LICENSE
file. (Of course these dependencies might be documented in the readme
file, but his is good sense, not a policy requirement).
I had a look at all dependencies. I expect that if a library is hosted at
apache we don't need to do anything special? What about notices that are
contained in these libraries, e.g. clerezza-rdf-core contains this, what I
expect to be a fragment for a notices file:
If we include the bits then we need to account for them in the
LICENSE. So if we bundle code from another Apache project we need to
mention that in the LICENSE file. And if that project includes other
3rd party code then we do that as well. We need to do this
recursively for all the bits that we include in the release tarball.
Contains code from the following book:
Jonathan Knudsen, "Java Cryptography", O'Reilly Media, Inc., 1998
Contains code from mulgara project for sparql query parsing
http://svn.apache.org/viewvc/incubator/clerezza/trunk/rdf.core/src/main/appended-resources/META-INF/NOTICE?view=markup
Do we need to add this too?
If we include the Clerezza code in our release, yes.
This is a list of all compile time dependencies not hosted at Apache. I
expect that we don't need to do anything if a license is considered similar
to Apache:
com.hp.hpl.jena:iri:jar:0.8:compile
Part of Apache Jena
com.ibm.icu:icu4j:jar:3.4.4:compile
License is considered similar to Apache
http://www.apache.org/legal/resolved.html#category-a
com.sun.msv.datatype.xsd:xsdlib:jar:2009.1:compile
com.sun.msv.datatype.xsd:xsdlib:jar:2010.1:compile
These are two different concepts:
1) What kinds of dependencies are permitted in an Apache project.
2) How do we document the license of the code we distribute
The category-a stuff concerns the first question. It says that we're
fine to include such code in our release and distribute it. But we
still need to do the documentation part, and include the information
in our LICENSE file. Why? Because the user of our release is bound by
those license terms as well, so we want to make sure they are aware of
this.
As you can see, this gets messy quickly. It would be less painful to
just have the info in the readme, in a Prerequisites section, giving
the specific dependencies we have, along with URL's for the user to
download. And if the user really wants an all-in-one JAR, then Maven
can create that for them easily.
-Rob
Already contained in our NOTICE file so I guess this already has been
checked
isorelax:isorelax:jar:20030108:compile
MIT is considered similar to Apache
http://www.apache.org/legal/resolved.html#category-a
javax.activation:activation:jar:1.1:compile
Common Development and Distribution License (CDDL) v1.0, should be easy to
find out as this is a commonly used artifact
net.java.dev.msv:msv-core:jar:2009.1:compile
net.java.dev.msv:msv-core:jar:2011.1:compile
net.java.dev.msv:msv-testharness:jar:2009.1:compile
Already contained in our NOTICE file so I guess this already has been
checked
net.rootdev:java-rdfa-htmlparser:jar:0.4.2-RC2:compile
net.rootdev:java-rdfa:jar:0.4.2-RC2:compile
nu.validator.htmlparser:htmlparser:jar:1.2.0:compile
This needs to be stated in the notice, we should be able to get those from
the clerezza NOTICE and LICENSE files (this seems to be part of the license:
https://github.com/shellac/java-rdfa/wiki/licence)
org.iso_relax.verifier.jaxp.validation:isorelax-jaxp-bridge:jar:1.0:compile
Already contained in our NOTICE file so I guess this already has been
checked
org.osgi:org.osgi.compendium:jar:4.2.0:compile
org.osgi:org.osgi.core:jar:4.2.0:compile
Not sure if we need to do something about those. The clerezza notice and
license for the submodules doesn't state anything but this notice is
contained in the binary distribution: The OSGi Alliance
(http://www.osgi.org/)
org.slf4j:jcl-over-slf4j:jar:1.6.4:compile
org.slf4j:slf4j-api:jar:1.6.4:compile
org.slf4j:slf4j-log4j12:jar:1.6.4:compile
MIT is considered similar to Apache
http://www.apache.org/legal/resolved.html#category-a
org.wymiwyg:wymiwyg-commons-core:jar:0.7.6:compile
Seems to be part of Clerezza? Not sure. Is contained in the global NOTICE
file for Clerezza.
Regards
Florian
--
Florian Hopf
Freelance Software Developer
http://blog.florian-hopf.de
