[kepler-dev] [Bug 2318] - Copyrights and licenses of subpackages need to be handled

[bugzilla-daemon@ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2318





------- Comment #12 from cxh at eecs.berkeley.edu  2008-04-14 13:13 -------
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.