[OSGeo-Discuss] Proposal for the listing of projects in our new web site
gcpp.kalxas at gmail.com
Sun Oct 8 09:03:46 PDT 2017
One action item from a recent board meeting was to help review the
community project rules.
Even has raised some interesting points some time ago and I think it
would be valuable to follow up on this discussion with help from
Some comments inline:
On 08/19/2017 03:39 PM, Even Rouault wrote:
> Hi Angelos,
> thanks for turning those discussions into a positive way forward and your proposal sounds
> good to me. A few comments below.
>> I would like to propose a way forward:
>> 1. We should *only* promote projects that are somehow affiliated with OSGeo
>> (as other Free and Open Source organizations do eg. Apache, Eclipse)
> Makes sense. When you promote something on your website, you are somewhat responsible
> for it, so you must ensure that it meets some minimum criteria that are in the "OSGeo spirit"
>> A proposal for *new* rules:
>> * Has to have an OSI or FSF approved license and be found on the web in a
>> public place.
> Sounds obvious, but we should probably rephrase that "Source code is released with an OSI
> or FSF approved license and is available on the web in a public place."
> I know at least one project that is Apache licensed but released only as binaries, which makes
> it not very convenient to modify :-)
I agree with the new phrasing.
>> * Has to be useful on its own with normal data, and NOT require another
>> license to really use it
> Is it something that is currently required for graduation ? I don't see this criterion mentioned
> That one is probably tricky to write correctly. Stated like this, that would for example exclude
> a Windows executable, since to use it you must own a Windows license... Even if you take a
> Linux executable that is X/MIT licensed, it links against the GNU libc that is GPL licensed (but
> as GNU libc is considered part of the OS, there's a provision in the GPL license to not apply
> the GPL obligations to the code that links to it). Or if you take a Java program, it must run
> within a JVM that comes with its own license. Same for Python, etc...
We definitely need to review the phrasing.
This is indeed something we do not check for graduation, perhaps just
because we did not get an application with such issues.
> But beyond this nitpicking, that criterion can raise more fundamental debates:
> * is the intent to exclude projects that would be open-source released plugins of a
> proprietary software for example (the plugin could be an exporter from proprietary formats/
> projects to open source ones for example) ?
> * Or open-source released projects that would connect to a proprietary server (just saw in
> LWN headlines that Debian is currently debating whether they should allow OSS software
> that connect to proprietary services) ?
> * What about a fully open-source project that connects to a proprietary service ?
Very interesting points.
In my opinion, we should make sure that we do not list projects that
only require a proprietary server to work with. Even if they are fully
open source, one would need to pay the server side to actually use them...
> If I take the exemple of GDAL, the following situations can be found:
> * it is X/MIT licensed but can link to a few GPL licensed lib (poppler, GRASS, ...)
> * it can link to proprietrary licensed libs
> * it can interact with proprietary services that have a public API, but don't require linking
> against proprietary code
> * other/most parts are fully useful on their own
> So I think this question alone could deserve its own thread.
Offering interaction with proprietary services/libraries is completely
different from requiring them to work properly, so I do not see an issue
with GDAL obviously :)
>> The project should need to officially apply for being included as OSGeo
>> Community Project, by answering a questionnaire (including information
>> gathering for the web site and provide a point of contact for maintaining
>> that information in the future)
> Relation question: if OSGeo website promotes a community project, should the website of
> this project (or github page if no dedicated website) links to OSGeo one ? I'm not even sure
> this is a requirement for a graduated project.
I think that most graduated projects link to OSGeo. Perhaps we should
look again as part of the project review the board is initiating.
Angelos Tzotsos, PhD
Open Source Geospatial Foundation
More information about the Discuss