Open Source and Government Procurement

Transcription

2 Increasingly unwise not to consider open source Increasingly unrealistic to avoid open source

3 You How are governments using open source software?

4

5 Surveyed DOD shops regarding open source usage Found more usage than was expected Should not come as a surprise

6 Reported usage averages 94 packages Actual usage typically exceeds reported usage by 3x-10x

7 Why are governments using open source software?

8 Benefits of Open Source (to Government) Direct benefits Access to source code (both yours and others) Fewer legal restrictions (than proprietary software) Increased ability to update Faster evaluation and prototyping Lower barriers to entry/exit (lowered risk of lock-in) Increased maintenance options (and lowered maintenance costs) Lowered TCO (and TCD) Indirect benefits Increases in openness, transparency, accessibility, integrity, etc. R&D/Technology transfer Education Job creation

9 Why isn t government using open source software?

10 Procurement rules?

11 The federal government should allow Open Source development efforts to compete on a level playing field with proprietary solutions in government procurement [...]. PITAC Panel for High End Computing May 18, 2000

12 This memorandum reminds agencies of policies and procedures covering acquisition of software to support agency operations. These policies are intentionally technology and vendor neutral, and [...] implementation should be similarly neutral. These policies apply to acquisitions of all software, whether it is proprietary or Open Source Software.

13 Differences in [open source] licensing may affect the use, the security, and the total cost of ownership of the software and must be considered when an agency is planning a software acquisition. [S]oftware licensing requirements can be legally complex and can directly impact agency operations.

14 [C]onsult with their General Counsel s Office to ensure the requirements are understood before procuring and using the software. [M]ake sure employees are aware of the [open source] licensing restrictions of the software they are using. This is particularly important when the licensing restrictions require changes to routine employee operations.

15 Procurement rules? Procurement practices?

16

17 "In order to fully take advantage of open-source software, Defense Department agencies may need to rethink how they do procurement. Fritz Schulz Chief Technology Office Defense Information Systems Agency (Speaking at the 2007 Red Hat Government Users Conference)

18 Clarity and consistency in Procurement rules? Procurement practices?

19 "Those factors that are in favor of open source have not been appreciated to date. "Those mandates [in which] we have to consider commercial off-the-shelf software, we have to apply that to open source software as well. And that is not well appreciated within government." Daniel Risacher Office of the Secretary of Defense (Speaking at the 2008 Red Hat Government Users Conference)

20 DoD CIO has announced a memo aiming to address various questions that have arisen since earlier policies and directives Dispel lingering ideas that open source is a form of shareware or freeware Clarify the extent to which open source is a form of commercial off-the-shelf software (COTS) Clarify how open source should be included in standard procurement processes Confirm when it is acceptable for an agency to contribute source code back to an open source project (and how to do it) Articulate possible advantages of deploying open source. Slated for release as early as November

21 Can open source Overcome its past?

22 Open Source Software Documentation Proprietary Software Documentation Implementation Integration Procurement channels Certifications Financing Support Maintenance Updates/Upgrades Warranties Indemnification Insurance Code Scanning

23 Open Source Software Documentation Implementation Integration Procurement channels Certifications Financing Support Maintenance Updates/Upgrades Warranties Indemnification Insurance Code Scanning Proprietary Software Documentation Implementation Integration Procurement channels Certifications Financing Support Maintenance Updates/Upgrades Warranties Indemnification Insurance Code Scanning

24 Clarity and consistency in Licensing and legal issues

25 Increasingly, open source licensing is no more disorderly (or risky) than proprietary licensing

26 Open source software licensed software is Open source licenses make the software open source

27 Understand the similarities Understand the differences Understand why they matter

28 The agencies are of the opinion that the use of FOSS does not pose risks that are fundamentally different from the risks presented by proprietary or self-developed software. However, the acquisition and use of FOSS necessitates implementation of unique risk management practices.

29 What is Open Source Software? You should think of free as in free speech, not free as in free beer. Richard Stallman

31 What is Open Source Software? Open source licensing is not anti-copyright Open source licensing is dependent on copyright laws

32 What is Open Source Software? Open Source Evolved With Copyright Law Copyright law has evolved significantly over time Decrease in the barriers to obtain copyright Increase in the scope and duration of copyright Past Copyright Law Copyright Act of 1909 Copyright attached only after following requirements for: Notice Publication Failure to comply meant dedication to public domain 28 year term (with chance for 28 year renewal) Current Copyright Law Copyright Act of 1976 Copyright attaches when a work is fixed in a tangible medium of expression Full publication not required No chance of work falling into the public domain Life of the author plus 70 years (and counting)

33 What is Open Source Software? Open Source Relies on Copyright Law Open source software licensing has arisen (at least in part) as a response to this evolution Open source licensing relies on the ability of a copyright owner to choose how to enforce (or not enforce) their copyright Each open source license is intended to act as a set of permissions (and restrictions) granted by a copyright owner under their copyright Like any license (or contract), open source licenses have limits Unlike proprietary licenses, these limits generally allow for more open or free use of the software Each open source license implements the Open Source Definition (some more closely than others)

34 What is Open Source Software? The Open Source Definition The Open Source Definition (OSD) articulates the principles a license must meet to be open source Availability of source code Free redistribution Availability of derived works Integrity of the author s source code No discrimination against persons or groups No discrimination against fields of endeavor License must travel with software License not dependent on particular software distribution License does not restrict other software License technology neutral Used by the OSI to define licenses as open source OSI maintains a certification program to approve licenses as compliant with the OSD

35 What is Open Source Software? OSI-Approved Licenses Over 70 OSI-approved licenses Big names: GNU General Public License (GPL) GNU Lesser General Public License (LGPL) Other common OSS licenses: BSD, MIT, Apache, Eclipse, Mozilla, Common Public All implement the OSD, each with its own specific terms One definition, many different licenses Many other un-approved open source licenses exist Many are based in part on OSI-approved licenses Some even refer to themselves as open source But, no guarantee that they comply with the terms of the OSD

36 What is Open Source Software? Standard Definition Many Licenses Liberal Copyleft No Strings Strings Attached Traditional Copy left Additional Clauses BSD (current) MIT/X W3C BSD (original) Apache Software License Eclipse Public License Artistic GNU GPL GNU LGPL GNU GPL v3 Common Public License Mozilla Public License SISSL IBM Public License

37 What is Open Source Software? Open Source vs. Proprietary Open Source License flows with code Unilateral permission No negotiation No affirmative assent to terms Use Permissions Source and object code forms Copy, modify, and distribute May allow other end users to do the same Permissions do have boundaries Limited Licensor Obligations No warranties No updates/upgrades No support obligations No infringement indemnification Proprietary Arms-length agreement Meeting of the minds Often negotiated Affirmative assent (sign, click, etc.) Use Restrictions Object code only Limited copying and use No reverse engineering No distribution Robust Licensor Obligations Warranties Updates/upgrades Support and maintenance Infringement indemnification

38 Open Source Software is Protected by patent laws

39 Patent Infringement Patent Aggression

40 Patent Aggression The Firestar Case v. Firestar sued Red Hat on June 28, 2006 Eastern District of Texas Firestar Software, Inc v. Red Hat, Inc et al (Case No.: 2:06cv258) Alleged that the JBoss Hibernate 3.0 technology infringed U.S. Patent No. 6,101,502 directed to a method of interfacing an object oriented software application with a relational database. Patent was later assigned to patent holding company DataTern (and its parent company Amphion Innovations) First patent infringement suit targeting an open source project Settlement reached before much activity took place

41 Patent Aggression The Firestar Settlement Settlement terms are now public: Very broad: All software licensed under the Red Hat brand (whether developed by Red Hat or third parties) Derivative works of Red Hat branded products and combinations of software including Red Hat branded products Upstream developers as well as predecessor products of Red Hat branded products Distributors, customers, and everyone All patents owned by DataTern and Amphion Model for open source patent infringement settlements?

42 Patent Aggression Other Activity Still Ongoing v. IP Innovation, LLC et al v. Red Hat Inc. et al (Case No.: 2:2007cv00447) Both plaintiffs are subsidiaries of Acacia Research Suits filed on October 12, 2007 in the Eastern District of Texas Directed against the desktop and server versions of the Linux operating system distributed by Red Hat and Novell Based on U.S. patent No. 5,072,412 for a User Interface with Multiple Workspaces for Sharing Display System Objects issued on Dec. 10, 1991 (also named two other similar patents). Patents originally owned by Xerox PARC, now assigned to Acacia First patent infringement suits directly targeting Linux

43 Patent Aggression Patents Are Nothing New to Open Source 2004 study by Open Source Risk Management revealed at least 283 patents implicated by Linux At least 27 of those patents held by Microsoft

44 Patent Aggression Patents Are Nothing New to Open Source Microsoft claims that Linux and other major OSS projects infringe 235 individual Microsoft patents Claims that Linux alone infringes 42 Microsoft patents To date, Microsoft has refused to identify any of the patents

45 Open source software licenses are enforceable

46 Jacobsen v. Katzer

47 License Enforceability Enforceable as Copyright Licenses Decision is broadly worded Applies to other open source licenses (GPL, LGPL, etc.) Relevant to non-open source licenses as well Ringing endorsement of open source licenses in general Open source license violations trigger claims for Breach of license Copyright infringement Copyright infringement opens the door to additional remedies Injunctive relief Statutory damages Attorney s fees

48 License Enforceability Open source software licenses are being enforced

49 License Enforceability BUSYBOX

50 License Enforceability

51 License Enforcement The Busy Box Lawsuits Very straightforward failures to comply with the GPL BusyBox was included in firmware of a device BusyBox has or has not been modified Device (and firmware) distributed without the BusyBox source code or a written offer to receive source code (as required by GPL Section 2) Appear to involve a relatively innocent violations of the GPL Claim copyright infringement Seek relief in the form of Unspecified damages Litigation costs Injunction against further use of the BusyBox software Trend toward settlement Common settlement terms Will this become the model for GPL lawsuits?

52 License Enforcement The Busy Box Lawsuits Suits targeted very big, very small, and a growing number of middle-market technology companies Most all appeared to be (relatively) innocent offenders Often distributing third party products/firmware BUSYBOX

53 License Enforcement The Busy Box Lawsuits Suits targeted very big, very small, and a growing number of middle-market technology companies Most all appeared to be innocent offenders Often distributing third party products/firmware Only Verizon seems to have received an indemnification from its supplier Results are reflected in the terms of settlement Actiontec (not Verizon) assumed the obligations imposed by the settlement Others remained responsible for their own defense and settlement

54 License Enforcement The Busy Box Lawsuits Suits targeted very big, very small, and a growing number of middle-market technology companies Most all appeared to be innocent offenders Often distributing third party products/firmware Only Verizon seems to have received an indemnification from its supplier Disputes preceded by (at least some) contact with the defendants Initially by third parties Follow-up by SFLC Meaningful attempts to negotiate? Rapid movement to lawsuits (sometimes very rapid) None of the defendants have chosen to (materially) challenge the allegations (yet)

55 License Enforcement The Busy Box Lawsuits Do not overlook third party inquiries Help desks inquiries Increased premium on preemptive action Diligence of software (and hardware) products Do your products use BusyBox (or another would-be plaintiff s software)? Are you in compliance with the GPL (or applicable open source licenses)? Agreements with software providers Compliance with applicable laws Indemnification provisions Compliance policies and procedures

56 License Enforcement New trend? Evolution? Nothing new?

57 License Enforcement Private Enforcement Actions > 100 actions

58 License Enforcement Non-US Enforcement Actions

59 Cause for Concern? Compliance

60 Compliance Compliance Is Often Not A Priority Source: Infoworld & OpenLogic Survey

61 Compliance Understand your use of open source Make each use of open source a knowing and compliant use

62 Compliance Best Practices Define objectives for compliance Build an open source risk profile Understand tolerance for open source risk Evaluate existing (and ongoing) use of open source Inventory (package, version, license and origin) Nature of usage/distribution Modifications Develop and implement an open source policy Based on your objectives Establish rules regarding open source usage and participation Field a compliance team Educate developers (help not hinder) Iterate (and reiterate) Utilize available tools and resources

63 Compliance With proper compliance open source licensing need not be any more risky than proprietary software licensing

64 Thank You.

65 Compliance Best Practices Your risk depends on your use of open source

66 Compliance Best Practices Compliance requires understanding your use of open source

67 Compliance Best Practices Understand your use of open source Understand the risk caused by your use of open source

68 Compliance Best Practices Set clear objectives Define compliance

69 Compliance Best Practices Understand the Compliance Process Deployment Information Collection Analysis Compliance Recognition Implementation Increasing recognition of the need for compliance License analysis is also increasingly more manageable Beware of the practical bottlenecks Information collection Compliance implementation

70 Compliance Best Practices Open Source Audits Understand and evaluate the scope and nature of your open source use Start with the open source software Understand the license Evaluate the use case and how it may change over time But, remember Audits are not the perfect solution Resource intensive Time consuming Questionable accuracy Provide only a snapshot Avoid management through audit Use as part of an overall ongoing compliance program

71 Compliance Best Practices Open Source Policy Develop an open source policy Start simple, at a higher level Cover objectives and strategy Add procedures and controls as your use and experience grows Conform to other corporate policies and corporate culture Emphasis on consistency Document the policy Circulate and centralize

72 Compliance Best Practices Cross-disciplinary Compliance Interdependent, not subservient Emphasis on collaboration and communication Services Sales and Marketing IT Legal and Procurement Management Development HR

73 Compliance Best Practices Compliance Requires Communication Cultivate an internal open source community to provide feedback Allow procedures and controls to evolve over time Deployment Revision and Update Implementation Feedback

74 Compliance Best Practices Educate Essential but often overlooked Raise awareness and build common understanding Promote overall OSS objectives and strategies Formal and informal methods Include all stakeholders Develop a culture of compliance

75 Compliance Manage and Update Your use of OSS will not be static Neither is the OSS community Procedures and controls should not be static Periodic reviews and updates Maintain consistent approach

76 Compliance Best Practices Utilize Available Tools Infrastructure and support is now often similar to that found in the proprietary software world Communication Intranets E-rooms Legal License analysis Indemnification Insurance Managerial Training Consulting Education Technical Platforms for implementation and management Automated source code reviews Operational Support Maintenance Code updates

77 Compliance Best Practices Key Recommendations Remember, compliance takes time Field a cross-disciplinary team Define objectives and strategy Develop a policy to fit the objectives Clearly document procedures and controls Keep it simple (and consistent) Operate in real-time (avoid reliance on audits) Review and evolve the program over time

78 "We have a lot of examples of restrictions in end user licenses that turn out to prevent the DOD from doing things [it] wanted to do. We find that problematic. Daniel Risacher Office of Secretary of Defense