{"id":369,"date":"2016-02-15T12:00:47","date_gmt":"2016-02-15T18:00:47","guid":{"rendered":"http:\/\/ericlambert.net\/blog\/?p=369"},"modified":"2016-02-15T12:00:47","modified_gmt":"2016-02-15T18:00:47","slug":"the-rewards-and-risks-of-open-source-software","status":"publish","type":"post","link":"https:\/\/ericlambert.net\/blog\/2016\/02\/15\/the-rewards-and-risks-of-open-source-software\/","title":{"rendered":"The Rewards and Risks of Open-Source Software"},"content":{"rendered":"<p>Open-source software (or \u201cOSS\u201d) is <strong>computer software distributed under a license whose source code is available for modification or enhancement by anyone<\/strong>.\u00a0 This is different than free (or public domain) software, which is not distributed under a license.\u00a0 Free and open-source software are alternatives to \u201cclosed source,\u201d or proprietary, software.<\/p>\n<p>Companies use OSS for a variety of reasons.\u00a0 In some cases, it\u2019s <u>used as part of a project deliverable<\/u>, such as a DLL or a JavaScript library. In others, it\u2019s <u>used as a tool as part of the development process or production environment<\/u>, such as a compiler, development environment, web server software, database software, etc.<\/p>\n<p><strong><em>The Rewards of OSS.<\/em><\/strong>\u00a0 There are significant benefits to using open-source software in your business.\u00a0 Here are some of the most significant:<\/p>\n<ul>\n<li><strong>Enhanced Security. <\/strong>Anyone can modify and enhance OSS, resulting in a larger developer base than proprietary software. This means that security holes are often found more quickly, and patched more quickly, than proprietary software.<\/li>\n<li><strong>Lower Cost<\/strong>. There is no license fee for open-source software.\u00a0 (That does not mean it\u2019s totally free \u2013 OSS is subject to license requirements.)<\/li>\n<li><strong>Dev Cycle Streamlining.<\/strong> Using OSS in a project cuts down development time by allowing developers to avoid \u201creinventing the wheel\u201d on needed code if an OSS version of that code is available.<\/li>\n<li><strong>Perpetual Use<\/strong>. As long as you abide by the terms of the open-source software license, you can generally use it forever.\u00a0 There are no annual renewal fees or license renegotiations for mission-critical software.<\/li>\n<li><strong>Adaptability\/Customizability.<\/strong> Users of closed source software must find the software package that most closely aligns with the business\u2019 needs, and adapt to it.\u00a0 There\u2019s no need to settle with OSS \u2013 since it can be customized and adapted, you can start with the existing code and modify it to fit your company\u2019s exact needs.<\/li>\n<li><strong>Better Quality<\/strong>. Since there is a larger developer base, new and enhanced features and functionality are often rolled out, and usability bugs fixed, at a more rapid rate than in proprietary software.<\/li>\n<li><strong>Support Community.<\/strong> Many common closed source software packages require the purchase of a maintenance subscription along with a license.\u00a0 Well-used OSS has a robust developer community that can help with questions.There are also companies that have sprung up around common OSS packages to provide support solutions.<\/li>\n<\/ul>\n<p><strong><em>Know Your OSS Licenses.\u00a0 <\/em><\/strong>The author of software code owns the copyright to that code.\u00a0 If the author released software into the public domain, he\/she is waiving his\/her copyrights in that code, making it free for anyone to use.\u00a0 However, if someone creates a derivative work of public domain code, the new portions of code are protected by copyright, and are not in the public domain.\u00a0 In other words, by adding his\/her own modifications, someone can take public domain software and make it proprietary.<\/p>\n<p><u>That\u2019s the primary difference between free software and OSS<\/u>.\u00a0 In most cases, when an author makes his\/her software code open-source, that author is allowing use of his\/her copyrighted code under an open-source software license, but is not relinquishing his\/her copyright.\u00a0 Under the OSS license, the author grants others a right to use the author\u2019s copyrighted code to modify, copy and redistribute it, but only if they follow the terms of the open-source software license.\u00a0 There are hundreds (or more) open-source licenses out there.\u00a0 However, there are relatively few that are considered generally accepted with a strong developer community.\u00a0 <a href=\"https:\/\/opensource.org\/licenses\" target=\"_blank\" rel=\"noopener\">The Open Source Foundation (OSF) categorizes the most common OSS licenses here<\/a>.\u00a0 The most common are the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), the \u201cNew\u201d BSD License, the \u201cSimplified\u201d BSD License, the MIT License, and the Apache License v2.\u00a0 However, not all OSS licenses are the same.\u00a0 There are many websites that can help you analyze the differences between OSS licenses, including <a href=\"http:\/\/www.tldrlegal.com\" target=\"_blank\" rel=\"noopener\">tl;dr Legal<\/a> and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Comparison_of_free_and_open-source_software_licenses\" target=\"_blank\" rel=\"noopener\">Wikipedia\u2019s Comparison of Open-Source Software Licenses<\/a>.<\/p>\n<p>Many OSS licenses are <strong>\u201cpermissive\u201d licenses<\/strong>, meaning that a work governed by that license (e.g., a BSD License) may be modified and redistributed under a different\u00a0license as long as you comply with the requirements of the permissive\u00a0license (e.g., attribution). Other OSS licenses are <strong>\u201ccopyleft\u201d licenses<\/strong>.\u00a0 A copyleft license is one under which a work may only be used, modified or distributed if the same license rights apply to anything derived from it.\u00a0 The copyleft license will \u201cinfect\u201d modifications and derivations of the source (some think of it as a \u201cviral\u201d license).\u00a0 It\u2019s a play on words as\u00a0copyright and copyleft are converse terms: <u>copyright<\/u> gives exclusive rights to a work to one person, and <u>copyleft<\/u> gives non-exclusive rights to a work to everyone.\u00a0 There are two types of copyleft licenses:<\/p>\n<ul>\n<li><strong>\u201cStrong\u201d copyleft<\/strong> <strong>licenses<\/strong> (e.g., the GNU GPL) state that if you modify code governed by a copyleft license, you must distribute the software as a whole under that copyleft license, or not distribute it at all.<\/li>\n<li><strong>\u201cWeak\u201d copyleft licenses<\/strong> (e.g., the GNU Lesser GPL) state that if you modify code governed by a copyleft license, portions of the software containing modifications (e.g., a software module or library) must be distributed under that copyleft license, but other portions may be distributed under a different license type.<\/li>\n<\/ul>\n<p><strong><em>The Risks of OSS.<\/em><\/strong>\u00a0 Due to its benefits and rewards, most companies use open-source software, whether the management and Legal teams know it or not. Quite often, developers rely on OSS to deliver software development projects on time and within budget. The bigger question is whether developers are using OSS in a way that exposes the company to risk. \u00a0Unless your company has a well-defined OSS policy that has been well-communicated to the developers at your company, you\u2019re \u201cflying blind\u201d when it comes to OSS usage. Here are some of the risks and considerations for companies using OSS:<\/p>\n<ol>\n<li><strong> OSS makes more sense for \u201cutility layer\u201d software needs than for \u201ccompetitive\/proprietary layer\u201d software needs. <\/strong>Think of the software used in business as two layers. The first is <u>software at the \u201cutility layer\u201d<\/u> \u2013 software packages that go to the general operation of the business and its IT infrastructure, and do not give the business a competitive advantage based on the code itself. Examples are web server software, database software, and standard APIs.\u00a0 Above that is the <u>software at the \u201ccompetitive\/proprietary layer\u201d<\/u> \u2013 software that gives your company a competitive advantage you\u2019re your competition, or provides significant offensive or defensive IP protection. Examples are custom functionality on your website and specialized software applications. OSS makes a lot of sense at the utility layer \u2013 you don\u2019t need something better than everyone else, just something that works and works well. Introducing OSS at the competitive\/proprietary layer can be problematic as you may want to ensure the entire solution is proprietary.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><strong> You can\u2019t get IP warranties or indemnification for OSS. <\/strong>When you negotiate a software license agreement for proprietary closed source proprietary code, in most cases the software licensor will provide warranties and\/or indemnification against claims of IP infringement. With OSS, there is no IP warranty or indemnity. If someone introduced proprietary code into the OSS earlier in its life, you bear the risk of infringement if you use it.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><strong> Some OSS license types can snuff out IP rights to your own developed code (and even expose it).<\/strong> The type of OSS license governing OSS used in your business, and how you use OSS software, can directly affect your IP rights to your own developed code. If you use OSS governed by a strong copyleft license to enhance your own codebase, your entire codebase could potentially become governed by a copyleft license.\u00a0 This means that a savvy competitor or customer that suspected or learned of OSS in your code could send you a letter demanding a copy of your source code under the copyleft license, or just decompile it and modify it, putting you on the defensive as to why your software license should override the copyleft open source license.<\/li>\n<\/ol>\n<ol start=\"4\">\n<li><strong> If you don\u2019t follow the license terms, you can be sued. <\/strong>Open source software is licensed. That means there are license terms you must follow.\u00a0 If you don\u2019t, you may face litigation from competitors or others.\u00a0 There has been a recent upswing in litigation for breach of the terms of open source licenses, and that trend is expected to continue.\u00a0 For example, VMware was sued in March 2015 alleging that it violated the GNU GPL v2 license by not releasing the source code for VMware software that used OSS subject to the copyleft license.<\/li>\n<\/ol>\n<p><strong><em>Implement a Company-Appropriate OSS Policy.<\/em><\/strong>\u00a0 To mitigate the risks associated with OSS, <em>all companies should implement an open-source software policy governing the when, why and how of using open-source software in the company\u2019s codebase<\/em>.\u00a0 Here are some important considerations:<\/p>\n<ul>\n<li><strong>Ensure there is alignment on the goal of the OSS policy at the outset. <\/strong>Different stakeholders may have different views on the goal of an OSS policy.\u00a0 To Legal, it make be to protect the company\u2019s intellectual property; to IT, it may be to leverage OSS to reduce costs; to developers, it could be to ensure they are free to keep using the OSS they need to meet goals and deadlines.\u00a0 One thing stakeholders cannot do is go in with the mindset that OSS is bad for business or that they can keep it out of their code.\u00a0 <u>OSS in business is a reality that can either be ignored or accepted<\/u>.\u00a0 The policy\u2019s goal should be to ensure OSS is being used effectively to advance the company\u2019s business objectives while protecting its IP and living within its risk profile.<\/li>\n<li><strong>An OSS policy must balance the practical needs of developers with risk management. <\/strong>OSS is the domain of the developer, not the Legal department.\u00a0 While the risks are something lawyers consider, a policy written and imposed by non-developers on your developer corps will likely face an uphill battle, or worse, be viewed as \u201cout of sync with the goals of the business\u201d and just ignored.\u00a0 The attorneys\u2019 role in creating an OSS policy is to provide guidance on the risks of OSS to the company as a whole, provide \u201cbest practices\u201d guidance in OSS policies, and to draft the actual policy from the outline in plain English (remember, <u>developers<\/u>, not other attorneys, are the audience).\u00a0 IT management\u2019s role is to provide guidance on the outside contours of the policy.\u00a0 Developers need to be directly involved in developing the policy itself as they are the ones using OSS in their daily work.\u00a0 Developers, Legal and IT should develop the company\u2019s OSS strategy, and its OSS policy, as <u>equal stakeholders<\/u>.\n<ul>\n<li>Ensure senior management buys into the policy before it is finalized; it\u2019s important that management understand how OSS is used in the business.<\/li>\n<li>Ensure the policy covers key topics, e.g., sourcing OSS; selecting OSS code for use at the utility layer and the competitive\/proprietary layer; the OSS approval process; support and maintenance requirements; redistribution; tracking OSS usage; and audits\/training.<\/li>\n<li>Ensure the policy covers\u00a0independent contractor\u00a0developers as well as employees.<\/li>\n<\/ul>\n<\/li>\n<li><strong>OSS code review and approval must be a streamlined process. <\/strong>If the review and approval process is complicated, developers will be more likely to just skip it.\u00a0 Make approval easy.\u00a0 Provide a \u201cpre-approved list\u201d of OSS \u2013 certain combinations of license types, utility level software categories, and\/or specific code packages that only need notification of usage for tracking purposes.\n<ul>\n<li>Have a simple process for vetting other usage requests, asking the critical questions (e.g., What is the name and version number of the software package for which use is requested? What license type applies? Where was the code sourced from? Will the code be modified? What is the support plan?\u00a0 Will the code be distributed or used internally?\u00a0 What is the expected usage lifetime of the code? Are there closed source alternatives? Etc.) so that the legal and business risks can be measured and balanced against the benefits of usage.<\/li>\n<li>Determine who will do the first review and escalated review (IT, Legal).<\/li>\n<li>Turn requests quickly as delays can impact development timeframes.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Keep a database of all used OSS, including where is it used and what license type applies. <\/strong>Knowing what OSS you\u2019re using is critical to avoid introducing code that has a bad reputation or is governed by an OSS license your company is not comfortable with (e.g., a strong copyleft license). IT should maintain a database of OSS used by the company, including the license type for each OSS.\u00a0 This database is also helpful when responding to security questionnaires and is often needed in M&amp;A due diligence.<\/li>\n<li><strong>Other Considerations. <\/strong>Consider conducting quarterly or semi-annual reviews of OSS usage, e.g., questionnaires to developers.\u00a0 Consider having developers acknowledge the OSS policy at hire, and on an annual basis.\u00a0 Consider conducting OSS training if your company\u2019s learning management system (LMS) has an available course module on OSS.\u00a0 And most importantly, review the OSS policy no less than once a year with all stakeholders to ensure it is evolves as the world of OSS, and the company\u2019s own needs, change over time.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Open-source software (or \u201cOSS\u201d) is computer software distributed under a license whose source code is available for modification or enhancement by anyone.\u00a0 This is different than free (or public domain) software, which is not distributed under a license.\u00a0 Free and &hellip; <a href=\"https:\/\/ericlambert.net\/blog\/2016\/02\/15\/the-rewards-and-risks-of-open-source-software\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,8,9,12,1],"tags":[132,133,134],"class_list":["post-369","post","type-post","status-publish","format-standard","hentry","category-legal","category-nonlegal","category-otherlegal","category-technology","category-uncategorized","tag-open-source","tag-open-source-licenses","tag-open-source-software"],"_links":{"self":[{"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/posts\/369","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/comments?post=369"}],"version-history":[{"count":0,"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/posts\/369\/revisions"}],"wp:attachment":[{"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/media?parent=369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/categories?post=369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ericlambert.net\/blog\/wp-json\/wp\/v2\/tags?post=369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}