open source legality patterns - tiedekunnatohar/luennot/luennot2010/opensource.pdfopen source...
TRANSCRIPT
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
Open Source – The Design
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
Open Source – The Design
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
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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
Eclipse Bug Reports
Eclipse Bug Reports
Agenda
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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
Open Source Licenses - Definitions
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
Open Source Licenses - Definitions
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
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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 )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
Client (Proprietary )
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
Client (Proprietary )
Initialize and get results
Agenda
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
Client (Proprietary )
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (AGPL)
Client (Proprietary )
Additional service layer
Agenda
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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
Presentation Layer (Proprietary )
Data Archiving (BSD)
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (AGPL)
Client (Proprietary )
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
Client (Proprietary )
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
Presentation Layer (Proprietary )
Data Archiving (Open Source )
Data Processing (GPL)
Data Collection (Open Source )
Remote Data Source (Open Source )
Client (Proprietary )
Implement as a pool of plugins
Agenda
q Introduction§ Definitions§ Example
qOpen Source LicensesqOpen Source Legality Patterns§ Interaction Legality Patterns§ Isolation Legality Patterns§ Licensing Legality Patterns
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?