[SciPy-user] patch copyrights, and Guido's comments

[eric]

Folks,

I pinged Guido and asked him about Python's policy on this issue.  With his permission, I've posted his comments below.  I think for now it is safe to say we will continue with the "patches cannot add copyrights" policy -- unless someone on the list comes up with an acceptable plan.  It sounds like an alternative acceptable policy is legally involved and would require a lot of effort.  The Python folks are working on this, and, once Python formalizes their policies, we'll review things again.  The direction they are leaning has definite possiblities.

thanks,

eric


------------------ Eric

Hello Guido,

I'm part of the team developing SciPy (www.scipy.org), an early stage effort to create a large package of modules for Scientific Computing.  We're trying to follow the general license, copyright process of Python with the exception that we are using the BSD license instead of the Python license because of the quagmire it was in when SciPy came out.  Changing to the Python license may be in the future, but that is not the issue here.

We have had our first issue with someone unhappy about a copyright policy.  It concerns whether patches submitted to modules should be able to attach a copyright notice to the file they patch.  This seems to be a bad idea to me, and from looking through the code in Python, it doesn't appear that this is allowed in Python either.

The thread discussing the issue is archived here:

http://scipy.net/pipermail/scipy-dev/2001-October/000072.html

and continues here:

http://scipy.net/pipermail/scipy-dev/2001-November/000073.html

I'm inclined to allow only a single copyright per file, but the copyright can be owned by someone other than Enthought.  Travis Oliphant and others have copyrighted modules in SciPy right now.  I would like to get feedback on whether this is an appropriate policy and how you handle this in Python.

Sorry to bother you with legal matters, but your experience in this area could probably save some future headaches.

thanks,
eric

--------------------- Guido

Hi Eric,

We don't have an explicit policy against multiple copyright notices in
files; it's just that most of our contributors don't care.
Personally, I think it's pretty murky whether it makes sense to assert
copyright on a 50-line patch to a 500-line file.

Python currently doesn't have strict guidelines about who owns
contributions, but we realize this is not good, and the PSF is
planning to work on fixing this situation.  There are three possible
ways to deal with this:

- Copyright assignment: murky, because in most European countries you
  can't assign the "moral" rights

- Licensing: clear, but must be careful that the PSF has the right to
  change the license -- imagine having to go back to hundreds of
  contributors for a change in license

- Joint ownership: this is an experimental approach taken by Zope
  Corp.  See: http://dev.zope.org/CVS/ContributorIntroduction

We're currently leaning towards JO for regular contributors and large
contributions, and some light form of licensing for smaller
contributions (like most patches) for which ownership seems overkill.

We haven't decided yet; in a couple of months, check the PSF website
for an outcome.

(Are you coming to python10?)

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------- Guido in a follow-up

Actually, Python has a lot of contributed modules that have an outside
copyright notice and license, and we've always be fine with those as
long as it was a BSD or Python style license.  I just don't recall
people wanting a copyright notice for a relatively small change;
instead, we typically have a comment saying "Author: XXX" or "Patched
by: XXX".

Ehm, we do have multiple copyrights in a few files.
Tools/scripts/trace.py has at least 4!

I guess I should have said that it's rare but that we do allow
multiple copyrights per file.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20011101/d82b3d13/attachment.html>