Open source geospatial software use continues to grow, as more users realize the value it brings an organization in reducing license management and costs, preventing single vendor lock-in, and promoting interoperability. As a result, Boundless now has a number of partners and integrators who have developed both open and closed solutions on top of Boundless Suite. Building open solutions enables an organization to leverage the advantages of community participation. Namely that you aren’t maintaining your own forked code base, but are fulfilling your social obligation to share back with the community, and allowing for contributed code to live within the open source community. On the other hand, developing proprietary or closed solutions in conjunction with open source allows greater control of intellectual property.
For many, open source licensing is still somewhat of an unknown, and there are many questions surrounding how to build closed solutions around, or in conjunction with, open source software. Unfortunately, this confusion has led to hesitation in adopting open source. For those using the Boundless Distribution of QGIS 2.14.1 release, Tim Sutton did a great job clarifying some of this in a recent QGIS blog post. Boundless initially posted a blog about closed solutions on top of open source back in 2012, but given how fast things change in the IT world, perhaps now is a good time to revisit the topic.
This blog post is focused on the use of open source licenses in distributing software to your customers. We hope to help organizations better understand open source licensing, and dispel any rumors around how it can be incorporated in closed solutions.
Licenses Used in the Boundless Platform
For starters, we should make clear that Boundless releases software under several different open source licenses, depending on the technology and how it is used. For example, OpenLayers is a library for building web applications, whereas Boundless Connect is a plug-in for the Boundless distribution of the QGIS desktop application.
The following tables describe the licenses used by key components.
Combining Open Source and Proprietary Software
Before we talk about integrating solutions on top of the Boundless Platform, we need to understand the key differences between open source licenses.
- Software using a permissive license places minimal restrictions on how software may be distributed.
- Libraries using a weakly protective license wish to remain open source (for your customers) but allow for integration with proprietary software.
- Components using a strongly protective license are required to maintain license if changes or additions are made.
The differences of permissive, weak and strong licenses will guide our understanding of where closed software can be integrated with Boundless Suite and Boundless Desktop. These restrictions are all expressed in terms of software distribution to your customer, not necessarily the general public. These licenses place no obligations on contributing changes to the community, which we can cover more in-depth in a subsequent blog post.
The terms of each license allow certain licenses to be compatible (shown as arrows in the above diagram). As an example, code written for GeoTools (LGPL) can be included in GeoServer (GPL) as the additional constraints provided by GPL do not prevent the terms of LGPL being met.
Berkeley Software Distribution (BSD)
The BSD license permits commercial use, such as including the software in your own application or website. The only restriction is the inclusion of a license and copyright notice in any work you create. Your own work remains unaffected.
Apache License v2.0
The Apache License is a permissive license similar to the MIT and BSD licenses with some additional benefits. The Apache License provides additional language around patents with clear pathways for both open and closed code development. But there is no obligation to make a contribution, and licensees are free to take their Derivative Work and license it under a different license.
GNU Lesser General Public License (LGPL)
The GNU Lesser General Public License (LGPL) is another license created for the purpose of permitting libraries to be licensed as open source, while permitting integration with proprietary software. In fact, LGPL was formerly known as the Library General Public License. LGPL offers weak protection asking that changes made to the library are provided to your customer, and places no restriction on the use of proprietary technology, making it a little more relaxed than the GPL.
Example 1: A connector to a proprietary data format can be written using GeoTools (LGPL) DataStore API. The resulting data source can be distributed in binary form to your customer (with no requirement to make the source code available). To provide your customer with the source code for the GeoTools library, you can point them to the GeoTools website as you have used the library in unmodified form.
Example 2: A connector to a proprietary database format can be written using GeoTools (LGPL). If a fix is required to the core GeoTools library, then the source code of the fix must be made available to your customer (to meet the terms of the LGPL license). The resulting proprietary connector can still be distributed in binary form to your customer.
GNU General Public License (GPL)
GPL states that any modifications made to the original application, and any extensions you make to the application, must be provided to your customer. This enables the original licensed work to be distributed or sold by your customer. So any person can acquire and repackage GPL-licensed software, market it, and sell it without any additional work. This license focuses on safeguarding your customers, ensuring that system administrators running your software have full access to the code they are responsible for.
Example: Developing a new output format for GeoServer must be distributed under a GPL license. This means the compiled executable, and the source code, would need to be made accessible upon request with the purchaser of software. The purchaser of your software can be defined as your customer or the system administrator, but not necessarily the general public.
Some Common FAQs
So we can hear you saying, “Thanks Boundless, all of this information is useful, but what does it mean to an organization who wants to build solutions on top of open source?” The answer depends on what portion of the Boundless Platform you are building a solution on top of, since each software component has a different license. So perhaps the best way to approach this is to answer a few frequently asked questions we tend to receive.
“My organization would like to make changes to the core GeoServer code base. Am I obligated to share those changes back to the community?”
No, you are not obliged to participate in the community. The GPL license states that any modifications made to the core application code must be provided to those deploying the application. So you are obligated to share these changes with your customer upon request, but not necessarily the public.
“My organization would like to create a plugin/extension to GeoServer, but not make any changes to the core GeoServer code base. Am I obligated to share those back to the community?”
No, you are not obliged to share those changes back to the community, but you are required to share the plugin with your customer under the terms of the GPL license.
“My company would like to make a closed web application using open source OpenLayers library. Can I sell the software we make for a fee?”
Yes, this is especially easy for “permissive” licenses such as BSD. You are welcome to combine open libraries with your own proprietary/closed code, and resell that solution for a profit.
“My organization would like to create a process for GeoServer which integrates our proprietary billing system for use by our OpenLayers powered web application. Am I obligated to share this work with our website visitors?”
You are not obligated to share this work with website visitors:
- OpenLayers (BSD) is a permissive license placing no obligation to share your work with website visitors.
- While GeoServer (GPL) is a strong license, these terms are with your system administrator who is running GeoServer (and not the website visitors who are making use of the WPS service). As a web component, GeoServer allows website visitors to make use of the billing process via the industry standard web processing service protocol.
- GeoTools (LGPL) provides a process API under a weak license allowing integration with the proprietary billing system.
“My organization is including GeoServer as part of our software-as-a-service (SaaS) offering, we have added a monitoring extension so our customers can track layer usage in the service management console.”
Your SaaS customers are in effect ‘website visitors’ (of the management console) and do not directly run the GeoServer application on their own hardware. You are not obligated to share your monitoring extension with website visitors.
“My organization created a custom QGIS plugin for a customer. The customer dictates that software developed inside their network cannot be shared back to the general public on the Internet. Am I obligated to share this custom plugin back to the public?”
No, you are not required to share the custom plugin, or its source code, back to the general public. However, GPL states that you are obligated to share the source code with your customer should they request it. But given they are asking for a custom plugin to begin with, sharing the source code should not be an issue.
“If I create a closed solution on top of Open Source, am I required to pay royalties back to the Open Source Community?”
No, there are no royalties or payment of any kind due back to the community. But the use of patents and trademarks are not always covered by an open source license. Some licenses, such as Apache, EPL and GPL provide specific customer protection with respect to patents. In a similar fashion the QGIS project has taken the step of obtaining a trademark to better control project branding. The social obligation of working with open source will be covered in a separate blog post.
“My company would like to run a training course based on the PostGIS workshop found on the Boundless website. Can I sell the course for a fee?”
Yes. The PostGIS workshop (and the other workshops found there) are public and published with a documentation license. The CC-BY license offers authors the same freedoms enjoyed by open source software developers. The CC-BY license allows you to remix the workshop contents (or use it as-is) while requesting “attribution”. This simply means you must tell your customers that the course contains material from Boundless, and let them know if you made changes.
Your legal counsel may ask you to explicitly mention respect of open source licenses in your product and customer contracts. An example of this is the Boundless End User License Agreement (EULA). The Boundless EULA is a RHEL-type EULA which preserves licensing of all constituent components inside Boundless Suite.
(a) OpenGeo Suite (consisting of Composer, GeoServer, GeoWebCache, PostGIS, QGIS Plugin, and OpenLayers software) is available in source code form under the terms of various open source licenses (collectively, the “Open Source Licenses“) at http://www.boundlessgeo.com/legal. Nothing in this Agreement will be construed to limit any rights granted under the Open Source Licenses and the terms of those Open Source Licenses take precedence over any conflicting terms herein with respect to OpenGeo Suite.
You can read the entire EULA here.
If you would like to learn more about the details of the different open source licenses, we recommend you start with a great O’Reilly e-book freely available on the web. Some of the content in this post related to the licenses was derived from this great resource. And we encourage all our users to work with Boundless to help them understand how to make the most out of open source GIS, and how to work with the various licenses the open source projects are released under.
And if you are interested in writing your own open software, you might also visit the Open Source Initiative to read more about the permissiveness of each license. If you are still confused about what license works best, have a look at the decision tree here http://choosealicense.com/.
This post was originally published by Boundless on their blog.