Software Distribution Scenarios

Transcription

1 Software Distribution Scenarios Thomas W. Storey Keck Graduate Institute of Applied Life Sciences Mentor: Judith Connor, Ph.D Summer 2002 Keywords: technology transfer, intellectual property, software, open source, proprietary, collaboration, start-up, ABSTRACT MBARI s research activities are supported by software engineering efforts and many of the software tools developed have an audience outside of the Institute. Irrespective of whether the interested party is a commercial firm or non-profit research organization, MBARI must have processes in place to transfer its software innovations to others. There are four basic models of technology transfer for software: open source distributions, closed source distributions, collaborations with commercial partners and formation of start-up companies. Some of the relevant factors when considering a technology transfer model i.e. the software s likely user base (commercial or scientific), its need for further development, its application outside of ocean science and its licensing strategy are described in discussions of each software technology transfer model. Whenever possible, case studies from past MBARI innovations are included as examples of successful technology transfers.

2 INTRODUCTION Technology transfer describes the process by which academic research innovations are transferred to other scientific or commercial interests outside the Institute 1. MBARI licenses the commercial rights to technology it has developed in hopes of disseminating new innovation to the public. Licensing activities can be instrumental in building name recognition for the Institute and can also generate revenue that can be reinvested in research activities 2. However, since proceeds from licensing are small, they do not solely justify technology transfer activities. The deployment and adoption of new innovation are the greater goals for MBARI s technology transfer efforts. In fact, MBARI s technology transfer objectives can be summarized by the following five principles 3 : Distribute MBARI innovations to the scientific community Protect MBARI s non-profit status and intellectual property assets Provide responsive service to MBARI staff on intellectual property issues Ensure MBARI s scientific mission is met Build mutually beneficial relationships with the scientific and business community The responsibility of applying these principles to individual technology transfer cases belongs to the director of Information and Technology Dissemination (ITD), Judith Connor, Ph.D. Technology transfer can happen in a number of ways. The first and most obvious method occurs by publication of scientific results in a scholarly journal. However, when a technology will be transferred to an organization with the expectation that it will be

3 commercialized, there are three general models of transfer. The first model disseminates pre-existing technology or innovations that are currently functional but need further improvement before marketing. Collaboration and/or sponsored research agreements represent the second model of transferring technology. Collaborations both create new information and start the technology transfer process. Finally, the third model sees new for profit companies formed around academic research as a way to develop new innovations into useful products 4. These three models govern most technology transfers, but since our discussion will focus on software, the model relating to preexisting technologies implicates software code distributions and can be further subdivided into two categories open source distributions and closed source distributions. Therefore, we can reformulate the three technology transfer models specifically for software as follows: Open source distributions Closed source distributions Co-development or collaboration Formation of a start-up venture The manuscript is divided into several sections that either provide background for or analyze each transfer model. The first section discusses the basic principles behind software intellectual property and licensing and is only recommended for readers unfamiliar with software engineering. More advanced audiences, should proceed directly to the sections which describe each technology transfer model. Each section begins with a theoretical discussion of the technology transfer model and is followed by a case study that exemplifies it. Whenever possible, MBARI cases were selected, but when this was

4 not possible, a case was borrowed from Stanford University s Office of Technology Licensing. INTELLECTUAL PROPERTY PRIMER Intellectual property (IP) is any product of human intellect that has commercial value 5. It is usually thought of in the context of scientific inventions, although poetry, songs and other works of art can qualify for protection. Establishing intellectual property rights for a scientific invention protects the commercial interests of an inventor s intellectual work. As the holder of these commercial rights, the owner is free to do with them as s/he pleases. This includes licensing the rights to another party, capitalizing on those rights individually or simply doing nothing. It is possible to release software inventions without any intellectual property protection whatsoever. This is called releasing the software into the public domain. Since the software has no IP protection, another person may assert intellectual property rights on the invention and force the original inventor to license the right to use the program back from the new owner. This situation describes the strictest legal definition of public domain. The colloquial definition of public domain, and the definition used most often in software circles, refers to users having wide latitude with the software to use, modify and redistribute it. In most instances of public domain software, the author has actually copyrighted it and issued a permissive license to use the software that, in essence, returns the software to the public domain. This distinction may seem trivial, but it highlights the importance of protecting an author s work even if the end goal is public distribution.

5 Copyright, patent, trademark and trade secret are the four basic classes of intellectual property and Table 1 briefly describes them. We will only touch on them here and apply each to computer software. Trademarks or service marks identify a business goods or services in the market. Their role in software is no different than in any other business. The half-eaten apple, for example, is a trademark of Apple Computer. Copyright is the literal expression of a work. Almost all the software code both object and source code can be protected with copyright. Copyright protection establishes ownership of the software and provides a means of allowing others permission to use the software with a license. Copyright does not preclude others from replicating the function of the program nor does it protect the idea behind the code (i.e. the algorithm). Copyright is easy to establish and lasts a long time. All that is required is to label each version of the published work with a copyright notice and the author is protected for 100 years. Better copyright protection can be obtained by registering a copyright with the U.S. Copyright Office. This ensures the date in which your code was copyrighted, but requires disclosing a portion of the work to the Copyright Office. Copyright is an excellent way to protect software even if you want to distribute the source code freely. Patents are for novel and nonobvious inventions and, in software; they try to capture the idea behind a software program rather than its literal expression. Generic examples of patentable inventions are any new machines, compositions, or processes. Computer algorithms are not eligible for patents for the same reason that you cannot patent mathematical formulas. However, if the program, software, or algorithm affects some hardware or process for instance, if the algorithm controls a display, a memory, a

6 keyboard, any other hardware or process, or if it processes or analyzes a signal then it can be patented 6. Patent protection is stronger protection than copyright because it protects the idea behind the code rather than just the code. Selecting a patent or copyright for software depends upon a number of factors. Patents are costly and time consuming to obtain and require disclosure of the program s secrets. Copyright is quick and easy to establish, however if another program is developed independently by another engineer, copyright affords no offensive rights against the other inventor. Patent protection protects the idea behind the program and may provide a legal basis for stopping independently developed infringements. Table 2 provides hypothetical examples of software and their appropriate intellectual property protection. A final intellectual property protection that can be important in software is trade secret protection. Trade secrets provide a means of protecting industrial know how, designs, processes, or compositions that confer a competitive advantage to a firm. Trade secrets can be valuable commodities, especially if the protected information does not lend itself well to an established type of intellectual property. Trade secrets have an indefinite life and, in software, are used to protect algorithms and/or source code. Maintaining a trade secret can be difficult in practice, but it does not require registration with any federal agency. All protected information must be kept confidential and the owner must take reasonable precautions to protect it 6. Intellectual property protects the commercial potential of intellectual assets, but owners are allowed to transfer these commercial rights to others. This is done through a license. Licenses define the commercial privileges of recipients and are negotiated from the owner of the IP. There are three basic types of licenses. The first type is called a

7 non-exclusive license and reserves the owner of IP s right to license the technology to others at their discretion. In other words, non-exclusive licenses allow MBARI to license the same technology to a number of different parties. Exclusive licenses, on the other hand, preclude the licensor from licensing the technology others. This becomes especially important for technology that may form the basis of a start-up company. The third type of license, the field of use license, lands somewhere in between exclusive and non-exclusive licenses. Field of use licenses define the scope a license and limit the licensee s commercial rights to a specified industry or field. For example, a technology with application in many industries could be licensed individually to each industry with terms that restrict its use to a given field. Selecting a particular license depends upon the technology and the priorities of the principals in the negotiation. For interested readers, Pressman provides an excellent background on intellectual property in Patent It Yourself. Materials and Methods Whenever possible, peer-reviewed journal articles were used as references, but trade journals and web sites were also referenced. Other print materials included annual reports from corporations, trade associations (AUTM), and technology licensing offices (i.e. Stanford and MIT). The report also includes information collected from personnel interviews. All but one (Stanford DNA Microarrays) of the case studies were written based upon personnel interviews with the inventors or licensing personnel instrumental in the negotiation. In many cases, both sources were consulted. In addition to those interviews, I talked informally with a number of computer scientists about general

8 concepts in computer software and corresponded with non-profit organizations about licensing issues (i.e. The Free Software Foundation). To ensure the report s accuracy, MBARI software engineers and licensing personnel reviewed the manuscript. RESULTS AND DISCUSSION Software developed by MBARI staff without support from extramural funding agencies or commercial partners allows the greatest flexibility for distribution. The Institute has total control of the project and can establish intellectual property protection and transfer the technology according to the Institute s needs. A common question that will face MBARI personnel is the decision to release software open source or closed source. Each method has its advantages and disadvantages and developing a plan for distributing each type of software depends upon understanding the licensing agreements for each type of software and their effects on software adoption. Distributing Preexisting Technologies I: Open Source Software Object code is the machine-readable form of software and the form of software required for functionality. The human readable form of a software program is called the source code largely because it is the precursor to the object code and holds the secrets of the program s core functionality. Since the source code is not required by the computer to run the program, it is often omitted in commercial releases of software. Corporations and for profit entities have traditionally protected the source code of their products by only distributing the object code to end-users. This prevented the dissemination of proprietary secrets embodied in the source code and the source code

9 preserved a competitive advantage for the firm. The drawback of this policy was that by restricting access to the source code, the end-users ability to understand and modify the program was restricted. When a user has access to the source code so called open source software (OSS) they can easily learn, modify and adapt the abilities of a software program to their specific and individual needs. This creates an environment where advancements in the source code evolve over time as more users interact with the code. The peer-reviewed nature of this process has an academic feel to it and, not surprisingly, university researchers and non-profit organizations have championed the release of source code since the early days of computers. They argue that free and open information exchange in source code is consistent with the academic mission and results in faster development of innovative, robust software. To adequately protect the free dissemination of source code from proprietary interests, the non-profit community has developed a sophisticated set of legal protections for OSS. These efforts have been largely successful, but they have also resulted in considerable confusion about open source software and its terms of use. Understanding open source software means understanding the underlying legal and commercial forces at work in the software industry. By reading this report, MBARI personnel will gain an understanding of the issues that must be addressed when contemplating a development project open source or otherwise that may culminate in a technology transfer of some sort.

10 Open Source Software and The Free Software Movement Open source software enjoys an almost evangelical following and has its roots in the academic and hacker communities of the early 1980 s. Richard Stallman founded the Free Software Foundation (FSF) in 1984 as a tax-exempt charity to raise funds for free UNIX-compatible software development and the movement has steadily gained in popularity since 7. Stallman s vision described software that was free. For him, this did not mean that the software was available at no charge, but rather the user was free to use, copy, modify and distribute software according to their own discretion. The movements early followers were research oriented academics and independent programmers (hackers, recreational programmers, consultants, etc.) whose notion of software ownership differed significantly with those of proprietary vendors and the movement was viewed as antiproprietary or anticommercial from the beginning. The movement began to fragment as it increased to include members with more commercially oriented value structures. There were those who saw open source software as a collectivist right and those who viewed open source software as a new commercial tool to be used with innovative business models. Their differences introduced ambiguity into many of the terms and vocabulary usually associated with OSS. We will use the term open source software to mean software were the source code is freely available and avoid using the term free software as its connotation with price confuse the issue of open source software and the privilege to use, modify and distribute source code. There is general agreement, however, on the basic principles of open source and they are articulated below (courtesy of the Free Software Foundation website,

11 The user has the freedom to use the software as they see fit. The user has the freedom to copy the software verbatim and share it with others. The user has the freedom to study the program s functionality and adapt it to their needs. Access to the source code is a precondition for this. The user has the freedom to distribute modified versions of the software. Access to the source code is a precondition for this. The Open Source Initiative ( is also an excellent resource for further information. Irrespective of which division of the movement an individual belongs too, the ability to copy, use and modify the source code is critically important. The confusion both legal and philosophical surrounds the application of the fourth criterion; the user s freedom to distribute modified versions of the software. This aspect of free software encompasses the panoply of open source license agreements and reflects the differing opinions of movement proponents toward the role of commercial interests in software. Analyzing the various licensing models in the context of their commercial utility is an excellent way of learning the nuances of each agreement and their practical application. Open Source Software Licensing Models The primary reason that open source software didn t flourish in the 80 s was that firms feared releasing their source code meant compromising proprietary information and, therefore, competitive advantage. Companies hid their source code with copyright and trade secret law and only licensed the user the ability to run the program. Open

12 source software licenses, on the other hand, protect the freedom of the source code and ascribe powerful rights to users. They ensure the liberal distribution of source code and, in varying degrees, restrict a piece of code s commercial utility. There are countless OSS license agreements, but we will only discuss the four most widely used and wellunderstood agreements. They are the General Public License (GPL), the Lesser General Public License (LGPL), the Mozilla Public License (MPL) and the Berkeley Software Distribution License (BSD). Each license represents a different stance of the open source community toward commercial interests and proprietary code. Open source license agreements are broadly classified into two categories copyleft agreements and noncopyleft agreements. Copyleft imposes restrictions on developers who modify and distribute OSS stating that they cannot limit the end user s ability to freely copy or further modify the software. It expressly prohibits adding additional restrictions in the license agreements ascribed to derivative works. This creates a self perpetuating, spiral licensing model in which derivative works are distributed under the same licensing agreement they were created under and so on and so forth 8. Copyleft license agreements are effectively immune to any proprietary interests that try to limit the availability of the source code. The other class of OSS licenses, noncopyleft license agreements also protect the users ability to use, modify and distribute open source software, but allow for modifications in the licensing restrictions applied to derivative works. Depending on the wording of noncopyleft licenses, these additional restrictions can have a wide range of effects on the commercial utility of a piece of code. The license manifestation of the copyleft principle is the GNU General Public License or simply the General Public License (GPL). Linux was written under the GPL

13 and the result is an ever-expanding body of OSS protected by the law from commercial privatization. The GPL is a powerful license and has far reaching effects on software projects that incorporate even small amounts of GPL-protected code. Incorporation of any piece of GPL-protected code contaminates the remaining body of the code by requiring the collected work be licensed under the GPL. If, for example, GPL protected code links to code protected by another license, then assembled GPL-protected code and non GPL-protected code must be licensed as a larger work under the GPL. An example here will help elucidate this concept. XFree86 is an open source video driver originally developed for the X Windows System and carries the GPL. nvidia corporation develops closed source, proprietary video drivers and incorporated a portion of the XFree86 video into one of their projects. Under the terms of the GPL, this would have forced nvidia to release all of the source code for the new proprietary driver under the GPL. Instead, nvidia chose to remove the GPL protected code and release a clean version with locally developed code 9. This example highlights the impact GPL licensing can have on commercial development efforts and is not a trivial concern. It is also important to realize that the terms of the GPL legally conflict with the terms of other OSS licenses and, regardless of your motivations or plans for a particular piece of code, it is important to understand the implications of combining GPL-protected software with other works. The GPL is an effective means of eliminating proprietary interests in open source software, but there are situations when this is an adverse result, even for non-profit or academic minded software engineers. It is easy to imagine situations were MBARI engineers are modifying software developed by proprietary vendors and incorporation of

14 GPL code would be in direct conflict to the interests of friendly commercial collaborators. Furthermore, software engineered and distributed under the GPL will draw little attention from commercial developers, meaning that software requiring further development, testing and/or support will not be picked up by commercial developers. Using GPL to prevent commercial developers from using a piece of code may, on the face of it, appear to be a good idea, but limiting the user base of a software tool may detract from the technology transfer mission and overall utility of the software. There is also some concern as to whether GPL protected code has the potential to become a widely adapted standard. The success of Linux certainly speaks against this hypothesis, but if we posit Linux as an exception, it seems plausible that proprietary vendors might shun GPL protected code when designing standards or platforms for their newest hardware and software. These concerns are at least partially alleviated in another copyleft license written by the Free Software Foundation called the Lesser General Public License (LGPL). The LGPL has a much narrower scope than its GPL cousin and is usually reserved for shared software libraries that may be linked or used by non-free software. In this scenario, users can extend the source LGPL-protected library with proprietary modules (closed or open source) and users of non-free software can incorporate LGPL libraries into their development activities while not contaminating their proprietary projects with copyleft model. The Free Software Foundation developed this license largely in response to problems with adoption of GPL protected code when proprietary equivalents already existed.

15 There are other open source licenses that do not rely on the copyleft principle. Recall that copyleft agreements do not allow redistributors to add additional restrictions to subsequent modifications and releases. In practical terms, this enforces that free software remains free. Noncopyleft agreements, however, allow modifications to the licensing terms in derivative works. Most noncopyleft software comes with permission from the author to use, modify and distribute the software AND impose additional restrictions on the licensing terms of derivative works. For example, if a piece of software was licensed under a permissive noncopyleft license, an individual could modify a piece of noncopyleft code, compile it and distribute the object code as a proprietary software product 8. This is allowed under some noncopyleft. The noncopyleft agreements increase the flexibility of OSS by being more attractive to commercial developers. Noncopyleft agreements can account for most distribution scenarios that lie within MBARI s mission. The Mozilla Public License (MPL) is a noncopyleft open source license, which requires derivative works to be licensed under the MPL. Since the GPL also requires derivative works to be licensed under the GPL, MPL-protected code and GPL-protected code are incompatible and cannot be combined in derivative works. Anytime GPL protected code links with code protected under other license agreements the larger work must be licensed under the terms of the GPL. The MPL lacks this restriction. Files protected under the MPL that are modified slightly i.e. the addition of a call pointing to a subroutine in a proprietary file must be released under the terms of the MPL, but the files called by MPL-protected code may be licensed under different terms. The resultant MPL-protected files are effectively useless without their proprietary counterparts and

16 much of the freeness of the original open source software has been lost. The Lesser GPL (LGPL) seemingly mimics MPL s ability link to proprietary files without requiring the linked code to be licensed under the LGPL, but the licenses are still distinct in subtle ways. For example, the kinds of links to other code allowed by each license are different. This author does not have the expertise in software or law to interpret the subtle differences between the licenses and legal counsel should be consulted before licensing a major project that may depend on this distinction. There are, however, are non-technical differences in the licenses that could at least explain in part why so much confusion between the licenses exists. Mozilla wants MPL-protected code to successfully interface with GPL-protected code AND code licensed under more proprietary terms 10. Therefore, their license terms are carefully crafted to accomplish this dual compatibility. The Free Software Foundation, in contrast, developed the LGPL to allow linking with proprietary code in hopes of making GPL-protected code collectively more competitive with proprietary software 8. The LGPL is designed to pull software toward the GPL license model were the MPL is designed to occupy the middle ground. It is no wonder that this arrangement creates confusion and it gets worse. Mozilla introduced a new triple license (MPL/GPL/LGPL), which allows users to license derivative works under the GPL, LGPL or MPL. This largely solves the problems of incompatibility between the GPL and LGPL with the MPL. Moreover, Mozilla will only accept MPLGPL/LGPL licensed code into its CVS repository. But this change by Mozilla is resulting in some challenges with backward compatibility of older code licensed under the original MPL. A discussion of this topic is certainly beyond the

17 scope of this document and it is enough to know that MPL version 1.1 is the GPL compatible license 10. The Berkeley Software Distribution license (BSD) is the most permissive of the popular open source licenses. Initially designed around the Berkeley version of UNIX, the BSD license allows users to modify and distribute source code under different licensing terms. That is, an open source contribution licensed under the BSD can be adopted and modified by a proprietary interest and re-released as closed source proprietary software. The BSD license originally required any advertisement of second generation products based on BSD code to attribute UC, Berkeley in the advertisement, but other programmer s began including their advertising clauses the their releases and soon popular code became unwieldy to use because of all the advertising restrictions. UCB has since dropped this clause from the license. Be sure which version of the BSD license you are using or select an alternative license which offers equivalent protection without the ambiguity (for example, the MIT license has similar provisions as the BSD but without the advertising clause. See Table 3). While this model makes the BSD license a business-friendly OSS license it is also the license most vulnerable to privatization. Users can make modifications to the source and not distribute them freely or as open source. From the perspective of an MBARI personnel contemplating the release of code, the BSD license appeals to the largest audience of developers and is an excellent candidate for anyone who sees further development by a commercial as an attractive option. The BSD is an effective way of just putting it out there. In short, anybody can use it for any purpose.

18 There are other open source licensing models besides the GPL, LGPL, MPL, and BSD but these are four of the most common and four that MBARI personnel will likely encounter. The license models are important for developers who are working on open source projects. When or if it comes time to select a distribution scenario, you must consider the license model s relationship to your software s most probable audience. If, for example, you are preparing software with a commercial partner then you should understand the workings of their business and try to match their needs in the selection of your license agreement. Or if you are developing an alternative to proprietary software, you should understand the nature of the competition and the needs of the market you are trying to reach. In either case, understanding the business of open source software will be crucial to selecting the appropriate distribution and/or licensing model. Open Source Software as A Business The competitive advantage for firms entering the OSS market is access to independent software engineers who will produce evolutionary enhancements to software products for no charge in what is effectively a peer-reviewed system. Distributed development is the incremental improvement of an application s functionality resulting from the coordinated efforts of hundreds of users with access to the source code. In theory, distributed development can produce more products faster and with higher quality than would be possible in an isolated effort 11. Individual users will take an official source code distribution and tailor it to their own specifications adding functionality along the way. They will identify and fix bugs and, eventually, a robust quality product will emerge. The sponsoring institution for open source development

19 projects provides infrastructure support and guidance for the network of remote developers. The process is usually jump-started by the release of a common, highquality, seed code by the sponsoring firm that demonstrates the promise of future solutions to developers and provides a standard base upon which to develop 11. Other useful services include newsgroups, version control, and bug-reporting systems (Sourceforge offers these services 12 ). An important example of the success of this strategy is the Linux operating system and the body of free software that surrounds it 11. Distributed as open source, Linux users modify and change the source code as they see fit. They report their modifications back to a number of different caretakers who compile, test, and re-release worthy additions in subsequent versions of the operating system. This development model produced a robust operating system that includes a diverse, dependable and powerful collection of software tools. Clearly, the advantage of distributed development lies in delegating the workload to a large number of creative problem solvers rather than relying on the finite efforts of developers working in the isolation of a software corporation. OSS development may flourish in a distributed model, but where do users especially those users who are either unable or unwilling to solve code-level problems find support for their problems. OSS software is notorious for poor user interfaces, difficult installations and no vendor backed support and support is the most often cited reason by corporations for not adopting OSS 7. Distributed development occurs through the efforts of otherwise occupied developers who tinker with the code or modify it to fit their previously assigned tasks and then submit their improvements back to the developer

20 community. But support does not fit into the distributed development model, because adequate support includes training, documentation, real-time support, bug fixes, and professional consulting. All of these tasks require dedicated, capable service personnel 13. However, this dichotomy between development and support is increasingly drawing the attention of large commercial entities interested in generating support-based revenues for open source projects. IBM, for example, is supporting a successful freeware project, the Apache Web server. Apache is the world s most popular web server and IBM integrated it as part of its WebSphere Internet commerce application server. In exchange for including open source free software in its proprietary packages, IBM promised to share improvements it makes to the code and provide enterprise-level support for Apache 7. Commercial grade support will certainly help Apache maintain its large market share, which is already greater than Netscape and Microsoft combined, and represents a significant entry for open source software into traditional commercial markets. There are proponents of OSS who fear that involvement of large scale commercial firms will gradually privatize open source software but, on the face of it, IBM providing enterprise level support for freeware seems to be a step in the right direction for open source software. The IBM example is an interesting case for another important reason. It highlights one of the emerging business models being built around OSS. The immaturity of the movement has yet to validate any single OSS business model, but at least three different approaches will be relevant. The first model, exemplified by Red Hat and IBM, shows companies distributing source code for little or no charge and generating revenue by support activities like branding, consulting, custom development, and post-sales

21 support 11. Red Hat overseas the development and support of Linux and IBM curates Apache, but neither company did the seminal work on these products. The programs from the open source community and the advent of third party corporate sponsored support make each program an excellent alternative to more traditional proprietary software products. One intriguing technology transfer model from MBARI s perspective emulates this product life cycle. MBARI might develop an OSS product and encourage commercial developers to provide support for the product. This would ensure that a robust, well-supported OSS product is available to the general public thereby servicing MBARI s mission and improving corporate relations. The Support Sellers business model brings us to another important, albeit somewhat unrelated, point. One of the most successful companies utilizing the Support Sellers business model is Red Hat. Earlier we affirmed that the GPL effectively destroys the commercial value of a piece of software, yet Linux is licensed under the GPL and is supporting a number of profitable businesses (Red Hat, MandrakeSoft, etc.). How can this be? The GPL effectively removes proprietary value out of the code itself, but it also creates a user base that demands support. Companies enjoying profits from Linux are not selling the code, they are meeting its support demand. In the final analysis, it is possible to run successful businesses around OSS protected under the GPL. A second open source business model requires companies develop a loss leader to attract consumers to traditional proprietary software. A loss leader is a commodity or product sold at a loss to attract customers. Many open source software programs could become loss leaders in more traditional software companies. For example, some basic functionality is conferred to the user in a free source code release, but advanced or more

22 sophisticated products are only available under commercial software 11. The Netscape Browser is classic example of a loss leader. It is distributed for free as an open source project in an effort to increase the customer base for Netscape s proprietary software applications (web servers). The browser is licensed under the Netscape Public License, a close cousin to the Mozilla Public License (MPL) and allows Netscape to incorporate changes made by independent developers into proprietary versions of its software (the MPL lacks this clause). Widget Frosting is colloquial term for a third open source business model and a model that should already be intuitively familiar to MBARI personnel involved in device engineering. Metaphorically speaking, widgets are hardware devices that companies sell for a profit and the frosting is open source enabling software for the widget (drivers, interface code, etc.) 11. Silicon Graphics (SGI) is executing this business model in its Origin line of servers. In this case, the widget is an SGI server and they frost it with the open source program suite, Samba. Samba is a collection of programs designed to facilitate data sharing between Windows and UNIX clients, thereby expanding the capabilities of SGI s server Widget frosting is an excellent model for companies, because enabling software is typically a development cost of the widget and now it can be outsourced to the distributed development community. MBARI engineers often develop software that accompanies hardware. Understanding the business models that proprietary vendors work under will be invaluable in designing systems that are compatible with commercial adoption and widespread application. (NOTE: Both the Open Source Initiative and Silicon Graphics Website describe Samba as an open source tool kit, but upon further investigation, a sales representative from SGI told me that

23 Samba is closed source on their platform. I didn t have time to follow up, and even if the example is flawed, it demonstrates the concept of widget frosting.) There are other OSS business models and Frank Hecker of Netscape discusses them in The Business of Open Source Software, but support sellers, loss leaders and widget frosting seem to be the most likely fates of MBARI-developed open source software transferred to commercial partners. Servicing MBARI s technology transfer mission requires an understanding of the business climate that commercial collaborators are operating in. Furthermore, understanding the licensing models and their implications for commercial potential provides more relevant information for decision-makers contemplating a tech transfer or software development project. If an open source distribution is clearly the path to maximum benefit, then understanding the license models and business climate were the invention is likely to find a home is essential. Case I: MB Sonar 16 Selecting an appropriate license model for an open source distribution depends on adequate understanding of how the software fits into the environment in which it is released. Dave Caress of MBARI and Dale Chayes of the Lamont-Doherty Earth Observatory (L-DEO) of Columbia University have developed MB-System a software package that can process and display bathymetry and backscatter imagery data derived from multibeam, interferometry, and sidescan sonars and it is an excellent example of this concept. MB-System is distributed as open source software under the GPL and is available for download from the L-DEO and MBARI websites.

24 In the early 1990 s, scientists using multibeam sonars for deep-ocean seafloor mapping depended on whatever locally written software was available from the few institutions operating these sonars. For most U.S. marine geologists, this meant working with groups at either the Scripps Institution of Oceanography (SIO) or the University of Rhode Island (URI). In general, the software was cumbersome to use and poorly documented, making it difficult for outsiders to effectively use the SIO and URI tools. Moreover, although both groups were instrumental in the scientific success of the first generation of sonars, their software development efforts eventually failed to keep up with advancements in both computer and sonar technology. In 1992, NSF requested that David Caress and Dale Chayes, then both at L-DEO, undertake the development of a generic set of software tools for processing multibeam sonar data that could be distributed throughout the Marine Geology and Geophysics community. This was not a stand-alone effort, but rather one component of a much larger effort to upgrade the hardware and software associated with the multibeam sonar then installed on the L-DEO research ship R/V Maurice Ewing. The resulting software came to be called MB-System, and the development and support of MB-System by Caress and Chayes has been funded by NSF continuously since Over the last 9 years, the licensing restrictions on MB-System have evolved along with the code and reflect Caress employment history in non-profit and for profit institutions. Early versions of the code were released into the public domain without intellectual property protection and, not until 1994 was MB-System protected with copyright. The GPL was added in 2001 after Caress came to MBARI from SeaBeam Instruments.

25 SeaBeam Instruments is a private corporation involved in the design, development and manufacturing of multibeam sonar survey systems and SeaBeam financed a significant portion of MB-Systems development via employment of Caress from MB-System was kept open source, however, because Caress built SeaBeam s proprietary system on top of MB-System. This resulted in the simultaneous development of both systems and demonstrates the feasibility of such an arrangement. Part of the original rationale for developing MB-System was to create a free alternative to proprietary tools and the GPL s anti-proprietary nature makes it an excellent choice for this purpose. It is worth mentioning however, that MB-System s license includes special provisions that maintain the commercial viability of SeaBeam products developed around previous releases of MB-System. The GPL only protected the current version of MB-System and did not effect the version that SeaBeam used as a foundation for its tools. Another relevant factor that played a part in determining MB- System s licensing strategy related to the project s NSF support. NSF funding was contingent upon an open source free release of MB-System. The GPL certainly honors this restriction however another open source license could have been used. Caress selected the GPL because it satisfied the mandate of his research sponsor and ensured MB-System would function indefinitely as a free alternative to proprietary tools. Support of MB-System remains Caress and Chayes responsibility and is a source of continual frustration for them. The system has a relatively large user base with most American oceanographic installations using MB-System in some capacity. Scripps, L-DEO, Woods Hole, MBARI, and other oceanographic institutions all use MB- System and this creates a significant support need that manifests itself as 1-2 s per

26 day for the MB-System team. There is also a large international user base, with the software being commonly used by academic researchers in Japan, Korea, UK, Germany, Italy, Turkey, and other countries. Support requests vary in complexity and require nontrivial resources to answer. The largest shortcoming of committing time to support is the negative impact it has on further software development. Since Caress time for MB- System work at MBARI is allocated for support AND development, the larger the support load, the slower the development. Chayes spends more of his allocated time on software support, but since Caress is the primary developer, any requests for software fixes or modifications have to be handled at MBARI. Software engineers contemplating an open source release should consider the time commitment for support. Developers should remember that the support load only increases with the success of the project. Furthermore, the initial MB-System development could not be funded today because a number of commercial alternatives exist. The development project continues to be funded because the MB-System software is functionally competitive with the commercial packages and because of the existing user base. However, if we ever falter in support or development, the user base will rapidly disappear. Distributing Preexisting Technologies II: Closed Source Software Transferring preexisting software technologies occurs via open source distributions or closed source releases. Closed source software describes programs where the source code is hidden from the user and the release only includes machine readable object code. Attempts by the user to reverse engineer or decompile the code are restricted by the license. Despite recent gains by the open source movement, closed source distribution models remain the industry standard for proprietary software releases

27 and represent a proven distribution scenario for MBARI software. Closed source distributions do not always conflict with the academic mission and can still offer tremendous flexibility with respect to usage, duplication and redistribution of software. MBARI may opt for a closed source distribution for a number of reasons. For example, to preserve the commercial utility of a software invention or accommodate the needs of a commercial partner. There are many strategies for intellectual property protection for closed source software. The source code is usually protected with a patent or trade secret and the object code released to the user is protected by copyright. Algorithms and core functionality, therefore, remain hidden from user. The license agreements for closed source software are diverse and have varying degrees of flexibility. They are clearly designed for commercial software releases, but do not preclude distributing smaller incomplete applications like software components. Software components are reusable portions of code with modest functionality and seem likely results of MBARI research. For users, the code is useful and sophisticated enough to warrant licensing rather than replication, but not large enough or widely applicable for a stand-alone release. Transfer scenarios for closed source software might see a software component being added to an existing product. For the company, the add-on increases the size of the product s market and contributes another feature 17. For MBARI, the distribution satisfies the tech transfer mission by making the component available to a targeted group of users at a reasonable cost (i.e. ocean scientists). Closed source distributions also invite collaboration. For example, users may require the expertise of the software s author to integrate the program into their activities. Assistance may be simple support issues like

28 installation and troubleshooting or may require sophisticated adaptation of the program's source code to meet the user s needs. In either case, collaborating with the author lends the necessary technical skill to facilitate the transfer quickly and establishes a collaboration between the principals, MBARI and the licensee. Closed Source Licenses Just because a software program is closed source does not mean that its terms of use are inflexible. Off the shelf software license agreements can be rigid and restrictive however closed source license agreements for MBARI-derived software can be flexible, custom tailored agreements. The following list describes the basic tenants of all closed source agreements and provides a basic framework for license negotiations. All closed source licenses define the following parameters 18 : The license grant Royalty payments Confidentiality Support and maintenance Ownership of collected or derivative works Risks and liabilities The license grant is the critical provision of any license agreement and stipulates the rights and privileges being transferred. It is heavily negotiated in any license deal and strives to balance the interests of the licensor and the licensee. The license grant defines the scope and usage of the software. Minimally, it allows users to use the object code with limited rights for backup or archival copying. More flexible license grants allow

29 licensees to incorporate licensed code into collected works and release them as their own third party products. The license may also grant the licensee the right to modify portions of the software. For example, some closed source software includes a section of source code that allows modification of the component interface for integration into an existing system. Liberal terms for archiving and copying can also be negotiated. The license grant represents the crux of any license agreement and many of the subsequent provisions in the deal are structured around the grant s terms 18. The royalty payment schedule is another heavily negotiated provision and the structure of payments largely depends upon the nature of the software. Software that requires little to no integration and functions independently is usually licensed with up front royalty fees 18. However, software components that may be integrated into collected third-party works and redistributed, require royalty payment structures that account for the commercial success of the collected work. Confidentiality is another important element of license deals 18. Licensors do not want licensees to disclose or distribute proprietary information embodied in the software so agreements often carry stipulations that protect the intellectual property of the licensor. These stipulations usually last for a specified period of time and, in the case of software components, may require the licensee to encrypt the component prior to storing or distributing it. Obviously, the licensor wants to keep the support and maintenance obligations small but, nonetheless, they are a part of most agreements. The scope of the licensor s obligations once again depends upon the nature of the software and the individual agreement. Typical support agreements for stand-alone software have a short, specified warranty period of free support followed by support offered for a fee 18. But support