You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/07/17 17:14:02 UTC
Exploring possible contribution
Hello all
I would like to introduce myself: My name is Martin Desruisseaux. I'm
the chair of the GeoAPI working group at OGC (Open Geospatial
Consortium) and the maintainer of the "core" of the Geotoolkit.org
(abridged Geotk) project. Years ago I was one of the GeoTools 2 project
initiators. In particular, I'm the author of the referencing engine
(coordinate transformations). I have also done a few contributions to
ISO 19111 and 19115, and I'm somewhat used to OGC meetings.
We were wondering if the Apache SIS and Geotk projects could gain mutual
benefit in merging selected portions of them. We were considering for a
while to change the license (currently LGPL 2.1) to the Apache or BSD
license. It may be possible if OSGeo agree.
The Apache project would gain a pool of more than 230000 lines of clean
code (plus 520000 lines of code in the "pending" area) in which they can
select the parts they have interest in. The Geotk project would get a
wider community, which is missing to us.
The Geotk project (http://www.geotoolkit.org/) features one of the most
powerful referencing engine available in open-source. It provides also
an extensive metadata support (ISO-19115) close to the European
regulation (INSPIRE). There is bridges between those metadata and some
formats like NetCDF.
Geotk is an implementation of GeoAPI 3.0 (http://www.geoapi.org/).
GeoAPI is a set of interfaces derived from OGC/ISO standards. The aim is
to provide for geospatial applications what JDBC interfaces provide for
database applications: an isolation layer allowing the same applications
to run with different libraries. In addition to Geotk, GeoAPI
implementations include wrappers around the NetCDF and the C/C++ Proj.4
libraries. GeoAPI provides also a conformance test suite which include
parts of the Geospatial Integrity of Geoscience Software
(http://www.epsg.org/gigs.html) tests. Using those interfaces as an
isolation, it is possible to keep large parts of Geotk as internal
mechanic and expose mostly the interfaces as committed API.
Where the project would be hosted (current servers vs Apache servers),
which part of the project would be eventually hosted by Apache, which
package name, integration with existing SIS code are all open questions.
With this email, I'm just exploring if there is any interest. The main
requests I would have on my side are:
* Distributed Version Control (DVS) like Mercurial or Git rather than
centralized one like SVN, because we may which to maintain a branch
on our side (while doing merges, of course).
* A commit right policy with emphasis on quality (e.g. complete
javadoc, new code does not duplicate existing code, equals/hashCode
consistency, etc.), maybe using branches with DVS for pending works.
I would like to known if there is any though/interest...
Regards,
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Thanks for the pointer Martin!
Cheers,
Chris
On Jul 21, 2012, at 5:06 AM, Martin Desruisseaux wrote:
> Hello all
>
> Just for letting peoples known, the request to OSGeo board for re-licensing Geotoolkit.org from LPGL to Apache can be followed there. Not many reply yet, but initial contact seem encouraging:
>
> http://lists.osgeo.org/pipermail/board/2012-July/009857.html
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Jul 30, 2012, at 7:59 AM, Martin Desruisseaux wrote:
> Hello all
>
> The OSGeo foundation had put our request on their agenda for their next meeting, to be hold in August 9. We clarified that the agreement we signed with OSGeo was intended to allow us to distribute our contribution under the Apache 2 license. But there is different opinions about what the wording actually means. For this reason we have to wait.
OK to clarify, OSGeo will discuss this issue at their board meeting on 8/9?
>
> In the main time, do peoples wish to discuss about the project structure (e.g. Git, branches, Maven modules organisation, developer guide)? It would probably keep us busy until de OSGeo meeting.
Sure feel free to start threads here on sis-dev@ to discuss your thoughts.
> In the event where their answer would be negative, then well... SIS may have gained the structure for an ambitious project.
Sure, that's fine. And in the end, you, Martin, individually (and others from GeoTK) may decide to simply contribute new code
or contributions not already covered or at dispute with OSGeo here in Apache SIS. To begin there, you can sign an Apache
Individual Contributor License Agreement (ICLA) here:
http://www.apache.org/licenses/icla.txt
Then you could start the process of examining Apache SIS and our SVN:
http://svn.apache.org/repos/asf/incubator/sis/trunk
and our JIRA:
https://issues.apache.org/jira/browse/SIS
And then deciding (a) what existing issues you'd like to work on; and/or (b) what new issues you'd like to file and/or work on
and then proceeding by filing JIRA issues, submitting patches, and having fun! :)
>
> I guess that we need to sign the agreement at http://www.apache.org/licenses/software-grant.txt and send it to someone (who?)
The organization that owns the copyright (or set of individuals that own the copyright) would perform a software grant, but
that would be for the code in question (which appears to be the GeoTK code). A Software Grant is not needed for new ideas,
contributions, or work by you (or others) individually -- that is covered by the Apache ICLA above.
HTH!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
The OSGeo foundation had put our request on their agenda for their next
meeting, to be hold in August 9. We clarified that the agreement we
signed with OSGeo was intended to allow us to distribute our
contribution under the Apache 2 license. But there is different opinions
about what the wording actually means. For this reason we have to wait.
In the main time, do peoples wish to discuss about the project structure
(e.g. Git, branches, Maven modules organisation, developer guide)? It
would probably keep us busy until de OSGeo meeting. In the event where
their answer would be negative, then well... SIS may have gained the
structure for an ambitious project.
I guess that we need to sign the agreement at
http://www.apache.org/licenses/software-grant.txt and send it to someone
(who?)
Martin
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
I will follow your recommendation, thanks for the tip. I will also send
a new mail to the OSGeo board asking clarification. Most OSGeo projects
run under a "Contributor Agreement" that do not give ownership to OSGeo.
I think that GeoTools is the only project having a "Copyright
Assignment". It was done on a volunteer basis and in good faith, I don't
think it would be in OSGeo philosophy that it resulted in less rights
than the agreement running other projects.
This issue is concerning mostly the library foundation (metadata,
referencing, coverage). From that point, we wrote most of the remaining
(renderer engine, web services, desktop application, etc.) outside the
GeoTools project, so those code are not contentious provided we rewrite
some parts of them. The web services cover a spectrum which I think is
not commonly found in a single project (map, coverage, sensor,
catalog...), and is among the early libraries to support some features
of interest for the scientific community like multi-dimensional coverages.
Cheers
Martin
Le 28/07/12 05:50, Mattmann, Chris A (388J) a écrit :
> This is a great question -- my read is similar to that of the OSGeo board member (that the agreement you signed
> does not remove your original broad rights as the progenitors of the work and thus you are able to relicense the
> work) but IANAL.
>
> Kevan Miller on this list is an excellent legal resource -- hopefully he chimes in. I would also recommend
> taking this question to the Apache legal-discuss@ list (which includes lawyers). I would include this thread
> for context, and the pertinent question you're asking -- i.e., given the above, are you able to contribute the
> GeoTK code to Apache SIS?
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Jul 27, 2012, at 10:35 AM, Martin Desruisseaux wrote:
> Hello all
>
> The discussion on OSGeo about re-licensing is continuing. Up to date we got only one reply from a board member. He expressed his personal interpretation (not a formal board position). I would like to know if anyone familiar with those considerations could emit an advice about whatever the cited paragraph allows re-licensing?
>
>> With respect to your point that you (and perhaps other Geotoolkit
>> contributors) were originally responsible for much of the code in
>> question I did go back to the contribution agreement:
>>
>> http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf
>>
>> I highlight:
>>
>> "The Foundation hereby grants the Contributor the nonexclusive,
>> perpetual, irrevocable, worldwide, royaltyfree,
>> license to use, copy, prepare derivative works of, publicly display or
>> perform, and distribute the Submission."
>>
>> I*perceive* this as granting back to the original contributor very broad
>> rights and I would be inclined to treat this as including the right to
>> re-license the original original contribution. That is, I believe it is
>> already within your rights to offer code you personally contributed
>> under this agreement under other licenses.
>>
>> This would not apply to code from other contributors without either
>> their specific permission or with permission of the board (hopefully
>> after a positive recommendation from the Geotools PSC).
>
> Alternatively, does copyright assignments prevent the contributors to re-license their code base (of course without the work of other contributors) in the state it was before the assignment? In the particular case of the code that we would like to offer, the copyright assignment and the creation of the "Geotidy" project were close together, so we don't think that we would lost much work. This is not something we want to do - the discussion are still going -, but we would like to know the possibilities.
This is a great question -- my read is similar to that of the OSGeo board member (that the agreement you signed
does not remove your original broad rights as the progenitors of the work and thus you are able to relicense the
work) but IANAL.
Kevan Miller on this list is an excellent legal resource -- hopefully he chimes in. I would also recommend
taking this question to the Apache legal-discuss@ list (which includes lawyers). I would include this thread
for context, and the pertinent question you're asking -- i.e., given the above, are you able to contribute the
GeoTK code to Apache SIS?
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Kevan Miller <ke...@gmail.com>.
On Jul 27, 2012, at 1:35 PM, Martin Desruisseaux wrote:
> Hello all
>
> The discussion on OSGeo about re-licensing is continuing. Up to date we got only one reply from a board member. He expressed his personal interpretation (not a formal board position). I would like to know if anyone familiar with those considerations could emit an advice about whatever the cited paragraph allows re-licensing?
>
>> With respect to your point that you (and perhaps other Geotoolkit
>> contributors) were originally responsible for much of the code in
>> question I did go back to the contribution agreement:
>>
>> http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf
>>
>> I highlight:
>>
>> "The Foundation hereby grants the Contributor the nonexclusive,
>> perpetual, irrevocable, worldwide, royaltyfree,
>> license to use, copy, prepare derivative works of, publicly display or
>> perform, and distribute the Submission."
>>
>> I*perceive* this as granting back to the original contributor very broad
>> rights and I would be inclined to treat this as including the right to
>> re-license the original original contribution. That is, I believe it is
>> already within your rights to offer code you personally contributed
>> under this agreement under other licenses.
>>
>> This would not apply to code from other contributors without either
>> their specific permission or with permission of the board (hopefully
>> after a positive recommendation from the Geotools PSC).
>
> Alternatively, does copyright assignments prevent the contributors to re-license their code base (of course without the work of other contributors) in the state it was before the assignment? In the particular case of the code that we would like to offer, the copyright assignment and the creation of the "Geotidy" project were close together, so we don't think that we would lost much work. This is not something we want to do - the discussion are still going -, but we would like to know the possibilities.
In my non-lawyer, personal opinion -- the copyright of code contributions under this agreement has been assigned to the Foundation. And the contributors are no longer able to assign a new license to these contributions. The foundation is giving contributors the "license to use, copy etc". However, I don't think this gives the contributors the right to relicense.
The legal affairs committee can be a bit reticent to dispense legal advice outside of the ASF. So, I'm not sure how they'll respond. I'll see what I can do…
--kevan
--kevan
>
> Thanks,
>
> Martin
>
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
The discussion on OSGeo about re-licensing is continuing. Up to date we
got only one reply from a board member. He expressed his personal
interpretation (not a formal board position). I would like to know if
anyone familiar with those considerations could emit an advice about
whatever the cited paragraph allows re-licensing?
> With respect to your point that you (and perhaps other Geotoolkit
> contributors) were originally responsible for much of the code in
> question I did go back to the contribution agreement:
>
> http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf
>
> I highlight:
>
> "The Foundation hereby grants the Contributor the nonexclusive,
> perpetual, irrevocable, worldwide, royaltyfree,
> license to use, copy, prepare derivative works of, publicly display or
> perform, and distribute the Submission."
>
> I*perceive* this as granting back to the original contributor very broad
> rights and I would be inclined to treat this as including the right to
> re-license the original original contribution. That is, I believe it is
> already within your rights to offer code you personally contributed
> under this agreement under other licenses.
>
> This would not apply to code from other contributors without either
> their specific permission or with permission of the board (hopefully
> after a positive recommendation from the Geotools PSC).
Alternatively, does copyright assignments prevent the contributors to
re-license their code base (of course without the work of other
contributors) in the state it was before the assignment? In the
particular case of the code that we would like to offer, the copyright
assignment and the creation of the "Geotidy" project were close
together, so we don't think that we would lost much work. This is not
something we want to do - the discussion are still going -, but we would
like to know the possibilities.
Thanks,
Martin
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 25/07/12 19:45, Mattmann, Chris A (388J) a écrit :
>> My thought was that if GeoTools goes to Eclipse license, this is one more argument for convincing OSGeo to give formal approval for Geotoolkit.org going to Apache license.
> I hope the 2nd outcome of that to happen, but in all honesty, I don't think it's implied by the first -- EPL is different from ALv2. The fact that Eclipse and Apache
> are both *foundations* so they provide a legal framework, community, environment, governance model, set of accepted licenses, etc. so that's similar, but it
> doesn't imply they are equivalent.
Maybe I was wrong to think that Eclipse and Apache license was
relatively close. On our side, we noticed that many users are more
familiar with Apache license than other licenses. However in my about
thought, I was thinking more about charter than legal concerns. If OSGeo
allows GeoTools re-licensing to Eclipse, with a code base containing
hundred of thousands of lines that we wrote, then it seems to me that
OSGeo as a neutral organisation should have no objection with Geotoolkit
re-licensing to Apache.
> I wouldn't see how -- in contrast, the small business could more easily incorporate the changes from the upstream Apache code in a lot easier fashion
> than they would be able to with EPL and similar (weak) copyleft software since the ALv2 has no downstream restrictions on redistribution, packaging, or commercialization.
In the particular case of the companies having vested interests in this
debate, I think it actually make no difference because the license was
the same: LGPL. But for the general case I agree.
> we are interested in building the best Apache Licensed, version 2,
> geospatial toolkit out there -- we've done a good job of community building, have a decent code base to build from, and the sky is the limit
> and we are looking for people with similar goals! ;)
Sound very encouraging :-)
> Understood, but I would encourage the Geo Server, Geo Tools (upstream) and other projects considering Eclipse to actually ask questions of e.g.,
> the Apache board (feel free to CC me) and other Apache sages b/c I think there are some misperceptions of what Eclipse is providing (and potentially
> even Apache) that may wrongly influence their decision as to where to go. Whether they decide to take my advice on this or not, is up to them, but
> it's worth trying. I'm happy to facilitate any side of the Apache end of this as possible.
I understand that its look like in the best Apache SIS interest. But on
our side, it would put ourselves in a delicate situation regarding the
Eclipse foundation. They also worked hard in building their community
and actually LocationTech and GeoTools/Geoserver are in touch for a long
time (I don't know how long exactly). Anyway I think that they are aware
of this possibility, since I gave the URL to this thread on the GeoTools
mailing list when I posted our request.
There is an other issue: we forked from the GeoTools project 4 years ago
because we had difficulties to conciliate our point of views. I
mentioned the "scientific" versus "mass-market" issue previously. There
is also different points of view about what is a standard: we put larger
effort in trying to work with official standards, while the other point
of view is to consider that de-facto standards matter more (GeoJson is a
good example). Sometime official standards are in contradiction with
common practices. Sometime the contradiction is between geographers and
developers practices (example: the axis order debate). While we try to
conciliate all those points of view, sometime it becomes difficult when
the priorities are too far apart. Apparently the concerns that we had 4
years ago are still present in today GeoTools code base. We would feel
uncomfortable if Apache SIS were basically becoming a new home for
GeoTools - while of course the decision does not belong to us.
Sometime, merging too many projects may cause more weight than
innovation. GeoTools already has its community, the project is well
known and widespread, they have a long history and can not change
lightly. Maybe a bit of diversity would be in the community interest.
Note that separated projects can be beneficial to everyone: when we
forked 4 years ago, in reaction GeoTools did a remarkable reworking of
their web site.
> I would also point out that IbM, Google, Oracle, etc., also
> allow their developers to contribute to Apache tons -- it's not just Eclipse. Those big companies don't discriminate as to what foundations they allow their developers
> to participate in -- at the ASF we are all individuals here, so there are not corporations having seats on a board, or having people on projects -- at Apache,
> merit is earned individually.
Understood. Thanks for clarifying.
Cheers
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marin,
On Jul 25, 2012, at 10:21 AM, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 25/07/12 17:28, Mattmann, Chris A (388J) a écrit :
>> Do you have any indication as to why GeoTools, GeoServer, and uDig would rather go to Eclipse than come to Apache? I would welcome them all here. And of course, I think a non copyleft license like the ALv2 is the superior choice for a Geospatial toolkit compared to copyleft licenses (that may impose downstream impacts), that's why I started the SIS project.
>
> The Eclipse peoples asked the same question, why to go to Apache rather than Eclipse... I interpret (maybe wrongly) Eclipse as a little bit more business-oriented than Apache.
Gotcha -- well not sure if Eclipse is more business-oriented than Apache, depends on what business-oriented means.
> I'm sure that both approaches are legitimate, but on our side we have a bit more academic/scientific background. Our company is hosted in a governmental agency trying to help developing countries, which has some influence on our philosophy. We have the (maybe superficial) impression that we could feel a little bit more at home at Apache.
Yeah I think Apache is home for all kinds of projects, academic, business oriented, etc. It's the "Apache way" that makes it distinct from Eclipse -- Apache has a governance model, and process, that Eclipse basically tried to model itself around, but not totally -- differences being in the license of course, but also community oriented, and goals. Apache is a home for all kinds of software -- Eclipse typically is a home for projects that are related (at some level to the "Eclipse" toolkit).
> [...snip...]
> GeoTools/uDig use more Eclipse technologies than we do, and the fact that we use more Apache technologies than they do (e.g. the Derby database) is an additional argument for the way the respective projects would settle down... This is not necessarily at the Apache SIS disadvantage, since the softwares that we would like to offer to Apache cover a similar spectrum of functionalities. Since they do not have the installed users base that uDig/Geoserver have, I think the Apache SIS project would get more flexibility for making drastic changes if needed to better suit peoples needs.
That's a fine reason to more closely align with Apache and SIS. Cross fertilization is important.
>
>
>
>>> Their initial plan was to make an exception to the Eclipse licensing policy in order to accept GeoTools with its LGPL license. However our request to re-license our code to Apache caused some GeoTools members to propose re-licensing GeoTools to Eclipse. If GeoTools makes such re-licensing, it may facilitate our request to OSGeo since it is a similarly-permissive license.
>>>
>>> That's the thing. LGPL isn't similarly permissive to ALv2. In fact they are quite different, depending on the versions (e.g., LGPL2, LGPL3, compared to ALv2).
>
> I wanted to said "Eclipse license similarly permissive to ALv2". I see the Eclipse license as somewhere between Apache and LGPL, but closer to Apache than to LGPL.
I don't really think they are similar at all, I think they are a bit different. Eclipse is interesting in making sure that changes in downstream products that use upstream EPL licensed software being contributed back upstream as I understand it. ALv2 doesn't care.
Here's a simple comparison on Wikipedia that really only is comparing downstream modifications and attribution/redistribution: http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
Of course there are more subtle differences, but I don't see the licenses as similar at all. In fact, for me personally, I envision the ALv2 as being the
most flexible, permissive license out there that governments whose code is funded by the people, and then made available (eventually) as open
source, should use.
> My thought was that if GeoTools goes to Eclipse license, this is one more argument for convincing OSGeo to give formal approval for Geotoolkit.org going to Apache license.
I hope the 2nd outcome of that to happen, but in all honesty, I don't think it's implied by the first -- EPL is different from ALv2. The fact that Eclipse and Apache
are both *foundations* so they provide a legal framework, community, environment, governance model, set of accepted licenses, etc. so that's similar, but it
doesn't imply they are equivalent.
>
>
>> I'm not sure how economical interests play into the fold really. ALv2 allows anyone downstream to use the software however they want. IMHO, it's extremely more permissive than the current situation in Geospatial toolkits and APIs for Java, which by my accounts in 2010 were mostly copyleft licenses. IME, copyleft licenses prevent commercial companies in most situations, e.g., like IBM, Oracle, Google, etc., from contributing their developer time because the copy can't turn around on the consumer end of the open source, and include that open source in their commercial products without inheriting the upstream copyleft restrictions.
>
> At least two small or medium companies are making their living from selling GeoTools/GeoServer services. Geotoolkit.org/Constellation-SDI is a competitor for them. It was a rather inoffensive competitor as long as it was largely unknown despite the technical merits (in my opinion). But a project having Apache's credibility with the code that Geotoolkit.org can provide may be a treat to some businesses.
I wouldn't see how -- in contrast, the small business could more easily incorporate the changes from the upstream Apache code in a lot easier fashion
than they would be able to with EPL and similar (weak) copyleft software since the ALv2 has no downstream restrictions on redistribution, packaging, or commercialization.
> However it doesn't mean that they would behave madly; in the GeoTools vote, two members of the same company voted in opposite way: 1 yes and 1 no. Consequently I really don't know if/how those considerations may play.
Sure, understood.
>
> However those kind of projects don't have to be competitors in all aspects. GeoAPI is in theory a path allowing a project to use services from an other project. The hard thing is to convince other projects to use and implement GeoAPI interfaces. I think it can happen only if a GeoAPI implementation - as Apache SIS could be - become attractive enough for inciting other projects to inter-operate with it.
Competition is fine too -- we compete at Apache all the time. There are many web server projects, big data projects, etc., etc. Apache
doesn't make decisions with respect to competition, communities, consumers, and products do. But it's perfectly healthy to compete,
and Apache isn't against that, and SIS isn't really against that either -- we are interested in building the best Apache Licensed, version 2,
geospatial toolkit out there -- we've done a good job of community building, have a decent code base to build from, and the sky is the limit
and we are looking for people with similar goals! ;)
>
>
>> Cool, well up to you guys but Apache could also be a home for GeoAPI too -- but again up to you guys. Not sure of the precise
>> thought process behind bringing that part to Eclipse, but it's probably b/c I lack the full context.
>
> A first reason why we propose GeoAPI to LocationTech is that we feel useful to stay in touch with them, so GeoAPI could be our link. A second reason is that the guys that we need to convince to use GeoAPI, namely GeoTools, are on the Eclipse side (hopping that Apache SIS would not be too difficult to convince :-) ), so we hope to make that easier by being close to them. A third reason is that the big players involved in Eclipse (Oracle, IBM, etc.) seem similar to the big players involved in OGC, and they are the players who make standards a success or a failure (at least in the way OGC currently work). Since GeoAPI is an OGC standard but not yet a de-facto standard, we think that we need to play by their rules in order to give GeoAPI a chance.
Understood, but I would encourage the Geo Server, Geo Tools (upstream) and other projects considering Eclipse to actually ask questions of e.g.,
the Apache board (feel free to CC me) and other Apache sages b/c I think there are some misperceptions of what Eclipse is providing (and potentially
even Apache) that may wrongly influence their decision as to where to go. Whether they decide to take my advice on this or not, is up to them, but
it's worth trying. I'm happy to facilitate any side of the Apache end of this as possible. I would also point out that IbM, Google, Oracle, etc., also
allow their developers to contribute to Apache tons -- it's not just Eclipse. Those big companies don't discriminate as to what foundations they allow their developers
to participate in -- at the ASF we are all individuals here, so there are not corporations having seats on a board, or having people on projects -- at Apache,
merit is earned individually.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 25/07/12 17:28, Mattmann, Chris A (388J) a écrit :
> Do you have any indication as to why GeoTools, GeoServer, and uDig would rather go to Eclipse than come to Apache? I would welcome them all here. And of course, I think a non copyleft license like the ALv2 is the superior choice for a Geospatial toolkit compared to copyleft licenses (that may impose downstream impacts), that's why I started the SIS project.
The Eclipse peoples asked the same question, why to go to Apache rather
than Eclipse... I interpret (maybe wrongly) Eclipse as a little bit more
business-oriented than Apache. I'm sure that both approaches are
legitimate, but on our side we have a bit more academic/scientific
background. Our company is hosted in a governmental agency trying to
help developing countries, which has some influence on our philosophy.
We have the (maybe superficial) impression that we could feel a little
bit more at home at Apache.
The Eclipse's LocationTech group has been very active in approaching
some Geospatial projects. Given that LocationTech could been seen as an
OSGeo competitor, I wonder how they will work together. Because Eclipse
is much bigger, OSGeo has to find some way to collaborate while
preserving their identity.
A similar relationship exists between the
"Geotoolkit.org/Constellation-SDI/Puzzle" stack and the
"GeoTools/GeoServer/uDig" stack. Both have similar targets, but the
later stack has more marketing power. Geotoolkit.org tries to find its
identity by focusing on a different community and by exploring different
technologies, e.g. JAXB (included in JDK6) instead than the Eclipse
Modelling Framework for XML, Swing instead than SWT for desktop
applications (while we make room for different widget toolkits). Maybe
the fact that GeoTools/uDig use more Eclipse technologies than we do,
and the fact that we use more Apache technologies than they do (e.g. the
Derby database) is an additional argument for the way the respective
projects would settle down... This is not necessarily at the Apache SIS
disadvantage, since the softwares that we would like to offer to Apache
cover a similar spectrum of functionalities. Since they do not have the
installed users base that uDig/Geoserver have, I think the Apache SIS
project would get more flexibility for making drastic changes if needed
to better suit peoples needs.
>> Their initial plan was to make an exception to the Eclipse licensing policy in order to accept GeoTools with its LGPL license. However our request to re-license our code to Apache caused some GeoTools members to propose re-licensing GeoTools to Eclipse. If GeoTools makes such re-licensing, it may facilitate our request to OSGeo since it is a similarly-permissive license.
>>
>> That's the thing. LGPL isn't similarly permissive to ALv2. In fact they are quite different, depending on the versions (e.g., LGPL2, LGPL3, compared to ALv2).
I wanted to said "Eclipse license similarly permissive to ALv2". I see
the Eclipse license as somewhere between Apache and LGPL, but closer to
Apache than to LGPL. My thought was that if GeoTools goes to Eclipse
license, this is one more argument for convincing OSGeo to give formal
approval for Geotoolkit.org going to Apache license.
> I'm not sure how economical interests play into the fold really. ALv2 allows anyone downstream to use the software however they want. IMHO, it's extremely more permissive than the current situation in Geospatial toolkits and APIs for Java, which by my accounts in 2010 were mostly copyleft licenses. IME, copyleft licenses prevent commercial companies in most situations, e.g., like IBM, Oracle, Google, etc., from contributing their developer time because the copy can't turn around on the consumer end of the open source, and include that open source in their commercial products without inheriting the upstream copyleft restrictions.
At least two small or medium companies are making their living from
selling GeoTools/GeoServer services. Geotoolkit.org/Constellation-SDI is
a competitor for them. It was a rather inoffensive competitor as long as
it was largely unknown despite the technical merits (in my opinion). But
a project having Apache's credibility with the code that Geotoolkit.org
can provide may be a treat to some businesses. However it doesn't mean
that they would behave madly; in the GeoTools vote, two members of the
same company voted in opposite way: 1 yes and 1 no. Consequently I
really don't know if/how those considerations may play.
However those kind of projects don't have to be competitors in all
aspects. GeoAPI is in theory a path allowing a project to use services
from an other project. The hard thing is to convince other projects to
use and implement GeoAPI interfaces. I think it can happen only if a
GeoAPI implementation - as Apache SIS could be - become attractive
enough for inciting other projects to inter-operate with it.
> Great to hear! :) Of course my personal interest would be to have you guys join up with SIS.
Thanks, this is appreciated :-)
> Cool, well up to you guys but Apache could also be a home for GeoAPI too -- but again up to you guys. Not sure of the precise
> thought process behind bringing that part to Eclipse, but it's probably b/c I lack the full context.
A first reason why we propose GeoAPI to LocationTech is that we feel
useful to stay in touch with them, so GeoAPI could be our link. A second
reason is that the guys that we need to convince to use GeoAPI, namely
GeoTools, are on the Eclipse side (hopping that Apache SIS would not be
too difficult to convince :-) ), so we hope to make that easier by being
close to them. A third reason is that the big players involved in
Eclipse (Oracle, IBM, etc.) seem similar to the big players involved in
OGC, and they are the players who make standards a success or a failure
(at least in the way OGC currently work). Since GeoAPI is an OGC
standard but not yet a de-facto standard, we think that we need to play
by their rules in order to give GeoAPI a chance.
Cheers,
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Jul 25, 2012, at 3:10 AM, Martin Desruisseaux wrote:
> Hello Adam and all
>
> Thanks you very much for your encouragement, and sorry for the late reply.
No worries!
> To get peoples informed on the progress, as recommended on the OSGeo board mailing list we posted our request to the GeoTools mailing list. They had a non-definitive vote yesterday which resulted in 2 "inclined yes" and 2 "inclined no" (http://sourceforge.net/mailarchive/message.php?msg_id=29578915). However they mentioned in their discussion that our project started before the copyright assignment, which could allow us to proceed anyway. Nevertheless we prefer of course to get a formal OSGeo approval. The OSGeo board will listen to the GeoTools point of view, but we have good hope that they will also stay in agreement with their charter, as we expected when we signed the copyright assignment to OSGeo (not to GeoTools).
Great, yeah I understand the community good will perspective.
>
> The Eclipse foundation is launching a "LocationTech" group, which seems similar in goals to OSGeo. The GeoTools, GeoServer and uDig projects are likely to join that group.
Do you have any indication as to why GeoTools, GeoServer, and uDig would rather go to Eclipse than come to Apache? I would welcome them all here. And of course, I think a non copyleft license like the ALv2 is the superior choice for a Geospatial toolkit compared to copyleft licenses (that may impose downstream impacts), that's why I started the SIS project.
> Their initial plan was to make an exception to the Eclipse licensing policy in order to accept GeoTools with its LGPL license. However our request to re-license our code to Apache caused some GeoTools members to propose re-licensing GeoTools to Eclipse. If GeoTools makes such re-licensing, it may facilitate our request to OSGeo since it is a similarly-permissive license.
That's the thing. LGPL isn't similarly permissive to ALv2. In fact they are quite different, depending on the versions (e.g., LGPL2, LGPL3, compared to ALv2).
ALv2 is a non-copyleft license, with upstream patent termination. LGPL is a (weak) copyleft license, with the ability to bake in downstream restrictions.
>
> The Geotoolkit.org code that we are proposing for Apache SIS consideration is similar in functionalities to GeoTools, which is why the first reply to our request on the GeoTools mailing list raised the question of economical interests.
I'm not sure how economical interests play into the fold really. ALv2 allows anyone downstream to use the software however they want. IMHO, it's extremely more permissive than the current situation in Geospatial toolkits and APIs for Java, which by my accounts in 2010 were mostly copyleft licenses. IME, copyleft licenses prevent commercial companies in most situations, e.g., like IBM, Oracle, Google, etc., from contributing their developer time because the copy can't turn around on the consumer end of the open source, and include that open source in their commercial products without inheriting the upstream copyleft restrictions.
> But in theory, the OSGeo foundation is supposed to make the promotion of open source softwares.
Yep, I think that's a great thing for OSGeo. I would encourage them to leverage the ASF to open source more
of their geospatial software -- I think Apache is a great home for cross fertilization of the geospatial community
with the larger, broader technologies here at the ASF.
>
> We have been approached by LocationTech for joining them. We had very long debates and feel more inclined to join Apache.
Great to hear! :) Of course my personal interest would be to have you guys join up with SIS.
> One reason is that we are not necessarily searching for the biggest community, but rather for a community sharing similar goals and interests. We work mostly with scientific research institutes, which sometime have different priorities than the mass-market ones (e.g. supporting data structured in a NetCDF-like way has significant influence on the API). While science and mass-market are not exclusive, the issue is sometime just a matter of focus.
+1.
>
> However we are considering to propose hosting GeoAPI on LocationTech. If the Eclipse foundation accepts, GeoAPI would still copyrighted by OGC under OGC license (which is BSD-like), milestones could be released by LocationTech but normative releases would still have to go through the OGC standardisation process. If Eclipse accepts, GeoAPI could be a glue between OGC, Apache and Eclipse where some collaboration happen.
Cool, well up to you guys but Apache could also be a home for GeoAPI too -- but again up to you guys. Not sure of the precise
thought process behind bringing that part to Eclipse, but it's probably b/c I lack the full context.
>
> I will come back with more information has I get some.
Thanks for the debrief and for collaborating and coordinating with us here in the SIS community.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam and all
Thanks you very much for your encouragement, and sorry for the late
reply. To get peoples informed on the progress, as recommended on the
OSGeo board mailing list we posted our request to the GeoTools mailing
list. They had a non-definitive vote yesterday which resulted in 2
"inclined yes" and 2 "inclined no"
(http://sourceforge.net/mailarchive/message.php?msg_id=29578915).
However they mentioned in their discussion that our project started
before the copyright assignment, which could allow us to proceed anyway.
Nevertheless we prefer of course to get a formal OSGeo approval. The
OSGeo board will listen to the GeoTools point of view, but we have good
hope that they will also stay in agreement with their charter, as we
expected when we signed the copyright assignment to OSGeo (not to GeoTools).
The Eclipse foundation is launching a "LocationTech" group, which seems
similar in goals to OSGeo. The GeoTools, GeoServer and uDig projects are
likely to join that group. Their initial plan was to make an exception
to the Eclipse licensing policy in order to accept GeoTools with its
LGPL license. However our request to re-license our code to Apache
caused some GeoTools members to propose re-licensing GeoTools to
Eclipse. If GeoTools makes such re-licensing, it may facilitate our
request to OSGeo since it is a similarly-permissive license.
The Geotoolkit.org code that we are proposing for Apache SIS
consideration is similar in functionalities to GeoTools, which is why
the first reply to our request on the GeoTools mailing list raised the
question of economical interests. But in theory, the OSGeo foundation is
supposed to make the promotion of open source softwares.
We have been approached by LocationTech for joining them. We had very
long debates and feel more inclined to join Apache. One reason is that
we are not necessarily searching for the biggest community, but rather
for a community sharing similar goals and interests. We work mostly with
scientific research institutes, which sometime have different priorities
than the mass-market ones (e.g. supporting data structured in a
NetCDF-like way has significant influence on the API). While science and
mass-market are not exclusive, the issue is sometime just a matter of focus.
However we are considering to propose hosting GeoAPI on LocationTech. If
the Eclipse foundation accepts, GeoAPI would still copyrighted by OGC
under OGC license (which is BSD-like), milestones could be released by
LocationTech but normative releases would still have to go through the
OGC standardisation process. If Eclipse accepts, GeoAPI could be a glue
between OGC, Apache and Eclipse where some collaboration happen.
I will come back with more information has I get some.
Martin Desruisseaux
Le 21/07/12 14:46, Adam Estrada a écrit :
> I've been following this thread over the past week and gotta say that it's very much appreciated that you are so willing to move your project to Apache. Thanks and I look forward to working with you more on SIS.
Re: Exploring possible contribution
Posted by Adam Estrada <es...@gmail.com>.
Martin,
I've been following this thread over the past week and gotta say that it's very much appreciated that you are so willing to move your project to Apache. Thanks and I look forward to working with you more on SIS.
Adam
On Jul 21, 2012, at 8:06 AM, Martin Desruisseaux wrote:
> Hello all
>
> Just for letting peoples known, the request to OSGeo board for re-licensing Geotoolkit.org from LPGL to Apache can be followed there. Not many reply yet, but initial contact seem encouraging:
>
> http://lists.osgeo.org/pipermail/board/2012-July/009857.html
>
> Martin
>
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
Just for letting peoples known, the request to OSGeo board for
re-licensing Geotoolkit.org from LPGL to Apache can be followed there.
Not many reply yet, but initial contact seem encouraging:
http://lists.osgeo.org/pipermail/board/2012-July/009857.html
Martin
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 19/07/12 06:44, Mattmann, Chris A (388J) a écrit :
> Points below, well taken and I am +1 to move forward.
Thanks :-). I just had send email to OSGeo. Waiting for reply now.
In the main time, maybe we can determine what code SIS wishes to take
and how to organize that. I have see a recent discussion about using the
Proj4 library for map projection. Actually it is possible to have both
Proj.4 and Geotk, using the GeoAPI interfaces as an isolation layer (in
the same way than JDBC interfaces regarding databases). Both have
advantages and inconvenient. In the "Geospatial Integrity of Geoscience
Software (GIGS)" terminology, Proj.4 is an "early-binding"
implementation while Geotk is a "late-binding" implementation. I can
post more about that in an other thread.
On the Geotk side, the most fundamental modules that I suggest as a
starting point for consideration are:
* Utilities (partially derived from ISO 19103) - maybe it should be
non-public API.
* Metadata (ISO 19115), including the extensions for imagery and
gridded data (ISO 19115-2)
* Spatial referencing by coordinates (ISO 19111)
According the SIS email archives, it seems to me that the referencing
module could fill a current SIS need. However in order to be ISO 19111
compliant, referencing needs metadata, because the OGC/ISO specification
uses ISO 19115 metadata in order to:
* Specify who defined the Coordinate Reference System (USGS? Nasa? other?)
* Specify its geographic area of validity and its scope of use
* Give an estimation of coordinate transformation accuracy.
So if we follow dependencies order, ISO 19115[-2] metadata would be the
first public API to consider. Does it make sense up to date? (I will
continue on metadata in new email thread if this path is okay to everyone).
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
Points below, well taken and I am +1 to move forward.
Cheers,
Chris
On Jul 18, 2012, at 11:03 AM, Martin Desruisseaux wrote:
> Hello Chris
>
> Thanks a lot for you email, I'm glad to see there is interest!
>
>
> Le 18/07/12 16:46, Mattmann, Chris A (388J) a écrit :
>> Ah, NetCDF, I knew that you and I had crossed paths before too! :) Maven, NetCDF Java support, anyone? :)
> Yes, I still in touch with some UCAR and Readings developers for various aspects related to NetCDF.
>
>> Yep, that's how Apache works. We have CI systems (ci.apache.org), we leverage
>> unit tests, we generally care about the code, but more importantly, we *care* about
>> the people here and are all mutually friendly to one another.
> Actually I had a few years of experience with an Open Source community in the past. At that time, it was on a centralized versioning system (SubVersion). The project had a friendly start, but a few years later some tensions happened. My analysis is that they were conflicts in the goals and constraints of different developers:
>
> * Conflicts in the goals between the "scientist inclined" and the "mass-market inclined", since the former want computation results they can trust while the later want pretty pictures to show fast. While both needs are perfectly valids, my (maybe egocentric) wish would be to give priority to the former, because I think it is easier for a "mass-market inclined" to take a trusted library and makes it more flexible for his needs, than for a "scientist inclined" to make an extensive review of a library for the places where correctness may be compromised. (Note: this discussion ignores the "security inclined" because I have no experience in that area, but it would probably be an other factor to consider.)
>
> * Conflicts in the constraints between developers working for different institutions or companies, since a company may have strong deadlines for their releases. It may result in some peoples pushing strongly for a work to be injected in the code base, while some others feel uncomfortable but lack of time for alternative proposals. For this particular issue, I put my hopes in Distributed Versioning Systems. I'm a supporter of Joshua Bloch statement "In case of doubt, leave it out": I would like the SIS project to move relatively slowly, to commit only things we feel confident about, and let each institutions/companies manage their own DVS clones with all the branding-new code they wish.
>
> * Conflicts in the choice of technologies (logging framework, etc.). While I think everyone agree for letting the choice to users, I though (maybe naively) that the most consensual technology would be the one bundled in the standard JDK, when applicable. It is often possible to use the JDK API in a way that still allow freedom of choice to users. But I realized that this approach still sometime controversial.
>
>
> So based on the above, I wonder what peoples feel about the following?
>
> * Focus on a "trusted" library, eventually with branches for peoples
> who need trimmed-down versions;
> * Relatively "slow" commitment, with institutions/companies managing
> their own clones if needed
>
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Thanks a lot for you email, I'm glad to see there is interest!
Le 18/07/12 16:46, Mattmann, Chris A (388J) a écrit :
> Ah, NetCDF, I knew that you and I had crossed paths before too! :) Maven, NetCDF Java support, anyone? :)
Yes, I still in touch with some UCAR and Readings developers for various
aspects related to NetCDF.
> Yep, that's how Apache works. We have CI systems (ci.apache.org), we leverage
> unit tests, we generally care about the code, but more importantly, we *care* about
> the people here and are all mutually friendly to one another.
Actually I had a few years of experience with an Open Source community
in the past. At that time, it was on a centralized versioning system
(SubVersion). The project had a friendly start, but a few years later
some tensions happened. My analysis is that they were conflicts in the
goals and constraints of different developers:
* Conflicts in the goals between the "scientist inclined" and the
"mass-market inclined", since the former want computation results they
can trust while the later want pretty pictures to show fast. While both
needs are perfectly valids, my (maybe egocentric) wish would be to give
priority to the former, because I think it is easier for a "mass-market
inclined" to take a trusted library and makes it more flexible for his
needs, than for a "scientist inclined" to make an extensive review of a
library for the places where correctness may be compromised. (Note: this
discussion ignores the "security inclined" because I have no experience
in that area, but it would probably be an other factor to consider.)
* Conflicts in the constraints between developers working for different
institutions or companies, since a company may have strong deadlines for
their releases. It may result in some peoples pushing strongly for a
work to be injected in the code base, while some others feel
uncomfortable but lack of time for alternative proposals. For this
particular issue, I put my hopes in Distributed Versioning Systems. I'm
a supporter of Joshua Bloch statement "In case of doubt, leave it out":
I would like the SIS project to move relatively slowly, to commit only
things we feel confident about, and let each institutions/companies
manage their own DVS clones with all the branding-new code they wish.
* Conflicts in the choice of technologies (logging framework, etc.).
While I think everyone agree for letting the choice to users, I though
(maybe naively) that the most consensual technology would be the one
bundled in the standard JDK, when applicable. It is often possible to
use the JDK API in a way that still allow freedom of choice to users.
But I realized that this approach still sometime controversial.
So based on the above, I wonder what peoples feel about the following?
* Focus on a "trusted" library, eventually with branches for peoples
who need trimmed-down versions;
* Relatively "slow" commitment, with institutions/companies managing
their own clones if needed
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
First off, thanks so much for your email! I think this will be a strong collaboration and we welcome you
into the Apache SIS community (and are happy to be welcomed into your existing community).
Specific comments below;
On Jul 17, 2012, at 10:14 AM, Martin Desruisseaux wrote:
> Hello all
>
> I would like to introduce myself: My name is Martin Desruisseaux. I'm the chair of the GeoAPI working group at OGC (Open Geospatial Consortium) and the maintainer of the "core" of the Geotoolkit.org (abridged Geotk) project. Years ago I was one of the GeoTools 2 project initiators. In particular, I'm the author of the referencing engine (coordinate transformations). I have also done a few contributions to ISO 19111 and 19115, and I'm somewhat used to OGC meetings.
Great to have someone with your background hanging out here in Apache SIS!
>
> We were wondering if the Apache SIS and Geotk projects could gain mutual benefit in merging selected portions of them. We were considering for a while to change the license (currently LGPL 2.1) to the Apache or BSD license. It may be possible if OSGeo agree.
We would welcome any such contributions, and the greatest thing is that Apache is a meritocracy. If you make such contributions
to the project you will earn the committership bit and the (P)PMC membership bit soon enough -- to date SIS has been a very
welcoming community.
Also, we would welcome a license change as the ALv2 (Apache license, "version 2") is our preferred license of
choice in Apache products (though we can work with any license that is defined as "category A", here):
http://www.apache.org/legal/resolved.html#category-a
>
> The Apache project would gain a pool of more than 230000 lines of clean code (plus 520000 lines of code in the "pending" area) in which they can select the parts they have interest in. The Geotk project would get a wider community, which is missing to us.
That would be awesome, sounds win win to me.
>
> The Geotk project (http://www.geotoolkit.org/) features one of the most powerful referencing engine available in open-source. It provides also an extensive metadata support (ISO-19115) close to the European regulation (INSPIRE). There is bridges between those metadata and some formats like NetCDF.
Ah, NetCDF, I knew that you and I had crossed paths before too! :) Maven, NetCDF Java support, anyone? :)
http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-java/2010/msg00129.html
>
> Geotk is an implementation of GeoAPI 3.0 (http://www.geoapi.org/). GeoAPI is a set of interfaces derived from OGC/ISO standards. The aim is to provide for geospatial applications what JDBC interfaces provide for database applications: an isolation layer allowing the same applications to run with different libraries. In addition to Geotk, GeoAPI implementations include wrappers around the NetCDF and the C/C++ Proj.4 libraries. GeoAPI provides also a conformance test suite which include parts of the Geospatial Integrity of Geoscience Software (http://www.epsg.org/gigs.html) tests. Using those interfaces as an isolation, it is possible to keep large parts of Geotk as internal mechanic and expose mostly the interfaces as committed API.
>
+1, all aspects and goals of Apache SIS. We would welcome any such contribution.
> Where the project would be hosted (current servers vs Apache servers), which part of the project would be eventually hosted by Apache, which package name, integration with existing SIS code are all open questions. With this email, I'm just exploring if there is any interest. The main requests I would have on my side are:
>
> * Distributed Version Control (DVS) like Mercurial or Git rather than
> centralized one like SVN, because we may which to maintain a branch
> on our side (while doing merges, of course).
I believe Kevan addressed this, but there isn't really a barrier to Git support
anymore at the ASF. infra@ is supporting Git for projects that desire it, though
to date, the SIS folks have been using SVN for maintenance of the code. We
could easily work with the community to figure this out.
> * A commit right policy with emphasis on quality (e.g. complete
> javadoc, new code does not duplicate existing code, equals/hashCode
> consistency, etc.), maybe using branches with DVS for pending works.
Yep, that's how Apache works. We have CI systems (ci.apache.org), we leverage
unit tests, we generally care about the code, but more importantly, we *care* about
the people here and are all mutually friendly to one another.
>
>
> I would like to known if there is any though/interest...
Tons, let's do this!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Jul 18, 2012, at 11:10 AM, Martin Desruisseaux wrote:
> Le 18/07/12 01:27, Ramirez, Paul M (388J) a écrit :
>> For the copyright assignment are you referring to this
>> http://wiki.osgeo.org/wiki/Contributor_Agreement?
>
> I got the reply for Adrian. Actually no, it was not that document. The copyright assignment which we signed is that one:
>
> http://download.osgeo.org/osgeo/legal/
>
> Every developers from our company signed that agreement. Many others GeoTools developers did so.
Thanks for the FYI, here.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 18/07/12 01:27, Ramirez, Paul M (388J) a écrit :
> For the copyright assignment are you referring to this
> http://wiki.osgeo.org/wiki/Contributor_Agreement?
I got the reply for Adrian. Actually no, it was not that document. The
copyright assignment which we signed is that one:
http://download.osgeo.org/osgeo/legal/
Every developers from our company signed that agreement. Many others
GeoTools developers did so.
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Jul 18, 2012, at 3:48 PM, Martin Desruisseaux wrote:
> Sound like we are sharing the same goals for a library :-)
+1.
>
> What about this plan?
>
> * I contact OSGeo for asking permission to re-license Geotk "core"
> under the Apache license (the "pending" part may need more
> negotiation with OSGeo; it would be a next step).
> * We re-license Geotk in their current repository
> (http://www.geotoolkit.org).
> * Apache SIS can consider the Geotk code and migrate to SIS only the
> parts that SIS selects, on a case-by-case basis. This will probably
> need a discussion on the overall architecture first.
> * Code migrated to SIS will be replaced by a dependency to SIS in the
> Geotk code base. This allow a migration at whatever speed peoples
> want, without any pressure.
That sounds great, and actually right in line with the Apache way. We prefer
small, incremental change, easily revertible, and bringing over Geotk in this
fashion will also probably allow the SIS committers and PPMC members
to become most familiar with Geotk and the integration points with the code
to date in SIS.
>
>
> We will probably have duplication between some Geotk classes and existing SIS classes; I guess we will need to resolve them on a case-by-case basis.
Yep, and we will be happy to help.
>
> We may also need a discussion about what should be public committed API, and what should be internal mechanic available to the users "at their own risk", and what should be the package names for each of those parts.
+1 that sounds great.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Sound like we are sharing the same goals for a library :-)
What about this plan?
* I contact OSGeo for asking permission to re-license Geotk "core"
under the Apache license (the "pending" part may need more
negotiation with OSGeo; it would be a next step).
* We re-license Geotk in their current repository
(http://www.geotoolkit.org).
* Apache SIS can consider the Geotk code and migrate to SIS only the
parts that SIS selects, on a case-by-case basis. This will probably
need a discussion on the overall architecture first.
* Code migrated to SIS will be replaced by a dependency to SIS in the
Geotk code base. This allow a migration at whatever speed peoples
want, without any pressure.
We will probably have duplication between some Geotk classes and
existing SIS classes; I guess we will need to resolve them on a
case-by-case basis.
We may also need a discussion about what should be public committed API,
and what should be internal mechanic available to the users "at their
own risk", and what should be the package names for each of those parts.
Martin
Re: Exploring possible contribution
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin, others,
On Jul 18, 2012, at 4:01 AM, Martin Desruisseaux wrote:
> [..snip...]
>
>> Is there interest in the two communities to collaborate? Do our technical goals mesh well? etc.
> On the Geotk side, some of the goals are:
>
> * Target both desktop applications and web services.
+1, same here. We want to start out with a computational library, layer APIs on top (maybe web services, may others), build this capability into an end-to-end capability and drive out desktop applications and GUIs.
>
> * Follow closely the international standards. We are active members at OGC and put large amount of effort in expressing OGC/ISO models in Java.
This is one of our goals though clearly we haven't nearly gotten there yet and you guys are much further!
>
> * Focus on scientific needs (I'm an oceanographer). This means that we care a lot about metadata, uncertainties and the like, and often prefer to get an exception rather than an image that "looks good" but were computed on inaccurate assumptions (while I admit that some users legitimately just want an image that looks good, so it probably needs to be configurable, but I tend to prone the exception as the default behaviour). Example: when a coordinate transformation requires a datum change, Bursa-Wolf parameters (or something equivalent) are needed in order to reach a 1 metre accuracy. Without Bursa-Wolf parameters, the error may be around 1 kilometre. The default behaviour is to thrown a "Required Bursa-Wolf parameters" exception in such case, but the user can configure the library to ignore the lack of parameters if they can accept a 1 km error.
+1, agreed.
>
> * Try to keep the amount of dependencies low (favour JDK classes or some JSR) at least for the core parts. The "coverage" modules have a JAI (Java Advanced Imaging) dependenciy, but we are working right now on removing that dependency. Example: we use the JDK logging framework instead that Common Logging, but users can still redirect to Common Logging of Log4J. It is possible to do such redirection through the standard Java API (I don't know why Common Logging didn't do that in the first place. My guess is that JDK 1.2 and 1.3 were important targets at the time Common Logging were designed).
+1, this is fine with me too. I am fine with decisions like this, and we make them on the dev list, with
general consensus amongst each other the community.
>
> * Extensive comments both in code and in javadoc.
++1!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 18/07/12 03:28, Kevan Miller a écrit :
> If I understand correctly, the copyright for a very large portion (95%) of the Geotoolkit.org codebase is owned by Martin's company.
Just to be sure there is no ambiguity, this number (around 95%) applies
to the "core" of Geotoolkit.org: metadata (ISO 19115), referencing by
coordinates (ISO 19111) and grid coverages. In the "pending" part of
Geotk, this number is lower (but still relatively large).
> Their ability to relicense (as copyright holder) seems clear.
Since we gave the copyright to OSGeo, I think we have to ask them. But
we already had some talks with them in the past about relicensing, and I
think there is good chances that they will not object against at least
the 95% that we wrote.
> Is there interest in the two communities to collaborate? Do our technical goals mesh well? etc.
On the Geotk side, some of the goals are:
* Target both desktop applications and web services.
* Follow closely the international standards. We are active members at
OGC and put large amount of effort in expressing OGC/ISO models in Java.
* Focus on scientific needs (I'm an oceanographer). This means that we
care a lot about metadata, uncertainties and the like, and often prefer
to get an exception rather than an image that "looks good" but were
computed on inaccurate assumptions (while I admit that some users
legitimately just want an image that looks good, so it probably needs to
be configurable, but I tend to prone the exception as the default
behaviour). Example: when a coordinate transformation requires a datum
change, Bursa-Wolf parameters (or something equivalent) are needed in
order to reach a 1 metre accuracy. Without Bursa-Wolf parameters, the
error may be around 1 kilometre. The default behaviour is to thrown a
"Required Bursa-Wolf parameters" exception in such case, but the user
can configure the library to ignore the lack of parameters if they can
accept a 1 km error.
* Try to keep the amount of dependencies low (favour JDK classes or some
JSR) at least for the core parts. The "coverage" modules have a JAI
(Java Advanced Imaging) dependenciy, but we are working right now on
removing that dependency. Example: we use the JDK logging framework
instead that Common Logging, but users can still redirect to Common
Logging of Log4J. It is possible to do such redirection through the
standard Java API (I don't know why Common Logging didn't do that in the
first place. My guess is that JDK 1.2 and 1.3 were important targets at
the time Common Logging were designed).
* Extensive comments both in code and in javadoc.
Martin
Re: Exploring possible contribution
Posted by Kevan Miller <ke...@gmail.com>.
On Jul 17, 2012, at 7:48 PM, Martin Desruisseaux wrote:
> Le 18/07/12 01:39, Martin Desruisseaux a écrit :
>> Yes, it was that copyright assignment. This agreement has been created during the incubation of GeoTools 2 - from which Geotoolkit.org is derived - at OSGeo. Among others peoples, one of our former employees (Adrian Custer) contributed to this agreement, and GeoTools was the main target at that time.
>
> Well, I have to email to Adrian for being 100%. It seems to me that we also signed a paper (on a volunteer basis) giving copyright to OSGeo, and have faxed a copy to OSGeo. If a remember correctly, a good amount of developers faxed this paper. I will try to get more information about that.
Thanks for the information.
If I understand correctly, the copyright for a very large portion (95%) of the Geotoolkit.org codebase is owned by Martin's company. Their ability to relicense (as copyright holder) seems clear. There will be some questions about under what contributor agreements the remaining 5% were made under. We'll also be interested in the political sentiment of those contributors about a license change as well as the ability of geotoolkit.org to relicense their contributions.
There will be questions, hurdles, and perhaps some minor roadblocks. But I suggest we know enough, at present, to merit moving on to the larger, more important questions.
Is there interest in the two communities to collaborate? Do our technical goals mesh well? etc.
At present, I'm only filling a mentor's role in the project. I'm not really driving any technical contributions to the project (too bad for me) So, I'll be quite interested to hear what other community members think.
--kevan
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 18/07/12 01:39, Martin Desruisseaux a écrit :
> Yes, it was that copyright assignment. This agreement has been created
> during the incubation of GeoTools 2 - from which Geotoolkit.org is
> derived - at OSGeo. Among others peoples, one of our former employees
> (Adrian Custer) contributed to this agreement, and GeoTools was the
> main target at that time.
Well, I have to email to Adrian for being 100%. It seems to me that we
also signed a paper (on a volunteer basis) giving copyright to OSGeo,
and have faxed a copy to OSGeo. If a remember correctly, a good amount
of developers faxed this paper. I will try to get more information about
that.
Martin
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Ramirez
Le 18/07/12 01:27, Ramirez, Paul M (388J) a écrit :
> For the copyright assignment are you referring to this
> http://wiki.osgeo.org/wiki/Contributor_Agreement? The reason I ask is I
> know of a few other OSGeo projects that have worked that into their
> process and it may have some bearing on this question. If so maybe we can
> get Apache legal to look at it for us and give it the once over.
Yes, it was that copyright assignment. This agreement has been created
during the incubation of GeoTools 2 - from which Geotoolkit.org is
derived - at OSGeo. Among others peoples, one of our former employees
(Adrian Custer) contributed to this agreement, and GeoTools was the main
target at that time.
Martin
Re: Exploring possible contribution
Posted by "Ramirez, Paul M (388J)" <pa...@jpl.nasa.gov>.
Hey Martin,
For the copyright assignment are you referring to this
http://wiki.osgeo.org/wiki/Contributor_Agreement? The reason I ask is I
know of a few other OSGeo projects that have worked that into their
process and it may have some bearing on this question. If so maybe we can
get Apache legal to look at it for us and give it the once over.
Thanks,
Paul Ramirez
On 7/17/12 11:34 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Kevan
>
>Thanks for the reply
>
>Le 17/07/12 18:13, Kevan Miller a écrit :
>> One initial question -- what is the provenance on the Geotk code? Are
>> all contributors willing to relicense from LGPL to ALv2? --kevan
>
>Geotk is splitted in two parts: "core" and "pending". For the "core"
>part, which includes metadata, referencing and coverage services, myself
>or other members of our company wrote most of the code (probably more
>than 95%). For the remaining 5%, the various contributors already gave a
>copyright assignment to the OSGeo foundation around 2009. So I think
>that if OSGeo accepts the relicensing, we would be okay. However in case
>of objections, it should be possible to identify through SVN history
>(before we migrated to Mercurial) the 5% of code that would need
>rewrite, and we will be wiling to rewrite it.
>
>The "pending" part is in the same situation, except that the percentage
>of external contribution is larger. It may be a more long-term road.
>
> Martin
>
Re: Exploring possible contribution
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Kevan
Thanks for the reply
Le 17/07/12 18:13, Kevan Miller a écrit :
> One initial question -- what is the provenance on the Geotk code? Are
> all contributors willing to relicense from LGPL to ALv2? --kevan
Geotk is splitted in two parts: "core" and "pending". For the "core"
part, which includes metadata, referencing and coverage services, myself
or other members of our company wrote most of the code (probably more
than 95%). For the remaining 5%, the various contributors already gave a
copyright assignment to the OSGeo foundation around 2009. So I think
that if OSGeo accepts the relicensing, we would be okay. However in case
of objections, it should be possible to identify through SVN history
(before we migrated to Mercurial) the 5% of code that would need
rewrite, and we will be wiling to rewrite it.
The "pending" part is in the same situation, except that the percentage
of external contribution is larger. It may be a more long-term road.
Martin
Re: Exploring possible contribution
Posted by Kevan Miller <ke...@gmail.com>.
On Jul 17, 2012, at 11:14 AM, Martin Desruisseaux wrote:
> Hello all
>
> I would like to introduce myself: My name is Martin Desruisseaux. I'm the chair of the GeoAPI working group at OGC (Open Geospatial Consortium) and the maintainer of the "core" of the Geotoolkit.org (abridged Geotk) project. Years ago I was one of the GeoTools 2 project initiators. In particular, I'm the author of the referencing engine (coordinate transformations). I have also done a few contributions to ISO 19111 and 19115, and I'm somewhat used to OGC meetings.
>
> We were wondering if the Apache SIS and Geotk projects could gain mutual benefit in merging selected portions of them. We were considering for a while to change the license (currently LGPL 2.1) to the Apache or BSD license. It may be possible if OSGeo agree.
>
> The Apache project would gain a pool of more than 230000 lines of clean code (plus 520000 lines of code in the "pending" area) in which they can select the parts they have interest in. The Geotk project would get a wider community, which is missing to us.
>
> The Geotk project (http://www.geotoolkit.org/) features one of the most powerful referencing engine available in open-source. It provides also an extensive metadata support (ISO-19115) close to the European regulation (INSPIRE). There is bridges between those metadata and some formats like NetCDF.
>
> Geotk is an implementation of GeoAPI 3.0 (http://www.geoapi.org/). GeoAPI is a set of interfaces derived from OGC/ISO standards. The aim is to provide for geospatial applications what JDBC interfaces provide for database applications: an isolation layer allowing the same applications to run with different libraries. In addition to Geotk, GeoAPI implementations include wrappers around the NetCDF and the C/C++ Proj.4 libraries. GeoAPI provides also a conformance test suite which include parts of the Geospatial Integrity of Geoscience Software (http://www.epsg.org/gigs.html) tests. Using those interfaces as an isolation, it is possible to keep large parts of Geotk as internal mechanic and expose mostly the interfaces as committed API.
>
> Where the project would be hosted (current servers vs Apache servers), which part of the project would be eventually hosted by Apache, which package name, integration with existing SIS code are all open questions. With this email, I'm just exploring if there is any interest. The main requests I would have on my side are:
>
> * Distributed Version Control (DVS) like Mercurial or Git rather than
> centralized one like SVN, because we may which to maintain a branch
> on our side (while doing merges, of course).
> * A commit right policy with emphasis on quality (e.g. complete
> javadoc, new code does not duplicate existing code, equals/hashCode
> consistency, etc.), maybe using branches with DVS for pending works.
>
>
> I would like to known if there is any though/interest…
Hi Martin,
Thanks for the email.
See http://www.apache.org/dev/git.html for information about git at the ASF. Git support is evolving. And there are expectations that there will be full-fledged support for Git within the ASF in the (near?) future. I'll note that there is not a Git mirror for SIS, currently. But that could be created quite easily.
I would certainly expect that there will be interest from the SIS community. There will be a number of aspects that would need to be explored, including: technical, community, and legal/licensing.
One initial question -- what is the provenance on the Geotk code? Are all contributors willing to relicense from LGPL to ALv2?
--kevan