Heather Meeker and Michael Herzog discuss the primary open source license obligations and some practical approaches for compliance with attribution and redistribution obligations.

1. Managing
Open
Source
Obliga1ons

2. Managing
Open
Source
Obliga1ons
Agenda
• Introduc1on
• Iden1fy
the
ten
most
common
open
source
license
obliga1ons
• Explain
what
you
need
to
do
to
comply
with
these
obliga1ons
• Discuss
the
key
compliance
challenges
today
• Outline
an
approach
for
automa1ng
compliance
• Describe
compliance
automa1on
case
studies
–
Android
and
DejaCode
• Ques1ons

3. Managing
Open
Source
Obliga1ons
Ten
Most
Common
OSS
License
Obliga1ons
• Copyright
no1ces
• License
no1ces
• AFribu1on
requirements
• “CopyleI”
obliga1ons
(licensing
of
deriva1ve
works)
• Source
code
licensing
• Source
code
delivery
• Build
and
installa1on
instruc1on
delivery
(GPL)
• No1ce
of
changes
• Indemni1es
• Non-­‐use
of
trademarks

4. Managing
Open
Source
Obliga1ons
How
to
Comply
–
No1ces
• Copyright,
license,
modifica1on,
and
aFribu1on
requirements
• Delivery
of
source
code
may
be
the
easiest
way
to
comply,
because
no1ces
are
“baked
in”
to
distribu1on
package
• Binary
delivery
requires
crea1on
of
no1ce
files
• No1ces
must
be
in
the
product
delivery,
for
most
licenses
• Online
delivery
is
usually
not
sufficient
• Relying
on
third
party
no1ces
is
usually
not
sufficient

5. Managing
Open
Source
Obliga1ons
How
to
Comply
–
Source
Code
• For
GPL,
LGPL,
and
other
copyleI
licenses
• Source
materials
must
be
made
available,
but
not
necessarily
delivered
with
product
• Not
necessary
to
post
source
materials
on
the
web,
but
this
is
a
good
prac1ce

6. Managing
Open
Source
Obliga1ons
How
to
Comply
-­‐
Licenses
• Need
to
carve
copyleI
licensing
requirements
from
EULAs
• GPL,
LGPL
and
other
licenses
cannot
be
changed
to
other
terms
• “Weak
copyleI”
licenses
like
EPL,
MPL
allow
bifurcated
licensing
of
source
and
binaries

7. Managing
Open
Source
Obliga1ons
Key
Compliance
Challenges
• Tracking
open
source
use
• No1ce
crea1on
• No1ce
delivery
• Build
and
installa1on
instruc1on
delivery
• Ensuring
the
source
code
is
right
for
the
build

8. Managing
Open
Source
Obliga1ons
Compliance
Automa1on
Star1ng
point
is
a
good
baseline
analysis
• Origin
and
license
of
open
source
components
• Which
open
source
components
are
Deployed
Then
you
need
prac1cal
ways
to:
• Enable
and
encourage
the
engineering
team
to
keep
origin
and
license
data
current,
and
• Use
that
data
to
create
compliance
deliverables,
and
• Audit
a
new
release
efficiently,
and
• Repeat
the
process

9. Managing
Open
Source
Obliga1ons
Compliance
is
easier
than
you
think
Establish
simple
policies
–
“Highest
common
requirement”
for:
• AFribu1on
text
documenta1on
and
display
• Source
code
Redistribu1on
• Change
documenta1on
• Non-­‐endorsement
/
trademarks
ALWAYS
keep
original
copyright
and
license
no1ces
with
the
codebase
(in
files
or
directories)

10. Managing
Open
Source
Obliga1ons
Compliance
is
easier
than
you
think
Add
a
simple
system
to
track
license
data
that:
• Can
be
adapted
to
exis1ng
engineering
processes
– Engineers
can
use
and
update
the
data
during
normal
soIware
development
ac1vi1es
– Independent
of
programming
languages
or
tools
• Can
produce
data
for:
– Delivery
to
customers
as
• AFribu1on
and
Redistribu1on
packages
• SPDX
(SoIware
Package
Data
Exchange)
files
– Import
into
enterprise
systems

11. Managing
Open
Source
Obliga1ons
SoIware
Package
Data
Exchange®
• A
standard
format
for
communica1ng
the
components,
licenses
and
copyrights
associated
with
a
soIware
package
• Allows
easy
exchange
of
license
informa1on
between
companies
reducing
burden
on
both
suppliers
and
consumers
• A
Working
Group
of
the
Linux
Founda1on
• Part
of
Linux
Founda1on’s
Open
Compliance
Program
www.spdx.org

12. Managing
Open
Source
Obliga1ons
Component
Metadata
• Add
one
text
file
per
soIware
component
at
the
level
necessary
to
document
the
origin,
license
and
obliga1ons
for
the
component
• Typically
a
text
or
XML
file
with
“tag
/
value”
format,
such
as:
COMPONENT:
Myarchive
VERSION:
1.2.3
LICENSE_NAME:
MIT
LICENSE_TEXT:
(text
goes
here……)
ATTRIBUTION_TEXT:
(if
different
from
license
text)
LICENSE_FILE:
myarchive.LICENSE
SOURCE_REDISTRIBUTION:
yes/no
USAGE:
Internal
only

13. Managing
Open
Source
Obliga1ons
Basic
Automa1on
• Use
script-­‐style
programs
to
read
Component
Metadata
file
and
• Create
an
AFribu1on
text
file
• Create
a
Redistribu1on
package
list
• Edit
the
files
to
remove
components
that
are
not
Deployed
• Add
the
AFribu1on
text
file
to
the
product
documenta1on
and(or)
product
GUI
(Help
/
About)
• Assign
an
engineer
to
create
the
Redistribu1on
package
and
installa1on/build
instruc1ons

14. Managing
Open
Source
Obliga1ons
Advanced
Automa1on
Enhance
the
build
system
and
tools
to:
• Recognize
Component
Metadata
files
• Assemble
Component
Metadata
files
during
a
build
for
components
included
in
an
end-­‐product
(Deployed)
• Collect
AFribu1on
data
for
Deployed
components
and
create
AFribu1on
text
file
• Insert
AFribu1on
text
into
GUI
(Help
/
About)
• Collect
source
code
for
the
components
that
require
Redistribu1on
(including
dependencies)
• Create
an
archive
file
of
the
Redistribu1on
package

15. Managing
Open
Source
Obliga1ons
AndroidTM
Case
Study
• Android
project
applies
an
advanced
approach
to
automate
OSS
compliance
• Several
types
of
metadata
files
added
to
the
project
codebase
• Build
system
can
use
these
files
to
create
AFribu1on
text
and
Redistribu1on
packages
based
on
Deployed
components
The Android robot is reproduced or modified from work created and shared by Google and used according to terms described
in the Creative Commons 3.0 Attribution License.

16. Managing
Open
Source
Obliga1ons
Android
Metadata
• MODULE_LICENSE_xxx
marker
files
• MODULE_LICENSE_APACHE2
means
the
directory
is
Apache
2.0-­‐licensed
• Approx.
500
such
files
in
Android
4.1
–
Jelly
Bean
• NOTICE
files
• Co-­‐located
with
MODULE_LICENSE
marker
files
• Contains
license
and
other
aFribu1on
text
• Created
by
the
original
OSS
project
or
by
Android
team
• Plus
keep
all
original
no1ces

17. Managing
Open
Source
Obliga1ons
Android
Tools
• Tools
in
the
Android
build
system:
• Create
aFribu1on
no1ces
from
and
display
them
in
the
Android
UI
• Collect
source
code
and
create
archives
for
redistributable
source
code
• AFribu1on
and
Redistribu1on
packages
are
based
on
the
actual
subset
of
code
Deployed
as
determined
by
the
build
system

18. Managing
Open
Source
Obliga1ons
Android
Compliance
Deliverables
• AFribu1on
text
is
delivered
on
the
phone
or
tablet
as
an
HTML
file
located
at
Seongs
/
About…
/
Legal
Informa1on
/
Open
Source
License
– (You
can
check
this
now)
• You
can
see
examples
of
Android
compliance
packages
for
Motorola
Mobility
phones
and
tablets
• Source
code
packages
are
provided
at:
– hFp://sourceforge.net/motorola/wiki/Android/
– (Metadata
files
are
inside
each
code
package)

19. Managing
Open
Source
Obliga1ons
DejaCodeTM
Case
Study
• nexB
has
developed
a
basic
specifica1on
and
corresponding
tools
to
automate
compliance
• Based
on
ABOUT
files
for
Component
Metadata
• Applicable
to
any
programming
language
and
soIware
development
environment
• Extensible
to
build
system
integra1on
for
advanced
approach
• Tools
licensed
under
Apache
2.0

20. Managing
Open
Source
Obliga1ons
ABOUT
File
Example
hFpd-­‐2.4.3.tar.gz.ABOUT
name:
Apache
HTTP
Server
home_url:
hFp://hFpd.apache.org
download_url:
hFp://apache.belnet.be//hFpd/
hFpd-­‐2.4.3.tar.gz
version:
2.4.3
date:
2012-­‐08-­‐21
license:
apache-­‐2.0
license_file:
hFpd-­‐2.4.3.tar.gz/LICENSE
copyright:
Copyright
2012
The
Apache
SoIware
Founda1on.
no1ce_file:
hFpd-­‐2.4.3.tar.gz/NOTICE

21. Managing
Open
Source
Obliga1ons
DejaCode
compliance
tools
• Based
on
Component
Metadata
in
ABOUT
files
• Creates
OSS
inventory
on
demand
(spreadsheet)
• Creates
AFribu1on
text
file
• Text
file
organized
by
copyright/license
no1ce
and
component
• Default
text
or
HTML
format
• Creates
source
code
Redistribu1on
package
list

22. Managing
Open
Source
Obliga1ons
DejaCode.org
• nexB
is
sponsoring
DejaCode.org
as
a
community
site
to
share
techniques
and
tools
for
automa1ng
compliance
with
OSS
obliga1ons
• Documenta1on
of
exis1ng
techniques
and
tools
from
Android,
Apache
Maven
(Java),
CPAN
(Perl)
and
others
• Home
for
new
projects
like
nexB’s
ABOUT
system
• Visit
us
at:
www.dejacode.org

23. Managing
Open
Source
Obliga1ons
“Virtuous”
compliance
lifecycle
• Complete
baseline
codebase
analysis
for
a
product
• Generate/create
Component
Metadata
files
in
the
codebase
from
baseline
analysis
findings
• Update
Component
Metadata
files
during
release
development
• Confirm
Component
Metadata
changes
and/or
iden1fy
addi1onal
changes
with
an
audit
• Regenerate
compliance
deliverables
using
the
Component
Metadata
files
• Repeat…

24. Managing
Open
Source
Obliga1ons
Ques1ons

25. Managing
Open
Source
Obliga1ons
About
Greenberg
Traurig
LLP
• GT
is
an
interna1onal,
mul1disciplinary
law
firm
in
35
loca1ons
in
the
United
States,
La1n
America,
Europe,
the
Middle
East
and
Asia.
• An
Interna1onal
Network
of
More
than
1,750
AForneys
&
Governmental
Affairs
Professionals

26. Managing
Open
Source
Obliga1ons
About
nexB
Inc.
• nexB
offers:
– SoIware
analysis/audit
services
for
acquisi1ons
and
for
products
– DejaCode
Enterprise
–
a
central
business
system
for
managing
soIware
components
• 200+
soIware
audit
projects
completed
to-­‐date
– Aggregated
audited
codebases
>
3
billion
lines
of
source
code
– Aggregated
value
of
the
acquisi1ons
transac1ons
>
$5B
• See
the
DejaCode
License
Library
at
www.dejacode.com

27. Managing
Open
Source
Obliga1ons
Contacts
• Greenberg
Traurig
Heather
Meeker
MeekerH@gtlaw.com
• nexB
Inc.
Michael
Herzog
mjherzog@nexB.com
+1
650
380
0680