New Application: GeoToolkit

[Martin Desruisseaux]

Hello all

I was encouraged by the discussion started Saturday, and feel very sorry that it
slipped recently... Adrian has exposed some general context. I will try to reply
to a few questions that I saw on the archive (I just registered to the list a
few minutes ago).

Daniel issued that DVCS would be like SVN sandbox except that they are private
instead of public. Actually it can be one or the other, at the DVCS user choice.

It has also been pointed that it would make release management more painful
since we would have to merge from several repositories. But merging experience
on DVCS is different than SVN, because of the history presents on every DVCS,
which tecnically allows a repository "A" merged with repository "B" and "C" to
know that repository "B" has been merged with repository "C" at some point of
its history. To make a long story short, we can intuitively imagine that when
the full history is available, there is information that a DVCS can exploit for
applying the merge in a more sophesticated fashion than what a SVN having only
the latest version locally can done.

Anyway back to the talk about Geotoolkit

Given that this fork is a precedent, I understand Frank's questions as
definition of what would be the criterion OSGeo should apply in such situation,
both in the Geotoolkit case and (possibly) in future cases.

So:

1) Does it really have a sufficient community to flourish for some time?

Today it is Geomatys and a few parteners and institutions outside Geomatys. I'm
tempted to answer "yes", or "it will be", but this is based on my own faith. Our
hope is to get as much community as we can, but maybe a different community than
the GeoTools one. We are focusing more on scientifics - myself I'm not really a
computer man, my schollarship is all in science (physic, oceanography) and this
is reflected in the library design. It was also one reason of disagrement (to me
a Coverage is a matrix of measurements, while other GeoTools PMC were more
interrested by the imaging aspect - those two visions lead to different
technical choices).


2) Is it really going to be able to operate in a community based
    manner or is it essentially a geomatys fork?

Today it is a Geomatys initiative. However in order to answer the question about
how we would behave with the community, the most reliable answer would be (like
Adrian suggested) to look at the 7 years of emails archive, especially the first
5 years before the discussions became more difficult. To summarize I believe
that I made a lot of effort on my own free time for adressing Geoserver and uDig
requests on referencing, and for integrating community contributions (except the
"threaded authority factory" contract, but it would be an other discussion on
its own).


3) Does it have technical strengths that make it appropriate for
    OSGeo to promote it?

I'm well aware that this is a very prententious statement from me, but I think
that not many in the GeoTools community put as much effort on documentation and
rigor than me. I claim that Geotoolkit has the best referencing module, with a
long list of bugs fixed (http://jira.codehaus.org/browse/GEOT-2117 contains only
a fraction of them) - some of those bug fixes are difficult enough that they
can't be fixed by the current GeoTools community unless someone is willing to
spend a lot of energy on them. I believe that it also have strenght of metadata
handling, coverage and renderer.


4) Is it going to be able to work within a governance model that is
    going fit with OSGeo's concept of prudent management?

I'm not sure to understand what "prudent management" means?

        Best regards,

                Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Frank Warmerdam]

Martin Desruisseaux wrote:
> Anyway back to the talk about Geotoolkit
>
> Given that this fork is a precedent, I understand Frank's questions as
> definition of what would be the criterion OSGeo should apply in such
> situation, both in the Geotoolkit case and (possibly) in future cases.

Martin,

I raised points of personal interest and concern.  They are by no
means definitive or authoratative.

> So:
>
> 1) Does it really have a sufficient community to flourish for some time?
>
> Today it is Geomatys and a few parteners and institutions outside
> Geomatys. I'm tempted to answer "yes", or "it will be", but this is
> based on my own faith. Our hope is to get as much community as we can,
> but maybe a different community than the GeoTools one.

I think this point will take a bit of time to get a sense on.  As
things gel I think it will be helpful to be able to show a diversity
of interest and contribution.

> 2) Is it really going to be able to operate in a community based
>    manner or is it essentially a geomatys fork?
>
> Today it is a Geomatys initiative. However in order to answer the
> question about how we would behave with the community, the most reliable
> answer would be (like Adrian suggested) to look at the 7 years of emails
> archive, especially the first 5 years before the discussions became more
> difficult. To summarize I believe that I made a lot of effort on my own
> free time for adressing Geoserver and uDig requests on referencing, and
> for integrating community contributions (except the "threaded authority
> factory" contract, but it would be an other discussion on its own).

Part of this is about personalities, part is about approach,
part is about governance model.  I'm not really sure how to evaluate
it, though it will be encouraging to see if some decisions get
made in favor of outside users at the expense of Geomatys priorities.

> 3) Does it have technical strengths that make it appropriate for
>    OSGeo to promote it?
>
> I'm well aware that this is a very prententious statement from me, but I
> think that not many in the GeoTools community put as much effort on
> documentation and rigor than me. I claim that Geotoolkit has the best
> referencing module, with a long list of bugs fixed
> (http://jira.codehaus.org/browse/GEOT-2117 contains only a fraction of
> them) - some of those bug fixes are difficult enough that they can't be
> fixed by the current GeoTools community unless someone is willing to
> spend a lot of energy on them. I believe that it also have strenght of
> metadata handling, coverage and renderer.

Indeed, to me it seems likely that the GeoToolkit georeferencing
(which I understand to be coordinate system transformation and some
additional functionality) is likely to be the gold standard for the
Java community.  For me, this alone could be a sufficient technical
strength to justify the project as one we would want to support and
promote.

> 4) Is it going to be able to work within a governance model that is
>    going fit with OSGeo's concept of prudent management?
>
> I'm not sure to understand what "prudent management" means?

We have obligation with regard to ensuring that contributions are
properly contributed - for instance by ensuring that all committers
sign a contribution agreement and are aware of their obligations.

I also expect project to be able to produce blessed releases which
they believe represent a reasonably solid and vetted level of readiness.

I expect a project to be able to make decisions as a project, and apply
them within the context of the project.

The reason I raise the issue is that I am still unclear on what
governance model is proposed.  I'm also not so clear what committer
means in the context of a DVCS or what a "blessed release" means in this
context.

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

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Arnulf Christl (OSGeo)-2]

Martin Desruisseaux schrieb:
> Hello all
>
> I was encouraged by the discussion started Saturday, and feel very sorry
> that it slipped recently... Adrian has exposed some general context. I
> will try to reply to a few questions that I saw on the archive (I just
> registered to the list a few minutes ago).

Martin,
thanks for joining this list and taking time to talk this out.

<snip>

> 2) Is it really going to be able to operate in a community based
>    manner or is it essentially a geomatys fork?
>
> Today it is a Geomatys initiative. However in order to answer the
> question about how we would behave with the community, the most reliable
> answer would be (like Adrian suggested) to look at the 7 years of emails
> archive, especially the first 5 years before the discussions became more
> difficult. To summarize I believe that I made a lot of effort on my own
> free time for adressing Geoserver and uDig requests on referencing, and
> for integrating community contributions (except the "threaded authority
> factory" contract, but it would be an other discussion on its own).

We have several projects that are dominated by one commercial entity,
this is a reality, whether we like that or not. Real world examples can
show how quick things can devolve without anythign going wrong inside
the project itself (MySQL -> Sun -> Oracle -> ?). So this is nothing
special to start with. But we need to keep it in mind and the general
intention is to keep project unencumbered by commercial interests. If
that works out as it does in the case Autodesk/MapGuide I am just fine
with it.

> 3) Does it have technical strengths that make it appropriate for
>    OSGeo to promote it?
>
> I'm well aware that this is a very prententious statement from me, but I
> think that not many in the GeoTools community put as much effort on
> documentation and rigor than me. I claim that Geotoolkit has the best
> referencing module, with a long list of bugs fixed
> (http://jira.codehaus.org/browse/GEOT-2117 contains only a fraction of
> them) - some of those bug fixes are difficult enough that they can't be
> fixed by the current GeoTools community unless someone is willing to
> spend a lot of energy on them. I believe that it also have strenght of
> metadata handling, coverage and renderer.

>From the little that I understand GeoToolKit seems to have technical
strength. In case of a vote I would give GeoToolKit a +1 on this aspect.
But I am a high orbiter and may have to be corrected by more savvy folks.

> 4) Is it going to be able to work within a governance model that is
>    going fit with OSGeo's concept of prudent management?
>
> I'm not sure to understand what "prudent management" means?
>
>     Best regards,
>
>         Martin

This loops back to the core of Free Software methodologies that OSGeo
adopts. Note that I explicitly do not say "*we* adopt" but *OSGeo
adopts* (that includes Adrian and Jody and Daniel and so on). This is
all about governance again... OSGeo set out to represent geospatial
software projects broadly. If we prescribe a certain governance model
maybe this is not true anymore - if FOSS can also be a viable option
under a different governance model.

We do believe that we know what it takes to make a project really Open
Source, there is plenty of information on the Wiki. We will have to
expand this.

Having one commercial entity in the lead *and* as a dictator on dev does
not go well with governance models that OSGeo has come up with. What
Frank calls "prudent management" is to make sure that what OSGeo has
come up with is actually followed by the projects. The other way is to
start working on the governance models that OSGeo can accept.

I would suggest to ask GeoToolKit to start as an OSGeo labs project.
Then we can figure out in the laboratory what aspects on governance this
will bring us. Maybe there are projects that do not need a strong,
formal PSC (which can always be taken over) but instead has such good
end results that people are happy to follow a single leader regardless
of the bus that may hit her and stop the project.

Best regards,
Arnulf

PS:
I just see that as usual Frank is way faster than me, so just take his
answer and ignore what I think he wanted to say...

--
Arnulf Christl
President OSGeo
http://www.osgeo.org
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Frank Warmerdam a écrit :

> Part of this is about personalities, part is about approach,
> part is about governance model.  I'm not really sure how to evaluate
> it, though it will be encouraging to see if some decisions get
> made in favor of outside users at the expense of Geomatys priorities.

This is true that we have not yet given any proof that outside users would get
their concern adressed adequatly. Our strategy is partially based on technical
tools (DVCS) to workaround a social issue, i.e. give more independance to users
to workaround the fact that as of today, I'm the only one to have write access
on the repository hosted on hg.geotoolkit.org. The question of "who decide what
will be in the release" still a social issue however.

One "way of thinking" that sound strange when we come from a CVS/SVN background
is that every "commit" on two distincts DVCS can be seen as a fork until someone
execute the "merge" command. So if two participants have conflicting priorities,
they can create clones of the repository where each one push their own priority,
keep merging with the "main" (which repository is "main" is purely a convention)
repository which would not contain the solution of any participant, until an
agreement is found, in which case a merge between the two clones is executed and
that merge pushed to the "main" repository.

However this raise an other concern that OSGeo may need to adress. Given that it
is so easy to clone a DVCS, put a few (trivial or not) changes in it and release
that, how a compagny (like Geomatys) which put a huge amount of energy in the
development of that toolkit can be credited for their work? The thing that can
scare Geomatys to the point of staying out of OSGeo would be that someone else
takes Geotoolkit code and push their modified flavor of it as if they were the
main author (they don't need to said that explicitly - I have meet last automn
developers of the gvSig project who were convinced that the GeoTools referencing
module has been wrote by an other compagny), getting contract at the expense of
Geomatys.


>> I'm not sure to understand what "prudent management" means?
>
> We have obligation with regard to ensuring that contributions are
> properly contributed - for instance by ensuring that all committers
> sign a contribution agreement and are aware of their obligations.

With Adrian around us, if we are drifting on this topic our flaw is likely to be
pointed out clearly.


> I also expect project to be able to produce blessed releases which
> they believe represent a reasonably solid and vetted level of readiness.

We plan to perform mountly releases, starting at the begining of June. The code
is actually splitted in two repositories:

   - geotoolkit, which contains code that I ported from GeoTools or elsewhere
     after cleaning. Large part of that code has been running for a while (in
     a different form) in GeoTools.

   - geotoolkit-pending, which contains every else.

My "dictatorial control" applies actually only on "geotoolkit"; I'm not doing
anything on geotoolkit-pending. As time allow, I pickup "geotoolkit-pending"
code that I move to "geotoolkit".


> The reason I raise the issue is that I am still unclear on what
> governance model is proposed.  I'm also not so clear what committer
> means in the context of a DVCS or what a "blessed release" means in this
> context.

I have (for now) dictatorial control on the "geotoolkit" repository which is
hosted on hg.geotoolkit.org web site - only on that repository. I said "for now"
because I would be happy to leave control to other members, providing I'm
confident that they have a wide vision of what is in that repository, a good
understanding of concepts that I consider as mandatory for being allowed to play
in that repository (e.g. affine transforms and the principles published in
Josh's book "Effective Java"), they agree with some principles that make
Geotoolkit distinct to some other projects (e.g. alignment on OGC/ISO standards,
exactitude of data more important than prety pictures even at the sacrifice of a
little bit of performance if we can't avoid to). I may wish to wait longer
before to give write access than what we did in GeoTools.

In case of lack of concensus of a particular topic, we can leave that topic out
of the "main" repository for now as proposed above and get each party to apply
their solution on their clone until we merge them. But of course I have no
experience of such process yet.

Which DVCS would be used for the release still an open question. A conservative
answer would be the "less common dominator", e.g. the "main" repository above
where we have leaved out the controversed topics for the time being.

        Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Frank Warmerdam]

Martin Desruisseaux wrote:

> However this raise an other concern that OSGeo may need to adress. Given
> that it is so easy to clone a DVCS, put a few (trivial or not) changes
> in it and release that, how a compagny (like Geomatys) which put a huge
> amount of energy in the development of that toolkit can be credited for
> their work? The thing that can scare Geomatys to the point of staying
> out of OSGeo would be that someone else takes Geotoolkit code and push
> their modified flavor of it as if they were the main author (they don't
> need to said that explicitly - I have meet last automn developers of the
> gvSig project who were convinced that the GeoTools referencing module
> has been wrote by an other compagny), getting contract at the expense of
> Geomatys.

Martin,

I'm not too sure what to say about the above.  I will note that
Autodesk did not place any special credit requirements into
FDO or MapGuide, nor did Refractions do so for PostGIS (which
has applied, but not been accepted yet into incubation).

To a large extent "open sourcing" means giving up the degree of
control that might be necessary to avoid such situations.  It is
customary for leading developers to depend on their reputation to
give them a strong position on getting contracts related to an open
source project.  I'm not sure what guarantees could be offered.  If
this is very important to Geomatys it might be best if they trademarked
"GeoToolkit", and managed the project more as a corporate open source
project.  This would give a degree of control over the GeoToolkit name
and allow credit control while still operating under an open source
license.

>> I also expect project to be able to produce blessed releases which
>> they believe represent a reasonably solid and vetted level of readiness.
>
> We plan to perform mountly releases, starting at the begining of June.
> The code is actually splitted in two repositories:
>
>   - geotoolkit, which contains code that I ported from GeoTools or
> elsewhere
>     after cleaning. Large part of that code has been running for a while
> (in
>     a different form) in GeoTools.
>
>   - geotoolkit-pending, which contains every else.
>
> My "dictatorial control" applies actually only on "geotoolkit"; I'm not
> doing anything on geotoolkit-pending. As time allow, I pickup
> "geotoolkit-pending" code that I move to "geotoolkit".

Well, this certainly can ensure a carefully reviewed and vetted release.

>> The reason I raise the issue is that I am still unclear on what
>> governance model is proposed.  I'm also not so clear what committer
>> means in the context of a DVCS or what a "blessed release" means in this
>> context.
>
> I have (for now) dictatorial control on the "geotoolkit" repository
> which is hosted on hg.geotoolkit.org web site - only on that repository.
> I said "for now" because I would be happy to leave control to other
> members, providing I'm confident that they have a wide vision of what is
> in that repository, a good understanding of concepts that I consider as
> mandatory for being allowed to play in that repository (e.g. affine
> transforms and the principles published in Josh's book "Effective
> Java"), they agree with some principles that make Geotoolkit distinct to
> some other projects (e.g. alignment on OGC/ISO standards, exactitude of
> data more important than prety pictures even at the sacrifice of a
> little bit of performance if we can't avoid to). I may wish to wait
> longer before to give write access than what we did in GeoTools.

I am getting the impression then that committers will be those who
can update the "master" repository - named geotoolkit in your case.
It seems then that things don't really work that much differently than
the version control approaches I'm accustomed to other than that there
is nicer support for alternate branches without a central location.

In that case - for me - the committer/DVCS issue is essentially answered.
The outstanding issue is primarily once of how governance will work.  For
instance, how will new committers be selected.

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

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Christopher Schmidt-2]

On Tue, May 26, 2009 at 07:47:13PM +0200, Martin Desruisseaux wrote:
> However this raise an other concern that OSGeo may need to adress. Given
> that it is so easy to clone a DVCS, put a few (trivial or not) changes in
> it and release that, how a compagny (like Geomatys) which put a huge amount
> of energy in the development of that toolkit can be credited for their
> work?

I'm not sure how this is OSGeo's job to address? So long as the
licensing terms are met, this is very much the point of Open Source.
See: Linksys routers (sub-par example due to GPL issues, but ignoring
those for the point of the discussion), Red Hat (which is thought of in
many circles to mean "Linux", with no possible alternatives), etc. These
companies do relatively little unique development -- compared to the
open source work they build on -- but combine marketing and packaging to
sell a better product.

It is not in the interest of any foundation to prevent that kind of
thing from happening -- the Apache Foundation hasn't gone to Red Hat and
insisted that it call its web-server products "Red Hat and Apache Linux
Web Server".

Perhaps "OSGeo may need to address" means something other than I think
it does here.

I'll also note that this concern isn't unique to DVCS. OpenLayers has
been forked by the Ordnance Survey, with no effort (That I'm aware of)
to merge. The product (Open Space) is released with relatively little
mention of the fact that OpenLayers is included outside of forums and so
on, and is maintained by a completely seperate group of people. Though
Im not aware of the Ordnance Survey charging for this service, this type
of thing would be exactly what I would expect based on the license that
OpenLayers has chosen -- so long as the copyright holder is acknowledged
in the code or docs, there's no need to be more up front about it.

> The thing that can scare Geomatys to the point of staying out of
> OSGeo would be that someone else takes Geotoolkit code and push their
> modified flavor of it as if they were the main author (they don't need to
> said that explicitly - I have meet last automn developers of the gvSig
> project who were convinced that the GeoTools referencing module has been
> wrote by an other compagny), getting contract at the expense of Geomatys.

Again, how does OSGeo play or not play a role here? That can happen
without a project being an OSGeo project, and the choice of tools and
governance model seems to encourage it to some extent. With dictatorial
style source code control and community governance, you are seeking to
excercise strict control over the codebase. This is reasonable, but is
likely to encourage companies who wish to invest to seek other avenues
for their investment -- whether that's forking or not.  

I don't have a desire to participate in topics of governance strongly
here, but I want to understand why you think that this particular
problem is 'worse' within OSGeo than it would be in any other way. In my
opinion, having a PSC for OpenLayers has prevented possible forking
eneterprises because participants have a multilateral body to appeal to,
rather than a dictatorship run by MetaCarta or its employees.

If you're really worried about someone forking your code and being more
successful with it than you are, then it might be that you're doing
something wrong -- but I don't see how being an OSGeo project would
affect it in either direction.

Best Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Martin Desruisseaux a écrit :
> (...snip...) I claim that Geotoolkit has the best
> referencing module, with a long list of bugs fixed (...snip...)

Just realized that my sentence may sound like "the best referencing module in
the world" while actually I was thinking at a much smaller scale - my mind was
in mode "competition with a few projects close to us" and didn't realized that
my wording didn't properly limited the scope to a few Java projects.

        Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Frank Warmerdam a écrit :
> I am getting the impression then that committers will be those who
> can update the "master" repository - named geotoolkit in your case.
> It seems then that things don't really work that much differently than
> the version control approaches I'm accustomed to other than that there
> is nicer support for alternate branches without a central location.

I think that this is basically that. Compared to SVN, the difference is that
what we call the central repository is purely a matter of convention and can
change at anytime, how often we wish. Whatever peoples accept to follow our
convention or not depends on their will, not anymore on the physical reality of
a repository being hoster in one place. The community could choose to ignore the
repository that we call "geotoolkit" and build from a clone maintained by
someone else, at the point where the binary download we provide are considered
irrelevant.

        Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Christopher Schmidt a écrit :

> On Tue, May 26, 2009 at 07:47:13PM +0200, Martin Desruisseaux wrote:
>> The thing that can scare Geomatys to the point of staying out of
>> OSGeo would be that someone else takes Geotoolkit code and push their
>> modified flavor of it as if they were the main author (they don't need to
>> said that explicitly - I have meet last automn developers of the gvSig
>> project who were convinced that the GeoTools referencing module has been
>> wrote by an other compagny), getting contract at the expense of Geomatys.
>
> Again, how does OSGeo play or not play a role here? That can happen
> without a project being an OSGeo project, and the choice of tools and
> governance model seems to encourage it to some extent. With dictatorial
> style source code control and community governance, you are seeking to
> excercise strict control over the codebase. This is reasonable, but is
> likely to encourage companies who wish to invest to seek other avenues
> for their investment -- whether that's forking or not.  

Our concerns are based on past experiences. The credit received outside a small
circle of developers is often more a factor of communication power than work
effectively done. This is part of the rules of Open Source, but I was thinking
about something slightly different. Could OSGeo play the role of someone that
"equilibrate the power" between the projects that it host? What I try to express
by "equilibrating" is to make sure that, if someone ask for an improvement in
one particular area of a project, OSGeo know and take in account the fact that
this area of project "A" actually come from project "B". It doesn't mean to give
automatically the contract to "B", but to avoid the situation were that fact was
simply unknown.

To be really frank, my sentence was worded like a general case scenario but my
real concern was specifically about the GeoTools - Geotoolkit relationship. It
may be me who is not yet appeased as I should - and my concern is not about
preventing GeoTools from recycling code (quite the opposite I would feel honored
if it happen). It is about consciensiousness that we don't have the same
marketing power, that (I believe) we can be recognized on the merit of the
library itself, but this effort can be vanished if our work is absorbed by
GeoTools to the point of making us invisible.


> If you're really worried about someone forking your code and being more
> successful with it than you are, then it might be that you're doing
> something wrong -- but I don't see how being an OSGeo project would
> affect it in either direction.

I will answer this question in a private email, not because it is impolite in
any way but because it involve strategic concerns on our side.

        Regards,

                Martin

_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Christopher Schmidt-2]

On Tue, May 26, 2009 at 10:08:29PM +0200, Martin Desruisseaux wrote:

> Christopher Schmidt a écrit :
> >On Tue, May 26, 2009 at 07:47:13PM +0200, Martin Desruisseaux wrote:
> >>The thing that can scare Geomatys to the point of staying out of
> >>OSGeo would be that someone else takes Geotoolkit code and push their
> >>modified flavor of it as if they were the main author (they don't need to
> >>said that explicitly - I have meet last automn developers of the gvSig
> >>project who were convinced that the GeoTools referencing module has been
> >>wrote by an other compagny), getting contract at the expense of Geomatys.
> >
> >Again, how does OSGeo play or not play a role here? That can happen
> >without a project being an OSGeo project, and the choice of tools and
> >governance model seems to encourage it to some extent. With dictatorial
> >style source code control and community governance, you are seeking to
> >excercise strict control over the codebase. This is reasonable, but is
> >likely to encourage companies who wish to invest to seek other avenues
> >for their investment -- whether that's forking or not.  
>
> Our concerns are based on past experiences. The credit received outside a
> small circle of developers is often more a factor of communication power
> than work effectively done. This is part of the rules of Open Source, but I
> was thinking about something slightly different. Could OSGeo play the role
> of someone that "equilibrate the power" between the projects that it host?
> What I try to express by "equilibrating" is to make sure that, if someone
> ask for an improvement in one particular area of a project, OSGeo know and
> take in account the fact that this area of project "A" actually come from
> project "B". It doesn't mean to give automatically the contract to "B", but
> to avoid the situation were that fact was simply unknown.

I don't feel that this is the responsibility of OSGeo. I would be
strongly against OSGeo playing this role with any projects.  

> To be really frank, my sentence was worded like a general case scenario but
> my real concern was specifically about the GeoTools - Geotoolkit
> relationship. It may be me who is not yet appeased as I should - and my
> concern is not about preventing GeoTools from recycling code (quite the
> opposite I would feel honored if it happen). It is about consciensiousness
> that we don't have the same marketing power, that (I believe) we can be
> recognized on the merit of the library itself, but this effort can be
> vanished if our work is absorbed by GeoTools to the point of making us
> invisible.

Again, I don't think that preventing this is the role of OSGeo. Ensuring
that projects are meeting the requirements of the license of places that
they obtain code from is a perfectly reasonable task -- though generally
I'm completely in support of leaving this up to the projects -- but
stepping in to say "You need to give GeoToolkit credit for code that you
are using which was written for the GeoToolkit project" would just be
silly. The copyright notices are likely required to be in place, and
anything beyond that would be well beyond the role of OSGeo as a
foundation.

If you don't want people to reuse your code -- again, in accordance with
the license -- then don't make it open source. (And if you want them to
follow a more strict set of rules, you might choose to create a more
strict license -- though without a nice lawyer behind you, you run a
pretty significant chance of that making it 'not open source'.)

> >If you're really worried about someone forking your code and being more
> >successful with it than you are, then it might be that you're doing
> >something wrong -- but I don't see how being an OSGeo project would
> >affect it in either direction.
>
> I will answer this question in a private email, not because it is impolite
> in any way but because it involve strategic concerns on our side.

If it's not relevant to OSGeo as a whole, there's no need. My point here
was to understand how this particular set of statements might affect
other projects -- not to understand how GeoToolkit intends to do
anything, specifically. I want to make sure I understand possible
concerns about why a project might not want to be incubated into OSGeo.
Your previous email indicated that you had such a concern, but it seems
that your concerns here are irrelevant of whether you become an OSGeo
Project or not, so I'm good.

Thanks,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Christopher Schmidt a écrit :
> Again, I don't think that preventing this is the role of OSGeo. Ensuring
> that projects are meeting the requirements of the license of places that
> they obtain code from is a perfectly reasonable task -- though generally
> I'm completely in support of leaving this up to the projects -- but
> stepping in to say "You need to give GeoToolkit credit for code that you
> are using which was written for the GeoToolkit project" would just be
> silly. The copyright notices are likely required to be in place, and
> anything beyond that would be well beyond the role of OSGeo as a
> foundation.

But this is the issue that I was about to develop in an other mail...

There is no "(C) Copyright Geotoolkit" or "(C) Copyright Geomatys" statement, at
least not until very recently. They were only "(C) Copyright OSGeo" statements.

In the course of GeoTools incubation, we choose to get every contributors to
give their copyright to OSGeo in order to resolve a legal issue ("GeoTools" was
a non-existent legal entity) and for making easier an enventual upgrade of the
licence, from LGPL 2.1 to LGPL 3.0. Adrian and myself were especially strong
supporters of this approach.

We are not asking for credit statement. But until yesterday they were even no
"Copyright Geomatys" statement, nothing else than "Copyright OSGeo"!

If Geotoolkit is incubated, I really wish to continue that way - to keep
licensing issues simplier and in good faith toward GeoTools, for allowing code
exchange with homogeneus licence. But this approach makes us more vulnerable to
the concern that I have pointed. Because we volontary choosed to give all
copyright to OSGeo, I though that hoping for some form of "equilibre" from OSGeo
was not unfair.

If Geotoolkit is not incubated, we will protect ourself by adding "(C) Copyright
Geomatys" below "(C) Copyright OSGeo" in every Geotoolkit classes. Actually we
already took this move yesterday when we realized that it may become necessary.
However if we do so and given that there is material in Geotoolkit which is
probably of interest to GeoTools, then the GeoTools licence homogenity is
broken. GeoTools would be in their right mind to react by adding themself "(C)
Copyright OpenGeo" or similar statement, which would compromise the hard work we
did during GeoTools incubation.

This issue may become totally irrelevant in two years if each project get enough
of own identity. But for now there is a window of vulnerability and - if we play
by the rule we were hoping to play inside OSGeo - there would be *no* copyright
statement for protecting our work.

The alternative would be that, if OSGeo accepts to incubate Geotoolkit, is also
accepts that we break the policy that we have setup ourself with GeoTools and
add "(C) Geomatys" statements in all our work. But be aware that we avoided that
until yesterday because I though that it would be unfair toward GeoTools (even
if I'm the main author of all the code in the "geotoolkit" repository).

A compromise could be that we accumulate "(C) Geomatys" during a year and
transfer the copyright to OSGeo once a year. This is not what we did since the
incubation of GeoTools (we were giving copyright directly).

        Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Christopher Schmidt-2]

On Tue, May 26, 2009 at 11:08:23PM +0200, Martin Desruisseaux wrote:

> Christopher Schmidt a écrit :
> >Again, I don't think that preventing this is the role of OSGeo. Ensuring
> >that projects are meeting the requirements of the license of places that
> >they obtain code from is a perfectly reasonable task -- though generally
> >I'm completely in support of leaving this up to the projects -- but
> >stepping in to say "You need to give GeoToolkit credit for code that you
> >are using which was written for the GeoToolkit project" would just be
> >silly. The copyright notices are likely required to be in place, and
> >anything beyond that would be well beyond the role of OSGeo as a
> >foundation.
>
> But this is the issue that I was about to develop in an other mail...
>
> There is no "(C) Copyright Geotoolkit" or "(C) Copyright Geomatys"
> statement, at least not until very recently. They were only "(C) Copyright
> OSGeo" statements.
>
> In the course of GeoTools incubation, we choose to get every contributors
> to give their copyright to OSGeo in order to resolve a legal issue
> ("GeoTools" was a non-existent legal entity) and for making easier an
> enventual upgrade of the licence, from LGPL 2.1 to LGPL 3.0. Adrian and
> myself were especially strong supporters of this approach.
>
> We are not asking for credit statement. But until yesterday they were even
> no "Copyright Geomatys" statement, nothing else than "Copyright OSGeo"!
>
> If Geotoolkit is incubated, I really wish to continue that way - to keep
> licensing issues simplier and in good faith toward GeoTools, for allowing
> code exchange with homogeneus licence. But this approach makes us more
> vulnerable to the concern that I have pointed. Because we volontary choosed
> to give all copyright to OSGeo, I though that hoping for some form of
> "equilibre" from OSGeo was not unfair.

The reason for copyright assignment seems to me primarily to be the
option of re-licensing the code at some point in the future. As a
developer, I see no particular reason to make it easier for another
project to take my code, and relicense it in any way they see fit. I
feel that maintaining a seperate copyright statement is simply
protection of the IP you've created, ensuring that it is used in the way
that you want to see it used. (Of course, GeoMatys could presumably
grant a license to GeoTools for code that is their copyright to
relicense if they thought that neccesary -- so long as GeoMatys is the
primary copyright holder for the new code.)

> If Geotoolkit is not incubated, we will protect ourself by adding "(C)
> Copyright Geomatys" below "(C) Copyright OSGeo" in every Geotoolkit
> classes. Actually we already took this move yesterday when we realized that
> it may become necessary. However if we do so and given that there is
> material in Geotoolkit which is probably of interest to GeoTools, then the
> GeoTools licence homogenity is broken. GeoTools would be in their right
> mind to react by adding themself "(C) Copyright OpenGeo" or similar
> statement, which would compromise the hard work we did during GeoTools
> incubation.

Presuambly the PSC would be against such a decision. OpenLayers
incorporates copyrighted material from other open source projects with
appropriate credit, but that doesn't mean that every contributor is
considered a copyright holder. I can't imagine that GeoTools would go
through the work to assign copyright to OSGeo and then *stop* doing so
for a reason like this.

In the end, the project PSC will presumably make the decision that is
best for the project. OSGeo's role is to ensure that decision meets a
certain set of criteria; nothing you've discussed yet seems to violate
it, and I would see no reason for OSGeo to step in to 'control' project
governance based on your concerns.

>
> This issue may become totally irrelevant in two years if each project get
> enough of own identity. But for now there is a window of vulnerability and
> - if we play by the rule we were hoping to play inside OSGeo - there would
> be *no* copyright statement for protecting our work.

That's correct. By choosing to grant your copyright to OSGeo, you make
it so that the code is easily 'copyable' across OSGeo copyrighted
projects with no neccesity to 'credit' anyone else.

An option here is clearly to *not* make that choice for
Geomatys/GeoToolkit -- as you've already done -- even with OSGeo
incubation.

> The alternative would be that, if OSGeo accepts to incubate Geotoolkit, is
> also accepts that we break the policy that we have setup ourself with
> GeoTools and add "(C) Geomatys" statements in all our work. But be aware
> that we avoided that until yesterday because I though that it would be
> unfair toward GeoTools (even if I'm the main author of all the code in the
> "geotoolkit" repository).

I don't think that there is any reason it's unfair to place a copyright
statement on work that is yours. Clearly, it is your legal
responsibility to continue to credit OSGeo and the GeoTools project
for data/code from that project, but beyond that, it is your IP,
presumably (as a derivative work -- so yours, and under the terms of the
GeoTools license as well), and there is no reason not to put the
appropriate copyright statement on the code.

> A compromise could be that we accumulate "(C) Geomatys" during a year and
> transfer the copyright to OSGeo once a year. This is not what we did since
> the incubation of GeoTools (we were giving copyright directly).

That would be a reasonable path to take, and it wouldn't be the first
time some non-trivial amount of existing code had copyright granted to
OSGeo. However, it seems clear to me that one way to alleviate this
potential concern is simply to maintain copyright of the code.

OpenLayers is currently "Copyright MetaCarta". We deal with credit in a
number of ways: via our CLA lists (http://trac.openlayers.org/wiki/CLA),
our contributors file
(http://svn.openlayers.org/trunk/openlayers/doc/authors.txt), etc.
In our builds, we include license information for incorporate
components:
 
  http://svn.openlayers.org/trunk/openlayers/build/license.txt

It seems to me like it would make sense to have GeoTools encourage this
type of credit, *regardless* of the fork.

However, I maintain that this is still not an OSGeo problem. It may be a
GeoMatys problem -- and I maintain that would likely be the case
regardless. GeoTools is the de facto library in this space, and
competing/setting GeoToolkit apart will be hard. You mention 'getting
contracts' several times, but I think that this aspect of the project is
really not within the realm of interest of OSGeo. The GeoTools PSC seems
to be open to working together to ensure the success, to what extent is
possible, of both projects, and I don't see any evidence that there
needs to be a 'hardship' attitude here. Work together, find your
relative strengths and weaknesses, and work to improve them all around,
and the result will likely be beneficial for everyone.

Starting off by saying "How can we make sure GeoTools doesn't use our
code?" seems like stepping off on the wrong foot.

Best Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator

[Martin Desruisseaux]

Christopher Schmidt a écrit :
> The reason for copyright assignment seems to me primarily to be the
> option of re-licensing the code at some point in the future. As a
> developer, I see no particular reason to make it easier for another
> project to take my code, and relicense it in any way they see fit.

Just for information, the option of re-licensing were one reason why we did
copyright assignment in order to get the option to upgrade from LGPL 2.1 to LGPL
3.0.

However the coypright assignement that every GeoTools contributor signed,
explicitly states that if OSGeo re-license GeoTools, then it can only be toward
an other Open Source license.


> Starting off by saying "How can we make sure GeoTools doesn't use our
> code?" seems like stepping off on the wrong foot.

It has never been my intend in any of my email. If I wrote a sentence saying
that, then it was a broken English from me. In defense or my faith in Open
Source, I would point out again the 7 years of email archive on GeoTools.

The concern from the begining was "how to ensure that the referencing code (for
example) is known as geotoolkit work (or derivative work)" (assuming that code
get incorporated in GeoTools) given that they were until yesterday no copyright
statement other than "OSGeo". They were two reasons why I wanted to avoid adding
such statement:

   - Avoid making the relicensing to LGPL 3 harder.

   - For preaching by example. Advantage of "Copyright OSGeo" is
     that it is much easier to ask external contributors to give
     their copyright to OSGeo (under the same condition as we did
     for GeoTools - see above) than asking them to give it to any
     proprietary compagny. And it is yet easier to ask them to
     trust OSGeo is we do the same ourself.

As said in previous email, possible approaches include:

   - Keeping "(C) Geomatys" forever (would violate the above goals)
   - Keeping "(C) Geomatys" for one year (starting a new cycle every year)
   - Credits in some pages like the ones you mentioned.

        Martin
_______________________________________________
Incubator mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/incubator