Is PostGIS effectively LGPL?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Is PostGIS effectively LGPL?

Bruce Momjian
I know PostGIS is GPL licensed.  However, I thought the major difference
between the GPL and the LGPL was that the LGPL didn't require
applications that link with the LGPL software to honor the LGPL
requirements.

Since PostGIS doesn't force applications that link to PostGIS to honor
the GPL license, isn't PostGIS more like LGPL than GPL?  Here is the
linking exception in the PostGIS FAQ:

        http://postgis.net/docs/manual-dev/PostGIS_FAQ.html#license_faq

FYI, This differs from the Free Software Foundation's interpretation of
the GPL linking/license-transfer requirement:

        https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Regina Obe
I wouldn't say essentially LGPL.

The thing is that when PostGIS is used, it is via linking or the psql  and similar driver API.  So e.g. PostgreSQL can exist without PostGIS and your software can call PostGIS functions without embedding PostGIS into it and alls stored functions are in source code anyway if you sell to a customer.

It falls under this exception:

https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

Now if you were to take the source code of PostGIS and compile it into your own software, then your software I think would then be governed by the

https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL  you describe.


Just my two cents,
Regina



-----Original Message-----
From: postgis-users [mailto:[hidden email]] On Behalf Of Bruce Momjian
Sent: Wednesday, December 21, 2016 1:29 PM
To: [hidden email]
Subject: [postgis-users] Is PostGIS effectively LGPL?

I know PostGIS is GPL licensed.  However, I thought the major difference between the GPL and the LGPL was that the LGPL didn't require applications that link with the LGPL software to honor the LGPL requirements.

Since PostGIS doesn't force applications that link to PostGIS to honor the GPL license, isn't PostGIS more like LGPL than GPL?  Here is the linking exception in the PostGIS FAQ:

        http://postgis.net/docs/manual-dev/PostGIS_FAQ.html#license_faq

FYI, This differs from the Free Software Foundation's interpretation of the GPL linking/license-transfer requirement:

        https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Paul Ramsey
In reply to this post by Bruce Momjian
Imagine PgSQL was GPL. Would most users of PgSQL have any concerns about that? Probably not, right, because they are just using the unmodified database, all their proprietary IP would be on the other side of the client/server boundary.

That's 99.9% of the questions about PostGIS licensing, right there.

That leaves folks who are shipping proprietary PgSQL with PostGIS added in. Are you wondering about them?

P


On Wed, Dec 21, 2016 at 10:28 AM, Bruce Momjian <[hidden email]> wrote:
I know PostGIS is GPL licensed.  However, I thought the major difference
between the GPL and the LGPL was that the LGPL didn't require
applications that link with the LGPL software to honor the LGPL
requirements.

Since PostGIS doesn't force applications that link to PostGIS to honor
the GPL license, isn't PostGIS more like LGPL than GPL?  Here is the
linking exception in the PostGIS FAQ:

        http://postgis.net/docs/manual-dev/PostGIS_FAQ.html#license_faq

FYI, This differs from the Free Software Foundation's interpretation of
the GPL linking/license-transfer requirement:

        https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Bruce Momjian
In reply to this post by Regina Obe
On Wed, Dec 21, 2016 at 02:12:36PM -0500, Regina Obe wrote:
> I wouldn't say essentially LGPL.
>
> The thing is that when PostGIS is used, it is via linking or the psql
> and similar driver API.  So e.g. PostgreSQL can exist without PostGIS
> and your software can call PostGIS functions without embedding PostGIS
> into it and alls stored functions are in source code anyway if you
> sell to a customer.

Well, some companies modify the Postgres server and ship a closed-source
binary, plus some people have compiled C functions or extensions that
might be closed source.

> It falls under this exception:
>
> https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

Well, I am sure some do ship PostGIS along with the closed-source
Postgres backend binary, and the system library exception excludes that.

        https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

> Now if you were to take the source code of PostGIS and compile it into
> your own software, then your software I think would then be governed
> by the
>
> https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL you
> describe.

Right.  I am asking more about dymanic linking into the Postgres server
binary.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Bruce Momjian
In reply to this post by Paul Ramsey
On Wed, Dec 21, 2016 at 11:31:56AM -0800, Paul Ramsey wrote:
> Imagine PgSQL was GPL. Would most users of PgSQL have any concerns about that?

Yes, they would it would affect closed-source versions of the Postgres
backend, as well as perhaps closed source/binary functions and
extensions.

> Probably not, right, because they are just using the unmodified database, all
> their proprietary IP would be on the other side of the client/server boundary.

Right, but that is not what the FAQ addresses, I thought.
>
> That's 99.9% of the questions about PostGIS licensing, right there.
>
> That leaves folks who are shipping proprietary PgSQL with PostGIS added in. Are
> you wondering about them?

Yes, plus things like server-side functions and triggers.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Paul Ramsey


On Wed, Dec 21, 2016 at 11:46 AM, Bruce Momjian <[hidden email]> wrote:
On Wed, Dec 21, 2016 at 11:31:56AM -0800, Paul Ramsey wrote:
> Imagine PgSQL was GPL. Would most users of PgSQL have any concerns about that?

Yes, they would it would affect closed-source versions of the Postgres
backend, as well as perhaps closed source/binary functions and
extensions.

"Most users" would have concerns w/ closed source PgSQL and proprietary forks? I'm guessing that 99.9% of our user community is using the community open source version w/o alteration. Or in the case of AWS Aurora, using a forked version of PgSQL that is not being "distributed".
 
> Probably not, right, because they are just using the unmodified database, all
> their proprietary IP would be on the other side of the client/server boundary.

Right, but that is not what the FAQ addresses, I thought.

Then we should clarify it a bit, because it's mostly about those Frequent questions on "I'm building a SaaS thing using PgSQL/PostGIS, so I have to share all my code?". Basically questions about stuff that's on the far side of the client/server dividing line. Almost nobody asking the licensing question has actually modified either PgSQL or PostGIS.
 
> That leaves folks who are shipping proprietary PgSQL with PostGIS added in. Are
> you wondering about them?

Yes, plus things like server-side functions and triggers.

For the "proprietary fork of PgSQL folks", which are a very small subset of the user community, things are greyer and we leave it to their own lawyers to determine how comfortable they are w/ it.  Our internal "we care about it" policy has been more LGPL'ish, in that we're concerned w/ people shipping closed, modified versions of PostGIS (apologies to strk if I'm granting more leniency than he might like). However, that doesn't stop lawyers and folks from applying a stronger interpretation around shipping proprietary PgSQL w/ un-modified community PostGIS. Does PgSQL depend on PostGIS? No. You can run it w/o. You can even have your users download a plug-in separate from the shipping PgSQL, so that you aren't "distributing" both parts together (I believe that's the line that historically EDB has taken w/ PostgresPlus?). There's all kinds of tap-dancing, depending on what companies have decided feels right. We aren't a $1B company, we aren't suing anybody, do your due diligence and abide by the spirit of the license as best you can.

P.
 

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Bruce Momjian
On Wed, Dec 21, 2016 at 12:12:16PM -0800, Paul Ramsey wrote:
>     Yes, they would it would affect closed-source versions of the Postgres
>     backend, as well as perhaps closed source/binary functions and
>     extensions.
>
>
> "Most users" would have concerns w/ closed source PgSQL and proprietary forks?
> I'm guessing that 99.9% of our user community is using the community open
> source version w/o alteration. Or in the case of AWS Aurora, using a forked
> version of PgSQL that is not being "distributed".

Yes, but the example in the FAQ talks about running Oracle on Linux, so
it is referring to a closed-source database there too.  There is no talk
about client-side apps vs. the database server in that FAQ.

>     > Probably not, right, because they are just using the unmodified database,
>     all
>     > their proprietary IP would be on the other side of the client/server
>     boundary.
>
>     Right, but that is not what the FAQ addresses, I thought.
>
>
> Then we should clarify it a bit, because it's mostly about those Frequent
> questions on "I'm building a SaaS thing using PgSQL/PostGIS, so I have to share
> all my code?". Basically questions about stuff that's on the far side of the
> client/server dividing line. Almost nobody asking the licensing question has
> actually modified either PgSQL or PostGIS.

Well, imagine someone writes a closed-source server-side function that
calls PostGIS functions.  Is that allowed?

>     > That leaves folks who are shipping proprietary PgSQL with PostGIS added
>     in. Are
>     > you wondering about them?
>
>     Yes, plus things like server-side functions and triggers.
>
>
> For the "proprietary fork of PgSQL folks", which are a very small subset of the
> user community, things are greyer and we leave it to their own lawyers to
> determine how comfortable they are w/ it.  Our internal "we care about it"
> policy has been more LGPL'ish, in that we're concerned w/ people shipping
> closed, modified versions of PostGIS (apologies to strk if I'm granting more
> leniency than he might like). However, that doesn't stop lawyers and folks from

Yes, that was my analysis too in reading the FAQ, that you are more LGPL
than GPL in this area.  My original question was how you were
_different_ from LGPL, even though you are listed as GPL.

I think the dynamic linking thing has always been unclear so clarifying
it in the FAQ is fine, if in fact that is what is says, and other
projects have done this clarification.  Right now I am not sure where
PostGIS is on this issue.

I will state that I think the FSF keeps the linking thing vague on
purpose.

> applying a stronger interpretation around shipping proprietary PgSQL w/
> un-modified community PostGIS. Does PgSQL depend on PostGIS? No. You can run it
> w/o. You can even have your users download a plug-in separate from the shipping
> PgSQL, so that you aren't "distributing" both parts together (I believe that's
> the line that historically EDB has taken w/ PostgresPlus?). There's all kinds

Yes, for EDB you install the closed-source server and then you can add
PostGIS later.  They are not shipped as combined.

> of tap-dancing, depending on what companies have decided feels right. We aren't
> a $1B company, we aren't suing anybody, do your due diligence and abide by the
> spirit of the license as best you can.

Well, these license issues can change if we rely just on intent, e.g.
Oracle buys Sun.  It is good to have it in an FAQ that everyone can
read.  You can change the FAQ, but as long as the text is there people
are clear.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Regina Obe

>> of tap-dancing, depending on what companies have decided feels right.
>> We aren't a $1B company, we aren't suing anybody, do your due
>> diligence and abide by the spirit of the license as best you can.

> Well, these license issues can change if we rely just on intent, e.g.
> Oracle buys Sun.  It is good to have it in an FAQ that everyone can read.  You can change the FAQ, but as long as the text is there people are clear.

I'm all for clarity.  How's this as added to FAQ. I think these points are fairly clear based on GPL and unfuzzify some of the linking issues the GPL glosses over.

1) If you are providing PostGIS via SaaS platform you do not need to provide source code of your application or SaaS platform to customers since you are not distributing binaries.
2) If you provide a closed source fork of PostgreSQL or some other database platform that uses PostGIS as an extension, you should distribute PostGIS separately from the core
application/database platform if you do not want to be obliged to provide the source code of your closed fork to your customers.

3) If your version of PostGIS requires changing the source code of PostGIS in any way, you must provide these changes to customers in source code form as well as your whole application if you distribute them together.

4) If you develop an extension that relies on PostGIS, you do not need to distribute the source of this extension unless you are distributing PostGIS library together with the extension.

Thoughts,
Regina





 


_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Bruce Momjian
On Wed, Dec 21, 2016 at 04:21:09PM -0500, Regina Obe wrote:
> > Well, these license issues can change if we rely just on intent,
> > e.g.  Oracle buys Sun.  It is good to have it in an FAQ that
> > everyone can read.  You can change the FAQ, but as long as the text
> > is there people are clear.
>
> I'm all for clarity.  How's this as added to FAQ. I think these points

Yes, improving the FAQ is probably the way to go.

> are fairly clear based on GPL and unfuzzify some of the linking issues
> the GPL glosses over.
>
> 1) If you are providing PostGIS via SaaS platform you do not need to
> provide source code of your application or SaaS platform to customers
> since you are not distributing binaries.

True.

> 2) If you provide a closed source fork of PostgreSQL or some other
> database platform that uses PostGIS as an extension, you should
> distribute PostGIS separately from the core application/database
> platform if you do not want to be obliged to provide the source code
> of your closed fork to your customers.

I think this is explaining how to avoid the requirement rather than
explaining the requirement first.  I think you need to state that if you
ship PostGIS together with a closed-source Postgres server binary, you
need to provide source code for the server binary and all other object
files shipped in the same package.  To avoid this, you can ship PostGIS
seprately.

> 3) If your version of PostGIS requires changing the source code of
> PostGIS in any way, you must provide these changes to customers in
> source code form as well as your whole application if you distribute
> them together.

I don't think you have to ship your application source code in this
case.

> 4) If you develop an extension that relies on PostGIS, you do not need
> to distribute the source of this extension unless you are distributing
> PostGIS library together with the extension.

I think that is true.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Paul Norman
In reply to this post by Regina Obe
On 12/21/2016 1:21 PM, Regina Obe wrote:
> I'm all for clarity.  How's this as added to FAQ. I think these points are fairly clear based on GPL and unfuzzify some of the linking issues the GPL glosses over.

I think the liblwgeom case should also be listed, where you're using
part of PostGIS as a library.
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Regina Obe
In reply to this post by Bruce Momjian

>> 3) If your version of PostGIS requires changing the source code of
>> PostGIS in any way, you must provide these changes to customers in
>> source code form as well as your whole application if you distribute
>> them together.

> I don't think you have to ship your application source code in this case.

I think I was being a little redundant in this case.

I meant you need to make available the source code of both if you are shipping them together
and  you always have to make available the code for the PostGIS fork as at the very least the fork would also be under GPL.

The point I was trying to make, admittedly very badly, is say you like in case of SQLite that does use PostGIS (liblgeom component) via SpatiaLite,
If you change PostGIS just so it can connect seamlessly with your forked SQLite or Firebird or whatever, then chances are you'd want to ship them together for ease of user experience.

In that case, you would be obliged to make available the source code of both parts regardless of if they are compiled together or dynamically linked.

This is redundant with the earlier of shipping PostGIS with anything even if you didn't make any changes to PostGIS, your application/database fork would still be under the GPL "uses software" vague clause.

I'm also thinking I should change the word, "provide" to "make available" as its' rare packagers ship code with the binaries
And most customers don't want the code anyway, but want it available to them should they need to change it.

Hope that clarifies things,
Regina

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Sandro Santilli-4
In reply to this post by Bruce Momjian
On Wed, Dec 21, 2016 at 03:25:28PM -0500, Bruce Momjian wrote:
>
> Well, imagine someone writes a closed-source server-side function that
> calls PostGIS functions.  Is that allowed?

It is allowed to write the function, but if such function is *distributed*,
then it will need to be distributed under the GPL license.

> I think the dynamic linking thing has always been unclear so clarifying
> it in the FAQ is fine, if in fact that is what is says, and other
> projects have done this clarification.  Right now I am not sure where
> PostGIS is on this issue.

To me using SQL from plpgsql or sql to call PostGIS is not to be
considered linking, while using DirectFunctionCall or directly
calling liblwgeom functions is.

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Is PostGIS effectively LGPL?

Bruce Momjian
On Fri, Dec 23, 2016 at 05:14:07PM +0100, Sandro Santilli wrote:
> On Wed, Dec 21, 2016 at 03:25:28PM -0500, Bruce Momjian wrote:
> >
> > Well, imagine someone writes a closed-source server-side function that
> > calls PostGIS functions.  Is that allowed?
>
> It is allowed to write the function, but if such function is *distributed*,
> then it will need to be distributed under the GPL license.

Yes, that is my reading of the GPL too, though I think only if PostGIS
is distributed to the user with the function.

The FAQ is misleading on this point:

        http://www.postgis.net/docs/manual-dev/PostGIS_FAQ.html#license_faq
       
        The only exception would be if you made changes to the PostGIS source
        code, and distributed your changed version of PostGIS. In that case you
        would have to share the code of your changed PostGIS (but not the code
        of applications running on top of it). Even in this limited case, you
        would still only have to distribute source code to people you
        distributed binaries to. The GPL does not require that you publish your
        source code, only that you share it with people you give binaries to.

Obviously, modifying PostGIS is not the _only_ case in which
developer-generated source code must be distributed.

> > I think the dynamic linking thing has always been unclear so clarifying
> > it in the FAQ is fine, if in fact that is what is says, and other
> > projects have done this clarification.  Right now I am not sure where
> > PostGIS is on this issue.
>
> To me using SQL from plpgsql or sql to call PostGIS is not to be
> considered linking, while using DirectFunctionCall or directly
> calling liblwgeom functions is.

Agreed.  I think the two cases that are linking are server-side C
functions that call PostGIS functions and the Postgres backend binary.

I don't know how this interacts with whether the user downloads PostGIS
independently, but this clearly is not covered in the license FAQ.  I
guess it isn't an FAQ if I am the only one asking about it, though.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users