Difference between revisions of "Talk:Open Source and Open Standards"

From OSGeo
Jump to navigation Jump to search
 
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
''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 [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).''
  
 +
= 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".
  
−
= Open Standards and Open Source =
+
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/).
  
−
: Carl Reed
+
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.
−
: Chief Technology Officer
 
−
: The Open Geospatial Consortium (OGC)
 
  
−
: Arnulf Christl
+
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].
−
: 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/).
 
  
−
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.
+
== Disclaimer ==
−
 
+
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.
−
== 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 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 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 for which the source code is made available
 
−
to use, study, change, and redistribute without cost or restriction by
 
−
the copyright holder.  These freedoms guaranteed by Open Source licensing
 
−
enables a public, collaborative development model that promotes early
 
−
publishing and frequent releases.
 
−
 
 
−
=== Open Source Development ===
 
−
 
 
−
 
 
−
=== Free Software Licenses ===
 
−
The following passage has been copied from the Free Software Foundation web site at: http://www.gnu.org/philosophy/free-sw.html
 
−
 
 
−
“Free software” 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.”
 
−
 
 
−
Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program's users have the four essential freedoms:
 
−
 
 
−
* The freedom to run the program, for any purpose (freedom 0).
 
−
* The freedom to study how the program works, and change it to make it do what you wish (freedom 1).
 
−
* Access to the source code is a precondition for this.
 
−
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
 
−
* The freedom to distribute copies of your modified versions to others (freedom 3).
 
−
 
 
−
By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
 
−
(end of citation)
 
−
 
 
−
The Open Source Geospatial Foundation (OSGeo) supports geospatial projects which adheres to these basic rules and publish their software under licenses compatible with these terms.
 
−
 
 
−
=== Proprietary Software ===
 
−
 
 
−
Software that does not follow all four basic principles of the Free Software definition is considered to be proprietary software.
 
−
 
 
−
=== Similarities and Differences ===
 
−
The software development, quality guidelines, release processes, coding styles and even the business models around Free and Open Source software are much closer to those of proprietary software than one might expect. Developers write source code and compile it into binaries that users install and run on their computers.
 
−
 
 
−
The only difference is caused by restrictive licensing terms - but these have far reaching implications, also in the way that software is released. One ...
 
−
 
 
−
 
 
−
 
 
−
''move this section further to the end of the paper''
 
−
 
 
−
 
 
−
 
 
−
 
 
−
In general, Open Source refers to whether or not the source code and the executable binaries of the software is made available freely for developers and users for any purpose. The source code of proprietary software is sometimes also 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 the license to use binaries, which computers can process but 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 has to acquire a license to use binaries.
 
−
 
 
−
In contrast, software can also be designed and developed in an open community process. Software developed in an open, community process is termed Open Source or Free Software. Usually those involved in developing and using such software agree to certain licensing terms. Other than proprietary licenses, Free Software and Open Source licenses are designed to protect the user's freedoms, not to restrict them. Another interesting difference is that there are general Open Source licenses for different use cases.
 
−
 
 
−
Depending on who you ask 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. 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, developers of Open Source projects can find ways to commercialize their activities. Open source software is not anti-commercial at all, instead it allows much more competition than if the source code is "owned" by a single entity. Businesses can make a profit by selling development services, such as systems integration or the development of client applications, training, consultation and so on - basically the same as with proprietary software, except selling software usage licenses.
 
−
 
 
−
> unsure whether to keep this in; should probably remove it to make the document more concise; --[[User:Seven|Seven]] 11:59, 7 April 2011 (UTC)]
 
−
 
 
−
 
 
−
* Simplified BSD
 
−
* GNU General Public License (GPL)
 
−
 
 
−
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 ==
 
−
''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.
 
−
 
 
−
== 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.
 

Latest revision as of 06:48, 15 May 2011

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

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

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

The paper was approved by the OSGeo Board of Directors in their 2011-05-05 Board meeting.


Disclaimer

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.

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Talk:Open_Source_and_Open_Standards&oldid=55188"