I would prefer just to make an interface in the GeoServer source tree and be
done with it, but that code would fall under the GPL license just by being
placed in the GeoServer source tree, according to Andrea. Since implementors
don't need to make use of any GeoServer classes, this is unnecessarily
restrictive. Unless it's not the case that the interface has to be GPL...
Yep, Guava has what we need; no need to bring in another Functor. The only
thing that bugs me is the lack of generic tuples; right now we can express
F:A->B but can't express F:A->B->C, for example, and just have to rely on
arrays or special-case structs for functions that take multiple arguments.
(There might already be a tuple on the classpath; I just can't find any.)
________________________________
From: Jody Garnett <[email protected]>
Sent: Sunday, September 15, 2013 10:48 PM
To: Justin Deoliveira
Cc: Dustin Parker; Andrea Aime; [email protected]; Dale F.
McIntosh
Subject: Re: [Geoserver-devel] GeoServer notification plugin
It is not really that murky, any of our GeoServer plugins tend to implement a
GeoServer interface of some sort ... thus making it very clear that they need
to be GPL. They require some GPL code in order to compile.
The exception is plugins that implement a GeoTools interface, such as a
DataStore. These only depend on LGPL which places fewer restrictions on the
result code.
Indeed a mix of these two approaches is possible (and recommended). You will
see a number of ideas that have a datastore or raster format in GeoTools,
backed up by a GeoServer community module donating addition user interface code.
I do not think we make use of the GPL classpath exception license (indeed since
GeoServer is GPL we do not require the classpath exception for our application
to be run on the JVM).
Jody
On Mon, Sep 16, 2013 at 12:16 AM, Justin Deoliveira
<[email protected]<mailto:[email protected]>> wrote:
Hey Dustin,
I generally suggest that people try to avoid extra dependencies if not needed,
especially in core modules. However given that this is itself a plugin I don't
think that is a show stopper. Although there does seem to be overlap with the
commons functor library and the guava library that we already depend on.
That said, I wonder why not just make NotificationSink an interface or abstract
class? And then allow folks to provide implementations via spring contexts.
This would more follow the typical geoserver extension point architecture.
Regarding the licensing of classes provided by a plugin via spring, it is
unfortunately murky waters. As I understand it the "gpl classpath exception"
allows one to license plug-ins differently than the core of GeoServer.
Unfortunately it is something that isn't really well understood in my
experience which hinders its usefulness. Jody actually knows much more about it
and can provide some guidance.
-Justin
On Thu, Sep 12, 2013 at 5:23 PM, Dustin Parker
<[email protected]<mailto:[email protected]>> wrote:
Okay, forget the public API part. How about this hypothetical API:
1. There's a bean type (call it NotificationSink) in the wfs-notification
plugin that is used to dispatch notifications. Users create more of these by
dropping its name into their own applicationContext.xml, but they don't need to
bind to it in their own Java code.
2. NotificationSink can take one or two functors:
* A mandatory function that takes a String (or byte[]?) that represents a
serialized message
* An optional predicate that returns boolean to indicate whether or not the
sink is ready to receive input
3. Those functors can refer to a specific instance of a class by being
non-static inner classes themselves.
4. Spring can inject those functors into a NotificationSink by way of an
instance factory. (Make a specialized notification class and provide getters
that return functors.)
I'm not married to the details at this point, just trying to determine
feasibility.
Apache Commons Functor provides a set of interfaces that could be used, so that
would be an extra dependency.
With that in mind, if a Spring configuration file names a class licensed under
the GPL, does that make the Spring config class a "derivative work" for the
purposes of the GPL?
--
Dustin Parker - Forward Slope, Inc.
Cell: 619 277 2591<tel:619%20277%202591>
SYBWB UI EXCEFI EK BEIF IRXMSURK SR BTBWF YMHEK
OWRZXBH--KBES, OXEMIUZXB, EKD CWRKV. - Y. X. HBKNABK
H4sIAOlx7FACA02MuQ7CMBQEe3/FdjTgcIWrSUMBFQVI1A5+2BaJ
HcUPTP6eU4J2dmb37o49K0MR4Yw1lVdjnDdiJHGwinFSvsewqmnI
SzH+Uh0o/jiCR92hVifrPEkx+VrRhmul//upxNF27xz8Uj5DIXKJ
ne1ji0jPg5nEJiRopz8W3ahFCu2lEHOJePMoK1WTWDwrT9CqQyIk
V1VIrWMCU+QoBrDMzSrLShWtDK3JimU+zBcj8QDNJmEc9gAAAA==
On 2013-09-06 23:04, Andrea Aime wrote:
On Fri, Sep 6, 2013 at 8:16 PM, Dustin Parker
<[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>> wrote:
By the way, I forked/branched and made it an actual community module:
https://github.com/dustinparker/geoserver/tree/wfs-notification
In src/community/wfs-notification there are two sub-modules: the
plugin itself and an API. I want to release the plugin has to be
GPL because it binds to GPL'd code, but I want the API to be LGPL
and only use GeoTools. This will make it much easier from a
licensing perspective for others to add any new messaging
providers they may need. Do y'all have any thoughts on that? Is
this approach even kosher, or do I need to publish the API outside
and somehow get it into a public repository?
No code in the GeoServer repository can be GPL'd, the license at the top of the
source tree applies
to the whole tree as far as I remember.
Either you contribute that API to GeoTools (and it has to make sense as a first
class component of it),
or you build a separate project containing the API, and have your GeoServer
plugin (GPL'd) depend on it.
Generally speaking to dodge the GPL you have to set it up so that whatever
you're writing makes sense
without any GeoServer environment around it, the moment you use even one bit of
GeoServer you're
back to GPL.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313<tel:%2B39%200584%20962313>
fax: +39 0584 1660272<tel:%2B39%200584%201660272>
mob: +39 339 8844549<tel:%2B39%20%20339%208844549>
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
