Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] "Works with" dependency for GeoServer (subset)
I just spoke with Jody and I think that we can wrap this up.

GeoMesa's code extends base classes that are GPL-licensed. This is a no-go, so we have to reject the CQ.

The work around is to do the same sort of thing that other consumers of GeoServer have done: make the extension available as a GeoServer deliverable.

Jody provided some specifics in this thread, but can--if I can speak on his behalf--provide additional assistance as necessary.

I will take care of rejecting the CQ on behalf of the PMC.

Wayne

On 08/12/14 04:49 PM, Jody Garnett wrote:
That matches my understanding David.

Since we are going around in circles on this one, is it worth having a PMC meeting - or asking Eclipse Legal to double check our research. 

I would hate to see GeoMesa held up here, and would like to make sure we have a couple of options for the project to move forward.

--
Jody Garnett

On 5 December 2014 at 17:02, david.w.smiley@xxxxxxxxx <david.w.smiley@xxxxxxxxx> wrote:
I've seen the EFF’s stance on this subject before, which I’ll share:

"There must be some slack as application servers like Tomcat can load up both a GPL Web App and a BSD Web App”
A GPL app can talk-to/implement/use/etc. a non-GPL interface/lib, but the reverse is not so.  The “non-GPL interface/lib” here is the servlet spec, which doesn’t have restrictions on what uses it (to my knowledge).  This neutral ground of the interface being open/permissive allows modules/app-servers to interoperate based on that spec without mutual license problems.

~ David Smiley
Freelance Apache Lucene/Solr Search Consultant/Developer

On Fri, Dec 5, 2014 at 7:22 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
I was not comfortable - but am happy to be corrected if my understanding is wrong.

The difference between interface and base class is does not (in my understanding) line up with the C distinction around header files and implementation (used to enable the idea of linking employed by the GPL). The distinction between base class and interface is even less for Java 8 where default methods can now be introduced for interfaces. The GPL with Classpath exception explicitly provide language for use in Java applications.

Since the GeoServer project uses GPL I believe the intension is that all work making use of that API is itself distributed under the GPL. As a GeoServer PMC member this is the stance we have taken with organizations wanting permission to make additional proprietary web services hooked into the GeoServer catalog. Here is a discussion from 2009 where the issues was discussed (http://comments.gmane.org/gmane.comp.gis.geoserver.devel/6096).

Sorry if I am wearing two hats on this one. I would like to check how GPL considers "linking" handled in Java. There must be some slack as application servers like Tomcat can load up both a GPL Web App and a BSD Web App. I guess the apps can communicate via HTTP (look ma no linking) or possibly share a few resources like JDBC connections via JNDI (the point of Java being distributed as GPL+Classpath). I cannot think of any examples where an implementation of a GPL Interface (or GPL base class) is used - can anyone?
--
Jody



Jody Garnett

On Thu, Dec 4, 2014 at 12:07 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
So are we comfortable declaring this a reasonable "works with" dependency?

Wayne


On 02/12/14 03:24 PM, Frank Gasdorf wrote:
Agree, right now the plugin isn't really an implementation against GPL API's. Especially the UI-contributions make use of GPL implementations (e.g. StorePanel, StoreProvider, etc).

GNU GPL : "The GPL requires that all derivative works be licensed as a whole under the terms of the GPL, an effect which can be described as “hereditary.” 

My read is : extended classes or other used implementations leads to GPL
However : Implementing against an API would not lead to GPL for own work 

HTH
- Frank  
 



2014-11-28 23:40 GMT+01:00 Jody Garnett <jody.garnett@xxxxxxxxx>:
Afternoon Wayne, had to wait until I had time to hunt down links for you.

To reiterate: I am unsure GeoMesa can include GeoServer user interface contributions in the code hosted at LocationTech. To implement a GeoServer user interface contribution reference must be made to GPL classes making up the GeoServer API.

I skipped a bit quickly past this common problem, in order to focus on the solution the GeoServer community has come up with. GeoServer is well aware that not all data source can meet the restrictions of the GPL license. As a result:
1) All data access code has been moved in the GeoTools project, where appropriate interfaces are provided with a less restrictive "business friendly" LGPL license is used.
2) Connection details required for data access is "advertised" as meta-data by an implementor as part of the DataStoreFactorySPI interface getParams() method. Using this metadata GeoServer will generate a user interface suitable for casual use.
3) Finally (if the generated user interface is not considered usable enough) we have a section of the code base called "community" (informal - no QA or docs) or "extensions" (formal - QA and Doc requirements met) where the few user interface classes that must be GPL can be hosted.

Armed with this background let me provide a couple of examples.

DB2
DB2 minimal example where auto-generated user interface is enough:

- https://github.com/geoserver/geoserver/tree/master/src/extension/db2 (geoserver extension, just contains a dependency on geotools)

In this case DB2 supported has been added by implementing a JDBCDialect and supporting classes from the GeoTools project.

ArcSDE
ArcSDE example uses this LGPL/GPL separation to allow interaction with a proprietary API.


The implementation of ArcSDECoverageStoreEditPanel implements the GPL interface StoredEditPanel. This is packaged as a GeoServer extension in order to hold code using GPL interfaces. The ArcSDEDataStore is extends the ContentStore base class from the GeoTools project.

I hope those two examples are sufficient? The use of GeoTools LGPL Interfaces allows implementors a great deal of freedom in choice of license (BSD, EPL, MIT, LGPL or even GPL).
--
Jody



Jody Garnett

On Mon, Nov 24, 2014 at 8:39 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
Actually, before we go there...

Is this templating feature what you mean by "custom pages"?

http://docs.geoserver.org/latest/en/user/tutorials/GetFeatureInfo/index.html

Or is it something else? Can you give me a pointer to a specific example?

Wayne


On 24/11/14 11:35 AM, Wayne Beaton wrote:
My apologies for dropping the ball.

The GeoServer project is aware of these limitations and has a "community module" section that can be used host optional integration such as custom pages. For many DataStores the connection parameters described by DataStoreFactorySpi is descriptive enough to generate a connection page.
If I understand this correctly, as long as the GeoMesa project uses this "community module" as the Glue to GeoServer, you believe that we're in good shape.

Is that accurate?

Wayne

On 23/09/14 11:54 AM, Jody Garnett wrote:
Yes that was my understanding.

Indeed this understanding led to the geogig geoserver module being removed from our initial contribution.

Jody

Jody Garnett

On Mon, Sep 22, 2014 at 6:47 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
Hi Jody.

I'm not sure that I understand your concern. I think that there might be a missing question.

Is it your concern that the implementation of a GeoServer interface constitutes linking?

Wayne


On 22/09/14 06:23 PM, Jody Garnett wrote:
This should be a clear works with dependency. 

* Custom DataStore configuration page to allow a GeoMesa DataStore to be used in GeoServer.
This could be a toned down to "works with GeoTools". 
* Implementation of various WPS processes, such as import into GeoMesa, an enhanced heat map, and various analytics.
In general WPS processes could be toned down to "Works with GeoTools".
A custom "Import into GeoMesa" may require access to GeoServer catalog? See discussion on GPL below...
* Custom GeoServer pages that allow monitoring and inspection of GeoMesa data
This is tricky as it requires making use of GPL interfaces.

I always found it confusing as the language used in source code licenses refers to linking - a concept which does not directly match what we do in Java.

I could see this two ways:

1) Custom pages depend on GeoServer API to compile, but cannot be instantiated by the JVM unless deployed in a GeoServer environment. Result: Custom page is not "linked" and can be distributed as with GeoMesa project.

2) Custom page implements GeoServer interface, considered GPL, and cannot be disturbed with main GeoMesa project. For GeoGig we chose this interpretation (separated "tight" GeoServer integration out into a seperate project) to avoid any use of GPL license.


The GeoServer project is aware of these limitations and has a "community module" section that can be used host optional integration such as custom pages. For many DataStores the connection parameters described by DataStoreFactorySpi is descriptive enough to generate a connection page.

If a custom page is not considered to be GPL we would happily fold our GeoServer integration back into the GeoGig project (rather than create a community module).
--
Jody

Per the Guidelines for the Review of Third Party Dependencies [2]:
The Eclipse software does not require the third party software to be present. If the third  
party software happens to be present, the Eclipse software may call or invoke it.  
Example: If a web browser is present, clicking on URL's in Eclipse will cause the user's  
configured web browser to open the URL.  

If you have any concerns, please make them known on this thread. If you are satisfied with the laid out criteria and are confident that this qualifies as a "works with" dependency, please express your approval with a +1 on this thread.

I'll leave this thread open for a couple of days to give all members a chance to express their concerns/approval. I'll set the flag on the CQ.

Thanks,

Wayne

[1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8744
[2] https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon Europe 2014

_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc



_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon Europe 2014

_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc



_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon 2015


_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon 2015

_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc


_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc



_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon 2015

_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc


_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc


_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc



_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon 2015

Back to the top