[Incubator] 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
<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 <jody.garnett at gmail.com> 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 <alexgleith at gmail.com> 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 <jody.garnett at gmail.com> 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 <alexgleith at gmail.com> 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 <even.rouault at spatialys.com>
>>>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20200514/f0f37639/attachment.html>