[OSGeo-Discuss] Proposal for the listing of projects in our new web site

[Jachym Cepicky]

Hi,

just noting: there can be currently "Community projects" and "Other
projects" on the new OSGeo web page

I agree, being "official OSGeo Community projects" requires some rules and
approval process

IMHO the "new proposed rules" are ok, if you want just your project appear
on OSGeo Web page as "other project", it still should be peer-reviewed by
some of the page administrators, but that would not make you to community
project

example: Yesterday I add Gisquick to new OSGeo web page
http://osgeo.getinteractive.nl/projects/gisquick/ it should be listed among
"Other projects", not community

hope, it's ok?

J



ne 20. 8. 2017 v 1:07 odesílatel James Klassen <klassen.js at gmail.com>
napsal:

> I generally agree with Even's comments.
>
> W.r.t. Not requireing other licenses clause, I would like to add a
> question about how this would apply to free software that is mostly
> intended to operate with non-free data?  e.g. GDAL drivers that enable
> reading proprietary formats via a vendor SDK or formats that tend to only
> be used with strictly licensed data or reading data from non-open standards
> based web services (where you only control the client but the client is
> pointless without a running server which requires its own separate license).
>
> On Aug 19, 2017 08:40, "Even Rouault" <even.rouault at spatialys.com> 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 :-)
>>
>>
>>
>> > * 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 in
>>
>> http://www.osgeo.org/incubator/process/project_graduation_checklist.html
>>
>>
>>
>> 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...
>>
>>
>>
>> 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 ?
>>
>>
>>
>> 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.
>>
>>
>>
>> > 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)
>>
>>
>>
>> +1
>>
>>
>>
>> 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.
>>
>>
>>
>> Even
>>
>>
>>
>>
>>
>> --
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.com
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/discuss
>>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20170821/58480c31/attachment.html>