[OSGeo-Board] Feedback from GRASS team members on contributors agreement

Wed Mar 8 00:22:53 PST 2006

Here some voices from GRASS team members on contributors
agreement, Frank knows them already as he is subscribed to
the related mailing lists. Sorry, it's a bit long here, but I thought
to fully cite the mails for the ease of reading (in order of posting).

Markus

Discussions in the GRASS Mailing lists:

http://grass.itc.it/pipermail/grass5/2006-February/021449.html
Glynn Clements  glynn at gclements.plus.com
"The main issue which I see is that the wording doesn't appear to give
the submitter any choice over the licence(s) used by the foundation:

  2. Grant of Copyright License. Subject to the terms and conditions of
  this Agreement, You hereby grant to the Foundation and to recipients
  of software distributed by the Foundation a perpetual, worldwide,
  non-exclusive, no-charge, royalty-free, irrevocable copyright license
  to reproduce, prepare derivative works of, publicly display, publicly
  perform, sublicense, and distribute Your Contributions and such
  derivative works.

This appears to suggest that the foundation can redistribute
contributions under whichever licence it chooses, the only restriction
being in the opening paragraph:

  In return, the Foundation shall not use Your Contributions in a way
  that is contrary to the public benefit or inconsistent with its
  nonprofit status and bylaws in effect at the time of the
  Contribution.

Unless the agreement includes a "space" to state a specific licence,
all contributions will essentially be under a BSD/MIT style licence
(i.e. permitting the creation of proprietary derivatives).

--
Glynn Clements <glynn at gclements.plus.com>
"

Frank's answer:
http://grass.itc.it/pipermail/grass5/2006-February/021450.html
########################

http://grass.itc.it/pipermail/grass5/2006-March/021526.html
Hamish  hamish_nospam at yahoo.com
">  http://www.fossgis.de/osgeo/index.php/Contributor_Agreement
reading that some things are clearer, some are not.

Two reactionary and probably non-constructive comments: (I prefer
solutions to complaints, but sometimes it feels good to complain)

1) As things are today, I don't want to share any of my copyright (ie
control of the code) with anyone other than "the GRASS development team".
Not to a group made up of people I mostly don't know with no established
track record. I am sure everyone on the board are wonderful people but
trust comes through personal observation, not reputation. I am sure it
is quite impossible to ever make modern GRASS non-GPL as to contact
everyone holding copyright or their surviving heirs is not practicable;
as is unwinding their contributions. So I am not very worried about a
license hijack here. What I am worried about, from a practical and "new
code" standpoint, is that if the power isn't held by the developers,
and decisions are made, even for non-malfeasant reasons, if these do not
align with the interests of the developers, then developers will walk
away quickly (unless well paid of course). This would quickly kill the
project. Control and recognition is an open source developer's capital-
we need to make very sure that by standing under the OSGeo banner we
don't stand in the shadow of it, and lose both.

I assign co-copyright of all my GRASS contributions to date to "the
GRASS development team", meaning I agree that it is up to the team
to decide what is best. If co-copyright on new code is assigned to
OSGeo, how do I assert G.D.T. decisions have priority over OSGeo w.r.t.
GRASS matters?

2) I don't like signing things. Rousseau's social contract not
withstanding, the benefit has to flow both ways. Am I concerned if a
non-contributing corporation can get ISO9000 certification while
depending on OSGeo software? Honestly?

I would advocate a go-slow approach. Call me the stick in the mud.

Interesting parallels with the for-the-users or for-the-developers
usability debates.

Hamish
"

Frank's answer:
http://grass.itc.it/pipermail/grass5/2006-March/021531.html
########################
http://grass.itc.it/pipermail/grass5/2006-March/021553.html
Glynn Clements  glynn at gclements.plus.com
"OK. That clarifies that the right to relicense code is intentional,
not an oversight.

Personally, I don't intend to sign the proposed CLA.

It would be useful to state now whether you intend to stop accepting
future contributions which are licensed under the GPL, and if so,
when. If you are, there probably isn't much point in me planning
signficant future changes (e.g. the display/GUI stuff).

Minor changes (bugfixes) aren't problem. The FSF considers patches of
a few lines to fall below the threshold of what constitues an
"original work", and thus not subject to copyright or licensing
issues.

--
Glynn Clements <glynn at gclements.plus.com>
"

########################
http://grass.itc.it/pipermail/grass5/2006-March/021583.html
"Glynn Clements  glynn at gclements.plus.com

I believe that, in most cases, releasing code under the GPL provides
the maximum benefit, as anyone wishing to create derivative works also
has to licence their version under the GPL. The more GPL'd code that
exists, the greater the incentive for developers to make new code
available under the GPL.

The CLA grants the foundation the right to redistribute contributed
code under almost any licence, including those which permit
proprietary derivatives (e.g. BSD and MIT licences). Such licences
provide significantly less incentive for developers to share their
additions or enhancements.
--
Glynn Clements <glynn at gclements.plus.com>
"

Frank's answer:
http://grass.itc.it/pipermail/grass5/2006-March/021585.html

########################
http://grass.itc.it/pipermail/grass5/2006-March/021594.html
Roger Bivand  Roger.Bivand at nhh.no
"I share Glynn's view. While I don't commit to GRASS source, insight into
the R foundation (I am an ordinary member, that is a board member), and
work with the interfaces suggests that, for the mix of contributors in
GRASS, GPL with LGPL for carefully chosen components is best. The R engine
is GPL/LGPL, and most of the 800+ contributed packages follow the same
model, including those in Bioconductor, the leading open source
bioinformatics project.

Most of the contributions are made by people who are not software
developers, but who need to develop software to do their work, whether in
companies, research institutes or higher education. There are also many
who are not from North America. The R foundation does own the copyright to
the R core engine, and as such is a different animal to OSGeo. R went GPL
ten years ago, and staying GPL has been part of its success, depending
crucially on trust in a core team of a dozen or more, who almost never
meet face to face. There has not been any debate over licencing apart from
a very few issues between GPL and LGPL to adjust the header files to suit.
This is described in: https://svn.r-project.org/R/trunk/doc/COPYRIGHTS.

Of course, R is a different animal with different experience. But based in
part on that, I agree with Glynn with regard to GRASS, and welcome Frank's
willingness to review the draft CLA to accommodate Glynn's position.

Best wishes,

Roger
"

http://grass.itc.it/pipermail/grass5/2006-March/021596.html
Moritz Lennert  mlennert at club.worldonline.be
"Even though I do not contribute much, I do support Glynn's position very
strongly.

Moritz
"
########################
http://grass.itc.it/pipermail/grass5/2006-March/021593.html
Michael Barton  michael.barton at asu.edu
"I understand this perspective and welcome mechanisms by which developers and
contributors can have their work properly credited and distributed.

On the other hand, I've already run into problems in trying to establish
links between GRASS and other open source software, using other licenses
(BSD and MIT). Because GRASS is GPL, if the developers of the other software
do not want to license under GPL, we are very limited in the kinds of
linkages we can establish. I understand (I think) the basic principals
though not the legal details.

It would be nice if we could maintain GPL principals for contributors who
feel most strongly about this, but could also find some way to let GRASS
interact more flexibly with other software. I don't know how this can
happen, but I hope that OSGeo can help work some of this out.

Michael
"