Open Source and Open Standards

• This article is a White Paper jointly published OGC and OSGeo. The text was collaboratively edited, reviewed and finalized by more than a 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, Arnulf Christl and others for their contributions.
• Please feel free to add comments, criticisms, links to other concise definitions on the associated Talk page.
• This article was approved as an official joint OSGeo and OGC White Paper by the OSGeo Board of Directors in their 2011-05-05 Board meeting.

Document Version 1.0 (stable, page protected)

Open Standards and Open Source

People who don’t work in the software industry (and many who do!) often confuse the terms "Open Standards" and "Open Source". This White Paper has been created collaboratively by the Open Geospatial Consortium (OGC) and the Open Source Geospatial Foundation (OSGeo) to look at what these terms mean in the context of the OGC and OSGeo and how they relate and where they are different.

Open Geospatial Consortium

The Open Geospatial Consortium (OGC) is an international consortium of more than 420 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available geospatial interface and format standards. OGC Standards empower technology developers to make geospatial information and services accessible and useful with any application that needs to be geospatially enabled.

Open Source Geospatial Foundation (OSGeo)

The Open Source Geospatial Foundation, or OSGeo, is a not-for-profit organization whose mission is to support, promote and endorse the collaborative development of Open Source geospatial technologies and data. The foundation provides organizational, legal and financial support to the broader Open Source geospatial community. It also serves as an independent legal entity to which community members can contribute code, funding and other resources, secure in the knowledge that their contributions will be maintained for public benefit. OSGeo also serves as an outreach and advocacy organization for the Open Source geospatial community, and provides a common forum and shared infrastructure for improving cross-project collaboration. The foundation's projects are all freely available and usable under an OSI-certified Open Source license.

Open Standards

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 consensus process to develop and agree on standards that enable information systems to exchange geospatial information and instructions for geoprocessing. The result of these efforts are Open Standards. The OGC defines Open Standards as standards that are:

1. Freely and publicly available – They are available free of charge and unencumbered by patents and other intellectual property.
2. Non discriminatory – They are available to anyone, any organization, any time, anywhere with no restrictions.
3. No license fees - There are no charges at any time for their use.
4. Vendor neutral - They are vendor neutral in terms of their content and implementation concept and do not favor any vendor over another.
5. Data neutral – The standards are independent of any data storage model or format.
6. 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 projects.

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. 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) are called "de jure" standards. Alternatively, standards can be developed, as in the OGC, through an inclusive consensus process of the members 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 (May 2011) more than 410 members.

The OGC's Open Standards are free, publicly available specifications for interfaces, encodings and best practices. They are not software.

Open Source

Open Source encompasses two related concepts regarding the way software is developed and licensed. They are codified in the "Free Software" and the "Open Source" definitions. "Free and Open Source Software" 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 enable Open Source software development, a public, collaborative model that promotes early publishing and frequent releases. The 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 Open Source Definition.

The Open Source Definition

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria (taken from http://opensource.org/docs/osd):

1. Free Redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of The Author's Source Code. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
5. No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
7. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
8. License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
9. License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
10. License Must Be Technology-Neutral. No provision of the license may be predicated on any individual technology or style of interface.

The Free Software Definition

It is sometimes helpful to understand that Open Source is a matter of liberty, not price. To this end the Free Software Foundation says that 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.

These freedoms are the prerequisites to Open Source software development.

The Difference of Proprietary Licensing

Software that does not follow all four basic principles of the Free Software definition and the ten Open Source requirements is considered to be proprietary (or privative) software. The most important difference to Free and Open Source Software lies in the distribution terms which are codified in the license terms. Proprietary license terms typically list the things that the user is not allowed to do (do not copy, do not change, do not re-engineer, do not pass on, etc.).

Development style, quality processes, stability of the software, availability of service, support and maintenance are not inherently tied to the license model. These factors have to be evaluated individually on a case by case comparison. Software is not better or worse just because of the licensing terms.

Sometimes the term "Freeware" or "Open" is applied to software which is available free of cost or even as source code but all the same with proprietary distribution terms. This is not Open Source and not Free Software. 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 real Open Source software.

Why Free and Open Source Software?

The freedom to use, explore, modify and give away software freely leads to a completely different motivation for creating the software in the first place. The motivation shifts away from primarily making money to solving a problem. The resulting software is typically more focused to solve a single problem at it's best and more open to integrate with other solutions. For users the investment into Free and Open Source software is more lasting because there is no single entity that can take away the right to continue to use the software which is what proprietary vendors can do.

Software is not a material good and therefore giving away a copy does not cause a loss. If you give away a brick you do not have it anymore. If you give away a copy of your software, you still have the 'original'. Therefore Free and Open Source software does not work well for business models which are focused on creating a shortage, for example through restrictive licenses. But at the same time Free and Open Source software is not anti-commercial or anti-business. Instead it fosters competition and is the most extreme form of an open market economy by giving everybody the same opportunities – developers, integrators and users alike.

How is Free and Open Source Software developed?

Beyond the license there are a wide variety of different styles in which Open Source can be developed. Best practices for Open Source development have been summarized by authors such as Eric Raymond (The Cathedral and the Bazaar), and Karl Fogel (Producing OSS) and groups such as the 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. The resulting software is known to be more secure, stable, quicker to evolve and more innovative. This White Paper cannot go into all the arguments why the Free and Open Source model is better than the closed, proprietary model. Please refer to the Further Reading section at the end of this paper.

OSGeo has codified guidelines on how a project should be run in the Incubation Process (http://www.osgeo.org/incubator). 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.

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 intellectual property rights (IPR) policy is enforced and that standards developed by the members remain royalty free. But this distinction is not definitive, which is one reason why Open Source organizations like OSGeo have clear regulations and guidelines projects must abide by, although "intellectual property" is not relevant inside the Open Source process.

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.

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

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, not-for-profit and public administrative 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 to its projects the implementation of Open Standards but it does encourage their use. Innovation often happens outside existing standards. Also many innovations later become standards because they are good technical solutions. 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

To demonstrate the mutual understanding and accepting the differences in scope of the two organizations, 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. The OGC on the other hand originates from an Open Source project in the late 80's which early on recognized the need for interoperability and to this day strives to have Open Source reference implementations for it's standards.

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."

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 software – whether proprietary or Open Source – 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.

Further Reading

• Standardized Open Source definition by the Open Source Initiative: http://opensource.org
• Standardized Free Software definition by the Free Software Foundation: http://fsf.org

Related Articles

• OGC White Paper by Carl Reed, "The Importance of Going Open"
• "FLOSS in Cadastre and Land Registration - Opportunities and Risks" by Arnulf Christl in a publication by the FAO and FIG Commission 7 WG 7.3 (http://www.fig.net/pub/fao/floss_cadastre.pdf)

Download

• Open Document Format (ODT 39KB)
• Proprietary Document Format (PDF 167KB)
• Proprietary document format Microsoft Word (DOC, 86KB)