Open Source Legality Patterns - Tiedekunnatohar/luennot/luennot2010/OpenSource.pdfOpen Source...

Open Source LegalityPatterns

Architectural Design DecisionsMotivated by Legal Concerns

Imed Hammouda, adjunct professorTampere University of Technology

1

2.11.2010

CreditsCredits

q Tommi Mikkonen, professorq TUTOpen, TUT Open Source Research Group

http://tutopen.cs.tut.fi/

Agenda

q Introduction§ Definitions§ Example

qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns

qConclusions

Open Source vs. Free Software

qFree software (1983) is:§ A philosophy§ A social movement§ FSF§ “Stallmanism”

qOpen source (1998) is:§ A business model§ A development methodology§ OSI§ “Raymondism”

qBoth approaches share a common vision on access to source code

qLoads of ready-made systems available in the Internet for various purposes in source form

4

2.11.2010

Open Source SoftwareOpen Source Software

q Basic idea: § When programmers can read, redistribute, and modify the source code for a piece of

software, the software evolves. § People improve it, people adapt it, people fix bugs. § And this can happen at a speed that, if one is used to the slow pace of conventional

software development, seems astonishing

q Open source does not just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

§ Free Redistribution§ Source Code§ Integrity of The Author's Source Code§ No Discrimination Against Persons, Groups, or Fields of Endeavor§ Distribution of License§ License Must Not Be Specific to a Product§ License Must Not Restrict Other Software§ License Must Be Technology-Neutral

[http://[http://www.opensource.orgwww.opensource.org/]/]

Open Source – The Method

q “Open source is a development method for software that harnesses the power of distributed peer review and transparency of process.”

q “The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.”

q Ideally, participation in the community need not be restricted in any ways.§ Practice can however make the

difference!

q [www.opensource.org]

q In addition, adequate tools are needed!

[www.bugzilla.org]

Open Source – The Community

qNon-profit organization qSponsorsqCommercial enterprisesq The Onion model of communitiesqCommunities around OSS projects§ Volunteer-based

• Ideology, freedom, sharing§ Company-based

• Business, funded developers§ Mixed

qDifferent types of communities§ Linux: Project centric§ MySQL: Business centric§ Eclipse: Foundation centric

Project leaderCore member

Active developerPeripheral developer

Bug fixerBug reporter

ReaderPassive user

Open Source – The License

q She who writes the code owns the copyright, and can decide the license

q A way to publish software with the right...§ ... to make copies and distribute software§ ... to have access to the software's source code§ ... to improve software

q License§ With Copyleft (GPL, LGPL, Mozilla (weak copyleft) etc.)§ Without Copyleft (BSD, Apache)§ Viral effect – open and proprietary can touch only if allowed§ Dual License – if you own the copyright, then you decide which license

q OS licenses are nowadays accepted by US authorities§ Court of Appeals for the Federal Circuit (THE "IP" court in the US) has

upheld a free copyright license. [http://lessig.org/blog/2008/08/huge_and_important_news_free_l.html]

Open Source – The Business

§ Internal usage + competition strategy§ Software As A Service (SAAS)§ Consulting (technical, legal, strategic,…)§ Integration, aggregation, and customization§ Retailing and distribution§ Product and software know-how§ Process and methodology know-how§ Services and product support§ Training and recruiting§ Certification and quality assurance§ Substitution/migration§ Dual licensing§ Documentation (books, user manuals, etc)§ Other process-related issues (testing, deployment, etc)§ Hardware + other related software (extra features, protocols, configurations) + media

content§ Commercial software on top of OSS§ Platform specialization/adaptation, localization§ IT infrastructure§ …

Open Source – The Technology Life Cycle

Efficient and Effective Development (http://www.itea-cosi.org/)

Open Source – The Cost

Open Source – The Design

Core system

Extension

Extension

Extension

Plugin

Plugin

Plugin

• Designs often remainundocumented

• Architecture recovery tools helpful

• In general attention gearedtowards running code

• Aim at designing (large)separate entities of open source

and proprietary code

q Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net.

q Technically speaking Linux is only the kernel

Processor/Cache Control

Memory Management

Process Management

File System Interface

Networking Stacks

Device & I/O Interface

Security/Auth.

Kernel State Inform

ation

Dev. Drv1

Dev. Drv2

Dev. Drv3

Dev. Drv4

New Funct.

Extended f.

q Linux is very modular and flexible. § Modularity and flexibility even while the system is

running is provided through additional modules e.g. ‘device drivers’.

§ In OSS/Linux everyone has the ability change or extend the kernel functionality through modules delivered e.g. through patches

q Modularity enables concurrent development


q Each Linux vendor distribution (Red Hat, Montavista, SuSE, …) is typically composed of tested and certified:§ The specific Kernel, “improving” Patches, and Modules§ Specific collection of packages§ Own value-adding enhancements from in-house or 3rd Party

q Distributions can provide quality support and professionalism for Linux. However, they also introduce a risk of fragmentation.

LinuxKernel

Patches

Driv

ers

Mod

ules

Compilers and Tools

Text Processing

Games

Communication

Networking

Packages > 1000

Installation tools

Support Tools

Enhancement

Localization

Packaging Tools

Distribution Specific Add-ons

Bundling

Distribution


qStability in different contexts§ Communities often develop for their own use, so a new context may be untested§ Integration into something more complex

qVersioning§ Branching when starting the development of a new feature is easy§ Merging when the feature is completed is difficult, as there can be several

contradicting and incompatible versions

q Testing§ Many open source systems (and other systems built on top of them) have no

formal requirements, so how to test them?

qManagement and trust§ How to know that some planned feature will acually be released in shedule?

q Legal issues§ Some licences are sticky and viral§ Some licences are incompatible§ Proprietary and open source do not mix well

Open Source – The Challenges

Agenda



qConclusions

Example: Eclipse

q The system§ Rich client platform for developing IDEs§ Licensed under EPL and CPL§ Originally an proprietary IBM project, later released as open source

q The organization§ Independant foundation formed in 2004§ Complex organization compared to most OSS projects

• Eclipse Foundation• Eclipse Management Organization (EMO)• Councils• Projects

§ (Restructured since this slide set has been composed!)

qMostly for companies, people commonly participate for money

[Based on Ilkka Luoma: MSc Thesis, Tampere U of Tech, 2007]

Eclipse Members

qStrategic Members: companies that view Eclipse as a strategic platform and are willing to invest. E.g. IBM, Nokia, Oracle

qAdd-in Provider Members: companies that view Eclipse as an important part of their corporate and product strategy. These companies want to participate in the development of the Eclipse ecosystem. E.g. MySQL, Adobe, Google

qAssociate Members: organizations that are a non-for-profit organization, standards body, university, research institute or publisher. E.g. Addison Wesley, VTT, OMG

qCommitter Members: individuals that are one of the core developers of the Eclipse technology

Projects in Eclipse

Management in Eclipse

RoadmappingRoadmapping in in EclipseEclipse

Project Lifecycle in Eclipse

• Projects go through six distinct phases

• All Projects are required to have at least one review per year.

Becoming an Eclipse Contributor

qNew committers are voted in by the existing committers on a project.

qBased on meritocracy: Prove your abilities before you can become a committer.§ Building a good reputation with the existing committers§ Demonstrating skills to the existing team§ Asking a current project committer to sponsor you as a committer§ Going through an election process, defined in each top-level project's

charter

qBest way to start contributing to Eclipse:§ Well-formed bug reports§ Feature requests§ Code enhancements

Eclipse Tools and Practices

q Tools§ Eclipse§ PDE (Plugin Development Environment)§ CVS§ Bugzilla§ Javadoc

qProjects use many commercial tools§ Example: MTJ focuses on Model Driven Development and uses Rational

Rose

qPractices§ Lots of teleconferences§ Project Plans§ Reviews

Eclipse Conventions and Guidelines

q Naming Conventions - How to name things like packages, classes, and methods

q Coding Conventions - How to make Java code readable

q Javadoc - How to write documentation comments, especially for API

q User Interface Guidelines - How to achieve user interface consistency

q Version Numbering - How to evolve plug-in version numbers

Release Early, Release Often…

Eclipse Bug Reports

Agenda



qConclusions

CategorizingCategorizing Software Software LicensesLicenses

Softwaretype

Licensefeature

Commercial

Shareware

Freeware

FLOSS

Zero price Redistributable Unlimited usage Source code

x x

x

x

x

x

x

x x

Open Source Licenses - Definitions

Licenses

Data Licenses Code Licenses

Open sourceProprietary Freeware

PermissiveWeak copyleftStrong copyleftSAAS

BSD Apache MITLGPLv2 LGPLv3 EPLGPLv2 GPLv3AGPL

Shareware

Non commercialOpen licensedProprietary

PermissiveStrong copyleft


Ownership

Public domainThird partyOwn

Release

CombinedDerived

Interface

UserSystem

Linking

DynamicStatic

Component relationships

ControlData

LibraryCallbackAPI (standard, non-standard) Remote vs Local

Text

Function callsMessages

Graphics Audio Video


11111221123Artistic

11111221111SSPL

11111221123IPL

11111221123Apache

11111221123PHP

22222111123CDDL

22222111123MPL

11111111111X11

11111111111BSD

21222221111LGPL

31333331111GPL

ArtisticSSPLIPLApachePHPCDDLMPLX11BSDLGPLGPL

1- Mixing and linking permissible2- Only dynamic linking is permissible3- Completely incompatible

License Compatibility

Consequences

qSoftware development cannot play with licenses freely but must take allused ones into account

q Technically feasible solutions can lead to violation of some licences

q In order not to violate the licences the software has to be designed in a way that respects licensing terms

qWith open source, one cannot usually deal with the vendor but is forcedto take restrictions and obligations into account in the design of software system

qUsually affect software architecture, i.e. the fashion software components are connected

Agenda



qConclusions

Open Source Legality Patterns

q The generic goal of design patterns is to define a recurring problem in a context, a solution to the problem, and documented consequences.

qOpen source legality patterns are used to document architectural decisions taken in practice by software engineers to enable the use of open source components.

q These design decisions serve as a precaution in connection with open source licenses, but do not pose any legal interpretation.

Patterns

q Interaction legality patterns

q Standardized interfaceq Dynamic linkingq Data-driven communicationq Evaluator

q Isolation legality patterns

q Proprietary serverq Service interaction

q Licensing legality patterns

q Repackageq Tierq User delegation

Pattern Description Format

qName: The name will extend design vocabulary and ease discussing the pattern.

qContext and Problem: Defines a situation in which the pattern is applicable.

qSolution: Defines the solution according to which the problem can be solved.

q Implementations: Introduces some known implementation mechanisms that have been used for this purpose.

qSpecial Considerations: Some patterns lend themselves to some special considerations. For those additional remarks will be given.

qExample: A running example is used throughout the pattern descriptions.

Example: Weather Prediction System

Agenda



qConclusions

Interaction Legality Patterns

qThe purpose of interaction legality patterns is to loosen and relax the dependency of components regarding each other.

Pattern: Standardized Interface

qContext and problem: A software component A links to a strong copyleftlicensed (such as GPL) component B using non-standardized interfaces (hacks). For this reason, the source code of the component A should be released as it strictly ties itself to the source code of component B. Still, the developers would not like to release the source code of component A.

qSolution: Use standardized interface calls to a strong copyleft licensed component to loosen the ties and dependencies among the two communicating components. In this way, component A is not tied any more to component B but can be integrated to any other product which offer same standard interfaces.

q Implementations: Embedded systems that can run on multiple platforms (such as Linux and Windows), software standard implementations, different kinds of wrappers.

qSpecial considerations: Developers should be aware of system interfaces to distinguish between standard and non-standard ones.

Standardized Interface: Example

Presentation Layer (Proprietary)

Data Archiving (Open Source )

Data Processing (GPL)

Data Collection (Open Source )

Remote Data Source (Open Source )

Client (Proprietary)

Use a standard interface

“The copyright does *not* cover user programsthat use kernel services by normal system calls –

this is merely considered normal use of thekernel, and does *not* fall under the heading

of ‘derived work’”.

Pattern: Dynamic Linking

qContext and problem: A system is composed of a number of proprietary and open source components that are statically linked. If a proprietary component statically links to a strong copyleft licensed component, the source code of the proprietary component needs to be published under the same license terms of the open source component.

qSolution: Switch from static linking to dynamic linking in the implementation.

q Implementations: COTS, different plugin systems, dynamic linking facilities in operating systems.

qSpecial considerations: While switching to dynamic linking, the developers should not tie the system to a particular strong copyleftlicensed component, but leave the freedom for users to integrate with any components.

Dynamic linking pattern is in practice often used in connection with Standardized interface pattern.

Dynamic Linking: Example

Presentation Layer (Proprietary )





Client (Proprietary )

Choose dynamic linking

The data processing componentshould be loaded into the application

at runtime

Pattern: Data-driven Communication

qContext and problem: A system is composed of a number of proprietary and open source components with conflicting licenses. The components link to each other control-driven communication.

qSolution: Avoid conflicting licenses by migrating from control-driven communication to data-driven component relationships.

q Implementations: Systems that can be implemented around architectural styles such as Pipes and Filters architectural style, and blackboard. Piping in Unix type of environment.

qSpecial considerations: Migrating to data-centric communication may come at the cost of overall system quality attributes such as performance, since interpreting the data may lead in increased processing requirements.

Data-driven Communication: Example







Migrate to data-driven component

relationships

System integration throughdata buffers

Pattern: Evaluator

qContext and problem: The main program is only available as open source, and it needs the results of another program, which in turn is derivative of another open source system. Licenses of used programs are incompatible.

qSolution: The main program initializes the execution of the auxiliary program with the desired set of data. Once the execution is complete, the auxiliary program delivers the results to the main program.

q Implementations: Many virtual machine based systems, in particular those that can be extended with scripts. Proprietary graphics accelerators that can be accessed from open source systems.

qSpecial considerations: At times it may be unclear how the input given to the evaluator should be licensed, under program (e.g. GPL) orcontent creation (e.g. Creative Commons) licenses.

Evaluator: Example







Initialize and get results

Agenda



qConclusions

Isolation Legality Patterns

qThe purpose of isolation legality patterns is to isolate open source components in a fashion that they would remain in the use of a single authority.

Pattern: Proprietary Server

qContext and problem: A system is composed of a number of open source components but the developers wish that certain parts of the system remain proprietary for business reasons.

qSolution: Introduce a single server system and run all business criticalcode in the server.

q Implementations: Numerous web systems.

qSpecial considerations: While many older licenses commonly allow this approach, there are newer licenses that have been written with servers in mind. They may also include viral effect for server software as well.

Proprietary Server: Example







Single server system

Pattern: Service Interaction

qContext and problem: A system which includes user interaction is a derived work of a system-as-a-service (SAAS) like licensed (such as AGPL) software. User interaction requires that the source code of the derived work needs to be published. The developers would not like to release the source code.

qSolution: Avoid user interaction by including an additional layer between the user and the open source licensed service. Since theconsumer of the open source licensed software is a service and not a user, the requirement of publishing the code does not hold.

q Implementations: Numerous web systems. Software as a service systems.

qSpecial considerations: The GUI interfaces are moved from the open source licensed service to the additional layer. The user interacts only with the additional layer.

Service Interaction: Example





Remote Data Source (AGPL)


Additional service layer

Agenda



qConclusions

Licensing Legality Patterns

qLicensing legality patterns concern the fashion the different software components should be licensed.

Pattern: Repackage

qContext and problem: Some open source licenses such as BSD are so liberal that a derived work of corresponding source code can be published under a different license. However, relicensing is often considered as a risky and bad practice. Still, the developers wish to relicense the component to address the legal concerns of clients.

qSolution: Repackage the derived source code and relicense the package. The source code itself keeps the original open source license. The derived source can be distributed under a new license.

q Implementations: COTS.

qSpecial considerations: What makes this solution possible is that a software package can be distributed using a license that is different from the one(s) used for the individual source files of that package.

Repackage: Example


Data Archiving (BSD)



Remote Data Source (AGPL)


Repackage

Pattern: Tier

qContext and problem: A piece of proprietary code or code under an incompatible open source license wants to use an open source component with strong copyleft.

qSolution: Add an intermediate tier layer that can be released under a license that is compatible with the copyleft license, but is less sticky so that a piece of code using its interface is not affected.

q Implementations: COTS. Numerous interfacing and wrapper components and frameworks.

qSpecial considerations: May lead to inventing new licenses that enable the intended use of the component, depending on what kind of a license is being wrapped.

Tier: Example







Add an intermediate

tier layer

The intermediate tier layer can belicensed under the terms of

LGPL or BSD

Pattern: User Delegation

qContext and problem: A system is constructed of a number of open source components that are not compatible with each other due to the use of different licenses. Consequently they cannot be made readily available as a single package that could be downloaded, compiled, and installed.

qSolution: Instead of making the system available as such, the user is instructed to follow a number of steps that are necessary for building the system. Consequently, the user himself is assuming the responsibility for the composed software system and in many cases that removes the compatibility issues.

q Implementations: Numerous patch systems.

qSpecial considerations: If the user is instructed to build a system that potentially violates licensing terms, the case should be made explicit in the associated documentation. The user should not be a reseller of the whole system.

User Delegation: Example







Implement as a pool of plugins

Agenda



qConclusions

Conclusions

qOpen source is not a silver bullet – but a good toolqOpen source licensing is a technical issue in addition to

legalitiesqLegality view of software architecture?

Thank You !

Questions?

Open Source Legality Patterns - Tiedekunnatohar/luennot/luennot2010/OpenSource.pdfOpen Source...

Documents

Transcript of Open Source Legality Patterns - Tiedekunnatohar/luennot/luennot2010/OpenSource.pdfOpen Source...