|
|
(8 intermediate revisions by 4 users not shown) |
Line 1: |
Line 1: |
− | ''This article is the collaborative work place for a White Paper to be published jointly by OGC and OSGeo. Please feel free to add comments, amend wording or open a conversation on the [http://lists.osgeo.org/mailman/listinfo/discuss OSGeo Discuss] mailing list. The document should be a high level summary only and give links for further exploration of the topic. It should be under regular review to ensure up-to-dateness (check the history for latest edits and links to the stable download location).'' | + | ''This article is a collaborative work by OGC and OSGeo. Please feel free to add comments, amend wording or open a conversation on the [http://lists.osgeo.org/mailman/listinfo/standards OSGeo Standards] mailing list. The document is a high level summary only. It should be under regular review to ensure up-to-dateness (check the history for latest edits and links to the stable download location).'' |
| | | |
− | = Open Standards and Open Source = | + | = History = |
| + | The document was started by Carl Reed, Chief Technology Officer of The Open Geospatial Consortium (OGC). This White Paper was initially adapted partly from articles by Carl Reed published previously in Directions Magazine and GeoWorld. For a more comprehensive explanation of "openness", see another OGC White Paper by Carl Reed, "The Importance of Going Open". |
| | | |
− | : Carl Reed | + | The first round of integrating OSGeo's position was done by Arnulf Christl, President of The Open Source Geospatial Foundation (OSGeo). The Open Source aspect has been adapted from articles by Arnulf Christl in "[http://www.fig.net/pub/fao/floss_cadastre.pdf FLOSS in Cadastre and Land Registration - Opportunities and Risks]" in a publication by the FAO and FIG Commission 7 WG 7.3. For standardised definitions of Open Source and Free Software please refer to the Free Software Foundation (http://fsf.org) and the Open Source Initiative (http://opensource.org/). |
− | : Chief Technology Officer | |
− | : The Open Geospatial Consortium (OGC)
| |
| | | |
− | : Arnulf Christl
| + | The text was then collaboratively reviewed, edited and finalized by a dozen active OSGeo and OGC members. Thanks especially to Gavin Fleming, Lance McKee, Markus Neteler, Athina Trakas, Michael Gerlek, Adrian Custer, Jeff McKenna, Cameron Shorter, Carl Reed, Frank Warmerdam, Steven Ramage, Daniel Morissette and Arnulf Christl for their contributions. |
− | : President
| |
− | : The Open Source Geospatial Foundation (OSGeo)
| |
| | | |
− | This White Paper will be published jointly by OGC and OSGeo. It is adapted partly from articles by Carl Reed published previously in Directions Magazine and GeoWorld. For a more comprehensive explanation of "openness", see another OGC White Paper by Carl Reed, "The Importance of Going Open". The Open Source aspect has been adapted from articles by Arnulf Christl in "FLOSS in Cadastre and Land Registration - Opportunities and Risks" in a publication by the FAO and FIG Commission 7 WG 7.3. For standardised definitions of Open Source and Free Software please refer to the Free Software Foundation (http://fsf.org) and the Open Source Initiative (http://opensource.org/).
| + | The paper was approved by the OSGeo Board of Directors in their 2011-05-05 [http://wiki.osgeo.org/wiki/Board_Meeting_2011-05-05 Board meeting]. |
| | | |
− | People who don’t work in the software industry (and many who do!) often confuse the terms "open standards" and "Open Source". Below we look at what these terms mean and how they’re different.
| |
| | | |
− | == Open Standards == | + | == Disclaimer == |
− | Communication means “transmitting or exchanging through a common system of symbols, signs or behavior.” Standards are a pre-requisite for communication, because standardization means “agreeing on a common system.” Geospatial software vendors, developers and users collaborate in the OGC's open, consensus process to develop and agree on standards that enable information systems to exchange geospatial information and instructions for geoprocessing.
| + | Thanks to all the people who have contributed to making this White Paper a comprehensive document! Please understand that it will always be a compromise because positions on Openness vary greatly from one community to the next. |
− | | |
− | A standard is like a blueprint that guides people who build things. A standard documents the use of rules, conditions, guidelines or characteristics for products or related processes and production methods. Standards can arise from a single company whose successful products become "de facto" standards (such as Microsoft’s Windows®). Standards can also be set by agreement among two or more software producers, or by government edict or a government-run process, or by representatives from multiple governments. Standards developed in governmental processes, such as those of the International Organisation for Standardisation (ISO) or INSPIRE (http://inspire.jrc.ec.europa.eu/) in Europe, are called "de jure" standards. Alternatively, standards can be developed, as in the OGC, through an inclusive and open consensus process ordered by well defined policies and procedures. These are agreed upon by the public and private sector participants in the consensus process, and they typically agree to make their standards freely available in a non-discriminatory manner. Such standards are known as "open" standards.
| |
− | | |
− | Why do OGC members participate in this process? Some technology providers and users participate because their geoprocessing and geospatial information products and resources are worth more when those products and resources are part of a larger network. Some users participate because they want more choice in their selection of product vendors and better data sharing with other users. They also want to reduce their technology risk. That is, they want to ensure that the systems they buy or build will continue to provide value in years to come. Some solution provider members participate because they want more choice in their selection of platform partners. Some software producer (including Open Source developers) participate because it reduces their development costs and helps them better understand their customers' needs. There are many reasons to participate in a standards consortium like the OGC. This is substantiated by the fact that, with the growth of the Internet and Web, there are more standards consortia than ever before, and a higher percentage of IT stakeholders than ever before are participating in them. Additionally, the OGC's global membership has grown every year since the OGC was founded in 1994 and is currently more than 400 members.
| |
− | | |
− | The OGC defines open standards as standards that are:
| |
− | # Freely and publicly available – They are available free of charge and unencumbered by patents and other intellectual property.
| |
− | # Non discriminatory – They are available to anyone, any organization, any time, anywhere with no restrictions.
| |
− | # No license fees - There are no charges at any time for their use.
| |
− | # Vendor neutral - They are vendor neutral in terms of their content and implementation concept and do not favor any vendor over another.
| |
− | # Data neutral – The standards are independent of any data storage model or format.
| |
− | # Defined, documented, and approved by a formal, member driven consensus process. The consensus group remains in charge of changes and no single entity controls the standard.
| |
− | | |
− | The OGC's open standards are specifications for interfaces and encodings that enable interoperability between geoprocessing systems from different developers, whether employed by proprietary product vendors, independent integrators, application developers or active in Open Source projets.
| |
− | | |
− | The OGC's open standards are free, publicly available specifications for interfaces, encodings and best practices. They are not software.
| |
− | | |
− | == Open Source ==
| |
− | | |
− | Open Source refers to software which has been made available under a free software license with the
| |
− | rights to run the program for any purpose, to study how the program works, to adapt it, and to
| |
− | redistribute copies, including modifications. These freedoms guaranteed by Open Source licensing
| |
− | enables a public, collaborative development model that promotes early
| |
− | publishing and frequent releases.
| |
− | | |
− | It is sometimes helpful to understand Open Source is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech", not as in "free beer". It means that the program's users have the four essential freedoms (from the Free Software Foundation web site at: http://www.gnu.org/philosophy/free-sw.html):
| |
− | | |
− | * The freedom to run the program, for any purpose.
| |
− | * The freedom to study how the program works, and change it to make it do what you wish. Access to the source code (Open Source) is a precondition for this.
| |
− | * The freedom to redistribute copies so you can help your neighbor.
| |
− | * The freedom to distribute copies of your modified versions to others.
| |
− | | |
− | The [http://www.opensource.org/ Open Source Initiative] has developed a set of 10 requirements of any software license that is to be considered an Open Source license under the [http://www.opensource.org/docs/osd Open Source Definition]. The Open Source Geospatial Foundation (OSGeo) supports geospatial projects which release their software under Open Source Definition compliant licenses.
| |
− | | |
− | Beyond the license there are a wide variety of different styles in which Open Source can be developed. Best practices for Open Development have been developed by in the open source community by authors such as Eric Raymond ([http://www.catb.org/esr/writings/cathedral-bazaar/ The Cathedral and the Bazaar]), and Karl Fogel ([http://producingoss.com/ Producing OSS]) and groups such as the [http://apache.org Apache Project]. These best practices include "release early, release often", "contributor meritocracy", consensus based decision making and open communication among project contributors.
| |
− | | |
− | These practices are followed to varying degrees by different Open Source communities. OSGeo has codified guidelines on how a project should be run in the [http://www.osgeo.org/incubator Incubation Process]. Projects wishing to join the Foundation have to abide by these rules. Users can rest assured that OSGeo projects are licensed correctly, function in an open, collaborative way and adhere to high quality standards.
| |
− | | |
− | === Proprietary Software and the Difference ===
| |
− | Software that does not follow all four basic principles of the Free Software definition is considered to be proprietary software. The most important difference to Free and Open Source Software lie the distribution terms which are typically codified in the license terms. Development style, quality processes, stability of the software, availability of service, support and maintenance are not inherently tied to the license, they have to be evaluated individually on a case by case comparison. Software is not better or worse just because of the license terms.
| |
− | | |
− | Sometimes the term Open Source is applied to software which is available as source code but where the distribution terms are proprietary, hence not offering the aforementioned four freedoms. This is not Open Source and not Free Software. Especially in the web and Java world and with open formats it is becoming increasingly difficult to only ship binary code. No matter what, the software must be shipped with an Open Source or Free Software license to qualify as such. This is an important distinction to easily identify a real Open Source software.
| |
− | | |
− | == Open Data ==
| |
− | Software development is the main undertaking developed and distributed using Open Source principles, but there are other examples. Recently the term "Open Data" is being used to describe the accessibility of data. Especially in the geospatial domain this is a very important aspect with lots of core data under the control of public administrations. But "Open Data" is still far from being as clearly defined as Free and Open Source Software. There are still quite a few open issues around data licensing, copyright and accessibility.
| |
− | | |
− | The most prominent open geospatial data project is OpenStreetMap (http://www.openstreetmap.org/) which set out to create a map of the world. Michael Goodchild coined the term "volunteered geographic data" to describe projects like this but it lacks one important aspect: The mission of OpenStreetMap includes the guarantee that the "volunteered" data is also freely available in readable source format for anyone. This is an important difference to other projects which also collect data from volunteers but deny full access to this data. This kind of "crowd sourced" data still lacks a good set of licenses but OpenStreetMap is making good progress (in a very open and community oriented way) to find a license that is compatible with as many legal systems and community requirements as possible.
| |
− | | |
− | == Similarities and differences – open standards and Open Source ==
| |
− | There are definite similarities to the design and development processes for the open standards and Open Source communities. An open consensus process is often important to both types of activity, though some very successful Open Source projects are led by a single “benevolent dictator,” and consensus in both activities is usually “rough consensus.” However, there are also fundamental differences. An open standards organization must comply with anti-trust law and work to ensure a balance of interest in the standards development process. Further, a standards organization must have a very well defined and rigorous intellectual property policy to insure that the standards are unencumbered by patents or any other essential claims. Standards organizations usually need to commit more staff and financial resources than Open Source organizations to ensure that the IPR policy is enforced and that standards developed by the members remain royalty free. But this distinction is not definitive, as sometimes Open Source organizations like OSGeo run into intellectual property issues.
| |
− | | |
− | Another way to explain the difference is that software very often implements open standards but open standards do not usually depend on Open Source software. Software and applications can be built on a solid foundation of open standards, regardless of whether the software and applications are proprietary or Open Source.
| |
− | | |
− | If we expand the definition of Open Source to include information system architectures, then there is one OGC document that can be thought of as Open Source, though it is not licensed with Open Source licenses. A reference architecture is an Open Source architecture intended to provide architecture developers with a template and implementation guidance. The OGC Reference Model (ORM), a reference architecture, serves as a model and planning tool for organizations planning software and system purchases. It helps people see which OGC standards are relevant to their organizations' needs.
| |
− | | |
− | Note that the term “public domain” has been applied to both open standards and Open Source software, but this term is problematic because "public domain" has no legal meaning outside of the Anglo-Saxon jurisprudence systems. Also, in the Anglo-Saxon legal framework, "public domain" means that you can do anything with it, including using it in a proprietary context.
| |
− | | |
− | == The OGC’s position regarding Open Source software ==
| |
− | ''Leave this as is, or if needed feed back to OGC for a double check''
| |
− | | |
− | As a matter of policy, the OGC board of directors and staff don't favor either proprietary software or Open Source software, and we can safely say that most OGC members, even the leading software vendors, recognize value in having Open Source software available in the market. (One reason is that most information and communication technology business, even the business of software vendors, is not centered around selling proprietary licenses, but around selling services, consulting, integration, training etc.) From the OGC perspective, any developer who implements OGC standards in software or online services is doing the right thing. We don't care if the implementation is part of a proprietary product for sale or an Open Source product to be shared. We care about interoperability – the ability to share geospatial software systems or information.
| |
− | | |
− | Our goal is to facilitate the development, deployment and maintenance of OGC standards that help to make geospatial or location based content and services ubiquitous – to improve the ability of decision makers to address the many pressing social, environmental and economic issues they face. What's important, from the OGC’s point of view, is not the purchasing and licensing details of software products, but their adherence to a shared, open, non-proprietary system for communicating geographically.
| |
− | | |
− | Openness – both open standards and open software – benefits markets. Vendors of proprietary software have found, in general, that, despite their early fears of open software and open standards, business has increased in a more open and complex “business ecosystem” that includes more providers, more partnerships and more customers. | |
− | | |
− | The OGC invites participation by all kinds of players. All kinds of commercial and non-commercial interests come together in our process, and we welcome a diversity of implementations. All our members are engaged in building the heterogeneous parts of the global spatial data infrastructure (GSDI). What's important, from our point of view, is not the purchasing and licensing details of the heterogeneous parts, but their shared, open, underlying, non-proprietary system of communicating geoprocessing instructions and geospatial information.
| |
− | | |
− | == OSGeo’s position regarding Open Standards ==
| |
− | As a matter of policy, OSGeo does not prescribe it's projects the implementation of open standards but it does encourage their use. Innovation often happens outside of existing standards. Also many innovations later become standards, ideally simply because they are good. Open Source innovations lend themselves ideally to standardization processes because they are not inhibited by patents or proprietary licenses.
| |
− | | |
− | OSGeo encourages project developers to adopt open standards. These include networking standards (HTTP), data processing standards (SQL), format standards (PNG) and many more. In the geospatial domain many of these standards are maintained and developed by the OGC resulting in a natural close relationship. In this way OSGeo members have helped to identify standards requirements which have been included into OGC standards following the OGC's policy and procedures.
| |
− | | |
− | OSGeo members have also contributed reference implementations for OGC standards. These are software applications that exemplify proper implementation of the standards in interfaces and encodings. Reference implementations are important resources for other programmers, who can study the source code and adapt it to suit their own applications.
| |
− | | |
− | == Memorandum of Understanding ==
| |
− | In 2009, the Open Geospatial Consortium, Inc. (OGC) and the Open Source Geospatial Foundation (OSGeo) signed a Memorandum of Understanding to coordinate in advancing open geospatial standards and Open Source geospatial software. As stated on the OSGeo home page, one of the Foundation’s goals is "To encourage the implementation of open standards and standards-based interoperability in foundation projects." The OSGeo's overall goal is to encourage the use and collaborative development of community-led Open Source geospatial software projects, and most of these depend on open standards like those from the OGC. Wider use of OGC standards increases interoperability, innovation and market growth, and this benefits developers and users of both Open Source and proprietary software.
| |
− | | |
− | Along with general commitments to expand collaboration and promote the synergy between open standards and Open Source software in the geospatial domain, the Memorandum of Understanding provides for the assignment of up to six one-year Individual Memberships in the OGC.
| |
− | | |
− | == Ensuring Interoperability of Proprietary and Open Source Software ==
| |
− | Members of the OGC would agree that, to quote from "The Importance of Going 'Open'" (http://portal.opengeospatial.org/files/?artifact_id=6211&version=2&format=pdf ), "It is incumbent upon buyers of geoprocessing software, data and services to carefully review their requirements and then draft interoperability architecture documents that lead to purchase of solutions that implement the appropriate OGC Standards. This can be done piecemeal, one upgrade or add-on at a time, or, if it is time for the organization to put a whole new solution in place, it can be done comprehensively, all at once. OGC and OGC's members can help by examining use cases and explaining where open interfaces can be specified into the architecture on which procurements will be based."
| |
− | | |
− | The OGC Reference Model (ORM), as mentioned above, serves as a model and planning tool for organizations planning software and system purchases, including – very significantly – components of various kinds that may not have been planned at the outset. The ORM may be used to guide the purchase of proprietary software or Open Source software or both. It helps people see which OGC standards are relevant to their organizations' needs.
| |
− | | |
− | Whether proprietary or Open Source software components are chosen to implement the parts of an architecture, there needs to be a way to ensure their interoperability. Interoperability depends on users and providers being able to know whether products and systems comply with the OGC interface and encoding standards that enable interoperability. The OGC Compliance & Interoperability Testing & Evaluation (CITE) program (http://portal.opengeospatial.org/files/?artifact_id=7586) provides a way to verify correct implementation of OGC standards. Geoprocessing products – purchased or obtained free – can carry the “Certified OGC Compliant” service mark, and it is incumbent upon those who contract for the purchase or development of geospatial components and systems to be sure that their procurement language – the terms spelled out in tenders and requests for quotes (RFQs) – asks bidding product and service providers to offer OGC-compliant products and architectures.
| |
− | == Conclusions ==
| |
− | Open standards and Open Source software are both important parts of today’s ICT ecosystem, but they are quite different things. The OGC facilitates an open standards process and promotes the use of open standards in both proprietary and Open Source software. The OGC also promotes the use of open standards in the production and publishing of geospatial data, regardless of the policies of the producers and publishers.
| |
− | | |
− | Providers of both proprietary and Open Source software join the OGC to further the development and market uptake of open standards in the world geospatial market, because open standards help both types of providers. This is true also for data providers.
| |
− | | |
− | Users of both proprietary and Open Source software join the OGC to be sure OGC standards meet their evolving requirements, and they also join to stay abreast of changing technology and remain innovative. Users of both kinds of software have an interest in being sure their systems are part of the growing global network of interoperable geospatial resources. The best way to gain such security is to be sure that their procurement language – the terms spelled out in tenders and requests for quotes (RFQs) – asks providers to offer products that carry the Registered OGC Compliant brand.
| |