Open Development
2 likes858 views
The document discusses the importance of open development and open data, highlighting the relevance of standards and open-source software in geospatial data management. It outlines various licenses like BSD, GPL, and LGPL, emphasizing the balance between user freedoms and developer protections. Additionally, it touches on governance practices in open-source projects and the risks associated with adopting new software components.
Open Development
- 2. Open Data • Spatial Data is important – Expensive and time-consuming to collect – Use of standards facilitates the reuse and repurposing of existing data – Datasets tend to have a very long lifespan • It is common for datasets to outlast the product that created them. • It is not uncommon to work with historical data from the 1970s or 1870s • Open Data – freely available to reuse and republish – Open Street Map, GeoNames, EPSG Geodetic Parameter Dataset – Slightly different from "free data" which is available free of charge 2
- 3. 3
- 4. Open Standards • International standards – International Organization for Standardization (ISO): interoperability between geospatial systems (known as TC 211) – World Wide Web Consortium (W3C): communication on the web and protocols used for machine-to-machine communication • Industry standards – Open Geospatial Consortium (OGC): web standards we used for publishing spatial information – OGP Geomatics Committee (OGP): the EPSG Geodetic Parameter Dataset facilitate communication between geospatial systems • Ad hoc standards: GeoJSON, GeoTIFF, MBTiles and WMS-C • De facto standards: shapefile 4
- 5. 5
- 6. Open Source • Open Source: – when you receive software you also receive the source code • Accomplished using a software license 6 VS
- 7. 7 Open Layers BSD Style License Open Layers 3 BSD 2 Clause License Copyright 2005-2013 OpenLayers Contributors. All rights reserved. See AUTHORS.md for full list. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY OPENLAYERS CONTRIBUTORS ‘AS IS’ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of OpenLayers Contributors.
- 8. Open Source Licenses • The Open Source Initiative maintains a list of recognized open-source licenses. • Licenses differ in how they balance – the freedoms granted to users of software – how they protect software developers 8
- 9. Berkley Software Distribution • BSD – The Berkeley Software Distribution 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 the OpenLayers file you use. – Your own work (that is, the website) remains unaffected. – This ability to be freely mixed with your own work makes BSD an excellent choice for OpenLayers. 9
- 10. GNU Public License • GPL: The GNU General Public License – is arguably the most popular open-source license – Any modifications made to the original application must be provided to those running the application. • This is the license used for GeoServer – It is especially appropriate, in that system administrators want to be sure exactly what is running on their server, while ensuring that any customizations made are available. – The GPL license is also used by Oracle for the distribution of the OpenJDK implementation of Java. 10
- 11. Lesser GNU Public License • LGPL: The Lesser General Public License – formerly the Library General Public License – Allows the mix of open source and proprietary technology, making it a little more relaxed than the GPL. • This license is employed by the GeoTools library – Pragmatic choice, allowing GeoServer to smoothly integrate with proprietary systems such as Oracle Spatial and ArcSDE. 11
- 14. Keep in Mind • An open source license: – only describes how software is distributed – How the software was obtained (and how the project is managed) are a matter of "Governance" 14
- 15. Managing Risks • Adopting a new software component – has well-understood risks for procurement – Open-source software helps mitigate some risks (such as vendor lock-in) while exposing an organization to others (such as the license incompatibility) • This is the responsibility of the project team's governance – Although you probably want to perform an audit – A software foundation is standardize governance (and reduce the risk of using open-source software). 15
- 16. Open Governance • Open Development – Perform decision making in an open and public manner. – Key factor success factor - projects that practice open development are in position to recover if one or more contributors fall by the wayside – The ability to see what is being worked on, and the opportunity to take part, is the key test of open development. • GeoServer – maintains a public issue tracker which can be used to report problems – Uses a public email list for development, discussions and questions – Public "developers guide" documents procedures (including how to join the project) 16
- 17. Open Source Review • An open source license is the terms under which users receive software, need to check license applied correctly – Failure to check prevents the open source license from being effective. This can result in a project being pulled from the market until such time as the problem can be addressed or the section of code rewritten. – Each source code file contains an introduction header describing who wrote the file and under what terms it has been provided to the project. – GitHub projects include a CONTRIBUTING file describing what is needed – Some projects ask for a contributing license to be signed 17
- 18. How to fail • Failure to check prevents the open source license from being effective. – This can result in a project being pulled from the market until such time as the problem can be addressed or the section of code rewritten. • A common mistake is an employee contributing a fix in their own name. – In this case, it is their employer who owns the fix and needs to provide correct authorization. • Your legal department, or a software foundation, are in a position to conduct code audits (or intellectual property checks) on software before it is released. – This is done both to protect their own liability and to let your legal department verify the results prior to use. 18
- 19. Software Foundation vs Forge • Software foundation – can offer strong legal projection for a project (and its users) – most common lawsuits are copyright and patent infringement – provides "vendor neutral" governance • Software Forge – GitHub is focused strictly on hosting source code, similar to how gmail shares email messages. It does operate as a software foundation 19