Open Source Legality Patterns

Transcription

1 Open Source Legality Patterns Architectural Design Decisions Motivated by Legal Concerns Imed Hammouda, adjunct professor Tampere University of Technology

2 Credits q Tommi Mikkonen, professor q TUTOpen, TUT Open Source Research Group

3 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

4 Open Source vs. Free Software 4 qfree software (983) is: A philosophy A social movement FSF Stallmanism qopen source (998) 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

5 Open 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 [

6 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 In addition, adequate tools are needed! 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 [ [

7 Open Source The Community q Non-profit organization q Sponsors q Commercial enterprises q The Onion model of communities q Communities around OSS projects Volunteer-based Ideology, freedom, sharing Company-based Business, funded developers Mixed q Different types of communities Linux: Project centric MySQL: Business centric Eclipse: Foundation centric Passive user Reader Bug reporter Bug fixer Peripheral developer Active developer Core member Project leader

8 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. [ huge_and_important_news_free_l.html]

9 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

10 Open Source The Technology Life Cycle Efficient and Effective Development (

11 Open Source The Cost

12 Open Source The Design Extension Designs often remain undocumented Plugin Architecture recovery tools helpful Plugin Extension Core system In general attention geared towards running code Plugin Extension Aim at designing (large) separate entities of open source and proprietary code

13 Open Source The Design q 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. Technically speaking Linux is only the kernel Dev. Drv Processor/Cache Control q 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 Modularity enables concurrent development Dev. Drv2 Dev. Drv3 Dev. Drv4 Memory Management Process Management File System Interface Networking Stacks Kernel State Information New Funct. Device & I/O Interface Extended f. Security/Auth.

14 Open Source The Design q 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 3 rd Party Distributions can provide quality support and professionalism for Linux. However, they also introduce a risk of fragmentation. Linux Kernel Patches Compilers and Tools Text Processing Games Communication Installation tools Support Tools Enhancement Localization Packaging Tools Drivers Modules Networking Bundling Packages > 000 Distribution Specific Add-ons Distribution

15 Open Source The Challenges q Stability in different contexts Communities often develop for their own use, so a new context may be untested Integration into something more complex q Versioning 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? q Management 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

16 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

17 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!) q Mostly for companies, people commonly participate for money [Based on Ilkka Luoma: MSc Thesis, Tampere U of Tech, 2007]

18 Eclipse Members q Strategic Members: companies that view Eclipse as a strategic platform and are willing to invest. E.g. IBM, Nokia, Oracle q Add-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 q Associate Members: organizations that are a non-for-profit organization, standards body, university, research institute or publisher. E.g. Addison Wesley, VTT, OMG q Committer Members: individuals that are one of the core developers of the Eclipse technology

19 Projects in Eclipse

20 Management in Eclipse

21 Roadmapping in Eclipse

22 Project Lifecycle in Eclipse Projects go through six distinct phases All Projects are required to have at least one review per year.

23 Becoming an Eclipse Contributor q New committers are voted in by the existing committers on a project. q Based 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 q Best way to start contributing to Eclipse: Well-formed bug reports Feature requests Code enhancements

24 Eclipse Tools and Practices q Tools Eclipse PDE (Plugin Development Environment) CVS Bugzilla Javadoc q Projects use many commercial tools Example: MTJ focuses on Model Driven Development and uses Rational Rose q Practices Lots of teleconferences Project Plans Reviews

25 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

26 Release Early, Release Often

27 Eclipse Bug Reports

28 Eclipse Bug Reports

29 Eclipse Bug Reports

30 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

31 Categorizing Software Licenses Software type License feature Zero price Redistributable Unlimited usage Source code Commercial Shareware x x Freeware x x x FLOSS x x x x

32 Open Source Licenses - Definitions Licenses Data Licenses Code Licenses Proprietary Open licensed Non commercial Proprietary Open source Freeware Strong copyleft Permissive Shareware SAAS Strong copyleft Weak copyleft Permissive AGPL GPLv2 GPLv3 LGPLv2 LGPLv3 EPL BSD Apache MIT

33 Open Source Licenses - Definitions Ownership Release Own Third party Public domain Derived Combined Interface Linking System User Static Dynamic

34 Open Source Licenses - Definitions Component relationships Data Control Text Graphics Audio Video Messages Function calls API (standard, non-standard) Callback Library Remote vs Local

35 Artistic 2 2 SSPL IPL Apache PHP CDDL MPL X BSD LGPL GPL Artistic SSPL IPL Apache PHP CDDL MPL X BSD LGPL GPL - Mixing and linking permissible 2- Only dynamic linking is permissible 3- Completely incompatible License Compatibility

36 Consequences q Software development cannot play with licenses freely but must take all used 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 q With open source, one cannot usually deal with the vendor but is forced to take restrictions and obligations into account in the design of software system q Usually affect software architecture, i.e. the fashion software components are connected

37 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

38 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. q Open 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.

39 Patterns q Interaction legality patterns q Licensing legality patterns q Standardized interface q Dynamic linking q Data-driven communication q Evaluator q Repackage q Tier q User delegation q Isolation legality patterns q Proprietary server q Service interaction

40 Pattern Description Format q Name: The name will extend design vocabulary and ease discussing the pattern. q Context and Problem: Defines a situation in which the pattern is applicable. q Solution: 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. q Special Considerations: Some patterns lend themselves to some special considerations. For those additional remarks will be given. q Example: A running example is used throughout the pattern descriptions.

41 Example: Weather Prediction System

42 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

43 Interaction Legality Patterns qthe purpose of interaction legality patterns is to loosen and relax the dependency of components regarding each other.

44 Pattern: Standardized Interface q Context and problem: A software component A links to a strong copyleft licensed (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. q Solution: 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. q Special considerations: Developers should be aware of system interfaces to distinguish between standard and non-standard ones.

45 Standardized Interface: Example Client (Proprietary ) Use a standard interface Presentation Layer (Proprietary ) Data Processing (GPL) The copyright does *not* cover user programs that use kernel services by normal system calls this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Data Archiving (Open Source ) Data Collection (Open Source ) Remote Data Source (Open Source )

46 Pattern: Dynamic Linking q Context 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. q Solution: Switch from static linking to dynamic linking in the implementation. q Implementations: COTS, different plugin systems, dynamic linking facilities in operating systems. q Special considerations: While switching to dynamic linking, the developers should not tie the system to a particular strong copyleft licensed 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.

47 Dynamic Linking: Example Client (Proprietary ) Choose dynamic linking Presentation Layer (Proprietary ) Data Processing (GPL) The data processing component should be loaded into the application at runtime Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (Open Source )

48 Pattern: Data-driven Communication q Context 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. q Solution: 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. q Special 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.

49 Data-driven Communication: Example Client (Proprietary ) Migrate to datadriven component relationships Presentation Layer (Proprietary ) Data Processing (GPL) System integration through data buffers Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (Open Source )

50 Pattern: Evaluator q Context 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. q Solution: 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. q Special considerations: At times it may be unclear how the input given to the evaluator should be licensed, under program (e.g. GPL) or content creation (e.g. Creative Commons) licenses.

51 Evaluator: Example Client (Proprietary ) Presentation Layer (Proprietary ) Data Processing (GPL) Initialize and get results Data Archiving (Open Source ) Data Collection (Open Source ) Remote Data Source (Open Source )

52 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

53 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.

54 Pattern: Proprietary Server q Context 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. q Solution: Introduce a single server system and run all business critical code in the server. q Implementations: Numerous web systems. q Special 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.

55 Proprietary Server: Example Client (Proprietary ) Presentation Layer (Proprietary ) Data Processing (GPL) Single server system Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (Open Source )

56 Pattern: Service Interaction q Context 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. q Solution: Avoid user interaction by including an additional layer between the user and the open source licensed service. Since the consumer 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. q Special considerations: The GUI interfaces are moved from the open source licensed service to the additional layer. The user interacts only with the additional layer.

57 Service Interaction: Example Client (Proprietary ) Presentation Layer (Proprietary ) Additional service layer Data Processing (GPL) Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (AGPL)

58 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

59 Licensing Legality Patterns qlicensing legality patterns concern the fashion the different software components should be licensed.

60 Pattern: Repackage q Context 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. q Solution: 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. q Special 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.

61 Repackage: Example Client (Proprietary ) Presentation Layer (Proprietary ) Repackage Data Processing (GPL) Data Archiving (BSD) Data Collection (Open Source ) Remote Data Source (AGPL)

62 Pattern: Tier q Context 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. q Solution: 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. q Special 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.

63 Tier: Example Client (Proprietary ) Add an intermediate tier layer Presentation Layer (Proprietary ) Data Processing (GPL) The intermediate tier layer can be licensed under the terms of LGPL or BSD Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (Open Source )

64 Pattern: User Delegation q Context 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. q Solution: 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. q Special 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.

65 User Delegation: Example Client (Proprietary ) Implement as a pool of plugins Presentation Layer (Proprietary ) Data Processing (GPL) Data Archiving (Open Source ) Data Collection (Open Source) Remote Data Source (Open Source )

66 Agenda qintroduction Definitions Example qopen Source Licenses qopen Source Legality Patterns Interaction Legality Patterns Isolation Legality Patterns Licensing Legality Patterns qconclusions

67 Conclusions qopen source is not a silver bullet but a good tool qopen source licensing is a technical issue in addition to legalities qlegality view of software architecture?

68 Thank You! Questions?