[GRASS5] FWD: [OSGeo-Discuss] Incubation Committee / Contributor Agreements]

Dear GRASS community,

we had a board meeting today in the OSGeo Foundation and
discussed details such as the project incubation. This
is a term borrowed from the Apache Foundation where all
projects wishing to join the foundation have to go through.
It covers basically license issues, a contributor
agreement, project management and the state of the
community (no dead projects are desired). Some draft
notes can be found here:

http://www.fossgis.de/osgeo/index.php/Project_Incubation
(this is the temporary wiki of the OSGeo Foundation unless
the osgeo.org isn't completely ready).

Attached I forward a fresh email from Frank Warmerdam
with more details. Things want to be discussed now.

Best

Markus

Markus Neteler wrote:

we had a board meeting today in the OSGeo Foundation and
discussed details such as the project incubation. This
is a term borrowed from the Apache Foundation where all
projects wishing to join the foundation have to go through.
It covers basically license issues, a contributor
agreement, project management and the state of the
community (no dead projects are desired). Some draft
notes can be found here:

http://www.fossgis.de/osgeo/index.php/Project_Incubation
(this is the temporary wiki of the OSGeo Foundation unless
the osgeo.org isn't completely ready).

Attached I forward a fresh email from Frank Warmerdam
with more details. Things want to be discussed now.

The board has reviewed a proposed committer agreement based loosely on
the Apache committer agreement. Now we are looking for broader feedback on
it the agreements. Of most interest is feedback from significant code
contributors. The draft agreements are available at:

   http://www.fossgis.de/osgeo/index.php/Contributor_Agreement

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@gclements.plus.com>

Glynn Clements wrote:

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,

You are correct that the above terms mean the foundation could
redistribute the code with any OSI license. However, it would
not automatically be BSD/MIT. The foundation could choose to
distribute it under the GPL.

In the case of GRASS the foundation would still have to license
GRASS as a whole under the GPL since it will not be possible to
get all previous contributors to GRASS to sign the contributor
agreement. However, that would not preclude the foundation from
relicensing new developers from contributors working under the
agreement.

I think the intention of this was so that the foundation would
be able to changes licenses in some cases where it is deemed
useful. For instance, situations like upgrading from GPL v2 to
GPL v3 or perhaps making parts of GRASS LGPL so they can be
shared.

For non GPL projects this stuff doesn't matter much. But for
contributors to GPL projects that feel strongly about keeping
them GPL I can see that it could be a problem. In practice
we (the board) are planning to put in place some safeguards.
Stuff like it requiring a super-majority of the PSC and the
foundation board to relicense code (written into the bylaws),
but that is still no guarantee that code would remain GPL for
ever.

This is definitely the part of the agreement that I have been
most concerned about raising red flags.

I am cc:ing Rich Steele, the foundation counsel who prepared
the agreement. He likely can't reply back to the grass lists,
but I think he and the foundation need to think about this aspect
carefully.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

Hi,

a new FAQ has been written which explains things related
to the proposed Contributor Agreements:

http://www.fossgis.de/osgeo/index.php/Contributor_Agreement

Markus

On Mon, Feb 27, 2006 at 11:53:35PM +0100, Markus Neteler wrote:

Dear GRASS community,

we had a board meeting today in the OSGeo Foundation and
discussed details such as the project incubation. This
is a term borrowed from the Apache Foundation where all
projects wishing to join the foundation have to go through.
It covers basically license issues, a contributor
agreement, project management and the state of the
community (no dead projects are desired). Some draft
notes can be found here:

http://www.fossgis.de/osgeo/index.php/Project_Incubation
(this is the temporary wiki of the OSGeo Foundation unless
the osgeo.org isn't completely ready).

Attached I forward a fresh email from Frank Warmerdam
with more details. Things want to be discussed now.

Best

Markus

Mailing-List: contact discuss-help@mail.osgeo.org; run by ezmlm
X-No-Archive: yes
list-help: <mailto:discuss-help@mail.osgeo.org>
list-unsubscribe: <mailto:discuss-unsubscribe@mail.osgeo.org>
list-post: <mailto:discuss@mail.osgeo.org>
Reply-To: discuss@mail.osgeo.org
Delivered-To: mailing list discuss@mail.osgeo.org
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:sender;
        b=DSykIK5wKCFcV2Q6cMNTHOLzsJV1xnt0pI0IMLpTObXI414nTKC3vf4OOm3cZuPp40A7jOX5fo8ANvCqj1ZxYjtVcc96TVNEktmg0nQFTUKl44B/XOvKw+LrN9nchLY8hnLTqNLbNkB2v0MYPBLnE0fGVuW8rqNZlZkF650gH08=
Date: Mon, 27 Feb 2006 14:52:15 -0500
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
To: OSGeo <discuss@mail.osgeo.org>
Subject: [OSGeo-Discuss] Incubation Committee / Contributor Agreements

Folks,

Today the Board initiated an Incubator Committee. The basic role of the
incubator is to do various sorts of review of projects as they join the
foundation. This includes IP review (is all the code cleanly under an
OS license?), arranging setup or approval of a project steering committee
with appropriate governance, and ensuring that committers sign appropriate
contributor agreements.

Some information on the Incubation Committee can be found at:

  http://incubator.osgeo.org/

At the preceeding board meeting it was decided that all founding projects
would go through the incubation process, not just new projects added in the
future. To that end we (the incubation committee) need one official
representative on the incubation committee from each of the seven founding
projects. I believe that we already have MapGuide Open Source (Bob Bray),
GDAL/OGR (Frank Warmerdam), and GeoServer (Chris Holmes) represented. Other
projects should select a representative for the incubation committee.
Please
contact me with the selected person.

One of the first items of discussion for incubation is the Committer
Agreements. These are legal documents that anyone with CVS/SVN commit
access must sign. Basically they provide the foundation the right to
redistribute the provided code, and to defend the code in case of
litigation.
But it does require the committer and possibly their employer to agree that
they have the right to provide code they are committing to the project.

The board has reviewed a proposed committer agreement based loosely on
the Apache committer agreement. Now we are looking for broader feedback on
it the agreements. Of most interest is feedback from significant code
contributors. The draft agreements are available at:

  http://www.fossgis.de/osgeo/index.php/Contributor_Agreement

Feedback may be to this mailing list, or to the incubation committee via
project representatives there.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

---------------------------------------------------------------------
To unsubscribe, e-mail: discuss-unsubscribe@mail.osgeo.org
For additional commands, e-mail: discuss-help@mail.osgeo.org

a new FAQ has been written which explains things related
to the proposed Contributor Agreements:

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

Hamish wrote:
  > 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?

Hamish,

From a legal point of view, assigning copyright to the "GRASS
Development Team" is a very questionable practice because there
is no such legal entity. Someone could setup a legal corporation
named the "GRASS Development Team" and (arguable) assert copyright
control over such portions of GRASS.

Assigning copyright to the foundation would be one alternative,
and the foundation does have legal standing to own things. However,
for the trust reasons you mention we can see that this might not
be appealing to everyone. That is why we also allow people to
retain copyright ownership of the code as long as a clear right
to redistribute is provided.

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 didn't really follow the ISO9000 point, but I can understand the
point about "what is the benefit to the developer?" in signing. I
have to assume that you are starting with an interest in contributing
to GRASS. If you do, then this becomes one of the requirements of
being a committer.

The agreement should be benefiting the developer in that is provides
a means for the foundation to have legal standing to defend against
legal attacks against GRASS. Having to do this piecemeal as individual
developers would really suck. However, I must admit this could seem
like a rather theoretical benefit since we have not seen much in the
way of legal threats in the OSGeo community to date.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGF, http://osgeo.org

Markus Neteler wrote:

a new FAQ has been written which explains things related
to the proposed Contributor Agreements:

http://www.fossgis.de/osgeo/index.php/Contributor_Agreement

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@gclements.plus.com>

Glynn,

On Mon, Mar 06, 2006 at 10:04:36PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> a new FAQ has been written which explains things related
> to the proposed Contributor Agreements:
>
> http://www.fossgis.de/osgeo/index.php/Contributor_Agreement

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).

Please note that
- it is a *proposed* CLA
- that the conditions for GRASS may be different due to the history
  of the project (I don't know)
- that *I* didn't say that I would sign the proposed CLA

So far I just forwarded discussions between lists.

Personally I am not interested to shrink the GRASS Development
Team.

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@gclements.plus.com>

As the thread subject suggests - it's in discussion.

Markus

Richard Greenwood wrote:

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

I have lurked on this list for long enough to know the contributions
that you make to GRASS. I am curious as to why you do not intend to
sign the CLA. I am not asking this as a 'leading' question. I am quite
ignorant of IP license issues and I would like to understand your
position.

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@gclements.plus.com>

Glynn Clements wrote:

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,

Well, I think this is the information we need. If the CLA is perceived
as a backdoor to undoing the GPL by a significant number of potential
contributors then I think we will just have to alter the CLA to respect
existing licensing.

For projects such as MapGuide OS that sign over all copyright to the
foundation, the option of relicensing would still exist. For project
like GRASS that don't sign over copyright, and more limited CLA would
not provide any mechanism to weaken the GPL.

Note, I am not a big fan of the GPL myself, but I don't think the CLA
ought to be positioned to undermine the GPL.

Of course, I'm not the final authority, but I think we can get the CLA
terms reviewed if Markus and I bring your feedback to the board.

Are there are other GRASS contributors that feel the same about this as
Glynn does?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGF, http://osgeo.org

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
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 8 Mar 2006 02:40:48 +0000
To: Richard Greenwood <richard.greenwood@gmail.com>
Cc: grass developers list <grass5@grass.itc.it>, GRASS user list
<grasslist@baylor.edu>
Subject: Re: [GRASSLIST:10783] Re: [GRASS5] FWD: [OSGeo-Discuss] Incubation
Committee / Contributor Agreements]

Richard Greenwood wrote:

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

I have lurked on this list for long enough to know the contributions
that you make to GRASS. I am curious as to why you do not intend to
sign the CLA. I am not asking this as a 'leading' question. I am quite
ignorant of IP license issues and I would like to understand your
position.

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@gclements.plus.com>

On Tue, 7 Mar 2006, Frank Warmerdam wrote:

Glynn Clements wrote:
> 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,

Well, I think this is the information we need. If the CLA is perceived
as a backdoor to undoing the GPL by a significant number of potential
contributors then I think we will just have to alter the CLA to respect
existing licensing.

For projects such as MapGuide OS that sign over all copyright to the
foundation, the option of relicensing would still exist. For project
like GRASS that don't sign over copyright, and more limited CLA would
not provide any mechanism to weaken the GPL.

Note, I am not a big fan of the GPL myself, but I don't think the CLA
ought to be positioned to undermine the GPL.

Of course, I'm not the final authority, but I think we can get the CLA
terms reviewed if Markus and I bring your feedback to the board.

Are there are other GRASS contributors that feel the same about this as
Glynn does?

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

Best regards,

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

Frank Warmerdam wrote:

Glynn Clements wrote:

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,

Well, I think this is the information we need. If the CLA is perceived
as a backdoor to undoing the GPL by a significant number of potential
contributors then I think we will just have to alter the CLA to respect
existing licensing.

For projects such as MapGuide OS that sign over all copyright to the
foundation, the option of relicensing would still exist. For project
like GRASS that don't sign over copyright, and more limited CLA would
not provide any mechanism to weaken the GPL.

Note, I am not a big fan of the GPL myself, but I don't think the CLA
ought to be positioned to undermine the GPL.

Of course, I'm not the final authority, but I think we can get the CLA
terms reviewed if Markus and I bring your feedback to the board.

Are there are other GRASS contributors that feel the same about this as
Glynn does?

Even though I do not contribute much, I do support Glynn's position very strongly.

Moritz

Hi all.
A professional user view: for us, it is VERY important to have guarantees that
the GRASS code will remain free. The risk of hijacking is a serious threat to
our business.
pc

At 08:48, mercoledì 08 marzo 2006, Roger Bivand has probably written:
...

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.

...
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

On Tue, 7 Mar 2006, Frank Warmerdam wrote:

Glynn Clements wrote:

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,

Well, I think this is the information we need. If the CLA is perceived
as a backdoor to undoing the GPL by a significant number of potential
contributors then I think we will just have to alter the CLA to respect
existing licensing.

For projects such as MapGuide OS that sign over all copyright to the
foundation, the option of relicensing would still exist. For project
like GRASS that don't sign over copyright, and more limited CLA would
not provide any mechanism to weaken the GPL.

Note, I am not a big fan of the GPL myself, but I don't think the CLA
ought to be positioned to undermine the GPL.

Of course, I'm not the final authority, but I think we can get the CLA
terms reviewed if Markus and I bring your feedback to the board.

Are there are other GRASS contributors that feel the same about this as
Glynn does?

Best regards,

I haven't had time to contribute as much as I would, but I also support Glynn's view.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

> 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?

Hamish,

From a legal point of view, assigning copyright to the "GRASS
Development Team" is a very questionable practice because there
is no such legal entity. Someone could setup a legal corporation
named the "GRASS Development Team" and (arguable) assert copyright
control over such portions of GRASS.

I see your point. Maybe we should look at incorporating "GRASS
Development Team" as a non-profit organization. It takes time but isn't
all that hard to do.

Assigning copyright to the foundation would be one alternative,
and the foundation does have legal standing to own things. However,
for the trust reasons you mention we can see that this might not
be appealing to everyone. That is why we also allow people to
retain copyright ownership of the code as long as a clear right
to redistribute is provided.

I think the trust issue will disappear with time as the foundation gets
established. e.g. I don't think folks would think twice about assigning
copyright to the FSF or GNU foundation today if that is what they wanted
to do with their code. The "distance" from the board to the devels on
the ground may not disappear with time, and that worries me -- if the
"shareholder rights" are not clear, people may not contribute.

Assigning co-copyright to yourself & to the mothership is probably a
good idea for any developer. i.e. both parties are free to do with the
code (relicense or reuse) as they please. - I take it if co-copyright
is assigned one party doesn't need the permission of the other to do
whatever it is they want to do with it?

> 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 didn't really follow the ISO9000 point,

as far as I see it, having commit rights restricted to those who have
signed a legal contract does two things:

1) makes managers at corps & govts happy that their "mission critical"
software has controlled entry points, procedures, and chain of command.
In reality I don't think it improves the quality or reduces the chances
of backdoors, but it means the foundation's customers can tick the
no-hippy box when trying to certify their production chain to their
internal auditors.

2) It deflects a large amount of the liability from the foundation to
the developer. The project is protected, but my house isn't, and I can't
expect that the OSGeo or FSF lawyers will come to my defense, even in
the case of a no-fault submarine patent suit. The CLA creates a paper
trail which focuses the blame. Item #5 should be manageable, but item #4
is harder unless everyone has a contract lawyer when they start their
job, submarine patents, etc...

I don't really care about (1) but am willing to do a minimum amount of
work to comply with the needs of large organizations. I do care about (2).

but I can understand the point about "what is the benefit to the
developer?" in signing. I have to assume that you are starting with
an interest in contributing to GRASS. If you do, then this becomes
one of the requirements of being a committer.

There is a balance point between "interest in contributing" and "signing
away your rights". I think for many part-time devels, the interest has
little mass; the software becomes a great pile of code created from
millions of little feather patches - to strech an analogy.

I see signing the agreement benefiting the developer in the sense that
it may accelerate the development of the software by bringing in new
corporate and government users. eg Agreeing to give up your right to
drive on whichever side of the road you please in return for the freedom
to comfortably drive at speed without worry of a head-on collision.
The question is: do the perceived benefits outweigh the perceived
costs..?

Also, I think it is unrealistic to expect a couple of signed-on gate
keepers to QA all the incoming code, especially in the case of GRASS.
There is just too much to understand & review.

The agreement should be benefiting the developer in that is provides
a means for the foundation to have legal standing to defend against
legal attacks against GRASS. Having to do this piecemeal as
individual developers would really suck. However, I must admit this
could seem like a rather theoretical benefit since we have not seen
much in the way of legal threats in the OSGeo community to date.

None the less a very real possibility we should protect ourselves from.
I don't want us to be the test case.

regards,
Hamish

On Tue, Mar 07, 2006 at 10:57:12PM -0700, Michael Barton wrote:

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.

Glynn,

there have been discussions earlier on releasing some libraries
under LGPL (you will remember).

What's your suggestions to deal with the issue mentioned by Michael?

Markus

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
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Wed, 8 Mar 2006 02:40:48 +0000
> To: Richard Greenwood <richard.greenwood@gmail.com>
> Cc: grass developers list <grass5@grass.itc.it>, GRASS user list
> <grasslist@baylor.edu>
> Subject: Re: [GRASSLIST:10783] Re: [GRASS5] FWD: [OSGeo-Discuss] Incubation
> Committee / Contributor Agreements]
>
>
> Richard Greenwood wrote:
>
>>> Personally, I don't intend to sign the proposed CLA.
>>
>> I have lurked on this list for long enough to know the contributions
>> that you make to GRASS. I am curious as to why you do not intend to
>> sign the CLA. I am not asking this as a 'leading' question. I am quite
>> ignorant of IP license issues and I would like to understand your
>> position.
>
> 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@gclements.plus.com>
>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

Hamish wrote:

> Assigning copyright to the foundation would be one alternative,
> and the foundation does have legal standing to own things. However,
> for the trust reasons you mention we can see that this might not
> be appealing to everyone. That is why we also allow people to
> retain copyright ownership of the code as long as a clear right
> to redistribute is provided.

I think the trust issue will disappear with time as the foundation gets
established. e.g. I don't think folks would think twice about assigning
copyright to the FSF or GNU foundation today if that is what they wanted
to do with their code. The "distance" from the board to the devels on
the ground may not disappear with time, and that worries me -- if the
"shareholder rights" are not clear, people may not contribute.

Assigning co-copyright to yourself & to the mothership is probably a
good idea for any developer. i.e. both parties are free to do with the
code (relicense or reuse) as they please. - I take it if co-copyright
is assigned one party doesn't need the permission of the other to do
whatever it is they want to do with it?

Hmm. I'm not sure what you mean by "co-copyright". For joint copyright
(multiple parties hold rights to different parts of a work), all use
requires the consent of all copyright holders.

It's probably easier to just have one copyright holder; if you want to
grant equal rights to another party, give them an unrestricted licence
(or sell them one for a nominal fee; a one-sided grant may be
revocable, whereas "mutual consideration" prevents this).

The standard FSF practice is to have the contributor assign sole
copyright to the FSF, in return for the FSF granting an unrestricted
licence back to the contributor. The advantage of this is that it
makes it easier for the FSF to litigate infringement cases if they are
the sole copyright holder rather than a licensee.

--
Glynn Clements <glynn@gclements.plus.com>

On Wed, Mar 08, 2006 at 10:52:49AM +0100, Markus Neteler wrote:

On Tue, Mar 07, 2006 at 10:57:12PM -0700, Michael Barton wrote:
> 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.

there have been discussions earlier on releasing some libraries
under LGPL (you will remember).

What's your suggestions to deal with the issue mentioned by Michael?

Micheal mentioned BSD and MIT licensed software.
These two licenses are GPL-compatible.
There shouldn't be a major issue, should there?

Best

  Jan
--
Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org
Intevation GmbH : www.intevation.de | Kolab : www.kolab.org
FreeGIS : www.freegis.org | GAV : www.grass-verein.de

Paolo Cavallini wrote:

A professional user view: for us, it is VERY important to have guarantees that
the GRASS code will remain free. The risk of hijacking is a serious threat to
our business.

Regardless of whatever happens with OSGeo, you will always be able to
use existing versions under the GPL. The proposed OSGeo CLA creates
the possibility that future enhancements might not be under the GPL.
But regardless of OSGeo, there's no actual guarantee that future
enhancements will occur, or that they will take GRASS in a direction
which is suitable for your purposes.

As I see it, the main risk of allowing proprietary derivatives is a
risk of "siphoning off" developers and beta testers (aka "users") from
the free version towards a "mostly, but not quite" free version.

IMHO, the biggest risk is with versions which are "free-enough for
most people", e.g. "free for non-commercial use". OpenDWG is probably
a good example; it isn't "Free Software", but it's close enough to
significantly reduce the chances of a genuinely-free alternative being
developed.

--
Glynn Clements <glynn@gclements.plus.com>