Talk:Open Source and Open Standards

This article is the collaborative work place for a White Paper to published jointly by OGC and OSGeo. Please feel free to add comments, amend wording or open a conversation on the 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).

Open Standards and Open Source

Carl Reed

Chief Technology Officer

The Open Geospatial Consortium (OGC)

Arnulf Christl

President

The Open Source Geospatial Foundation (OSGeo)

This OGC White Paper 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.

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

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

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 vendors, 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 vendors (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:

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 those developers are traditional proprietary product vendors, integrators, application developers or open source developers.

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

Open source software and proprietary software

In one basic respect, open source software and proprietary software are similar in the ways they are developed: Developers write source code and compile it into binaries that users install and run on their computers. The major difference between open source development and proprietary development is that open source developers work with an open community of other developers to continually refine the software, and many of them use the software (at no cost) to develop solutions. Another important difference between open source and proprietary software is in the licensing that proprietary developers impose when they distribute the software.

In general, open source refers to whether or not the source code for the software is made available for developers to reuse in unspecified new contexts. Proprietary source code can also be made “available”, but only to read and potentially to understand – not to reuse in other contexts. If source code is made available, and if developers can copy, modify and redistribute the source code without paying royalties or fees, it is called open source.

Proprietary software is typically licensed for profit, and the licensing terms are restrictive. When you purchase a usage license for proprietary software usage, you are purchasing binaries, which computers can process and humans cannot read. (Actually, today much proprietary code is available in source form but developers are required to purchase proprietary software licenses. Especially in the web and Java world and with open formats it is becoming increasingly difficult to only ship binary code.) But the typical user is buying binaries and not “source code” that is readable by humans and that can be changed and reused by software programmers.

In contrast, software can also be designed and developed in a completely open, community process. Software developed in an open, community process is termed “open source”. Usually those involved in developing and using such software agree to certain licensing terms, but open source licenses are designed to protect the user’s freedoms, not to restrict them.

There are ten guiding principals for open source development and use (http://www.opensource.org/docs/definition.php or http://www.opensource.org/docs/osd), all of which are designed to ensure that the software remains “open” and freely available to all parties in a non-discriminatory manner. These principles are followed to varying degrees by different open source communities. Some communities adhere to formal rules and impose tight management practices. Others are less structured. Most come to accept some degree of management authority because open source projects depend on public code repositories, bug and issue trackers, mailing lists, etc. It is generally true that open source communities cannot be "built", "managed" or "grown". They need to grow by themselves while software is being developed or after a proprietary product has been released under open source licensing. But management of open source projects (see http://producingoss.com/) is an important activity, because communities often function better when someone in the community is focused on facilitation and enablement.

To sustain open source software development and pay for project management, open source projects usually find ways to commercialize their activities. “Commercial open source software” refers to the ability of a commercial organization to package with the open source software a variety of support services and “for fee” applications that use the open source software while abiding by the open source license. These companies can make a profit by selling development services, such as systems integration or the development of client applications that use open source software, as well as support services and training.

Red Hat is the most commonly cited example of a commercial open source company, but it is atypical in the degree to which its revenue comes from software sales. Commercial open source software efforts usually endeavor to keep the basic software free and open. The special licenses that govern use and sale of open source software exist not to ensure profits to the software’s owner, but to ensure that the software’s source code remains free to all. Sometimes (as with “Simplified BSD”, for example), but not usually, licensing terms allow companies to sell derivative products that include the open source code. But over 70% (http://encyclopedia2.thefreedictionary.com/GPL+license ) of licenses are based on the GNU General Public License (GPL), which explicitly disallows the creation of proprietary derivatives or use of the code in proprietary contexts. 95% of companies that contribute to open source software development sell services and 5% sell derivative products.

Software is the main kind of product developed and distributed using open source principles, but there are other examples. Data can be open source, though “volunteered geographic data” is perhaps a more appropriate term, to clarify the distinction between “open source data” and “open data.” For example, Open Street Map (http://www.openstreetmap.org/) depends on a large number of volunteers to provide street data that is freely accessible to application developers. (“Open data” generally refers to data that are free and online, available for anyone’s use.) Open source principles can even apply outside the digital world: The Open Source Car Project (http://www.theoscarproject.org/) follows open source principles in developing and licensing designs for automobiles and automobile components.

There are now many open source geospatial software packages and the Open Source Geospatial Foundation (OSGeo) (http://www.osgeo.org ) works to formalize some of the efforts.

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

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.

How OSGeo promotes open standards

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.

OSGeo encourages project developers to adopt open standards and collaborate with other OSGeo projects that implement open standards. The use of standards as a means to connect and interoperate with other packages has helped to build a strong community of professionals who frequently share code and ideas, contributing to the advancement of geospatial technology in many application domains.

OSGeo members have contributed many 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.

OSGeo members have also helped to to identify standards requirements that result from our open source geospatial software development programs.

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.