DOCSLIB.ORG

Article Title

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Article Title International In-house Counsel Journal Vol. 5, No. 20, Summer 2012, 1 Corporate Use of Open Source Software: Dispelling the Myths with a Policy HEATHER E. MCNAY Senior Intellectual Property Counsel, Landis+Gyr, USA Abstract Many companies do not understand open source software and choose to avoid it completely instead of creating an informed policy. Avoiding the issue can lead to developers using open source software incorrectly and potentially exposing proprietary company intellectual property through mandated public disclosure. The legal department for every technology company needs to work with the software development group to create a comprehensive Open Source Policy. The policy should ensure that every piece of open source code that is used by the company is reviewed pursuant to a prescribed process. A good policy will require that the requesting developer list the planned use of the open source code and provide the name of the license covering the code, if known. The proposed use of the code is important because stand-alone, or separably compilable, applications will not trigger certain license’s obligations, such as the publication of source code. There are many distinct open source licenses being used today, each with very different terms. With knowledge of the use and the license, the legal department can investigate the license and make a recommendation based on whether it is a ‘viral license’ (requiring publication) or not. Then, together with the technical point of contact, an informed decision can be made about all source code used by the company. Organisations will discover that using open source software in controlled manner can provide actual cost savings without exposing the company to any risk. Keywords: Open Source General Public License GPL Corporate Policy Software License International In-house Counsel Journal ISSN 1754-0607 print/ISSN 1754-0607 online 2 Heather E. McNay 1.0 Introduction The prevalent myths about open source code diminish the common sense and legal education on the topic. Misunderstandings can prevent developers from using a useful, cost-saving tool. Worse still, misunderstandings can put a company at risk if open source code is used improperly. If your company develops or uses any software, it is likely that portions of that software are ‘open source’ code. Open source code is software that is free to use, and readily available on the Internet, but can be governed by very strict licensing terms. Understanding open source code and the accompanying licenses can be intimidating. There are still many companies around the world that do not fully understand open source and choose to avoid it completely. Unfortunately, having a policy prohibiting all open source code or having no policy at all can lead to software developers using open source software incorrectly and can even lead to charges of copyright infringement or to the losing of company intellectual property rights if release and publication of company source code is mandated. On the other extreme, there are companies that allow unmonitored use of open source software. Despite the myths about open source code, the truth is that many developers use it. Software developers are usually working on very tight schedules and know that widely used open source code is stable and well tested. However, the developers may not realize that such use can expose the company to risks. Therefore, each corporation must monitor the use, make educated decisions about the use and educate their employees on open source code and the various licenses. While open source code, being free, can reduce the costs of development and can provide stable, tested applications, the risks must be explored and weighed. Open source code does not come with warranties or indemnities, and can carry far-reaching license obligations. The solution is for every organization to have a concise Open Source Software Policy that sets forth a clear review process. Each potential use of open source software must be reviewed by a designated employee from the development or engineering department while an attorney identifies and evaluates the open source license governing the desired code. In addition, there must be an education initiative to teach the company’s employees about the policy, its processes and the basics of open source software licenses. 2.0 Open source code and licenses 2.1 Open source basics Open source software began as a movement to encourage the sharing of knowledge. In the U.S., the idea goes back to the creation of the Free Software Foundation, in 1985.1 This non-profit corporation was founded with noble goals; the basis being that use of the software code, regardless of copyright or patent coverage, must remain free for all to use. This movement is also sometimes called ‘copyleft’, as opposed to copyright, to designate freedom to copy. The Free Software Foundation established the most widely know open source license, General Public License (GPL) 2.0 (also known as the GNU™ License).2 The Free Software Foundation also had the goal to collect enough free software so that no one would ever have to use software that was not free.3 1 Free Software Foundation; www.fsf.org. 2 GNE General Public License V2.0; www.gnu.org/licenses/gpl-2.0.html. 3 Free Software Foundation. Open Source Software 3 The original label for the code governed by these licenses was ‘free software’. The term ‘open source software’ was coined in 1998 by the Open Source Initiative (OSI), another U.S. non-profit organisation.4 OSI chose the label ‘open source’ because they believed ‘free software’, being not necessarily ‘at no cost’, was confusing and discouraging business adoption.5 For example, the GPL 2.0 specifies that while the code is free, “you may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee”.6 There are many myths about why not to use open source code, including: one cannot use open source software in a proprietary environment; all open source licenses require the release of all source code; and it is easiest to just reject all open source software. Myths on the other side include: open source licenses are not enforceable; no one will ever find out if you use open source software; and you are protected if your corporate policy says that you do not use open source software.7 However, as this paper will set forth, all of these are truly myths. The truth is somewhere in the middle. With proper analysis, a stable policy and education, any company can benefit from open source code and avoid the pitfalls. 2.2 Open source licenses Both commercially sold code and open source software are governed by the same types of laws in every country, contract law and intellectual property law. The myth that open source licenses are not enforceable is completely untrue. The user is bound by whatever license terms agreed to by the user, whether by written contract, ‘click- wrap’ or simply by use of the code. U.S. courts have consistently upheld open source licenses. For example, in the U.S. Federal Court of the Northern District of California, the Court held in Jacobson v. Katzer that open source licenses are enforceable under U.S. copyright laws.8 There are many different licenses governing open source code. The Open Source Initiative reviews open source licenses and lists approved licenses on their site.9 The most common open source licenses are: GNU General Public License (GPL) 2.010, GNU Lesser GPL (LGPL) 2.0/3.011, Mozilla™ Foundation License12, Common Public License (published by IBM™)13, Apache License (Apache Software Foundation)14 and BSD (Berkeley Software Distribution) License15 4 www.opensource.org. 5 www.fsf.org/licensing/essays/free-software-for-freedom.html. 6 GNU General Public License V2.0. 7 Copenhaver, Radcliffe, Vescuso; Introduction to Open Source Licenses; Black Duck Legal Webinar Series Presentation Materials/ http://www.blackducksoftware.com/media/_slides/LWS-Intro-Open-Source- Licensing.pdf ; June 2010. 8 Jacobsen v. Katzer, No. C 06-01905 (N.D. Cal. Dec. 10, 2009). 9 Open Source Initiative; www.opensource.org. 10 General Public License V2.0. 11 GNU Lesser General Public License; http://www.gnu.org/copyleft/lesser.html. 12 Mozilla License; www.mozilla.org/MPL. 13 Common Public License; www.opensource.org/licenses/cpl1.0. 14 Apache License; www.apache.org/licenses. 4 Heather E. McNay Each open source license has slightly different terms, and some licenses are considered more onerous than others. One particularly invasive attribute is when the license is ‘viral’. The GPL is considered ‘viral’ because the license provisions travel with the code and apply to any and all modifications of the code and can even apply to neighbouring code dynamically linked or integrated to the modification. If a company uses an open source application covered by the GPL and then creates a modification of the code that is incorporated into the company’s proprietary software product, the GPL license states that the obligations under the GPL license apply to the modification. Then, having the modification incorporated into the entire project, the GPL terms will apply to the entire software product. The resulting obligation is that the modification, and all related code, must be made public in the same manner as the original open source code.16 This could cause a company to lose a competitive advantage if all competitors had access to the source code previously held as a trade secret. There are limits to the viral aspects of the GPL if the open source code is kept separate and not integrated into proprietary code. For example Linux™17 is generally covered by GPL but applications running on Linux are not necessarily governed by the GPL unless they directly interact with GPL modules.
Load more

Recommended publications
  • An Introduction to Software Licensing
    An Introduction to Software Licensing James Willenbring Software Engineering and Research Department Center for Computing Research Sandia National Laboratories David Bernholdt Oak Ridge National Laboratory Please open the Q&A Google Doc so that I can ask you Michael Heroux some questions! Sandia National Laboratories http://bit.ly/IDEAS-licensing ATPESC 2019 Q Center, St. Charles, IL (USA) (And you’re welcome to ask See slide 2 for 8 August 2019 license details me questions too) exascaleproject.org Disclaimers, license, citation, and acknowledgements Disclaimers • This is not legal advice (TINLA). Consult with true experts before making any consequential decisions • Copyright laws differ by country. Some info may be US-centric License and Citation • This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). • Requested citation: James Willenbring, David Bernholdt and Michael Heroux, An Introduction to Software Licensing, tutorial, in Argonne Training Program on Extreme-Scale Computing (ATPESC) 2019. • An earlier presentation is archived at https://ideas-productivity.org/events/hpc-best-practices-webinars/#webinar024 Acknowledgements • This work was supported by the U.S. Department of Energy Office of Science, Office of Advanced Scientific Computing Research (ASCR), and by the Exascale Computing Project (17-SC-20-SC), a collaborative effort of the U.S. Department of Energy Office of Science and the National Nuclear Security Administration. • This work was performed in part at the Oak Ridge National Laboratory, which is managed by UT-Battelle, LLC for the U.S. Department of Energy under Contract No. DE-AC05-00OR22725. • This work was performed in part at Sandia National Laboratories.
    [Show full text]
  • Creator's Guide to Commercializing Copyrighted Work
    STANFORD UNIVERSITY OFFICE OF Creator’s Guide to TECHNOLOGY Commercializing LICENSING Copyrighted Work OURSES WEB C PHY BOOKS S SI E GRA OFT TE D TO WA S O HO R C P E V M S U ID Y M S H E I E O C O P P C A S H F R G O N R I I C G E D O T O R G I O E R O C A R E N P R H O Y S M H P C C P O O A D B E E C L I I I C L B S O E O U U R M A S M N E P O S I T W P E C I E F B S R S O I T E A E D I S V B W O T O F K O S S he Stanford University Office of Technology Licensing (OTL) promotes the transfer of Stanford technology for Tsociety’s use and benefit. This technology grows out of the CONTENTS boundless creativity found in the faculty, staff, and students at the University. When that creative expression is protected by copyright, OTL and our Stanford creators face a distinct set THE BASICS .......................................................................................2 of commercialization and distribution issues that they do not STanford’s copyrighT POLICY .......................................................5 encounter for other forms of intellectual property. SOFTWARE .........................................................................................8 OTL created this booklet to help Stanford creators successfully identify and CONTENT AND COURSES..................................................................15 navigate those issues. The booklet is focused on out-licensing or distributing OPEN SOURCE SOFTWARE LICENSING ..............................................18 creative works owned by Stanford.
    [Show full text]
  • Open Source Software: Avoiding the Pitfalls; Reaping the Rewards
    McCarthy Tétrault LLP Open Source Software: Avoiding the Pitfalls; Reaping the Rewards Charles Morgan Presentation to the ALAI Auberge Le Saint-Gabriel September 24, 2003 McCarthy Tétrault Open Source »What is Open Source? »Brief History of Open Source »OSI Open Source Definition »Open Source Licenses »Open Source Business Models »Rewards & Pitfalls »Open Source Tips McCarthy Tétrault LLP What is Open Source? » Open source software can generally be defined by four freedoms: • The freedom to use the program • The freedom to examine and change the source code • The freedom to distribute the program • The freedom to distribute any changes to the source code McCarthy Tétrault LLP What is Open Source? » Nine core principles: • Free Distribution – no restriction on distribution of the software as a component of an aggregate software distribution (including royalty or fee) • Source Code - the source code must be accessible • Derived Works - license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software • Integrity of the Author’s Source Code - the license may restrict source code from being distributed in modified form only if the license allows the distribution of ‘patch files’ with the source code McCarthy Tétrault LLP What is Open Source? • No Discrimination Against Persons or Groups - the license must not discriminate against any person or group of persons • No Discrimination Against Fields of Endeavor - the license must not restrict anyone from making
    [Show full text]
  • The Penguin and the Cartel: Rethinking Antitrust and Innovation Policy for the Age of Commercial Open Source
    The Penguin and the Cartel: Rethinking Antitrust and Innovation Policy for the Age of Commercial Open Source Stephen M. Maurer1 Abstract: Modern open source (“OS”) software projects are increasingly funded by commercial firms that expect to earn a profit from their investment. This is usually done by bundling OS software with proprietary goods like cell phones or services like tech support. This article asks how judges and policymakers should manage this emerging business phenomenon. It begins by examining how private companies have adapted traditional OS institutions in a commercial setting. It then analyzes how OS methods change companies’ willingness to invest in software. On the one hand, OS cost-sharing often leads to increased output and benefits to consumers. On the other, these benefits tend to be limited. This is because sharing guarantees that no OS company can offer consumers better software than any other OS company. This suppresses incentives to invest much as a formal cartel would. In theory, vigorous competition from non-OS companies can mitigate this effect and dramatically increase OS output. In practice, however, de facto cartelization usually makes the OS sector so profitable that relatively few proprietary companies compete. This poses a central challenge to judges and policymakers. Antitrust law has long recognized that the benefits of R&D sharing frequently justify the accompanying cartel effect. This article argues that most commercial OS collaborations can similarly be organized in ways that satisfy the Rule of Reason. It also identifies two safe harbors where unavoidable cartel effects should normally be tolerated. That said, many OS licenses contain so-called “viral” clauses that require users who would prefer to develop proprietary products to join OS collaborations instead.
    [Show full text]
  • Using Open Source Software in Business
    Using Open Source Software in Business November 26, 2018 This post was first published on February 19, 2010. Open Source Software (OSS) has certain advantages when compared to proprietary software. It comes with the following benefits: a. The software may be downloaded for free; b. Source code of the software is available, which enables improvement and customization; c. The software generally has a community and the development is faster; d. Support and implementation services are available from multiple sources; and so on. As OSS always comes with a license, the rights and limitations with respect to the use of the software is defined by the kind of license that governs the software. Based on the restrictions imposed, licenses may be classified into viral, restrictive and flexible. A viral license is one that spreads to every software it comes in contact. In other words, if any software is combined with OSS that is governed by a viral license, such software will also be governed by the license. GNU General Public License (GPL) and Affero General Public License (AGPL) are popular examples of viral licenses. If OSS governed by any such license is distributed along with a proprietary software, more often than not the source code of the proprietary software also must be made available and the proprietary software will also become open source. Restrictive licenses generally have all provisions of a viral license but do not spread to every software combined with OSS. These licenses generally provide flexibility with respect to distributing OSS combined with a proprietary software. In such a case, the source code of the proprietary software need not be made available and it may be distributed under a license of choice.
    [Show full text]
  • A Practical Guide to Open Source Software1 Michael Pavento
    1 A Practical Guide to Open Source Software Michael Pavento I. Introduction Open source software (“OSS”) is software that is freely available in source-code form for anyone to use, copy, modify and distribute. Generally speaking, however, OSS is not “public domain” software. Like any other software, OSS is copyrighted intellectual property. Authors have the right to control or condition the use of their original OSS code and typically do so through license agreements. Unlike traditional software licenses that seek to limit or prohibit further dissemination of the licensed software and certainly the underlying source code, OSS license agreements generally seek to encourage dissemination and to ensure that the source code remains open and accessible to all. Like any other software acquired from an outside source, the applicable license agreement is the starting point for understanding and managing the obligations imposed upon and the risks undertaken by an organization with respect to OSS. A careful review of some of the more common license agreements, for example the GNU General Public Licenses, the Apache License, the Common Development and Distribution License and the Berkley Software Development License,2 will dispel some of the common misperceptions regarding OSS. For example, it is sometimes said that OSS cannot be used with proprietary software. To the contrary, OSS licenses do not limit the manner in which the licensed OSS may be used; they typically permit all uses, but impose reciprocal obligations that are triggered when the licensee distributes the licensed OSS or modifications of it. It is also often said that all OSS licenses require the release of source code for any proprietary software used in conjunction with the OSS.
    [Show full text]
  • “Infectious” Open Source Software: Spreading Incentives Or Promoting Resistance?
    “INFECTIOUS” OPEN SOURCE SOFTWARE: SPREADING INCENTIVES OR PROMOTING RESISTANCE? Greg R. Vetter* ABSTRACT Some free or open source software infects other software with its licensing terms. Popularly, this is called a viral license, but the software is not a computer virus. Free or open source software is a copyright-based licensing system. It typically allows modification and distribution on conditions such as source code availability, royalty free use and other requirements. Some licenses require distribution of modifications under the same terms. A license is infectious when it has a strong scope for the modifications provision. The scope arises from a broad conception of software derivative works. A strong infectious ambit would apply itself to modified software, and to software intermixed or coupled with non-open-source software. Popular open source software, including the * Assistant Professor of Law, University of Houston Law Center (UHLC); Co-Director, Institute for Intellectual Property and Information Law (IPIL) at UHLC; biography and additional background available at: www.law.uh.edu/faculty/gvetter. Relevant to this Article is that my background includes a Master’s degree in Computer Science and full-time work experience in the business-to-business software industry from 1987 to 1996. Research for this Article was supported by summer research grants from the University of Houston Law Foundation and a grant from the University of Houston’s New Faculty Research Program. I also thank UHLC’s IPIL Institute and its sponsors for support of my endeavors at UHLC. My thanks to UHLC students Jason Williams, Cuong Lam Nguyen, Stacey R. Vause and Nivine Zakhari for research assistance.
    [Show full text]
  • Open Source Licenses in Scientific Research Andres Guadamuz Gonzalez
    NORTH CAROLINA JOURNAL OF LAW & TECHNOLOGY Volume 7 Article 2 Issue 2 Spring 2006 3-1-2006 Open Science: Open Source Licenses in Scientific Research Andres Guadamuz Gonzalez Follow this and additional works at: http://scholarship.law.unc.edu/ncjolt Part of the Law Commons Recommended Citation Andres G. Gonzalez, Open Science: Open Source Licenses in Scientific Research, 7 N.C. J.L. & Tech. 321 (2006). Available at: http://scholarship.law.unc.edu/ncjolt/vol7/iss2/2 This Article is brought to you for free and open access by Carolina Law Scholarship Repository. It has been accepted for inclusion in North Carolina Journal of Law & Technology by an authorized administrator of Carolina Law Scholarship Repository. For more information, please contact [email protected]. NORTH CAROLINAJOURNAL OF LAW & TECHNOLOGY VOLUME 7, ISSUE 2: SPRING 2006 OPEN SCIENCE: OPEN SOURCE LICENSES IN SCIENTIFIC RESEARCH Andris Guadamuz Gonzdlez' In recent years, there has been growing interest in the area of open source software ("OSS") as an alternative economic model. However, the success of the OSS mindshare and collaborative online experience has wider implications to many other fields of human endeavor than the mere licensing of computer programmes. There are a growing number of institutions interested in using OSS licensing schemes to distribute creative works and scientific research, and even to publish online journals through open access ("OA "')licenses. There appears to be growing concern in the scientific community about the trend to fence and protect scientific research through intellectualproperty, particularlyby the abuse of patent applications for biotechnology research. The OSS experience represents a successful model which demonstrates that IP licenses could eventually be used to protect against the misuse and misappropriationof basic scientific research.
    [Show full text]
  • A Ac3dec, 500 Accent, 424 Accounts, Root, 11 Ack (Snort Rule Option)
    28747 05 pp. 519-548 r1ah.ps 4/11/02 12:10 PM Page 519 2 3 INDEX 4 5 6 7 8 9 A remote monitoring, 185–92 sound effects and filtering, ac3dec, 500 coding, 186–89 377–80 Accent, 424 compiling, 189–91 system preparation for, 370 Accounts, root, 11 testing, 191–92 types of digital audio, 366–69 ack (Snort rule option), 257 Apex DVD player, 419–20 amplitude-based, 366–67 Actions, Snort, 252 API, Apache, 182–85 frequency-based, 367, 369, activate (Snort action), 252 apxs tool, 189 380–81 Active reconnaissance, 233 arch directory, 17 MP3 (MPEG Layer 3) add command (CVS), 123 Artistic License, 6 format, 368–69, 381 2 Aeromail, 158 aRts, 407 Ogg Vorbis format, 369, 2 installation of, 165 ASF files, 500, 501 381 2 using, 171–75 Aspect ratio, 446 RAW format, 368 2 agetty command, 81–82 Attachments, e-mail, 174 WAV format, 368 2 AIM (AOL Instant Messenger), Attacks on networks, 232–34 vinyl record transfer to CDs, 2 54 browser-based, 288 384–95 2 under wine, 339–40, 345 denial-of-service (DoS), 50, audio system and, 386–87 2 Albing, Greg, 477 232 CD creation, 393–94 2 alert (Snort action), 252 “Man in the Middle” (MITM), MP3 file creation, 394–95 2 AllowUsers (SSH server option), 269 preparation for, 385–86 277 profiles of, 260 recording, 387–89 3 Amplifier, audio, 386 scripted, 234 removing clicks, pops, and 3 Amplitude-based method for by sniffing, 217 hisses, 389–90 3 storing digital audio Audacity waveform editor, trimming cuts, 390–93 3 (PCM), 366–67 375–77, 380, 387, 413 writing audio to CDs, 3 Analog-to-digital (A-D) Audio CDs, burning, 363 382–84 3 conversion, 366 Audio processing, 365–97.
    [Show full text]
  • Creating a Viral Federal Privacy Standard A
    University of Miami Law School University of Miami School of Law Institutional Repository Articles Faculty and Deans 2007 Creating a Viral Federal Privacy Standard A. Michael Froomkin University of Miami School of Law, [email protected] Follow this and additional works at: https://repository.law.miami.edu/fac_articles Part of the Constitutional Law Commons, and the Privacy Law Commons Recommended Citation A. Michael Froomkin, Creating a Viral Federal Privacy Standard, 48 B.C. L. Rev. 55 (2007). This Article is brought to you for free and open access by the Faculty and Deans at University of Miami School of Law Institutional Repository. It has been accepted for inclusion in Articles by an authorized administrator of University of Miami School of Law Institutional Repository. For more information, please contact [email protected]. CREATING A VIRAL FEDERAL PRIVACY STANDARD A. MICHAEL FROOMKIN* Abstract: National identification ("ID") cards appear increasingly inevi- table. National ID cards have the potential to be repressive and privacy- destroying, but it is also possible to design a system that captures more benefits than costs. Because the United States currently lacks a single, re- liable credential, private businesses have trouble authenticating their cus- tomers and matching data among distributed databases. This Article ar- gues that the desire for reliable ID creates a window of opportunity for the federal government to strike a bargain: offer private businesses the use of a reliable credential in the form of a national ID card, on the con- dition that they abide by a privacy standard set and owned by the United States.
    [Show full text]
  • Free and Open Source Software in Argentina
    Free and open source software in Argentina PABLO WEGBRAIT1∗ SUMARIO: 1. lntroduction. 2. Free or open source? 3. Is access to sotfware a constitutional/hu- man rignt under Argentine law? 4. Legal regime. 5. Foss in the Argentine governmental sector. 6. Enforceability of foss viral licenses under Argentine law. 7. A buoyant third sector. Conclusions 1. INTRODUCTION As in other parts of the world, free and open source software (FOSS)2 has been gain- ing acceptance in Argentina over the past years. FOSS differs from proprietary software. A proprietary software company devotes substantial monetary and human resources to develop computer programs. The “core” of those programs is the source code, its “written” part, which may be read by the human user3. Under a proprietary scheme, rights to the source code -which are protected under trade secret statutes, and copyright laws and treaties-, may only be modified by the author or rightholder, or with their consent. The rationale behind this business model is that mon- etary gain results from selling the software because, if users had access to the source code (or if they could freely reproduce it), they would not buy it from the software developer, who would not recoup its investment. Under the proprietary scheme, the software user acquires a license to use the program for only one computer terminal (as a general rule), and must pay for additional licenses for further use of the software. Moreover, the user may not access the source code in order to study how it works and/or to detect flaws. On the contrary, under the FOSS model, users may access the source code in order to see how it works and/or to improve it.
    [Show full text]
  • An Investigation of How Commercial Software Companies Should React to Open Source Software
    An Investigation of How Commercial Software Companies Should React to Open Source Software UW CSEP 590 TU Course Project December 10, 2004 Patrick Haluptzok, Bipin Karunakaran, Rodrick Megraw, Magdalene Tatum, James Welle, and Song Xue Abstract Open source software began as the hobby of a small number of programmers and has developed today into a worldwide phenomenon that is a viable economic alternative to proprietary software. As a proprietary software company, it is essential that you understand open source and how to interact with this type of software. You may choose to compete with open source or embrace it into your business model, but ignoring open source is not a viable option. We present this paper as a guide to open source software. First, we discuss what open source is and explain its history. We also explain the general advantages and disadvantages of open source software. Second, we explain the myriad of open source licenses and how they work. Next, we discuss how your workforce can safely and effectively coexist and interact with open source software. In the fourth section of the paper, we discuss the different open source business models and the benefits of each. Fifth, we discuss the specific legal issues involved with open source software and we highlight the recent SCO litigation. Finally, we present a case study on Microsoft Windows and other proprietary platforms and investigate how they have reacted to the open source phenomenon. We also investigate possible open source strategies for the Windows operating system. Haluptzok, Karunakaran, Megraw, Tatum, Welle, and Xue 2 0 Table of Contents 0 Table of Contents.......................................................................................................
    [Show full text]