<div><div dir="auto">Yes this is why I used my own project to illustrate CLA. It is not my goal to be put down anyone. Indeed my employer has the occasional proprietary, one has to choose an appropriate approach for the intended market.</div><div dir="auto"><br></div><div dir="auto">Jody</div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 24, 2021 at 12:46 AM Peter Baumann <<a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
folks, be careful.<br>
<br>
OSGeo, in its limited view on the world, is again starting getting
derogative about rasdaman. <br>
<br>
Please be careful about your choice of words in the context of
rasdaman - probably we all do not want to open this discussion
again.<br>
<br>
-Peter</div><div><br>
<br>
<br>
<div>On 24.09.21 06:43, Bruce Bannerman
wrote:<br>
</div>
<blockquote type="cite">
Regarding OSI Licenses, I understand this Jody.
<div><br>
</div>
<div>However this position does not cater for undesirable
proprietary dual license aspects.</div>
<div><br>
</div>
<div>Again the Rasdaman example. From memory, at the time
of the incubation vote, this product was subject to dual
licensing, the open source variant using approved OSI licences.
However the open source version was severely constrained,
particularly from aspects that improved product performance.</div>
<div><br>
</div>
<div>Consequently, at the time of the incubation vote,
one member of the Incubation Committee described the open source
variant as “crippleware”.</div>
<div><br>
</div>
<div><br>
</div>
<div>Now I don’t want to make this about one product.</div>
<div><br>
</div>
<div>I’d like to see us have a clear position to avoid
such problems in the future. I don’t think that we can just say
that we don’t accept the Benevelent Dictator model and that
solves all problems.</div>
<div><br>
</div>
<div>I also don’t want to see us chase away involvement
in projects and project sponsorship by proprietary
organisations. This would be foolish.</div>
<div><br>
</div>
<div><br>
</div>
<div>I have a similar view on CLAs. If used
appropriately, they can protect a codebase and make it easier to
manage IP arrangements should it become necessary. </div>
<div><br>
</div>
<div>But I also understand that they can be abused with
undesirable outcomes for an open source community. There are
many examples of these that we can all recall quite easily. </div>
<div><br>
</div>
<div>Kind regards,</div>
<div><br>
</div>
<div>Bruce</div>
<div><br>
</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On 24 Sep 2021, at 02:37, Jody Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Bruce:
<div><br>
</div>
<div>We presently follow the OSI approved list,
much easier to follow then to manage our own criteria.</div>
<div><br>
</div>
<div>However this discussion appears to be
around governance and control; and I think we are very
clear on these topics. Even during the Rasdaman
discussion we were very clear that the benevolent
dictator model did not meet our goals for open
governance. It was frustrating this the discussion
took so long: benevolent dictator is of course a
valid model, it is just not one that matches our
ideals.</div>
<div><br>
</div>
<div>OSGeo does support (and sometimes require)
CLAs providing asymmetrical rights on code bases such
as GeoTools and GeoServer (<a href="https://www.osgeo.org/about/licenses/" target="_blank">https://www.osgeo.org/about/licenses/</a>).
This increased permissions for the PSC has allowed
these committees to donate fixes to more permissive
projects such as GeoServer (GPL with EPL exception)
--> GeoTools (LGPL); or GeoTools (LGPL) to JTS
(BSD). The use of CLA to establish asymmetrical rights
has a community building use in this respect; however
the same tool is used to enable some of the harmful
(to the open community) practices being remarked on.</div>
<div>
<div><br>
</div>
<div>It is a shame folks like Elasticsearch
and MapBox abandoning open source, as I really
appreciate it as a way to produce excellent software
and manage risk across a wide range of stakeholders.
In many cases the justifications feel self imposed.
If an organization is not seeing enough
contributions to justify continuing a project as
open source, I can point to an organization that did
not setup equal governance to promote contributions
between equals.</div>
<div><br>
</div>
<div>Personally I like free-software, and
open-source software held by a vendor neutral
organization (such as OSGeo). Everything else seems
a bit risky.</div>
<div><br>
</div>
<div>OSGeo does not provide such a hard line,
but by stressing projects need to be willing for
others to take part in governance (no benevolent
dictator model) I believe the foundation is clear in
what kind of project we support. There is a reason
projects such as MapBoxGL or Cesium did not apply to
be part of OSGeo after all.</div>
<div>
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Jody Garnett</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 22 Sept 2021
at 17:31, Bruce Bannerman <<a href="mailto:bruce.bannerman.osgeo@gmail.com" target="_blank">bruce.bannerman.osgeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div dir="auto">
<div dir="ltr">Hi Jody,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">These thoughts extend on
your ‘there can be only one’ comment below.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I think that we in the
Incubation Committee and our potential future
incubating projects would benefit from our better
defining what type of open source project we will
support.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Greg Troxel contributed
valuable insight into a discussion that we were
having in the OSGeo Standards list on the proposed
OGC/OSGeo MOU. See [1] for context.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">With apologies to Greg for
my paraphrasing, I understand Greg’s arguments to
strongly differentiate between open source
projects that are subject to proprietary
relicensing and those that are not. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Greg contributed the blog
link at [2] as part of the discussion. This is an
insightful read.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">If we had had a clear policy
on the type of open source project that we are
willing to support during the unfortunate
situation with the Rasdaman Incubation vote, we
could have avoided a lot of the angst and
miscommunication that occurred on both sides.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">So before we progress too
much further on the ‘Platforms’ discussion, I
think that it would be beneficial to resolve the
OSGeo Incubation supported open source model issue
definitively. I believe that this will make it
much easier to progress the platforms discussion,
and future incubations.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div dir="ltr">While I have concerns over
the interpretation of what a Contributions
Licence is, I believe that the links at [1] and
[2] are a good starting point to get this sorted
out.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Kind regards,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Bruce</div>
<div><br>
</div>
</div>
<div dir="ltr">[1] <a href="https://lists.osgeo.org/pipermail/standards/2021-September/001274.html" target="_blank">https://lists.osgeo.org/pipermail/standards/2021-September/001274.html</a></div>
<div dir="ltr"><br>
</div>
<div dir="ltr">[2] <a href="https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/" style="font-family:Helvetica;font-size:12px" target="_blank">https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/</a> </div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On 17 Sep 2021,
at 01:59, Jody Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="auto">It is kind of like the
“highlander-principle” if the phrase “there
can be only one” applies … you are not open
source.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Jody</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed,
Sep 15, 2021 at 6:38 PM Jody Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div dir="ltr">
<div>There is a useful
definition of a framework (quite
technical) here <a href="https://en.wikipedia.org/wiki/Software_framework" target="_blank">https://en.wikipedia.org/wiki/Software_framework</a></div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Software
frameworks have these distinguishing
features that separate them from
libraries or normal user
applications: <a href="https://en.wikipedia.org/wiki/Software_framework" target="_blank">https://en.wikipedia.org/wiki/Software_framework</a>
<ul>
<li>inversion of control -
In a framework, unlike in
libraries or normal user
applications, the overall
program's flow of control is not
dictated by the caller, but by the
framework.[1]</li>
</ul>
<ul>
<li>default behavior - A
framework has a default behavior.
This default behavior must
actually be some useful behavior
and not a series of no-ops.</li>
</ul>
<ul>
<li>extensibility - A
framework can be extended by the
user usually by selective
overriding or specialized by user
code providing specific
functionality.</li>
</ul>
<ul>
<li>non-modifiable
framework code - The framework
code, in general, is not allowed
to be modified. Users can extend
the framework, but not modify its
code.</li>
</ul>
</blockquote>
<div>While all of that is
technically true it is perhaps a bit
too detailed for our purpose.</div>
<div><br>
</div>
<div>The core distinction is
earlier in the thread:</div>
<div>- Does your open source
code support a single website? Or is
is setup for use by others?</div>
<div>- Are you building a
community around services? This is a
user community ...</div>
<div>- Are you building a
community around software? This is
still a user community ...</div>
<div>- Are you building a
community around software where the
software source code is available to
look at? This is still a user
community ... looking at you
Elasticsearch</div>
<div>- Are you building a
community around software with shared
responsibility and risk (enabled by a
license to view *and change* source
code)? This is a free or open-source
community (depending on which license
chosen by the group)</div>
<div><br>
</div>
<div>--<br>
Jody Garnett<br>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Fri, 3 Sept 2021 at 18:32, Bruce
Bannerman <<a href="mailto:bruce.bannerman.osgeo@gmail.com" target="_blank">bruce.bannerman.osgeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div dir="auto">
<div dir="ltr">Jody,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I don’t
expect anything constructive from
the AGM. People won’t have time to
reflect.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">…now what is
a ‘Framework’?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I suggest
that we define what we support and
take it from there. We can always
adjust, if required.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Kind
regards,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Bruce</div>
<div dir="ltr"><br>
<blockquote type="cite">On
4 Sep 2021, at 05:27, Jody
Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Thanks
Bruce,
<div><br>
</div>
<div>I did not get
anything useful from the
board; perhaps it is a
subject for the AGM.</div>
<div><br>
</div>
<div>For now the way
forward seems to be to
recast the platform as a
framework and ensure the
resulting software stack and
be picked up and run
independently (with a
quickstart or similar).</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Jody
Garnett</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed,
14 Jul 2021 at 21:57, Bruce
Bannerman <<a href="mailto:bruce.bannerman.osgeo@gmail.com" target="_blank">bruce.bannerman.osgeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div style="word-wrap:break-word;line-break:after-white-space">Thanks Jody,
<div><br>
</div>
<div>Personally:</div>
<div><br>
</div>
<div>
<ul>
<li>I don’t
mind a situation
where an open source
project attempts to
develop and maintain
software that is
intended to
integrate a number
of software
components into a
working product
which could perhaps
be called a
platform.</li>
</ul>
<div><br>
</div>
<ul>
<li>I can see
many situations
where the ‘platform’
might deploy both
components and the
platform’s specific
customisations
concurrently.</li>
</ul>
<div><br>
</div>
<ul>
<li>However,
I would not support
a situation where
that product (or
platform) can only
be implemented once.
I’d prefer that it
can be implemented
many times by
different
organisations.</li>
</ul>
<div><br>
</div>
<ul>
<li>While
such a ‘platform’
project would look
after its own
"integration related
software", I’d see
that the individual
components would be
subject to their own
open source project
community’s
governance
practices.</li>
</ul>
<div><br>
</div>
<ul>
<li>This
could get quite
messy, when the
integration related
software is actually
a customisation of
an existing software
component with its
own open source
community already in
existence. This
would require
careful and close
collaboration
between both
communities…</li>
</ul>
<div><br>
</div>
<div>That will
do for now, let’s see
what others think.</div>
<div><br>
</div>
<div>Kind
regards,</div>
<div><br>
</div>
<div>Bruce</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div>On 15
Jul 2021, at
01:21, Jody
Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">It is
indeed
overloaded, and
no I cannot
clarify as the
applicants that
are coming in
are slightly
different from
each other.
<div><br>
</div>
<div>Turn-key
portals such
as <a href="https://www.osgeo.org/choose-a-project/information-technology/portal/" target="_blank">https://www.osgeo.org/choose-a-project/information-technology/portal/</a>
these showcase
a range of
projects. Some
like geomoose
are presented
as frameworks,
others
like GC2/Vidi
are presented
as a platform.</div>
<div><br>
</div>
<div>I
would be
cautious about
an open source
project that
just supports
a single
website (like <a href="http://github.com/mapstory" target="_blank">http://github.com/mapstory</a>),
but perhaps
that is my own
bias? There is
an advantage
to users of a
platform being
able to review
the code
responsible
for the
service they
are using. But
this
represents new
ground for
OSGeo,
hence the
discussion.</div>
<div><br>
</div>
<div>I
also brought
this
discussion to
the osgeo
board list; so
we do not need
to decide on
our own.</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Jody
Garnett</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Tue, 13 Jul
2021 at 18:56,
Bruce
Bannerman <<a href="mailto:bruce.bannerman.osgeo@gmail.com" target="_blank">bruce.bannerman.osgeo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi
Jody,<br>
<br>
The concept of
a platform is
quite
overloaded and
means
different
things to
different
people.<br>
<br>
Can you please
clarify what
you mean by
‘platform’?<br>
<br>
Kind regards,<br>
<br>
Bruce<br>
<br>
<br>
> On 12 Jul
2021, at
18:30, Jody
Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>>
wrote:<br>
> <br>
>
Discussion
topic for
incubation
committee:<br>
> <br>
> We are
getting
applications
from platforms
seeking to
join OSGeo.<br>
> <br>
> What do
you think?<br>
> --<br>
> Jody
Garnett<br>
>
_______________________________________________<br>
> Incubator
mailing list<br>
> <a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/incubator" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/incubator</a><br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Jody Garnett</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
Incubator mailing list
<a href="mailto:Incubator@lists.osgeo.org" style="font-family:monospace" target="_blank">Incubator@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/incubator" style="font-family:monospace" target="_blank">https://lists.osgeo.org/mailman/listinfo/incubator</a>
</pre>
</blockquote>
<br>
</div><div><pre cols="80" style="font-family:monospace">--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
<a href="https://www.faculty.jacobs-university.de/pbaumann" style="font-family:monospace" target="_blank">https://www.faculty.jacobs-university.de/pbaumann</a>
mail: <a href="mailto:p.baumann@jacobs-university.de" style="font-family:monospace" target="_blank">p.baumann@jacobs-university.de</a>
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
<a href="https://rasdaman.com" style="font-family:monospace" target="_blank">https://rasdaman.com</a>, mail: <a href="mailto:baumann@rasdaman.com" style="font-family:monospace" target="_blank">baumann@rasdaman.com</a>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
</pre>
</div>
_______________________________________________<br>
Incubator mailing list<br>
<a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/incubator" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/incubator</a><br>
</blockquote></div></div>
</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Jody Garnett</div></div></div></div></div>