Convergence of Open Source Projects and Standards Development SES Webinar Series

Convergence of Open Source Projects

and Standards Development

SES Webinar Series

September 24, 2014 Andrew Updegrove

Gesmer Updegrove LLP

“Five years ago companies collaborated

mostly by setting standards. They'd work

together to write specifications that

provided a level of interoperability and it

was up to each company to implement it.

Open source development has usurped that

and companies now exchange code instead

of, or in addition to, standards”

Linux Foundation CEO Jim Zemlin, 2014 Collaboration Summit Keynote

What is “Open Source?”

 Strictly speaking, software code in human readable form (in comparison to machine-readable object code)

 Generically, a collaborative development technique, usually open to anyone to participate in for free

 Most often used to develop software, but can also be hardware (or anything else)

 Results in a usable product rather than a design  The deliverable is usually available for free

 Exception: in the case of hardware, the architecture would be free, and an implementation (if available) would often be available at or near cost

What is “Open Source?”

 Can be as small as a few lines of code or a

single function or module

 Can be millions of lines of code (e.g., the

Linux kernel)

 Many examples of dominant code (e.g., the

LAMP stack running Web servers)

How is Open Source Developed?

 Many models, depending on objectives:

 Hosted at a “forge” like GitHub – provides technical development platform (i.e., version control, wiki, etc.) for free

 Hosted by an existing foundation (e.g., Apache or

Eclipse) with more sophisticated governance structure  Hosted by a foundation that provides full services,

including promotion (e.g., Linux Foundation or OuterCurve); may be incorporated or not

 Incorporated as a stand alone entity (usually with outsourced management)

How is Open Source Developed?

 Participation and technical governance are usually based on a meritocracy approach

 Funded projects may have a Board of Directors constituted in a manner typical of a consortium  Funded projects may also have multi-tier

memberships with ascending rights

 Elite projects maintain a strict separation between Board and Technical Steering Committee (TSB)

How are IPR Managed?

 Code is available for free

 Project may be subject to contribution and

licensing rules, or there may be no rules at all

 If there is a user license, the terms can vary

widely, from almost minimal (“permissive”) to

significant (“copyleft”)

 Copyright in each code contribution may be

conveyed to the project, or retained by the owner

 Patent rules for contributors and users can vary

Open Source vs. Open Standards

 There is a built in tension between the two

approaches

 Open standards provide value only if everyone

complies with the standard

 IPR commitments are limited to compliant

implementations

 Copyright applies only to standards, not to

implementations

 Participants are subject to explicit IPR policies

and obligations

Open Source vs. Open Standards

 Open source software derives its value from

allowing anyone to change it

 May or may not be contribution agreements

 Many participants may be subject to non-member inventions agreements or work for hire obligations  Patents are often not addressed at all

 Copyright applies to the deliverable itself

 Commercializing software under restrictive licenses can impose IPR and code-contributions on

Open Source vs. Open Standards

 BUT:

 Open source software needs to implement standards  RAND commitments can cause problems under

“Copyleft” licenses

 Many consortia have adapted their IPR policies to

deal with this

 Open source projects have done almost nothing to

accommodate open standards concerns

 Standards sometimes now include actual code,

which is not contemplated by the IPR policies

under which the standards were developed

Open Source vs. Open Standards

 Why a new breed of open source projects?

 Collaboration objectives are becoming more

ambitious and challenging

 Standards organizations are still largely “stove

piped”

 Time to market constraints are significant

 Middleware can be commoditized in order to

facilitate creation of new markets

 Many companies think an open source approach

can lead to a more satisfactory result (others do

not)

Contrasting approaches

 Open standards approach:

 Form a new foundation to create a framework of standards directed at a specific use case(s): Exp: SGIP

 Populate framework with appropriate standards  Identify gaps where standards are needed

 Establish liaisons with appropriate SSOs

 Vendors then build all the software individually, from the ground up (or the consortium may also create a reference implementation)

 Standards may or may not enable “plug and play” interoperability

Contrasting approaches

 Open Source approach:



addresses a specific use case(s)

 Incorporates appropriate standards  May also create code for APIs

 May also release specifications for APIs

 May also identify gaps where standards are needed

 Establish liaisons with appropriate open source foundations and SSOs

 Vendors then build on top of the common open source platform

Current example: the IoT

 A large array of organizations have been formed, including:

 The Thread Group (Google, ARM, Samsung): low-power mesh network protocols based on existing standards other than WiFi, Bluetooth

 OpenInterconnect Consortium (Intel, Samsung, Dell): wireless

connectivity standards based on Wifi, Bluetooth, etc.; open source reference implementation to follow

 AllSeen Alliance (Qualcomm, Cisco, Microsoft; hosted by Linux Foundation): open source platform; may do APIs in code and specification form

 Hypercat (UK based; IBM, ARM, BT): standards for “thin”

interoperability layer to allow queries between devices and hubs  Industrial Internet Consortium (OMG hosted; IBM, Intel, AT&T, GE,

Cisco): apps for commercial settings

 oneM2m (multiple SSOs) standards framework for communication and services in broad array of market settings

Is this Convergence Good or Bad?

 Positive aspects:

 Provides a new approach to solve complex problems  Broadens opportunities for innovation

 Able to address cross-sectoral challenges  Provides a faster time to market solution  Lowers per-participant development costs  Reduces risk of lock in

 Negative aspects:

 Provides more opportunities for overlap and duplication  May delay emergence of pervasive solutions

 Complicates IPR landscape since standards remain essential  Leaves IPR reconciliation burden on standards organizations

Resources

 ConsortiumInfo.org

 A Concise Introduction to Free and Open Source Software -

http://www.consortiuminfo.org/bulletins/aug09.php#feature

 Significant Open Source Foundations

http://www.consortiuminfo.org/links/linkscats.php?ID=66

 MetaLibrary/Open Source

http://www.consortiuminfo.org/metalibrary/bycat.php?PID=9

 Linux Foundation Collaborative Projects

http://collabprojects.linuxfoundation.org/

 Eclipse Foundation Projects