Kepler

Targeting copyright work at alpha9 (feature freeze).

I'm assigning this to Dan because he is the release master.
I'm not sure if there is time to do this or not, it is Dan's call.

What needs to happen is that for each package that is being shipped,
which really means each jar file, java file or possibly data set,
we need to determine the copyright, create an html file that describes
the copyright and update the
_applicationCopyrights configuration parameter so that it is an array of
records of the form {{actor="dot.separated.actor.class.name", copyright="relative/url/to/copyright.\
htm"}...}

This seems like a huge task, maybe it needs to be distributed to the
actor authors.
It could be done as part of
"Conflicting jars and classpath reduction"
http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2316

I suspect this needs to be done before 1.0, since technically some of the
packages probably require that the copyright get shipped somehow.

I can help out here with the Ptolemy side of things if the copyright facility
in Ptolemy needs enhancing. However, I probably don't have the time to
track down very many package and generate .html files myself.
A good template file can be found at
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII5.0/ptII5.0.1/ptolemy/actor/lib/jai/jai-copyright.htm
Note that the file name is jai-copyright.htm. I use the package name so
I can easily distinguish between all the copyright files in my editor.
Maybe the file should be called "copyright.htm"? I dunno.

FOSSology (http://www.fossology.org/) could help manage the copyrights.
However, installing it is not easy, it requires Apache and Postgres.
See http://fossology.org/docs/frequently_asked_questions#what_software_is_required

There was discussion on Slashdot:
http://it.slashdot.org/article.pl?sid=08/01/23/0131204&from=rss

David Welker is investigating the licenses for all 3rd-party jar files included in Kepler. Not all of them are BSD compatible. At least one is LGPL (lib/jar/cipres/jacorb.jar). We will be posting a list of all non-BSD jar files shortly.

Christopher Brooks, David Welker, and I talked on the phone about the LGPL jars, and concluded that including these jars in Kepler 1.0 may be acceptable. To satisfy the LGPL terms we propose to:

(1) Include a list of these LGPL'd jar files both in the distribution and on the Kepler web site.

(2) Provide links to the sources of the LGPL packages the jars come from, hosting these packages on the Kepler web site to ensure availability.

(3) Employ the Ptolemy about:copyright facility Christopher mentioned previously so that the copyrights and licenses of these jars can be readily displayed at run time.

(In the future I propose that the core of Kepler, maintained and distributed by the Kepler/CORE project, not depend on any LGPL packages, and that such dependencies be limited to particular Kepler extensions.)

Note that our proposal for handling LGPL jars in Kepler 1.0 is limited to those with version 3 of the LGPL license only.

The licensing on gnu-regexp-1.0.8.jar could be problematic. It is only used in org.ecoinformatics.util.Util.substitute(), and there only to reproduce the build-in functionality of String.replaceAll(). This redundant function doesn't appear to be called anywhere, although a call could conceivably be crafted at runtime. Is there any objection to removing this jar, and the associated String.replaceAll() duplicate function?

We have some major problems with licensing here. Very major problems.

Sean Riddle and I have examined licenses for our compile-time dependencies. (And there are a lot more run-time dependencies that presumably have similar problems that we have not gotten to yet.) Well, our initial examination has revealed some very serious licensing issues that go to whether we can release as BSD.

We have three sorts of problems. First, there are many jars that have restrictions on commercial use. Second, there are jars that are licensed as LGPL v2.1. After examining the licenses very carefully, we have concluded that LGPL v3.0 is acceptable but that licenses that say LGPL v2.1 without giving you the option of LGPL v3.0 are unacceptable. Third, is code that might be contaminated with GPL.

We need to resolve these issues ASAP. This is either a release blocker, or we must alter our release so it is not BSD... Not only that, we haven't even gotten started on run-time jars.

Restrictions on Commercial Use:

Digital Library for Earth System Education
dlese.jar

Nimrod: Tools for Distributed Parametric Modeling
NimrodService.jar

Cipres
cipres_framework.jar

com.oreilly.servlet
cos.jar

Skybound Software
doublePolygon.jar

LGPL v2.0:

Forester
forester.jar

GeoTools
gt1.jar

ODC/Kepler
odc-kepler-0.1.r18530.jar

JacORB
jacorb.jar

Might be GPL contaminated:

JUMP Unified Mapping Platform
jump.jar

Eco Grid
org.ecoinformatics.ecogrid.AuthenticatedQueryService-stub.jar
org.ecoinformatics.ecogrid.AuthenticatedService-stub.jar
org.ecoinformatics.ecogrid.IdentifierService-stub.jar
org.ecoinformatics.ecogrid.PutService-stub.jar
org.ecoinformatics.ecogrid.QueryService-stub.jar
org.ecoinformatics.ecogrid.RegistryService-stub.jar

Seek Taxon
tos-client.jar

The problem with jar licenses illustrates one good reason to cleanly partition the Kepler system into a core of essential functionality and a set of (domain- or technology-specific) extensions that the core does not depend on. The core could be kept free of these kinds of licensing entanglements, whereas each extension would be free to employ a wide range of licensing schemes and depend on 3rd-party libraries with a similarly diverse set of licenses. Should someone distribute a build of the core of Kepler with one or more extensions, then that distribution might have licensing restrictions that do not apply to the core when distributed alone or with other combinations of extensions.

In addition, by moving all non-core sources and libraries out of the core system (and out of the part of the repository hosting the core), and associating each extension with particular people responsible for maintaining that extension, it will be clear who is using what parts of Kepler. If no one is maintaining or using a particular extension to Kepler, this will be clear from lack of activity in that part of the repository, and unmaintained extensions wouldn't clutter up other folks' custom distributions of Kepler anyway. As it is, it's very difficult to know what things in the Kepler are still needed by anyone.

If you need to remove a jar...

If there is a jar on the "bad list" and you cannot get the license fixed. (Say it is impossible to renegotiate) then you may need to remove it from the system.

In that case, we have produced a file that lists compile-time jars and the corresponding Kepler source files or packages that use them. This might be helpful if you want to get an idea of what is involved in taking a particular jar out.

You can reach that PDF document by going to:
http://www.kepler-project.org/Wiki.jsp?page=BuildSystem

I have removed rbnb-3.1b2.jar and RDIPD0Ensemble.jar (and associated code and workflows).

I have removed those from the RELEASE-BRANCH-1-0-0, I should have said. They are still in head.

IANAL (I am not a lawyer), but what I suggest is that you clearly document
that some portions of Kepler are released under other copyrights and move on
to shipping.

You could generate a list of the offending copyrights and have that on
the installer copyright page and have a web page in the documentation that ships with the sourceq. Perhaps a summary on that page would help.

There are several different problem licenses.
- GPL - you probably don't want to ship - you could leave hooks for this
code to be included if the user has it in their classpath at build time.
- LGPL - no big deal, just follow the license rules.
- non-commercial use only - document and allow the user to decide for
themselves.
- others?

It might be worth building a version of Kepler that has none of the problem
licenses. This is what the Ptiny configuration is for in Ptolemy, though
we don't ship a separate source tree for Ptiny.

Anyway, just my $0.02. I think that identifying the different copyrights
and presenting them to the user is the first step. Simplifying the copyrights
where possible is a great second step.

Thinking about the different use cases for why we include copyrights may
help:
1. We include copyrights because we are required to when we use software that
has copyrights
2. Our institutions require us to copyright the code to protect the institution
against liability
3. Users of the code will want to have their rights preserved.
4. Future developers of the code may want to do a commercial release.

I think the first two are much more important than the second two and
the last option is best left up to the commercial developer.

odc-kepler-0.1.r18530.jar has been removed from 1.0 branch.

Good News. I have finished examining all of the remaining runtime jars, and I have found only one major problem.

The jar opendap-0.0.9.jar has distributes gnu.getopt, which is GPL. This makes the whole jar GPL. I am not sure what the license for the jar would be if getopt were not included...

The following jars have unknown licenses. In one case, it is unknown because I was unable to register on the IBM DeveloperWorks website.

These need to be researched...

ImageJ.jar
griddlesActorLib.jar
rdf-api-2001-01-19.jar
qaqc.jar
wmsd.jar
ncsu.jar
edu.sdsc.globusproxy.jar
kepler-styles.jar
geon-jdbc-driver.jar
db2jcc.jar
oracleJdbc.jar
omi.jar

There are also some Microsoft JDBC jars that we can only redistribute if we register. I think registering may be free, but I did not look that closely into it:

mssqlserver.jar
msbase.jar
msutil.jar

Overall, we are looking much better than I expected... The remaining risk remains with the unknowns.

We need to include extra JARs per these license restrictions: http://java.sun.com/webservices/docs/1.5/ReleaseNotes.html

If we include any of a module we have to include the entire thing. Below are the already included JARs and what module they belong to. Below that is a list of necessary-to-add JARs.

JAR Module
activation.jar SAAJ
jaxb-api.jar JAXB
jaxrpc-api.jar JAX-RPC
jaxrpc-impl.jar JAX-RPC
mail.jar SAAJ
saaj-api.jar SAAJ
xercesImpl.jar SAAJ

Module Jars
SAAJ dom, jaxp-api, saaj-impl, sax
JAXB jaxb-impl, jaxb-libs, jaxb-xjc, namespace
JAX-RPC jax-qname, jaxrpc-spi, relaxngDatatype, xsdlib

Okay, it looks like I was looking at compile-time dependencies instead of the full list. That negates the problems with JAXB and JAX-RPC, but SAAJ is still missing a few. However, looking over the new files, I see we include xws-security.jar, and maybe other JARs from the XML and Web Services Security component. It looks like this means we have to redistribute all of the WSDP.

• Bug 3182 has been marked as a duplicate of this bug. ***

We can delete the following jar files:

doublePolygon.jar
NimrodService.jar
griddlesActorLib.jar
ncsu.jar
edu.sdsc.globusproxy.jar
geon-jdbc-driver.jar
omi.jar

Two files with unknown licenses remain:

dlese.jar
oracleJdbc.jar

I recommended deleting all of these and running the tests and demos.

We still need to make the list of LGPL libraries included easily available and to include any other attribution required by a few of the non-BSD licenses.

Here are other file that will have to be removed if these jars are deleted. This list does not include the actors that use this class. It just includes compile time dependencies. Deleting these dependencies might cause other files that depend on them to have to be removed.

doublePolygon.jar:
-org/geon/PointinPolygon.java
-org/geon/PointinPolygonXY.java
-org/geon/SVGToPolygon.java

NimrodService.jar:
-org/monash/griddles/GriddlesExec.java
-org/monash/griddles/NimrodClient.java
**This basically breaks the griddles application, which has is has references in the User Manual and would need to be removed.

griddlesActorLib.jar:
-no compile time errors

ncsu.jar:
-no compile time errors

edu.sdsc.globusproxy.jar:
-org/nmiworkflow/GlobusProxy.java

geon-jdbc-driver.jar:
-no compile time errors

omi.jar:
-no compile time errors

dlese.jar:
-/org/geon/XMLToADN.java

oracleJdbc.jar:
-no compile time errors

I'm uncomfortable removing so many files from projects that are not mine. I'd like to get a go-ahead from someone related to these projects.

If/when these files are removed, it's going to take a concerted debugging effort on the part of several people to make sure there are no actors that depend on these jars at runtime. I'm worried about introducing instability due to missing jar files.

Here's a list of the files I removed. the ones with a "--" are had a secondary compile time dependency on the jar (i.e. they depended on a class that depended on the jar).

doublePolygon.jar:
-org/geon/PointinPolygon.java
-org/geon/PointinPolygonXY.java
-org/geon/SVGToPolygon.java
--org/geon/PolygonUtil.java

NimrodService.jar:
-org/monash/griddles/GriddlesExec.java
-org/monash/griddles/NimrodClient.java
--org/monash/griddles/JGridletCreator.java

griddlesActorLib.jar:

ncsu.jar:

edu.sdsc.globusproxy.jar:
-org/nmiworkflow/GlobusProxy.java

geon-jdbc-driver.jar:

omi.jar:

dlese.jar:
-/org/geon/XMLToADN.java

oracleJdbc.jar

We need to add to the distribution a file including all of the non-BSD licenses that apply to libraries included in the release, and listing each of the libraries to which these licenses apply.

Other than that, it appears that all of the jar and other library licensing issues listed above have been dealt with.

The file licenses.txt now includes the text of all of the non-BSD licenses that apply to libraries included in the release, and lists each of the libraries to which these licenses apply.

Original Bugzilla ID was 2318