Sie sind auf Seite 1von 68

OSS LICENSING

Disclaimers
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

U.S. GOVERNMENT DISCLAIMER NOTICE. The views expressed in this presentation are those of
the author and do not necessarily reflect the official policy or position of the Department of the
Army, Department of Defense, or the U.S. Government. The information appearing on this
presentation is for general informational purposes only and is not intended to provide legal advice
to any individual or entity. Please consult with your own legal advisor before taking any action
based on information appearing in this presentation or any sources to which it may cite.

UNLESS OTHERWISE STATED

Who is this guy?
MARCUS A. STREIPS
Attorney-Advisor (Intellectual Property)
United States Army Medical Research & Materiel Command
Fort Detrick, MD

Why are we here?
OSEHRA Mission

BUILD and SUPPORT an OPEN SOURCE COMMUNITY of users, developers,
service providers, and researchers engaged in advancing electronic health record
software and related health information technology.OSEHRAs mission includes
the creation of a VENDOR-NEUTRAL community for the creation, evolution,
promotion and support of an open source Electronic Health Record (EHR). This
community will operate with the TRANSPARENCY and AGILITY that characterize
open source software initiatives. This entails not only the development of a
community of software experts, clinicians, and implementers, but also a robust
ecosystem of complementary products, capabilities and services. OSEHRA is a
service organization. In one sense, our product is a thriving open source EHR
community. However, a more practical description of our products would list the
services OSEHRA provides to SUPPORT that community, such as our software
repository, testing, certification, and working group support.
Why are we here?

BUILD
SUPPORT
TRANSPARENT
AGILE
VENDER-NEUTRAL
OPEN SOURCE
COMMUNITY


OSEHRA Mission (Abridged)

Open Source Principles
1. Innovation comes from the outside. It must be channeled inside.
2. Software is knowledge transformed into code. It needs an engaged Community.
3. Software is never a finished product. Its evolution requires an involved Community.
4. Attract interested people with shared goals. Earn their trust.
5. Transparency: remove any obstacles to the free flow of information
6. Meritocratic governance driven by: Autonomy, Mastery, and Purpose
7. Release Early, Release Often.
8. Avoid Private Discussions.
9. Establish Credibility. Build relationships with Open Source Communities.
10.Welcome the unexpected. Listen carefully to the Community.
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
How do we make that happen?
1. Open Source Ecosystem: Patents, Data, Standards and Software
2. Open Source Software (OSS) Licenses Overview
3. OSS Compatibility: Aggregation, Integration, Linking
4. Dont Do it Yourself (DIYs): OSS Best Practices
How do we make that happen?
Part I: Open Source Ecosystem:
Patents, Data, Standards and Software
OSEHRA System Architecture
SOURCE: http://architecture.osehra.org/
OSEHRA System Architecture
SOURCE: http://architecture.osehra.org/
Data & Docs
Standards
Software
Architecture
Patents
Licensing Landscape
SOURCE: http://www.acq.osd.mil/log/mr/psm/09_technical_data_rights_acquisition_strategy_guertin_2nov2011_v2.pdf
OSEHRA System Architecture
Patents
Standards
(copyrights)
Data
(data rights)
Software
(copyrights)
OSEHRA System Architecture
Patents
Standards
(copyrights)
Data
(data rights)
Software
(copyrights)
Defn. Patent
Intangible Property
Concepts & Ideas
Social Contract
Hedge against risk
Inventive concept covering Anything under the Sun
NOT laws of nature, natural phenomena or abstract idea
Government sanctioned monopoly to make, use, sell, import
20 years from earliest effective filing date
Patents
The first patent was granted on July 31, 1790 to Samuel Hopkins of Philadelphia for a method
of producing potash (potassium carbonate), an essential ingredient used in making soap,
glass, and gunpowder.


Patents and OSS
VERY IMPORTANT to keep patents out of OSS code
Restrict software use and distribution
Undermine emergence of a commercial marketplace
Raise suspicion of costly litigation
Goes against principles of vendor-neutrality, agility and community
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
Patent Reciprocity and Open Standards
Most users of software probably dont realize how integral industry standards are to their
business and financial applications, nor how disruptive it might be to them if the standard
suddenly became more expensive or less available.


Open standards should be made available under reasonable reciprocal licenses that
require licensees to share under the same terms their own patent claims reading on the
standard, or the standard should not be called open.
SOURCE: http://www.rosenlaw.com/pdf-files/DefiningOpenStandards.pdf
Copyright 2013 Lawrence Rosen. Licensed under the Open Software License version 3.0 (OSL 3.0)
Patent Reciprocity and Open Standards
Create a common pool of patent claims that are available for all who share the standard.
Condition reciprocity for participation in the standards process
Condition reciprocity for commercial distribution of software that implements the specification.
Explicit in license conditions
Implicit through defensive termination provisions
Covenants not to sue (Sun/Microsoft XML standard) but see Microsoft's Open Specification Promise: No Assurance
for GPL, Copyright 2008, Software Freedom Law Center licensed under licensed CC-BY-SA 3.0.
SOURCE: http://www.rosenlaw.com/pdf-files/DefiningOpenStandards.pdf
Copyright 2013 Lawrence Rosen. Licensed under the Open Software License version 3.0 (OSL 3.0)
Patent Reciprocity and Open Standards
SOURCE: http://www.hl7.org/legal/patentinfo.cfm
Copyright 2007-2013 Health Level Seven International
Patent Reciprocity and Open Standards
SOURCE: http://www.hl7.org/legal/patentinfo.cfm
Copyright 2007-2013 Health Level Seven International
OSEHRA System Architecture
Patents
Standards
(copyrights)
Data
(data rights)
Software
(copyrights)
Defn. Copyright
Intangible Property
Expression
Social Contract
Monopoly to copy, distribute, modify an original Work
literary, visual and musical works, sound recordings and software
Term? (70/95/120) see http://copyright.cornell.edu/resources/publicdomain.cfm
Copyrights


A Little History:

The earliest recorded historical case-law on the right to copy comes from ancient Ireland. The Cathach is
earliest example of Irish writing. Around 560 AD St. Columba copied it from St. Finnian causing a
controversy that precipitated the Battle of Cl Dreimhne in 561 AD (3000 dead).
King Diarmait Mac Cerbhaill gave the judgment :

"To every cow belongs her calf, therefore to every book belongs its
copy
Copyright and Open Systems
Standards (HL7, ISO)
Data/Databases (US vs. EU/AU/CA)
Schema
Documentation
Design Concepts/GUI/Trade Dress
Software
Defn. Open Work (Knowledge/Data/Content/Service)
SOURCE: http://opendefinition.org/okd/
1. Access Agile
2. Redistribution Vendor-Neutral
3. Reuse Agile
4. Absence of Technological Restriction Transparent
5. Attribution Agile
6. Integrity Agile
7. No Discrimination Against Persons or Groups Vendor-Neutral
8. No Discrimination Against Fields of Endeavor Agile/Vendor-Neutral
9. Distribution of License Agile
10. License must NOT be Specific to a Package Agile/Vendor Neutral
11. License must NOT Restrict the Distribution of Other Works Agile
See Also: upcoming lecture: Open Data Dr. Fred Prior
Open Work Conformant Licenses
SOURCE: http://opendefinition.org/okd/
SOURCE: http://opendatacommons.org/licenses/
Open Work Conformant Licenses
SOURCE http://creativecommons.org/choose/
Open Work NON-Conformant Licenses
SOURCE http://opendefinition.org/licenses/nonconformant/
Government Data Rights
SOURCE: http://www.acq.osd.mil/log/mr/psm/09_technical_data_rights_acquisition_strategy_guertin_2nov2011_v2.pdf
OSEHRA System Architecture
Patents
Standards
(copyrights)
Data
(data rights)
Software
(copyrights)
Open Standards Requirement of OSS
Users of open standards arent locked into a particular implementation.
Easily switch to a different implementation Proprietary/FLOSS implementation.
The standard itself helps developers know what to do.
SOURCE: http://www.dwheeler.com/essays/open-standards-open-source.html
Copyright 2013 David A. Wheeler and licensed under the Creative Commons Attribution-Share Alike 3.0 License; the GNU Free
Documentation License; or the GNU GPL (version 2 or later)
Open standards aid FLOSS projects, and its not hard to see why:

Open Standards Requirement of OSS
1. No Intentional Secrets Transparent
2. Availability Agile/Vendor-Neutral
3. Patents Vendor-Neutral
4. No Agreements Agile/Transparent
5. Attribution Agile
6. No OSR-Incompatible Dependencies Agile/Vendor-Neutral
SOURCE: http://opendefinition.org/okd/
Open Standards Requirement of OSS
SOURCE: http://www.hl7.org/documentcenter/public_temp_B65E8487-1C23-BA17-0CA344F46F3417A2/pressreleases/HL7_PRESS_20120904.pdf
Copyright 2013 Health Level Seven International
OSEHRA System Architecture
Patents
Standards
(copyrights)
Data
(data rights)
Software
(copyrights)
How do we make that happen?
Part II: Open Source Software (OSS)
Licenses Overview
A Defn. Open Source Software
SOURCE: http://opensource.org/osd
See Also: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
See Also: http://www.gnu.org/philosophy/free-sw.html
1. Free Redistribution Vendor-Neutral
2. Source Code Transparent
3. Derived Works Agile
4. Integrity of the Authors Source Code Agile
5. No Discrimination Against Persons or Groups Vendor-Neutral
6. No Discrimination Against Fields of Endeavors Agile/Vendor-Neutral
7. Distribution of License Agile
8. License Must Not be Specific to A Product Agile
9. License Must Not Restrict other Software Agile
10. License Must be Technology-Neutral Vendor-Neutral
OSS License Category
SOURCE: http://flosscc.opensource.org/content/spread-the-word content on this site is licensed under a Creative Commons Attribution 2.5 License
3 Types of Licenses
1. Reciprocal (aka Viral, Copyleft, Restrictive)
- if you change the code and redistribute it, you must also
redistribute the source code; the code will remain open source.
- all code linked to the code with a reciprocal license must remain
with the same reciprocal license

2. Partially Reciprocal (Weak Copyleft)
- similar to the reciprocal but you can distribute a singe component
of your code with this license and link it to code with other license
(even proprietary)

3. Academic (aka Commercial Friendly, Permissive)
- you may relicense your derivative work under any license of your
choice, or even make it proprietary
OSS License Category
SOURCE: http://flosscc.opensource.org/content/spread-the-word content on this site is licensed under a Creative Commons Attribution 2.5 License
Popular and Widely Used License
1. Reciprocal (aka Viral, Copyleft, Restrictive)
- GNU General Public License (GPL)

2. Partially Reciprocal (Weak Copyleft)
- Eclipse Public License (EPL)
- GNU Lesser General Public License (LGPL)
- Mozilla Public License 2.0 (MPL)

3. Academic (aka Commercial Friendly, Permissive)
- Apache License 2.0
- BSD
- MIT License
OSS License Category
SOURCE : http://www.openfoundry.org/en/foss-license-category
OSS License Category
SOURCE : http://www.openfoundry.org/en/comparison-of-licenses
OSS License Category
SOURCE : http://www.openfoundry.org/LicenseWizard/index.htm?en
See also: http://home.ccil.org/~cowan/floss/
Rank of OSS Licenses by Popularity
SOURCE: http://osrc.blackducksoftware.com/data/licenses/
Copyright 2013 Black Duck Software,. Inc
SOURCE: http://johnhaller.com/jh/useful_stuff/open_source_license_popularity/
Copyright 2011 John T. Haller

Rank of OSS Licenses by User
SOURCE: http://www.openlogic.com/news/bid/154646/OpenLogic-Scanning-Data-Reveals-OSS-Developers-Choose-GPL-Enterprises-Prefer-Apache
Copyright 2013 OpenLogic, Inc.
OSS License Category
BSD/MIT (Commercial Friendly, Permissive)
The code is protected by copyright.
code can be used in closed source projects.
The code can be included in project with more restrictive licenses.
The program that used this can be sold and licensed commercially.
Derivative works need NOT be released (non-reciprocal).
There is implicit permission to exercise patents.
A number of terms that are left unspecified.

SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
OSS License Category
Apache 2.0 (Commercial Friendly, Permissive)
The code is protected by copyright.
The code can be used in closed source projects.
The code can be included in project with more restrictive licenses.
The program that used this can be sold and licensed commercially.
Derivative works need NOT be released.
The Apache license has a very explicit patent license.
A clear list of definitions is provided in its preamble.
Terms consistent in copyright, patent, trademark laws.
A clause for contributors license agreements provides a low entry path for contributors
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
OSS License Category
GPL 3.0 (Viral, Copyleft, Restrictive)

Viral because the licenses spreads a continuing use of the licenses in its derivatives.
The code can be sold and licensed commercially as long as the source code is under the same license.
Derivative works, when distributed, must be distributed under the same license (reciprocity condition).
Does not require you to release your modified version, or any part of it.
Patent permissions are included more strongly than GPL 2.0.
Hardware devices must allow modified versions to run.
Prevents the practice of applying restrictive licenses to modifications of original source code.
May NOT be distributed under any other license. Keep code free forever.


SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
OSS License Category
GPL 3.0 (Viral, Copyleft, Restrictive)
SOURCE: http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html
2013 Jeff Atwood.
The archetypal bearded, sandal-clad free software
license. Your code can never be used in any
proprietary program, ever! Take that, capitalism!
OSS License Category
LGPL (Lesser Copyleft)

The code is protected by copyright.
Considered halfway point between restrictive and permissive licenses
Allows combination with proprietary closed-source software impermissible under GPL
Does not extend to LGPL license to works that link against the original code.
Originally written to accommodate code libraries
Source: http://www.softwarefreedom.org/resources/2008/foss-primer.pdf
Copyright 2006, 2007, 2008, Software Freedom Law Center, Inc. Verbatim copying and
distribution of this entire document is permitted in any medium; however, this notice must be
preserved on all copies.
How do we make that happen?
Part III: OSS Compatibility:
Aggregation, Integration, Linking
Non-GPL Compatibility w/ GPL
SOURCE: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
SOURCE: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Text is available under the Creative Commons Attribution-ShareAlike License;
Aggregation Software is bundled in a distribution GPL Compliant
Pipes, sockets and command-line arguments are
communication mechanisms normally used between two
separate programs.

GPL Compliant
Integration - Modules are included in the same executable file GPL NON-Compliant
Modules run linked together in a shared address space GPL NON-Compliant
Static and Dynamic Linking ?
OSS Aggregation
An "aggregate" consists of a number of separate programs, distributed
together on the same CD-ROM or other media. The GPL permits you to create
and distribute an aggregate, even when the licenses of the other software are
non-free or GPL-incompatible. The only condition is that you cannot release
the aggregate under a license that prohibits users from exercising rights that
each program's individual license would grant them.

SOURCE: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Copyright 2007, 2008, 2010, 2013 Free Software Foundation, Inc.
Licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License
OSS Integration
SOURCE: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Copyright 2007, 2008, 2010, 2013 Free Software Foundation, Inc.
Licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License
If you integrate module Q, and release the combined program P+Q under the GPL,
that means any part of P+Q can be used under the GPL.


P : GPL Code
Q: Your Code

P+Q = P+Q = P = Q
OSS Linking
The Problem of Derivative Works
SOURCE: http://www.linuxjournal.com/article/6366
Copyright 1994 2013 Linux Journal.
The Copyright Act, at 17 U.S.C. 101, is a little vague and doesn't say anything at
all about software:

A derivative work is a work based upon one or more pre-existing works, such
as a translation, musical arrangement, dramatization, fictionalization, motion
picture version, sound recording, art reproduction, abridgment, condensation
or any other form in which a work may be recast, transformed or adapted. A
work consisting of editorial revisions, annotations, elaborations or other
modifications which, as a whole, represent an original work of authorship, is a
derivative work.

OSS Linking
SOURCE: http://www.cs.binghamton.edu
See Also: http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
OSS Linking
SOURCE: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
Text is available under the Creative Commons Attribution-ShareAlike License;
1. Dynamic and static linking violate GPL (FSF, LGPL, Stallman)
2. Static linking violates GPL but unclear as to dynamic linking (Torvalds, Novell)
3. Linking is does not automatically create a derivative work (OSI, Rosen)


Point of view:
OSS License Compatibility
SOURCE : http://www.openfoundry.org/en/compatibility-of-licenses

Here the term compatibility refers to the two following
conditions:

1. When a software developer makes use of more than one
external module in the development of a single project, and
when the licenses of used modules do not conflict with each
other, we say these licenses are compatible with each other.

2. When a software developer modifies a given program, and
the modified part makes use of other modules; when the
licenses of the modules do not conflict with the license of the
modified program, we say the licenses are compatible with
each other.
OSS Compatibility
SOURCE: http://www.dwheeler.com/essays/floss-license-slide.pdf
Copyright 2013 David A. Wheeler and licensed under the Creative Commons Attribution-Share Alike 3.0
License; the GNU Free Documentation License; or the GNU GPL (version 2 or later)

OSS Compatibility
SOURCE: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
Text is available under the CC-BY-SA-3.0; Released under the GNU Free Documentation License.
So which one?
Apache License 2.0
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
How do we make that happen?
Part IV: Dont Do it Yourself (DIYs):
OSS Best Practices
OSHERA OSS Key Features

1. Allow use in non-open source code (no reciprocity condition in license)
2. No licensing royalties
3. No Dual Licensing
4. Maximize business model diversity
5. Encourage, but NOT require contribution of improvements and modifications
6. Allow for project forking, but AVOID it
7. Share maintenance cost of code base
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
Dont DIYs
A GRAM license makes user and developer adoption quicker and easier.
A GRAM license has substantial licensing knowledge and support.
Many GRAM licenses are shepherded by professional organizations (e.g., FSF, OSI, Apache)
Developers have a understanding and consensus of how the GRAM license models work.
Too many different licenses makes it difficult for licensors to choose
License compatibility is a complex issue
Multi-License distributions are complex and hard to understand

SOURCE: http://www.softwarefreedom.org/resources/2008/foss-primer.pdf
SOURCE: http://opensource.org/proliferation-report
all content licensed CC-BY-SA 3.0.

Pick Generally Recognized as Mature (GRAM) Licenses:
Dont DIYs

The OSEHRA will only consider existing OSI-Approved licenses. There is already enough
variety of open source licenses to satisfy most common licensing situations. The Open
Source Initiative repeatedly discourages projects from creating new licenses. The effort of
devising a new license will drain a significant amount of resources and distract the OSEHRA
from more pressing issues while providing no benefit for the open source stance of the
project at large.

SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
Encouraged Practices
Individuals contributing bug fixes and improvements
Commercial companies contributing bug fixes and improvements
Commercial companies contributing large modules of source code
Commercial companies building a profitable and competitive marketplace
Educational use of the software
Use of the software for research purposes
Innovation ranging from small variations to radical disruptive concepts
High quality by continuous reduction of software defects
An environment of trust conducive to cooperation and collaboration
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
Discouraged Practices
Continuous tension and fractioning of the Community
Forking of the project into diverging branches (beyond experimental and exploratory purposes)
Litigation and uncertainty on potential future litigation
Entrenchment of the software and use of it by only a small niche of users
Unbalanced influence on the software by a small fraction of actors in the ecosystem
SOURCE: http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
FIN
Sources
http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
http://architecture.osehra.org
http://www.acq.osd.mil/log/mr/psm/09_technical_data_rights_acquisition_strategy_guertin_2nov2011_v2.pdf
http://www.rosenlaw.com/pdf-files/DefiningOpenStandards.pdf
http://www.hl7.org/legal/patentinfo.cfm
http://copyright.cornell.edu/resources/publicdomain.cfm
http://opendefinition.org/okd
http://opendatacommons.org/licenses
http://creativecommons.org/choose
http://opendefinition.org/licenses/nonconformant/
http://www.dwheeler.com/essays/open-standards-open-source.html
http://www.hl7.org/documentcenter/public_temp_B65E8487-1C23-BA17-0CA344F46F3417A2/pressreleases/HL7_PRESS_20120904.pdf
http://opensource.org/osd
http://osehra.org/sites/default/files/osehra_licensing_terms_v.1.0.pdf
http://www.gnu.org/philosophy/free-sw.html
http://flosscc.opensource.org/content/spread-the-word
http://www.openfoundry.org/en/foss-license-category
http://www.openfoundry.org/en/comparison-of-licenses

Sources (cont.)
http://www.openfoundry.org/LicenseWizard/index.htm?en
http://home.ccil.org/~cowan/floss
http://osrc.blackducksoftware.com/data/licenses/
http://johnhaller.com/jh/useful_stuff/open_source_license_popularity
http://www.openlogic.com/news/bid/154646/OpenLogic-Scanning-Data-Reveals-OSS-Developers-Choose-GPL-Enterprises-Prefer-Apache
http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html
http://www.softwarefreedom.org/resources/2008/foss-primer.pdf
http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
http://www.linuxjournal.com/article/6366
http://www.cs.binghamton.edu
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
http://www.openfoundry.org/en/compatibility-of-licenses
http://www.dwheeler.com/essays/floss-license-slide.pdf
http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
http://opensource.org/proliferation-report

Das könnte Ihnen auch gefallen