open source software: brussels a brief primera123.g.akamai.net/7/123/121311/abc123/yorkmedia... ·...

Skadden, Arps, Slate, Meagher & Flom LLP

Open Source Software: A Brief Primer

Stuart D. Levi

PLI - November 2014

Beijing

Boston

Brussels

Chicago

Frankfurt

Hong Kong

Houston

London

Los Angeles

Moscow

Munich

New York

Palo Alto

Paris

San Francisco

São Paulo

Shanghai

Singapore

Sydney

Tokyo

Toronto

Vienna

Washington, D.C.

Wilmington

Skadden, Arps, Slate, Meagher & Flom LLP 2

Defining “Open Source”

• There is no legal definition

• Open Source (1998) v. Free Software (1985)

– According to the Free Software Foundation, they convey

different ideas/philosophies

• “The fundamental difference between the two movements is in

their values, their ways of looking at the world.”

• “’Free software’ means software that respects users' freedom

and community. Roughly, the users have the freedom to run,

copy, distribute, study, change and improve the software.”

• Understanding the origins of the open source/free

software movement is critical to understanding the

legal issues that may arise.


Defining Open Source (cont.)

• Open source is a development methodology; free

software is a social movement. For the free software

movement, free software is an ethical imperative,

because only free software respects the users'

freedom. By contrast, the philosophy of open source

considers issues in terms of how to make software

“better”—in a practical sense only.

• For the Open Source movement, non-free software is

a suboptimal solution. For the Free Software

movement, non-free software is a social problem and

free software is the solution



• A program is free software if the program's users

have the following our essential freedoms:

– The freedom to run the program, for any purpose (freedom

0).

– The freedom to study how the program works, and change it

so it does your computing as you wish. Access to the source

code is a precondition for this. (freedom 1).

– The freedom to redistribute copies so you can help your

neighbor (freedom 2).

– The freedom to distribute copies of your modified versions to

others. Access to the source code is a precondition for this.

(freedom 3).



• Why does the different in philosophy matter?

– The FSF has written the most commonly

used “open source” license – the GPL,

Lesser GPL, and Affero GPL

• The FSF philosophy shapes much of the

debate in the “open source” community and

the manner in which open source is used


Software Development Methodology

• Source code (human-readable code) freely available

(hence, “open source”)

• Typically open, community-based software

development

• In many cases, no individual “controls” the evolution

of the software

• Programmers improve the software; fix bugs, etc. and

then send back into the community

• No counter-party to turn to if there are any issues.


Contrast Traditional Software Development

• “Closed” source

• Private development teams and methodology

• Restrictive License Terms

– Limitations on scope of use

– Restrictions on modifications, reverse engineering,

redistribution, etc.

– Vendor as sole source for maintenance and support

• But, a defined counter-party to turn to if there is an

issue


Open Source Licenses

• In many ways, open source is defined by the

license under which it is offered

• There are scores of available licenses that vary

in their approach to how the software may be

used.

• These licenses can, very broadly speaking, be

divided into two buckets


Open Source Licenses

• “Copyleft” licenses require licensee to license

specific developments (if they are not

restricted to internal use) to anyone under the

original license.

• “Permissive” or “Attribution” licenses

enable the licensee to license his modifications

to the original software as either Open Source

software or "proprietary" software


GPL Family of Licenses

• License that Linux is licensed under

• Arguably, the strictest of all licenses in preserving the

“purity” of open source

• The most complex of all licenses

• Goal is to ensure that any derivatives of open source

are themselves open source

• Raises concerns of open source “infecting” any

proprietary code with which it is integrated, and

rendering the proprietary code open source



• GPL (v.3) –

– The most commonly used GPL license – strong copyleft

protection.

• LGPL (“Lesser” GPL) –

– Often used for “shared libraries”

– Considered a compromise between the GPL and permissive

licenses like the BSD.

– Allows a work to be linked with (or in the case of a library,

'used by') another program, regardless of whether it is free

software or proprietary software.

– The non-LGPLed program can be distributed under any

terms if it is not a derivative work.



• Affero GPL

– If you run the program on a server and let other users

communicate with it, your server must also allow users to

download the source code corresponding to the program that

is running

– Originally designed to protect open source developers against

a case where the next developer modifies the software but

then only offers it on an ASP-type basis (thereby keeping

their modifications out of the open source community).

– Recommended by the FSF for any software that will run over

a network.

– Given a “version 3” designation to match up with the GPL


BSD-License (“Attribution Licenses”)

• BSD-style (originally used for BSD Unix)

– Most popular alternative to the GPL

– Considered a “permissive” license”

– No limits on integration with proprietary code

– No obligation to disclose modifications

– Basically allows the user to do anything if they provide credit

• Apache License (Apache Software Foundation)

• Form of BSD License

• Preserve attribution and any IP notices

• “as is” disclaimer


Mozilla License

• Different from BSD: Requires that any and all

changes to code covered by the license must

be made publicly available

• Different from GPL: “You may create and

distribute a Larger Work under terms of Your

choice, provided that You also comply with

the requirements of this License for the

Covered Software.”

• Allows you to more easily combine open

source with proprietary software.


Two Critical Issues in Open Source

• When is open source “combined” with another

work

– Important for GPL licenses

• When is open source deemed “distributed”

– Relevant for a variety of licenses (including

“attribution” licenses).”


“Combinations” Under the GPL

• A compilation of a covered work with other separate

and independent works, which are not by their nature

extensions of the covered work, and which are not

combined with it such as to form a larger program, in

or on a volume of a storage or distribution medium, is

called an “aggregate” if the compilation and its

resulting copyright are not used to limit the access or

legal rights of the compilation's users beyond what the

individual works permit. Inclusion of a covered work

in an aggregate does not cause this License to apply to

the other parts of the aggregate


“Combinations” Under the GPL

• Where's the line between two separate programs, and one program with

two parts?

– This is a legal question, which ultimately judges will decide.

– We believe that a proper criterion depends both on the mechanism of

communication (exec, pipes, rpc, function calls within a shared address

space, etc.) and the semantics of the communication (what kinds of

information are interchanged).

– If the modules are included in the same executable file, they are definitely

combined in one program.

– If modules are designed to run linked together in a shared address space, that

almost surely means combining them into one program.

– Pipes, sockets and command-line arguments are communication

mechanisms normally used between two separate programs. So when they

are used for communication, the modules normally are separate programs.

But if the semantics of the communication are intimate enough, exchanging

complex internal data structures, that too could be a basis to consider the

two parts as combined into a larger


Distribution

• Arises under both copyleft and permissive licenses

– For example, the BSD requires attribution and notices to be

included when the work is “redistributed.”

• When is a work deemed “distributed” today?

– Many SaaS applications have a robust “client side” especially

in cases of html5; javascript; and flash

– Is a SaaS program distributed if the client side includes

nontrivial code?


A New Concern for Many Companies

• “Heartbleed” (April 2014)

– OpenSSL (open source) encryption flaw

– View secure communications across HTTPS

• Passwords, encryption keys, PII, etc.

• Called a “trivial error with a severe impact”

– “Heartbleed: Is the open source development model broken?” –

ZDNet May 2014

• Not enough money to support open source development community

• Do open source projects have the same QT as proprietary projects?

• “Given enough eyeballs, all bugs are shallow” – still true?

•


A New Concern for Many Companies

• Bash Shellshock (Sept. 2014)

– A shell sends command to an operating system. The Bash Shell is

used primarily on Unix and Linux systems

– A flaw in Bash, which had been present for two decades, could

allow an attacker to take complete control of a computer if the

software is remotely accessible

– Led to intense scrutiny which revealed additional flaws

– Attackers exploited Shellshock to perform distributed denial of

service attacks and vulnerability scanning.


Questions or comments?

Stuart Levi

[email protected]

(212) 735-2750

mailto:[email protected]

open source software: brussels a brief primera123.g.akamai.net/7/123/121311/abc123/yorkmedia... ·...

Documents