Legal Issues in Developing in a Hybrid Envionment with Open Source Software

Karen Copenhaver
Mark Radcliffe
Michael Waldron

Webinar

March 18, 2009

Speakers

Karen Copenhaver
Partner at Choate Hall &
Stewart
Counsel for the Linux
Foundation
Michael Waldron
Marketing Communications
Manager,
Black Duck Software Mark Radcliffe
Partner at DLA Piper
General Counsel for the Open
Source Initiative (OSI)
Page 2
Copyright © 2006 Black Duck Software, Inc. All Rights Reserved.

Agenda
Developing in a Hybrid Open Source-
Proprietary World
What is a Hybrid Environment?
Why and when do I need a license?
How do you interpret an OS License?
Why license incompatibility is the wrong question
GPL / LGPL / Mozilla
Summary

Q&A

Page 3

Why Open Source: Leverage, Compelling
Economics

Linux Example: Leverage of 23:1
– Open source community contributes $1.4 Billion
– Red Hat spends $60 M

Customer saves 88% of development
– 19K lines of new code, 140K lines of open source
– Savings of approx. $20,000 for every 1,000 lines of code of
OSS used

“The fundamental economics of software
development leads you to open-source
softwarequot;
– David Rivas, Nokia VP for S60 Software

Page 4

Software Development Today
“40-50% of code comes from
outside the company”
Outsourced Code
Jim Duggan, Gartner group
Development

Internally
Commercial Developed
3rd-Party Code Code

Open Source
Software
Individuals
Universities
Corporate Developers

Software Application

YOUR COMPANY

Page 5

Complexity
Each component
has an
owner & license

Each license must
permit me to use
the code in the way I
would like with all of
the other code

And to do so over
time as the use of
the code changes

Page 6

Basics

Any use of intellectual property requires a license
– A license is permission to use someone’s property

Software is protected by intellectual property
– Copyrights and sometimes patents and trade secrets
– Copyright arises automatically in author

If no intellectual property → no need for a license
– Is it copyrightable subject matter?
Functional statement / Merger of idea and expression
– Has it been formally dedicated to the “public domain”?
A complete relinquishment of all intellectual property rights

Page 7

Licenses may be express or implied

An implied license may be:
– Implied in fact
Reasonable assumption based on circumstances
Cannot contradict an express license
– Implied in law
Exhaustion
Estoppel
– “(1) the party to be estopped must be apprised of the facts; (2) he must intend that
his conduct shall be acted upon, or must so act that the party asserting the estoppel
had a right to believe it was so intended; (3) the other party must be ignorant of the
true state of facts; and (4) he must rely upon the conduct to his injury.”
Fair Use
– May be eliminated in US by contract

An express license may be:
– Oral or written
– Formal or informal
– In plain English or legalese

Page 8

Scope of License

If you are acting within the scope of the license
– You are licensed
– A license is a defense to a claim of infringement

If you act outside the scope of the license, or
breach the terms of the license so that the license
is terminated
– You are unlicensed
– You are an infringer
– You can be forced to cease activities beyond scope of the
license depending on how the license is drafted, see Jacobsen

The Question is:
– Can I comply with the terms of the license under which the
code was made available?

Page 9

License Incompatibility

Frequently leads to the wrong analysis
Incompatible obligations are problems for both
commercial and open source licenses
The incompatible obligations only matter if the
programs interoperate in a manner which triggers
them
Summary: If the GPLv2 licensed program does
not create a derivative work of the Apache
licensed program, you do not have a problem
even though the licenses are “incompatible”

Page 10

License Compliance

Attribution Licenses – compliance is easy
– BSD, MIT, Apache

Weak Copyleft licenses – more challenging
– Mozilla
– EPL
– CDDL

Strong Copyleft licenses: most challenging
– GPL (GPLv2 differs from GPLv3)
– LGPL (LGPLv2 differs from LGPLv3)
– AGPL

Page 11

How do you interpret an OS License?

1. You read the license
2. You interpret the license as a lawyer would
interpret a contract
3. Basis for interpretation
1. Views about the license by the authors of the licensed code
(NOTE: the views of the authors of the license carry less
weight)
2. Views by the author of the license at the time of the license
creation (NOTE: FAQ on GPLv2 ten years after creation may
have limited effect on court except as “usages of the trade”)
3. Community view: valuable as “custom and usage and trade
practices ” under Article 2 of the UCC (2-208)
4. Limits on enforcement imposed by the community

Page 12

Perspectives on FOSS Licenses

Developer’s Attorney’s
– Familiar with community – Four corners of the license
consensus – Rules of contract construction
– Focus on common sense; legal – Article 2 of the UCC in US
and engineering “logic” is
– Copyright Act and caselaw
different
– Identification of the parties to
– Comfortable with “community”
the contract
interpretation
– Contract law versus
– Look to project committers like
intellectual property law
Linus for direction
– Breach and Remedies
– See absence of litigation as
– Change in programming
proof of little or no risk
techniques changes results
– Frustrated with “plain English”
– Anticipate a judge
discussions
Judge in Court
– Can describe function in many
different ways Licensor’s counsel
Community

Page 13

General Public License: GPLv2

Reciprocal License
– Works created using GPL licensed code may only be distributed
under the GPL

Scope of “based on” work
– Ambiguity of “derivative work”
– Use of “collective work”
– Linking issues

Focus on the word “work”
– When is the “work” a separate and independent work?
– What is included in the “work”?
Many lawyers believe that components that interoperate
using an interface created to enable components to work
together are separate works
Others do not agree

Page 14

Classpath Exception

Linking this library statically or dynamically with other
modules is making a combined work based on this library.
Thus, the terms and conditions of the GNU General Public
License cover the whole combination.
As a special exception, the copyright holders of this library
give you permission to link this library with independent
modules to produce an executable, regardless of the license
terms of these independent modules, and to copy and
distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license
of that module. An independent module is a module which is
not derived from or based on this library. If you modify this
library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not
wish to do so, delete this exception statement from your
version.

Page 15

Lesser General Public License: LGPL

Two licenses (LGPLv3 recognizes this fact by
making the LGPLv3 a modification of GPLv3)
– GPL for “library”
– Any terms for combination of “library” and commercial work

Designed for libraries to avoid reluctance to use
GPL licensed libraries with commercial programs
Section 5 exceptions for “small uses”
– Data structure layouts/small macros/inline functions

Scope 6 (linked LGPL program)
– Permit modifications for customers own use
– Make source code or object code available

Page 16

General Public License: GPLv3

Reciprocal License
– Works created using GPLv3 licensed code may only be distributed under the
GPLv3

Shift from US copyright to “contract” terms
– Convey
– Modification
– Propagate

Patents
– Direct license for those who modify the work
– Pass through of third party patent licenses if used with “knowledge”
– Microsoft/Novell provisions

Modification to permit compatability with obligations of certain
other license
– Warranties
– Trademark use/attribution
– Indemnity
– Prohibition of trademark use

Page 17

Mozilla Public License

Reciprocal
Scope based on files (with some ambiguity)
– ''Modifications'' means any addition to or deletion from the
substance or structure of either the Original Code or any
previous Modifications. When Covered Code is released as a
series of files, a Modification is:
A. Any addition to or deletion from the contents of a file
containing Original Code or previous Modifications.
B. Any new file that contains any part of the Original Code or
previous Modifications.

Very broad “patent peace” provision which applies
to both the work licensed under MPL and all
“software, hardware or device”
Numerous notice requirements

Page 18

Challenges of Using Open Source at Scale
Manual management methods are inadequate, prone to
error
– E.g., version proliferation raises complexity and likelihood of errors
Applications Components Versions Components to track
5 2 3 30
5 100 3 1500

When managed poorly, use of open source can introduce
risks and challenges:
– Legal exposure due to unmet license obligations
– Regulatory violations
– Unsupported open source
– Version proliferation

Using open source at scale, brings new challenges
– Management
– Compliance
– Pedigree

Page 19

Summary

Open Source Software is protected by Intellectual Property
Use of Intellectual Property Requires a License
Open source components have licenses with obligations that
must be met
Licenses vary in terms and complexity but cannot be
ignored
Breach the license and many open source licenses
automatically terminate without notice and cure period;
thus risk exposure to claims by the licensor

The Challenge
Give developers the creative freedom they desire while
minimizing process constraints and company exposure to
risk

Page 20

Next in the Black Duck Legal Webinar Series: Best
Practices in Managing OSS

The proliferation of OSS use combined with recent legal actions has
raised industry awareness that open source code must be managed
in compliance with applicable software licenses. Leading development
organizations are establishing policies around open source usage and
implementing engineering development processes which insure that
software products remain in compliance. Join us for a review of
industry best practices around the managed use of open source code.

In this webinar, we will discuss:
– Key issues when defining open source policies
– Formation of a compliance team
– Inbound and outbound compliance processes
– Top implementation approaches

Day and time:
– Wednesday April 15th at 11:30AM EST, 8:30am PT, 4:30pm GMT

To sign up:
http://www.blackducksoftware.com/files/legal-webinar-series.html

Page 21

Legal Issues in Developing in a Hybrid Envionment with Open Source Software

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (8)

Semelhante a Legal Issues in Developing in a Hybrid Envionment with Open Source Software

Semelhante a Legal Issues in Developing in a Hybrid Envionment with Open Source Software (20)

Mais de Mark Radcliffe

Mais de Mark Radcliffe (12)

Último

Último (20)

Legal Issues in Developing in a Hybrid Envionment with Open Source Software