Hi Angelos and Even,
Thanks for enlightening us with very thoughtful and pertinent points
and comments.
It would be great to have a broader view on this
and hope to hear from others in our community.
Best
Venka
P.S. Even, congratulations on your 10 years + 2 days since
your first commit to GDAL project!! Many thanks!
On 8/19/2017 9: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 :-)
* 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
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss
