CGAL/SFCGAL/PostGIS License Implications Clarification Documentation

[thx1138]

I'm preparing to upgrade an installation of Postgis in the near future and am excited to try out SFCGAL due to its robustness improvements for PostGIS functions. However, I was extremely confused by the astoundingly complicated dual GPL/LGPL license terms of CGAL upon which SFCGAL and Postgis now depend.

The Postgis FAQ ​http://postgis.net/docs/PostGIS_FAQ.html#license_faq implies that there should be no issues for a commercial app -unless that app actually modifies the postgis source:

3.19.

I am releasing software that uses PostGIS, does that mean my software has to be licensed using the GPL like PostGIS? Will I have to publish all my code if I use PostGIS?

Almost certainly not. As an example, consider Oracle database running on Linux. Linux is GPL, Oracle is not, does Oracle running on Linux have to be distributed using the GPL? No. So your software can use a PostgreSQL/PostGIS database as much as it wants and be under any license you like.

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.

However looking at the CGAL website​http://www.cgal.org/license.html they mention the following:

The GPL (v3+) is an Open Source license that, gives you the right to use, copy and modify the code freely. If you distribute your software based on GPLed CGAL data structures, you are obliged to distribute the modifications of CGAL you made, and you are furthermore obliged to distribute the source code of your own software under the GPL.

...and their product licensing page​http://geometryfactory.com/products/licenses/ shows even more confusing information:

Industrial Development License

This is the license for industrial users who integrate our software components in applications that they commercialize or that they use internally, for example in a production chain.

The price of a component is independent from the numbers of developers in the same company using it. It is a one shot fee, that is there are no royalties to pay when you distribute your software with our components inside.

Taken together, this information leads a person not familiar with the fine intricacies of software licensing (like myself) to the following possible contradictory conclusions:

1. It's safe to use ALL SFCGAL functions in a commercial PostGIS app regardless of whether or not the underlying CGAL code is GPLed unless you are modifying the cgal or Postgis source code.

2. It's safe to use ALL SFCGAL functions in a commercial app because the PostGIS functions are only pulling from the LGPL portion of CGAL

3. It is not safe to use any SFCGAL function in a commercial PostGIS app unless you look at each individual function definition in PostGIS/SFCGAL, trace it to the CGAL source files and determine if those files are GPL or LGPL.

PostGIS with SFCGAL support is now widely available on Ubuntu via a simple apt-get and I don't imagine most developers would expect that they would be required to release all of their app source code or pay $10,000+ if their app runs select st_union(geom) with an SFCGAL backend on their db.

TL;DR; Given that PostGIS is widely used, I think it would be worth clarifying the SFCGAL licensing situation and posting a clear answer on the FAQ and in the documentation. Also, if the use of individual SFCGAL-based functions would require purchasing a commercial license or releasing source code, I think it would be worth adding that information to the applicable function docs so that it is clear to users.

[gdt]

Note that I am not a lawyer. My one actual bit of advice is that you need actual legal advice from an actual lawyer with expertise in software licensing, as opposed to opinions from a a bunch of geo coder geeks. If you do get it, it would be a service to the community to publish it.

As a general comment on situations like this (without commenting on your specific case), the contentious issue is what constitutes a derived work. Under copyright law (absent fair use, which for a commercial product is not the best example :-), you need permission from the copyright holder to create a derived work. Everybody agrees that editing the source code is a derived work. Everybody agrees that writing to published APIs that are widely implemented, like POSIX, is not. The text from the postgis faq is arguing that a program that makes SQL calls from a different process is not a derived work.

People often say that linking (including headers, and putting procedures in the same binary) is the defining notion of derived work, but it's not clear that the law sees it that way. In my experience, lawyers tend to see CS details as just details, and ask the larger question if the entire work is based on a smaller one, with RPC vs static vs dynamic linking not being a big deal.

Your question, presumably, turns into whether code that links only against libpq or equivalent, and does SQL to a pgsql instance with postgis/sfcgal/cgal loaded is a derived work. That's a hard question to get a safe answer to.

There's another consideration, which is being a good citizen of the Free Software community and respecting the author's wishes about the extent to which use is a derived work. However, many view GPL/proprietary dual licensing unfavorably, not only in its own right, but also because projects like that tend to insist on CLA or grant of rights under a permissive license for contirbutions, instead of the typical Free Software practice of contributions being on the same terms as the project's license (called "inbound = outbound").

Before you talk to a lawyer, it would be good to research whether the SQL involved that describes things that get evaluated by CGAL is specified by standards for which there are multiple implementations, or whether it is specific to something only in CGAL. I'm not saying that's definitive - just that it's a likely question from your lawyer.

[gdt]

Perhaps cgal should be asked to clarify that "use of data structures" does or doesn't include programs that talk SQL to a pgsql db with postgis/cgal. If that doesn't resolve favorably, perhaps cgal should default to off, and be recommended default off for packaging.

[robe]

This might be something to bring up on PostGIS develop (or PostGIS Users) where SFCGAL devs hang out. I think we might have some lawyers on PostGIS users :). If you are not already subscribed to either, I suggest you do.

​https://lists.osgeo.org/mailman/listinfo/postgis-devel

​https://lists.osgeo.org/mailman/listinfo/postgis-users

[thx1138]

Ok, I will ask in the mailing list. I just figured this was a pretty common question people have, given that SFCGAL has now replaced basic functions like st_intersects() and st_union(), so thought it might be worth adding to the FAQ. If people need an industrial license (hoping that's not the case) to use Postgis with SFCGAL as the backend db for an app -it might affect a large number of Postgis installations.

[pramsey]

It's not really a common question, and frankly anyone who is twisting their knickers about it should be equally/more worried that PostGIS itself is fully GPL. But as the FAQ says: that doesn't matter if you're just calling SQL on the database. CGAL is using GPL FUD to drive folks to purchase commercial licenses, just like MySQL does/did. If you are building an app that actually links CGAL, then you have an issue. Using PostGIS, you do not.

I added a sentence at r15642, hopefully it doesn't make things worse. I find that GPL fear makes these conversations very hard at the best of times.