[PROJ] OSGeo incubation status

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] OSGeo incubation status

Kristian Evers-2
All,

At the code sprint held in conjunction with the FOSS4G conference I put some more
work into the PROJ OSGeo Incubation checklist [0]. Since PROJ is already a well-
established project most of the details has been easy to fill out. The only two
things left need to left before the checklist is finished are

1. Provenance review and other copyright/license related things
2. A logo for the project

The provenance review is by far the most daunting task in the incubation process.
I have started the work already. The progress can be seen on [1]. Still missing
are the sections on the license status of the individual source files and the
section on copyright holders. The latter is easy to compile once the first is finished.

For the review of the license status of the individual files I have created a Google
spreadsheet to keep track of the information. It is linked in the Provence Review
Wiki-page. Everyone is able to suggest changes. I would like to encourage you all
to do so - it is a big list to go through by myself. Guidelines for how to fill out the list
can be found in the OSGeo Incubation Provenance Review wiki-page [2], but mostly
it is self-explanatory.

As part of the provenance review it is also asked if committers has signed a
“Contribution Agreement”. Currently we don’t have one. I am not sure if we need it,
but if so, can anyone link me to an existing one that can be used as a template for
PROJ?


As for the project logo, does anyone subscribing to this list have artistic skills? If so,
suggestions for a new logo would be appreciated :-)


I would also appreciate if someone familiar with the OSGeo Incubation process
would be willing to go through checklist in it’s current state and provide feedback.
There is almost certainly going to be mistakes in the material I have filled in so far.

/Kristian




_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Howard Butler-3


> On Sep 9, 2019, at 1:41 PM, Kristian Evers <[hidden email]> wrote:
>
> All,
>
> At the code sprint held in conjunction with the FOSS4G conference I put some more
> work into the PROJ OSGeo Incubation checklist


>
> As part of the provenance review it is also asked if committers has signed a
> “Contribution Agreement”. Currently we don’t have one. I am not sure if we need it,
> but if so, can anyone link me to an existing one that can be used as a template for
> PROJ?

I'm quite sure no one has signed one, and I do not see any reason for contributors to PROJ to sign one going forward.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Even Rouault-2
> For the review of the license status of the individual files I have created
a Google spreadsheet to keep track of the information.

I've just asked write permission to update a few things.
I believe that most of the code under src/projections originates from Gerald
Evenden's initial work, so basically any file originally coming from
https://download.osgeo.org/proj/from_kai/PROJ.4.3.3.tar.gz is Public Domain,
later relicensed to X/MIT by Frank Warmerdam.
For other files, "git log" on them and finding the original committer should
be good enough.

>
> I'm quite sure no one has signed one, and I do not see any reason for
> contributors to PROJ to sign one going forward.

Agreed. Given the super permissive license of MIT, there would be hardly no
reason to relicense the code to something else. A CLA might bring other
advantages (like having "legal certainty" that a contribution was really
intended to be made as open source), but having to manage that would bring
complication and would make some contributors to go away.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Even Rouault-2
> For other files, "git log" on them and finding the original committer should
> be good enough.

"git log --follow" to be more exact due to renaming/moving around.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Sebastiaan Couwenberg
In reply to this post by Even Rouault-2
On 9/9/19 9:06 PM, Even Rouault wrote:
>> I'm quite sure no one has signed one, and I do not see any reason for
>> contributors to PROJ to sign one going forward.
>
> Agreed. Given the super permissive license of MIT, there would be hardly no
> reason to relicense the code to something else. A CLA might bring other
> advantages (like having "legal certainty" that a contribution was really
> intended to be made as open source), but having to manage that would bring
> complication and would make some contributors to go away.

Don't introduce a CLA, that just raises the barrier to entry unnecessarily.

I personally refuse to sign them and opt to stop contributing to the
project in question.

This is quite a good summary of the situation:

 https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status - CLA

Cameron Shorter

I agree with Bas. I've been researching best practices into Open Source licenses of late, and I'm now against CLAs. Further reason for proj:

* If at least one of your contributors won't sign the CLA, then you won't be able to retrospectively collect all ownership rights and allocate them to an entity (such as OSGeo). Thanks Bas for stating that you would be one of those people and forcing the issue.

--

While I think the "do nothing" approach for proj would be best, you might want to consider adding a statement along the lines of:

"If you contribute to Proj, we assume you do so under the terms of the Developer Certificate of Origin (DCO): https://developercertificate.org/"

The DCO is typically implemented with each contributor signing their commit message, however, a statement above could be used instead (I don't have legal advice on whether this is acceptable).

It also doesn't address retrospectively applying this.

Cheers, Cameron

On 10/9/19 5:21 am, Sebastiaan Couwenberg wrote:
Don't introduce a CLA, that just raises the barrier to entry unnecessarily.

I personally refuse to sign them and opt to stop contributing to the
project in question.

This is quite a good summary of the situation:

 https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Even Rouault-2
In reply to this post by Even Rouault-2
On lundi 9 septembre 2019 21:20:36 CEST Even Rouault wrote:
> > For other files, "git log" on them and finding the original committer
> > should be good enough.
>
> "git log --follow" to be more exact due to renaming/moving around.

OK, I did the exercice of completing Kristian's initiated source file listing
https://docs.google.com/spreadsheets/d/1Bdu73lw8I1iFX4cb7CIUF6yqWGDTcZKBfW0cUsEjCXk/edit#gid=0
Would be worth being double checked of course.

I've followed an "optimistic" principle, that is to say that we don't have issues
unless strong suspicion of the contrary: PROJ has always been released with
Copyright (c) 2000, Frank Warmerdam as the general license, so I think it is the
reasonable to consider this as the base to use for contributions
unless they state explicitly something else.
The general rules I followed in the case there's no explicit header with copyright & license are:
- files coming from initial commit by Frank in 1999 and present in PROJ 4.3 are copyright Frank
- files without explicit header and coming from SVN or git era are copyright their author
  when it can be recovered from the commit message, or otherwise the committer (Frank most of the times)
I've indicated those 2 situations in the remarks column.

There are a few lines underlined in yellow that might require follow up actions.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Kurt Schwehr-2
Thank you all for the work on the incubation!

Yet another vote for avoiding a CLA.

On Mon, Sep 9, 2019 at 2:26 PM Even Rouault <[hidden email]> wrote:
On lundi 9 septembre 2019 21:20:36 CEST Even Rouault wrote:
> > For other files, "git log" on them and finding the original committer
> > should be good enough.
>
> "git log --follow" to be more exact due to renaming/moving around.

OK, I did the exercice of completing Kristian's initiated source file listing
https://docs.google.com/spreadsheets/d/1Bdu73lw8I1iFX4cb7CIUF6yqWGDTcZKBfW0cUsEjCXk/edit#gid=0
Would be worth being double checked of course.

I've followed an "optimistic" principle, that is to say that we don't have issues
unless strong suspicion of the contrary: PROJ has always been released with
Copyright (c) 2000, Frank Warmerdam as the general license, so I think it is the
reasonable to consider this as the base to use for contributions
unless they state explicitly something else.
The general rules I followed in the case there's no explicit header with copyright & license are:
- files coming from initial commit by Frank in 1999 and present in PROJ 4.3 are copyright Frank
- files without explicit header and coming from SVN or git era are copyright their author
  when it can be recovered from the commit message, or otherwise the committer (Frank most of the times)
I've indicated those 2  situations in the remarks column.

There are a few lines underlined in yellow that might require follow up actions.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Kristian Evers-2
Thanks for you input everyone.

Even, thanks for going through all of the source files! I had hoped to save some work
by crowdsourcing this, but never in a million years had I expected it to be done by
the time I got up the morning after. Very impressive. As far as I can tell there’s only
a minor issues to deal with. 

We have a bunch of files without a license header present. The copyright holder
is inferred from the git log. Should we add headers to those files? Also, in many
files substantial work has been done by several developers, even though only
one is stated as the copyright holder. I assume because the developer has
forgotten to add their name in the header. We can also infer those from git, but
is that something that we ought to do?

Concerning the CLA, I take your responses as enough evidence that we do
not need one of those for the PROJ project :-) I have added the following
statement to the Provenance Review document:

"The project has opted to not ask committers to sign a contribution agreement
because 1) the MIT license is permissive which eliminates the desire to re-license
the software, 2) it's an added layer of complexity to the project and 3) some
developers has expressed that they will not sign such an agreement.”

/Kristian


On 10 Sep 2019, at 05:58, Kurt Schwehr <[hidden email]> wrote:

Thank you all for the work on the incubation!

Yet another vote for avoiding a CLA.

On Mon, Sep 9, 2019 at 2:26 PM Even Rouault <[hidden email]> wrote:
On lundi 9 septembre 2019 21:20:36 CEST Even Rouault wrote:
> > For other files, "git log" on them and finding the original committer
> > should be good enough.
>
> "git log --follow" to be more exact due to renaming/moving around.

OK, I did the exercice of completing Kristian's initiated source file listing
https://docs.google.com/spreadsheets/d/1Bdu73lw8I1iFX4cb7CIUF6yqWGDTcZKBfW0cUsEjCXk/edit#gid=0
Would be worth being double checked of course.

I've followed an "optimistic" principle, that is to say that we don't have issues
unless strong suspicion of the contrary: PROJ has always been released with
Copyright (c) 2000, Frank Warmerdam as the general license, so I think it is the
reasonable to consider this as the base to use for contributions
unless they state explicitly something else.
The general rules I followed in the case there's no explicit header with copyright & license are:
- files coming from initial commit by Frank in 1999 and present in PROJ 4.3 are copyright Frank
- files without explicit header and coming from SVN or git era are copyright their author
  when it can be recovered from the commit message, or otherwise the committer (Frank most of the times)
I've indicated those 2  situations in the remarks column.

There are a few lines underlined in yellow that might require follow up actions.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Sebastiaan Couwenberg
On 9/10/19 8:08 AM, Kristian Evers wrote:
> We have a bunch of files without a license header present. The copyright holder
> is inferred from the git log. Should we add headers to those files? Also, in many
> files substantial work has been done by several developers, even though only
> one is stated as the copyright holder. I assume because the developer has
> forgotten to add their name in the header. We can also infer those from git, but
> is that something that we ought to do?

You'll have assess whether the changes are eligible for copyright from
the diff, as trivial changes aren't copyrightable.

You don't have to add every author of changes, if they don't add a
copyright statement of their own, they may have just chosen to wave
their claim and implicitly grant it to the project.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Even Rouault-2
On mardi 10 septembre 2019 08:15:53 CEST Sebastiaan Couwenberg wrote:
> On 9/10/19 8:08 AM, Kristian Evers wrote:
> > We have a bunch of files without a license header present. The copyright
> > holder is inferred from the git log. Should we add headers to those
> > files?

Adding a copyright & license header on behalf of someone else is probably
something we should not do without their explicit consent. As the project has
a general COPYING file, that should cover those cases. I remember having seen
discussions on the Incubation mailing list where it was said that having a
per-file copyright&license information wasn't an obligation (I believe OSGeo
received legal advice regarding this, but my memory can be wrong)

That said, I'd find it a good practice to require new contributions to have an
explicit header.

> > Also, in many files substantial work has been done by several
> > developers, even though only one is stated as the copyright holder. I
> > assume because the developer has forgotten to add their name in the
> > header. We can also infer those from git, but is that something that we
> > ought to do?
>
> You'll have assess whether the changes are eligible for copyright from
> the diff, as trivial changes aren't copyrightable.
>
> You don't have to add every author of changes, if they don't add a
> copyright statement of their own, they may have just chosen to wave
> their claim and implicitly grant it to the project.

I'm in line with Bas here. Retracing all activity in each file and determine
which one is worth being copyrighted would be a lot of work.

I believe one of the main purposes of this provenance review is to check that
we don't have files explicitly under a proprietary license or under an
incompatible open source license (that's how I perceive
GDAL's https://github.com/OSGeo/gdal/blob/master/gdal/PROVENANCE.TXT was
established)

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Kristian Evers-2


> On 10 Sep 2019, at 11:55, Even Rouault <[hidden email]> wrote:
>
> On mardi 10 septembre 2019 08:15:53 CEST Sebastiaan Couwenberg wrote:
>> On 9/10/19 8:08 AM, Kristian Evers wrote:
>>> We have a bunch of files without a license header present. The copyright
>>> holder is inferred from the git log. Should we add headers to those
>>> files?
>
> Adding a copyright & license header on behalf of someone else is probably
> something we should not do without their explicit consent. As the project has
> a general COPYING file, that should cover those cases. I remember having seen
> discussions on the Incubation mailing list where it was said that having a
> per-file copyright&license information wasn't an obligation (I believe OSGeo
> received legal advice regarding this, but my memory can be wrong)
>
> That said, I'd find it a good practice to require new contributions to have an
> explicit header.

Let’s leave it at that. New files are required to include the license text at the top.
I’ll find somewhere relevant to put that info.

>
>>> Also, in many files substantial work has been done by several
>>> developers, even though only one is stated as the copyright holder. I
>>> assume because the developer has forgotten to add their name in the
>>> header. We can also infer those from git, but is that something that we
>>> ought to do?
>>
>> You'll have assess whether the changes are eligible for copyright from
>> the diff, as trivial changes aren't copyrightable.
>>
>> You don't have to add every author of changes, if they don't add a
>> copyright statement of their own, they may have just chosen to wave
>> their claim and implicitly grant it to the project.
>
> I'm in line with Bas here. Retracing all activity in each file and determine
> which one is worth being copyrighted would be a lot of work.

Definitely af lot of work. And I am happy to not do it if it is not required.

>
> I believe one of the main purposes of this provenance review is to check that
> we don't have files explicitly under a proprietary license or under an
> incompatible open source license (that's how I perceive
> GDAL's https://github.com/OSGeo/gdal/blob/master/gdal/PROVENANCE.TXT was
> established)
>

…and as far as I can tell we don’t have any problems. I will fill out the list
of copyright holders when I need a break from other work. With that, I think
we can declare the provenance review done. The logo is then the only thing
missing before we can submit the checklist to the incubation committee.

/Kristian

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Martin Desruisseaux-3
Le 10/09/2019 à 12:25, Kristian Evers a écrit :

> I think we can declare the provenance review done. The logo is then
> the only thing missing before we can submit the checklist to the
> incubation committee.
>
Just curious, what is the strategy chosen regarding EPSG data? They are
free for redistribution, but under some conditions that are a little bit
different than open-source licenses.

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Sebastiaan Couwenberg
On 9/10/19 12:32 PM, Martin Desruisseaux wrote:
> Le 10/09/2019 à 12:25, Kristian Evers a écrit :
>> I think we can declare the provenance review done. The logo is then
>> the only thing missing before we can submit the checklist to the
>> incubation committee.
>
> Just curious, what is the strategy chosen regarding EPSG data? They are
> free for redistribution, but under some conditions that are a little bit
> different than open-source licenses.

See the trac ticket for my take on it:

 https://trac.osgeo.org/osgeo/ticket/2268#comment:2

TL;DR: As long as the data is not attributed to the EPSG dataset, the
terms of the MIT license used for PROJ can also cover the SQL files and
resulting database.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Martin Desruisseaux-3

Thanks for the link to the ticket. One minor correction:

PROJ support the Well-Known Text and Well-Known Text2 described in the ISO 19111 standard on "Referencing by coordinates". I am not aware of any official certification. To the best of my knownledge PROJ is the first application to implement WKT2, so it can in some sense be regarded as a reference implementation.
To my knowledge, the first open-source project to support ISO 19162 (a.k.a. WKT2) was an ESRI prototype [1] and the second project was Apache SIS [2] since 2017. PROJ is third. PROJ is however the first project to my knowledge to implement the WKT2 update published in 2019, but this is a relatively minor revision of ISO 19162:2015 (compared to WKT 1).

On EPSG, can we really said that the data fail under MIT license because we do not modify it? The EPSG terms of use said:

You are obliged to inform anyone to whom you provide the EPSG Facilities of these Terms of Use.
So we need to inform users that they can not modify those data without changing the EPSG name. And also that they can not extract the data and sell them alone (without the added value of PROJ or other software). Those conditions are not MIT terms.

The Apache Software Foundation legal team has debated about the permission to include EPSG data in Apache software [3], and our conclusion was that we can not provide them directly. We do that indirectly by providing the data in a "non-free" package and require an explicit action from users (which we try to make as simple as possible) to get them.

Regards,

    Martin

[1] https://github.com/Esri/ogc-crs-wkt-parser
[2] http://sis.apache.org/
[3] https://issues.apache.org/jira/browse/LEGAL-183


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Sebastiaan Couwenberg
On 9/10/19 1:16 PM, Martin Desruisseaux wrote:
> On EPSG, can we really said that the data fail under MIT license because
> we do not modify it? The EPSG terms of use said:
>
>> You are obliged to inform anyone to whom you provide the EPSG
>> Facilities of these Terms of Use.
> So we need to inform users that they can not modify those data without
> changing the EPSG name. And also that they can not extract the data and
> sell them alone (without the added value of PROJ or other software).
> Those conditions are not MIT terms.

Unless PROJ already modifies the data and doesn't attribute it to the
EPSG dataset. There is no epsg init file any more, there is proj.db now.

Not being a lawyer I cannot provide an authoritative answer, only my
interpretation.

> The Apache Software Foundation legal team has debated about the
> permission to include EPSG data in Apache software [3], and our
> conclusion was that we can not provide them directly. We do that
> indirectly by providing the data in a "non-free" package and require an
> explicit action from users (which we try to make as simple as possible)
> to get them.

I hope we can prevent this situation with proj, as we'll revert back to
the one with libgeotiff-epsg which few users installed despite needing it.

In the worst case scenario proj moves to non-free and everything that
depends on it to contrib, making them not part of Debian and loose QA
coverage, autobuilding and the like. This would be very harmful to users.

I would stick to the working theory until IOGP complains and proves us
otherwise.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OSGeo incubation status

Martin Desruisseaux-3
Le 10/09/2019 à 13:50, Sebastiaan Couwenberg a écrit :

> Unless PROJ already modifies the data and doesn't attribute it to the
> EPSG dataset. There is no epsg init file any more, there is proj.db now.
>
On the "PROJ already modifies the data" part, that fact that PROJ
rewrites EPSG tables in a slightly different database structure is not
the essential thing. The EPSG terms of use allows such conversions
provided that data are numerically equivalent. The proj.db file in PROJ
6 is (to my knowledge) compliant with this condition, which is a very
good thing.

On the "doesn't attribute it to the EPSG dataset" part, in my
understanding we are attributing those definitions to EPSG dataset as
long as we use the "EPSG" authority name in "EPSG::4326", or that the
documentation claims to support EPSG codes. But since PROJ 6 is
compliant, this is not a problem.

The issue is that EPSG wants all users downstream to continue to comply
to those conditions, which is why they want us to inform users. I'm not
a lawyer neither, but my understanding of discussions I have seen at
Apache and at OGC (including with IOGP staffs) is that packaging the
same data in a different format does not erase EPSG ownership on those data.

Of course this is only my point of view. But maybe a verification by
someone more familiar than me on legal topics would be desirable.

Regards,

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj