The Open Data Cube as a OSGeo Community Project

Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The Open Data Cube as a OSGeo Community Project

Alex Leith
Hey Folks

After a too long hiatus, I'm back with a checked list of tasks for the ODC to become an OSGeo Community project.

Here's the list:

  1. Be geospatial
  2. Have a free license or an open source license.
    • The license must be OSI approved
    • We ask that the project team check the file headers and double check the license has been appropriately applied
      • We could use some feedback here. Should there be headers on all files?
  3. Welcome participation and new contributors.
    • We look for a clear contribution policy
    • We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
      • We have a long history of contributions and code review on a number of repositories, including the core and the ows engine.
    • Projects are required to have a code of conduct

So, I think file headers is the only outstanding issue. It would be great to get some input on what we should do here. I'll go do some research now.

Kind regards,

Alex 

--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

jody.garnett
Thanks for the progress Alex, I have not had much capacity for incubation list in April :)

As for headers try for the basics: 1) project name 2) that it is open source

But really the license you are using should tell you what to do for headers, does it have examples of how to apply it to code?

Really we want you to check that you wrote the code, or that everyone who wrote the code did so knowing it was going to be distributed as open source.

You use Apache License 2.0, that foundation has some guidance here: https://www.apache.org/legal/src-headers.html

Since you are not actually distributed by the Apache Foundation you will need to work on that example to reflect the organization that is distributing the code. Have a look around at what other projects have done.

--
Jody Garnett


On Sun, 26 Apr 2020 at 17:56, Alex Leith <[hidden email]> wrote:
Hey Folks

After a too long hiatus, I'm back with a checked list of tasks for the ODC to become an OSGeo Community project.

Here's the list:

  1. Be geospatial
  2. Have a free license or an open source license.
    • The license must be OSI approved
    • We ask that the project team check the file headers and double check the license has been appropriately applied
      • We could use some feedback here. Should there be headers on all files?
  3. Welcome participation and new contributors.
    • We look for a clear contribution policy
    • We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
      • We have a long history of contributions and code review on a number of repositories, including the core and the ows engine.
    • Projects are required to have a code of conduct

So, I think file headers is the only outstanding issue. It would be great to get some input on what we should do here. I'll go do some research now.

Kind regards,

Alex 

--
Alex Leith
m: 0419189050
_______________________________________________
Incubator mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/incubator

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

Re: The Open Data Cube as a OSGeo Community Project

Alex Leith
Hey Jody

Thanks for the advice.

We had a look at the Apache license documentation and it says:

>Each original source document (code and documentation, but not the LICENSE and NOTICE files) should include a short license header

Does the OSGeo Project process require the license to be in headers, or simply encourage?

Regarding headers, since we don't have an Open Data Cube organisation that is doing the distribution, do you or others have any feedback on what a minimal header might look like? Something like this, say:

This file is licensed to you under the Apache License, Version
2.0 (the "License"); you may not use this file except in 
compliance with the License. You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

Kind regards,



On Wed, 6 May 2020 at 15:13, Jody Garnett <[hidden email]> wrote:
Thanks for the progress Alex, I have not had much capacity for incubation list in April :)

As for headers try for the basics: 1) project name 2) that it is open source

But really the license you are using should tell you what to do for headers, does it have examples of how to apply it to code?

Really we want you to check that you wrote the code, or that everyone who wrote the code did so knowing it was going to be distributed as open source.

You use Apache License 2.0, that foundation has some guidance here: https://www.apache.org/legal/src-headers.html

Since you are not actually distributed by the Apache Foundation you will need to work on that example to reflect the organization that is distributing the code. Have a look around at what other projects have done.

--
Jody Garnett


On Sun, 26 Apr 2020 at 17:56, Alex Leith <[hidden email]> wrote:
Hey Folks

After a too long hiatus, I'm back with a checked list of tasks for the ODC to become an OSGeo Community project.

Here's the list:

  1. Be geospatial
  2. Have a free license or an open source license.
    • The license must be OSI approved
    • We ask that the project team check the file headers and double check the license has been appropriately applied
      • We could use some feedback here. Should there be headers on all files?
  3. Welcome participation and new contributors.
    • We look for a clear contribution policy
    • We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
      • We have a long history of contributions and code review on a number of repositories, including the core and the ows engine.
    • Projects are required to have a code of conduct

So, I think file headers is the only outstanding issue. It would be great to get some input on what we should do here. I'll go do some research now.

Kind regards,

Alex 

--
Alex Leith
m: 0419189050
_______________________________________________
Incubator mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/incubator


--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

Even Rouault-2

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


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

Re: The Open Data Cube as a OSGeo Community Project

Alex Leith
Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault <[hidden email]> wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

jody.garnett
This discussion, and your projects decision on how to open source, is why we have this check list.  

It is minimal, the part that is weak is noting the person or organization responsible. Headers with such information can help when doing a providence review (where the code came from), but git history even better :)

So back at you - what is appropriate for your project? And do you find any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith <[hidden email]> wrote:
Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault <[hidden email]> wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



--
Alex Leith
m: 0419189050
--
--
Jody Garnett

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

Re: The Open Data Cube as a OSGeo Community Project

Alex Leith
>person or organisation responsible

Responsible for distribution of the file?

If that's it, I guess I need to go digging for some further examples. Because as I said earlier, we don't have a formal ODC organisation. I could check into whether Geoscience Australia could be that org, but I'm not sure that it should.

And I really hope you're not talking responsible for holding copyright, because that's a far more complex issue!

On Thu, 7 May 2020 at 23:21, Jody Garnett <[hidden email]> wrote:
This discussion, and your projects decision on how to open source, is why we have this check list.  

It is minimal, the part that is weak is noting the person or organization responsible. Headers with such information can help when doing a providence review (where the code came from), but git history even better :)

So back at you - what is appropriate for your project? And do you find any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith <[hidden email]> wrote:
Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault <[hidden email]> wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



--
Alex Leith
m: 0419189050
--
--
Jody Garnett


--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

jody.garnett
Still that is the subject under discussion:
- confirmation that this is open source, and which license?
- are we sure it is open source?
- really? Who wrote this - and did they (or their employer) understand it was being released as open source

Copyright is a slightly different topic, it is a great tool for enforcing the open source license :)

For a community project we ask folks spot check their headers (which catches many of the above questions). For incubation was ask projects dig into the history a bit and confirm the providence of the code (where it came from).
--
Jody Garnett


On Thu, 7 May 2020 at 14:28, Alex Leith <[hidden email]> wrote:
>person or organisation responsible

Responsible for distribution of the file?

If that's it, I guess I need to go digging for some further examples. Because as I said earlier, we don't have a formal ODC organisation. I could check into whether Geoscience Australia could be that org, but I'm not sure that it should.

And I really hope you're not talking responsible for holding copyright, because that's a far more complex issue!

On Thu, 7 May 2020 at 23:21, Jody Garnett <[hidden email]> wrote:
This discussion, and your projects decision on how to open source, is why we have this check list.  

It is minimal, the part that is weak is noting the person or organization responsible. Headers with such information can help when doing a providence review (where the code came from), but git history even better :)

So back at you - what is appropriate for your project? And do you find any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith <[hidden email]> wrote:
Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault <[hidden email]> wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



--
Alex Leith
m: 0419189050
--
--
Jody Garnett


--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

jody.garnett
I went back to check the website (https://www.opendatacube.org) to see who is actually distributing opendatacube. This really is a great example of open source being used as the glue to bind a partner ship of a wide range of organizations. In this case I assume the players (Geoscience Australia, NASA, CSIRO, USGS,Catapult,Analytical Mechanics Associates) are putting in work, which is distributed by a public repository (https://github.com/opendatacube).

1. Checking the history of a random file shows it was created by Kirill888 from Canberra Australia.
2. That is a unique name so I have a good chance of finding him on LinkedIn krill-kouzoubov
3. LinkedIn shows his employer is Geoscience Australia
4. If I assume he is operating as an employee, and not as an individual, GeoScience Australia the legal entity distributing at least part of opendatacube.org as open source.

I think if I find another file we could find a different organization; this really is a shared work.

Notes:
- The kind of research I just did above is a bother, one of the things we are addressing here is getting that detail out of the way so that any potential user or contributor the the project can tell who they are working with (and evaluate risk accordingly).
- This kind of thing where multiple organizations are distributing a shared work are exactly where an open source foundation like OSGeo thrive. In some cases groups find it easier to use a CLA to donate the code to OSGeo which operates as neutral party to distribute the code. OSGeo is willing to do so, but asks that the project set up a committee (usually with representation from the different partners) to manage things.

I am really impressed with opendatacube, if you are happy using Even Rouault's approach you should run with it. The other questions you can save for later in your open source journey.
--
Jody Garnett


On Thu, 7 May 2020 at 15:23, Jody Garnett <[hidden email]> wrote:
Still that is the subject under discussion:
- confirmation that this is open source, and which license?
- are we sure it is open source?
- really? Who wrote this - and did they (or their employer) understand it was being released as open source

Copyright is a slightly different topic, it is a great tool for enforcing the open source license :)

For a community project we ask folks spot check their headers (which catches many of the above questions). For incubation was ask projects dig into the history a bit and confirm the providence of the code (where it came from).
--
Jody Garnett


On Thu, 7 May 2020 at 14:28, Alex Leith <[hidden email]> wrote:
>person or organisation responsible

Responsible for distribution of the file?

If that's it, I guess I need to go digging for some further examples. Because as I said earlier, we don't have a formal ODC organisation. I could check into whether Geoscience Australia could be that org, but I'm not sure that it should.

And I really hope you're not talking responsible for holding copyright, because that's a far more complex issue!

On Thu, 7 May 2020 at 23:21, Jody Garnett <[hidden email]> wrote:
This discussion, and your projects decision on how to open source, is why we have this check list.  

It is minimal, the part that is weak is noting the person or organization responsible. Headers with such information can help when doing a providence review (where the code came from), but git history even better :)

So back at you - what is appropriate for your project? And do you find any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith <[hidden email]> wrote:
Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault <[hidden email]> wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

> Hey Jody

>

> Thanks for the advice.

>

> We had a look at the Apache license documentation and it says:

> >Each original source document (code and documentation, but not the LICENSE

>

> and NOTICE files) *should* include a short license header

> https://infra.apache.org/apply-license.html#new

>

> Does the OSGeo Project process require the license to be in headers, or

> simply encourage?

 

Not speaking on behalf of OSGeo, but I'd suggest using the the one-line variant offered by the SPDX initiative, which is adopted by the Linux Kernel project among others, and has the advantage of conveying explicit non-ambiguous licensing in a short way, and to be easily analyzed by automated tools (compliance checking). Just put the following at the beginning of files (way of commenting to be adopted with the one offered by the programming language)

 

// SPDX-License-Identifier: Apache-2.0

 

See https://spdx.org/ids-how

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



--
Alex Leith
m: 0419189050
--
--
Jody Garnett


--
Alex Leith
m: 0419189050

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

Re: The Open Data Cube as a OSGeo Community Project

Angelos Tzotsos
Big +1 to have opendatacube onboard.

On 5/15/20 9:02 AM, Jody Garnett wrote:
I went back to check the website (https://www.opendatacube.org) to see who
is actually distributing opendatacube. This really is a great example of
open source being used as the glue to bind a partner ship of a wide range
of organizations. In this case I assume the players (Geoscience Australia,
NASA, CSIRO, USGS,Catapult,Analytical Mechanics Associates) are putting in
work, which is distributed by a public repository (
https://github.com/opendatacube).

1. Checking the history of a random file
<https://github.com/opendatacube/datacube-core/commits/develop/datacube/model/__init__.py>
shows
it was created by Kirill888 <https://github.com/Kirill888> from Canberra
Australia.
2. That is a unique name so I have a good chance of finding him on LinkedIn
krill-kouzoubov <https://www.linkedin.com/in/kirill-kouzoubov/>
3. LinkedIn shows his employer is Geoscience Australia
4. If I assume he is operating as an employee, and not as an individual,
GeoScience Australia the legal entity distributing at least part of
opendatacube.org as open source.

I think if I find another file we could find a different organization; this
really is a shared work.

Notes:
- The kind of research I just did above is a bother, one of the things we
are addressing here is getting that detail out of the way so that any
potential user or contributor the the project can tell who they are working
with (and evaluate risk accordingly).
- This kind of thing where multiple organizations are distributing a shared
work are exactly where an open source foundation like OSGeo thrive. In some
cases groups find it easier to use a CLA to donate the code to OSGeo which
operates as neutral party to distribute the code. OSGeo is willing to do
so, but asks that the project set up a committee (usually with
representation from the different partners) to manage things.

I am really impressed with opendatacube, if you are happy using Even
Rouault's approach you should run with it. The other questions you can save
for later in your open source journey.
--
Jody Garnett


On Thu, 7 May 2020 at 15:23, Jody Garnett [hidden email] wrote:

Still that is the subject under discussion:
- confirmation that this is open source, and which license?
- are we sure it is open source?
- really? Who wrote this - and did they (or their employer) understand it
was being released as open source

Copyright is a slightly different topic, it is a great tool for enforcing
the open source license :)

For a community project we ask folks spot check their headers (which
catches many of the above questions). For incubation was ask projects dig
into the history a bit and confirm the providence of the code (where it
came from).
--
Jody Garnett


On Thu, 7 May 2020 at 14:28, Alex Leith [hidden email] wrote:

person or organisation responsible
Responsible for distribution of the file?

If that's it, I guess I need to go digging for some further examples.
Because as I said earlier, we don't have a formal ODC organisation. I could
check into whether Geoscience Australia could be that org, but I'm not sure
that it should.

And I really hope you're not talking responsible for holding copyright,
because that's a far more complex issue!

On Thu, 7 May 2020 at 23:21, Jody Garnett [hidden email] wrote:

This discussion, and your projects decision on how to open source, is
why we have this check list.

It is minimal, the part that is weak is noting the person or
organization responsible. Headers with such information can help when doing
a providence review (where the code came from), but git history even better
:)

So back at you - what is appropriate for your project? And do you find
any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith [hidden email] wrote:

Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault [hidden email]
wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

Hey Jody

                

                

                
Thanks for the advice.

                

                

                
We had a look at the Apache license documentation and it says:

                
Each original source document (code and documentation, but not the
LICENSE


                

                
and NOTICE files) *should* include a short license header

                
https://infra.apache.org/apply-license.html#new

                

                

                
Does the OSGeo Project process require the license to be in headers,
or

simply encourage?


Not speaking on behalf of OSGeo, but I'd suggest using the the
one-line variant offered by the SPDX initiative, which is adopted by the
Linux Kernel project among others, and has the advantage of conveying
explicit non-ambiguous licensing in a short way, and to be easily analyzed
by automated tools (compliance checking). Just put the following at the
beginning of files (way of commenting to be adopted with the one offered by
the programming language)



// SPDX-License-Identifier: Apache-2.0



See https://spdx.org/ids-how



--

Spatialys - Geospatial professional services

http://www.spatialys.com


--
Alex Leith
m: 0419189050

--
--
Jody Garnett


--
Alex Leith
m: 0419189050


      

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


-- 
Angelos Tzotsos, PhD
President
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos

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

Re: The Open Data Cube as a OSGeo Community Project

Alex Leith
Hey Jody and others

I work at Geoscience Australia, and Kirill is on my team. Most of the contributions to the ODC Core codebase are from GA, though there some minor contributions from external individuals and some significant work from CSIRO.

We talked about the code headers and the team in GA feel confident that there is no significant code in there that is not original to the ODC, which is one of the reasons for auditing and adding headers, as I understand it.

I think we'll write some script that goes and adds Even's suggested addition into all the appreciate files. I'll report back when we've merged that in, which will be soonish!

Thanks again for your support here.

Cheers,

On Fri, 15 May 2020 at 21:48, Angelos Tzotsos <[hidden email]> wrote:
Big +1 to have opendatacube onboard.

On 5/15/20 9:02 AM, Jody Garnett wrote:
I went back to check the website (https://www.opendatacube.org) to see who
is actually distributing opendatacube. This really is a great example of
open source being used as the glue to bind a partner ship of a wide range
of organizations. In this case I assume the players (Geoscience Australia,
NASA, CSIRO, USGS,Catapult,Analytical Mechanics Associates) are putting in
work, which is distributed by a public repository (
https://github.com/opendatacube).

1. Checking the history of a random file
<https://github.com/opendatacube/datacube-core/commits/develop/datacube/model/__init__.py>
shows
it was created by Kirill888 <https://github.com/Kirill888> from Canberra
Australia.
2. That is a unique name so I have a good chance of finding him on LinkedIn
krill-kouzoubov <https://www.linkedin.com/in/kirill-kouzoubov/>
3. LinkedIn shows his employer is Geoscience Australia
4. If I assume he is operating as an employee, and not as an individual,
GeoScience Australia the legal entity distributing at least part of
opendatacube.org as open source.

I think if I find another file we could find a different organization; this
really is a shared work.

Notes:
- The kind of research I just did above is a bother, one of the things we
are addressing here is getting that detail out of the way so that any
potential user or contributor the the project can tell who they are working
with (and evaluate risk accordingly).
- This kind of thing where multiple organizations are distributing a shared
work are exactly where an open source foundation like OSGeo thrive. In some
cases groups find it easier to use a CLA to donate the code to OSGeo which
operates as neutral party to distribute the code. OSGeo is willing to do
so, but asks that the project set up a committee (usually with
representation from the different partners) to manage things.

I am really impressed with opendatacube, if you are happy using Even
Rouault's approach you should run with it. The other questions you can save
for later in your open source journey.
--
Jody Garnett


On Thu, 7 May 2020 at 15:23, Jody Garnett [hidden email] wrote:

Still that is the subject under discussion:
- confirmation that this is open source, and which license?
- are we sure it is open source?
- really? Who wrote this - and did they (or their employer) understand it
was being released as open source

Copyright is a slightly different topic, it is a great tool for enforcing
the open source license :)

For a community project we ask folks spot check their headers (which
catches many of the above questions). For incubation was ask projects dig
into the history a bit and confirm the providence of the code (where it
came from).
--
Jody Garnett


On Thu, 7 May 2020 at 14:28, Alex Leith [hidden email] wrote:

person or organisation responsible
Responsible for distribution of the file?

If that's it, I guess I need to go digging for some further examples.
Because as I said earlier, we don't have a formal ODC organisation. I could
check into whether Geoscience Australia could be that org, but I'm not sure
that it should.

And I really hope you're not talking responsible for holding copyright,
because that's a far more complex issue!

On Thu, 7 May 2020 at 23:21, Jody Garnett [hidden email] wrote:

This discussion, and your projects decision on how to open source, is
why we have this check list.

It is minimal, the part that is weak is noting the person or
organization responsible. Headers with such information can help when doing
a providence review (where the code came from), but git history even better
:)

So back at you - what is appropriate for your project? And do you find
any odd files when checking your headers? Most projects do...

On Wed, May 6, 2020 at 6:53 PM Alex Leith [hidden email] wrote:

Thanks Even, that looks like a really simple solution!

Does anyone see any issues with Even's proposed approach?

On Thu, 7 May 2020 at 09:22, Even Rouault [hidden email]
wrote:

On jeudi 7 mai 2020 09:09:01 CEST Alex Leith wrote:

Hey Jody

                

                

                
Thanks for the advice.

                

                

                
We had a look at the Apache license documentation and it says:

                
Each original source document (code and documentation, but not the
LICENSE


                

                
and NOTICE files) *should* include a short license header

                
https://infra.apache.org/apply-license.html#new

                

                

                
Does the OSGeo Project process require the license to be in headers,
or

simply encourage?
Not speaking on behalf of OSGeo, but I'd suggest using the the
one-line variant offered by the SPDX initiative, which is adopted by the
Linux Kernel project among others, and has the advantage of conveying
explicit non-ambiguous licensing in a short way, and to be easily analyzed
by automated tools (compliance checking). Just put the following at the
beginning of files (way of commenting to be adopted with the one offered by
the programming language)



// SPDX-License-Identifier: Apache-2.0



See https://spdx.org/ids-how



--

Spatialys - Geospatial professional services

http://www.spatialys.com

--
Alex Leith
m: 0419189050

--
--
Jody Garnett

--
Alex Leith
m: 0419189050


      

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


-- 
Angelos Tzotsos, PhD
President
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
_______________________________________________
Incubator mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/incubator


--
Alex Leith
m: 0419189050

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