best practice recommendations for utilizing open source software (from a legal perspective)

Best practice recommendations for utilizing open source software

(from a Legal Perspective)

Dave McLoughlin, Director OSS

Auditing

Presenters

Rogue Wave Software

[email protected]

© 2015 Rogue Wave Software, Inc. All Rights Reserved.

Marco Gatti, IP Attorney

Brooks Kushman

[email protected]

mailto:[email protected]


Agenda

• Trends in Open Source Software (OSS)

• The open source audit and license identification

• Developing a OSS process/policy• Compliance• Legal implications


Trends in open source

Use of open source continues to grow

90% of companies use OSS components

in commercial software (Gartner)

>80% of a typical Java application is

open-source components and

frameworks (TechCrunch)

11 million developers

worldwide make 13 billion open source requests each year


Open source components provide critical functionality Improves developer productivity

No license fees

Innovation drives open source use

“More eyes” improves security

Leveraged development effort

Apache, Tomcat, Wildfly, Jakarta Commons, Jquery Communities continuously improve features

Mature, commoditized applications and libraries

Massive peer review


Assessing risk in open source For all its benefits, risks exist

License risk

Failure to comply with OSS

license may create liability

Security risk

The OSS component can include

vulnerabilities

Support risk

Who do you call for help?


Managing OSS risk

20%

Scanning to discover open

of organizations lack meaningful controls over OSS selection and use


of developers need not prove security of OSS they are using


of the organizations claim to track vulnerabilities in OSS over time

76%

80%

Increased use + few controls = unmanaged risk

11 million developers worldwide make 13 billion open source requests each year


OSS audit & license identification


Ad hoc or automated scanning tools

Interview developers and build list of OSS

Run a scanning tool to find matches

Analyze results

Review matches: code, copyright, license, urls, author information

Find and validate copyright and license

Create

Bill of Material: OSS and associated licenses Compliance checklist

Example report


Open Source Bill of Material (BOM)

License Information

Compliance Information

OSS best practices

OSS Policy

Acquisition & approval

Support & maintenanc

e

Tracking

Audit & governanceTraining

Legal complianc

e

Community

interaction


– License requirements

– Security requirements

– Support requirements

Establish OSS policies

– Risk tolerance v. OSS value

– Recognize development realities

– Start small, streamline, and expand

Set the guiding principles

Institutionalize the policy at the development level


Feed and maintain policies

OSS Policy

Legal

Technical Security

Business


OSS licenses & terms• OSS Developer chooses • Hundreds of pre-existing licenses to choose

from• Developers may make their own license


Example of license obligations


OSS License Potential Conflicts


Example – Reviewing Clauses of LGPLv2• Allows the open source software to be “linked”

(“dynamically”) with software without having the OSS terms apply to the proprietary S/W.

• Allows developers and companies to integrate LGPL software into their own software without being required to release their proprietary source code ~ depending on integration (i.e., static vs. dynamic linking).

• Requires that the open source software is modifiable by an end-user (via source code availability), therefore the LGPL open source software are usually used in the form of a shared library so that there is a clear separation between the proprietary software and open source software.


Example - LGPLv2Two Kinds of “Linking”: Static vs. Dynamic

• Static libraries (e.g., .a file): Library of object code which is linked with, and becomes part of the application (i.e., executable).

• Dynamically linked shared object libraries (e.g., .dll, .so file): The libraries must be available during compile/link phase. The shared objects are not included into the executable component but are selected during the execution of the executable.

Depending on how the developer links the LGPLv2 OSS will determine whether you have to make proprietary software available


LGPLv2.1 – Static vs. Dynamic

Static Linking Dynamic Linking


The product having an executable that contains an OSS Library header files which dynamically call the OSS Libraries.

Example - LGPLv2.1 Section 5


LGPLv2.1 Section 6


Lean Header

Loaded Header

Example - LGPLv2.1 “Loaded Header File”?

LGPLv2.1• We researched the FSF’s position on the header file

implementation. In 2003, Richard Stallman (the author of the LGPL license) stated as follows:

Someone recently made the claim that including a header file always makes a derivative work. That's not the FSF's view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.

Based on this interpretation, the OSS header files having template code would follow under FSF’s view of header files not being a derivative work.


OSS – Copyright Cases

• Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)

• Welte v. Fantec GmbH (6/14/13 – Germany)

• XimpleWare Corp. v. Versata


Other OSS Copyright Cases


Enforcement• Free Software Foundation (FSF) is in

some ways the de facto enforcer of the GPL license

• FSF conducts a compliance laboratory that investigates violations

• FSF is available for hire to assist companies to comply


Summary

• Three takeaways– Understand the use of OSS

– Create Policies that works for your company/organization

– Be aware of legal obligations based on OSS license


Questions?

[email protected]@brookskushman.com



best practice recommendations for utilizing open source software (from a legal perspective)

Technology

open source software

oss license

oss risk

open source use of open

security of oss

oss components

open source audit

opensource components