Bug #2318
closedCopyrights and licenses of subpackages need to be handled
0%
Description
Just so we don't forget, I'm submitting the copyright issue as a bug.
As a proposed feature, I modified the Kepler configuration.xml and
added copyright.htm so that Kepler can take advantage of the Ptolemy
II about: facility that helps handle copyright issues.
The problem is that packages such as Ptolemy and Kepler include
copyrighted software from various sources. Each package has
a different copyright that usually must be displayed somewhere
in the release.
I hacked up the about:copyright facilty to help handle this. The
current implementation is not perfect, but it helps.
Here's how it works.
If a URL starts with "about:", then code in ptolemy.actor.gui
specially interprets it.
"about:copyright" creates a page that includes links to some base
copyrights, such as the Ptolemy copyright and the Aelfred copyright.
It also looks for particular actors and if those actors are found, it
includes a link to the appropriate copyright. One issue here is
that searching for the actors can take time, the user might notice a lag.
If the configuration includes a property called _applicationCopyrights
then that the value of that parameter is assumed to be an array of
records of the form
{{actor="dot.separated.actor.class.name", copyright="relative/url/to/copyright.\
htm"}...}
So, if the util.ImageJActor actor is present, then going to about:copyright
will include a link to the javadoc and also to imagej-copyright.htm
imagej-copyright.htm does not currently exist, but usually this file
would include the ImageJ jar file copyright.
One issue as that the link to the javadoc defaults to pointing to the
Ptolemy website if the documentation cannot be found. We could add
yet another parameter that would send this traffic to the Kepler website.
I'll do this later.
So, to try this out, update your Kepler tree, run "ant run-dev"
and then at the bottom of the intro.htm, follow the
"This software is protected by this license." link.
On the Kepler copyright page, follow the link at the bottom:
"Kepler is based on Ptolemy II"
This will bring you to the about:copyright page.
On other cool feature is at the bottom of the Kepler copyright page
is "Other information about this configuration"
This brings up a page that includes a link (about:configuration) to
expand the configuration, which is a good way to quickly test for
missing classes. For Kepler, this will not expand to include all the
actors the way it does under Ptolemy, but it still has value.
There are also links to expand all the .xml files listed in a file.
For example, "about:demos#ptolemy/configs/kepler/intro.htm"
will expand all the workflows listed on the Kepler splash page.
One can then run all the demos.
Also, "about:links#ptolemy/configs/kepler/intro.htm" will open
up all the .htm, .pdf and .xml links on the splash page, which
is a good way to check documentation.
In both cases, the expansion is only one level deep, but I use it
all the time to check releases.
I don't think this is a perfect solution but it can be used to
help address the copyright problem. Further refinement would help.
What would need to be done is that for each actor that uses a third
party jar file we would need to create a web page that includes
the copyright. This takes quite a bit of work, but helps ensure
that the copyright is actually shipped with the release.
If this utility is not of interest, then feel free to remove
the link at the bottom of copyright.htm.
Related issues
Updated by Matt Jones almost 19 years ago
Targeting copyright work at alpha9 (feature freeze).
Updated by Christopher Brooks over 18 years ago
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.
Updated by Christopher Brooks over 16 years ago
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
Updated by Timothy McPhillips over 16 years ago
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.)
Updated by Timothy McPhillips over 16 years ago
Note that our proposal for handling LGPL jars in Kepler 1.0 is limited to those with version 3 of the LGPL license only.
Updated by Sean Riddle over 16 years ago
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?
Updated by David Welker over 16 years ago
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
Updated by Timothy McPhillips over 16 years ago
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.
Updated by David Welker over 16 years ago
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
Updated by Derik Barseghian over 16 years ago
I have removed rbnb-3.1b2.jar and RDIPD0Ensemble.jar (and associated code and workflows).
Updated by Derik Barseghian over 16 years ago
I have removed those from the RELEASE-BRANCH-1-0-0, I should have said. They are still in head.
Updated by Christopher Brooks over 16 years ago
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.
Updated by Daniel Crawl over 16 years ago
odc-kepler-0.1.r18530.jar has been removed from 1.0 branch.
Updated by David Welker over 16 years ago
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.
Updated by Sean Riddle over 16 years ago
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
Updated by Sean Riddle over 16 years ago
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.
Updated by Timothy McPhillips over 16 years ago
- Bug 3182 has been marked as a duplicate of this bug. ***
Updated by Timothy McPhillips over 16 years ago
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.
Updated by Chad Berkley over 16 years ago
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.
Updated by Chad Berkley over 16 years ago
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
Updated by Timothy McPhillips over 16 years ago
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.
Updated by Timothy McPhillips over 16 years ago
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.