doc/en_US.ISO8859-1/articles/bsdl-gpl/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
	"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
  
  <info><title>Why you should use a BSD style license for your Open Source Project</title>

    <authorgroup>
      <author><personname><firstname>Bruce</firstname><surname>Montague</surname></personname><affiliation>
          <address><email>brucem@alumni.cse.ucsc.edu</email>
          </address>
        </affiliation></author>
    </authorgroup>

    <legalnotice xml:id="trademarks" role="trademarks">
      &tm-attrib.freebsd;
      &tm-attrib.intel;
      &tm-attrib.general;
    </legalnotice>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>
  </info>

<sect1 xml:id="intro">
  <title>Introduction</title>

  <para>This document makes a case for using a BSD style license for
    software and data; specifically it recommends using a BSD style
    license in place of the GPL. It can also be read as a BSD versus
    GPL Open Source License introduction and summary.</para>
</sect1>

<sect1 xml:id="history">
  <title>Very Brief Open Source History</title>

  <para>Long before the term <quote>Open Source</quote> was used, software was
    developed by loose associations of programmers and freely
    exchanged. Starting in the early 1950's, organizations such as
    <link xlink:href="http://www.share.org">SHARE</link> and <link xlink:href="http://www.decus.org">DECUS</link> developed much of the
    software that computer hardware companies bundled with their
    hardware offerings. At that time computer companies were in the
    hardware business; anything that reduced software cost and made
    more programs available made the hardware companies more
    competitive.</para>

  <para>This model changed in the 1960's. In 1965 ADR developed the
    first licensed software product independent of a hardware
    company. ADR was competing against a free IBM package originally
    developed by IBM customers. ADR patented their software in
    1968. To stop sharing of their program, they provided it under an
    equipment lease in which payment was spread over the lifetime of
    the product. ADR thus retained ownership and could control resale
    and reuse.</para>

  <para>In 1969 the US Department of Justice charged IBM with
    destroying businesses by bundling free software with IBM
    hardware. As a result of this suit, IBM unbundled its software;
    that is, software became independent products separate from
    hardware.</para>

  <para>In 1968 Informatics introduced the first commercial killer-app
    and rapidly established the concept of the software product, the
    software company, and very high rates of return. Informatics
    developed the perpetual license which is now standard throughout
    the computer industry, wherein ownership is never transferred to
    the customer.</para>
</sect1>

<sect1 xml:id="unix-license">
  <title>Unix from a BSD Licensing Perspective</title>

  <para>AT&amp;T, who owned the original Unix implementation, was a
    publicly regulated monopoly tied up in anti-trust court; it was
    legally unable to sell a product into the software market. It was,
    however, able to provide it to academic institutions for the price
    of media.</para>

  <para>Universities rapidly adopted Unix after an OS conference
    publicized its availability. It was extremely helpful that Unix
    ran on the PDP-11, a very affordable 16-bit computer, and was
    coded in a high-level language that was demonstrably good for
    systems programming. The DEC PDP-11 had, in effect, an open
    hardware interface designed to make it easy for customers to write
    their own OS, which was common. As DEC founder Ken Olsen famously
    proclaimed, <quote>software comes from heaven when you have good
    hardware</quote>.</para>

  <para>Unix author Ken Thompson returned to his alma mater,
    University of California Berkeley (UCB), in 1975 and taught the
    kernel line-by-line. This ultimately resulted in an evolving
    system known as BSD (Berkeley Standard Distribution).  UCB
    converted Unix to 32-bits, added virtual memory, and implemented
    the version of the TCP/IP stack upon which the Internet was
    essentially built. UCB made BSD available for the cost of media,
    under what became known as <quote>the BSD license</quote>. A customer purchased
    Unix from AT&amp;T and then ordered a BSD tape from UCB.</para>

  <para>In the mid-1980s a government anti-trust case against ATT
    ended with the break-up of ATT. ATT still owned Unix and was now
    able to sell it. ATT embarked on an aggressive licensing effort
    and most commercial Unixes of the day became ATT-derived.</para>

  <para>In the early 1990's ATT sued UCB over license violations
    related to BSD. UCB discovered that ATT had incorporated, without
    acknowledgment or payment, many improvements due to BSD into ATT's
    products, and a lengthy court case, primarily between ATT and UCB,
    ensued. During this period some UCB programmers embarked on a
    project to rewrite any ATT code associated with BSD. This project
    resulted in a system called BSD 4.4-lite (lite because it was not
    a complete system; it lacked 6 key ATT files).</para>

  <para>A lengthy series of articles published slightly later in
    Dr. Dobbs magazine described a BSD-derived 386 PC version of Unix,
    with BSD-licensed replacement files for the 6 missing 4.4 lite
    files. This system, named 386BSD, was due to ex-UCB programmer
    William Jolitz. It became the original basis of all the PC BSDs in
    use today.</para>

  <para>In the mid 1990s, Novell purchased ATT's Unix rights and a
    (then secret) agreement was reached to terminate the lawsuit. UCB
    soon terminated its support for BSD.</para>
</sect1>

<sect1 xml:id="current-bsdl">
  <title>The Current State of FreeBSD and BSD Licenses</title>

  <para>The so-called <link xlink:href="http://www.opensource.org/licenses/bsd-license.php"> new BSD
    license</link> applied to FreeBSD within the last few years is
    effectively a statement that you can do anything with the program
    or its source, but you do not have any warranty and none of the
    authors has any liability (basically, you cannot sue anybody). This
    new BSD license is intended to encourage product
    commercialization. Any BSD code can be sold or included in
    proprietary products without any restrictions on the availability
    of your code or your future behavior.</para>

  <para>Do not confuse the new BSD license with <quote>public
    domain</quote>. While an item in the public domain is also free
    for all to use, it has no owner.</para>

</sect1>

<sect1 xml:id="origins-gpl">
  <title>The origins of the GPL</title>

  <para>While the future of Unix had been so muddled in the late 1980s
    and early 1990s, the GPL, another development with important
    licensing considerations, reached fruition.</para>

  <para>Richard Stallman, the developer of Emacs, was a member of the
    staff at MIT when his lab switched from home-grown to proprietary
    systems. Stallman became upset when he found that he could not
    legally add minor improvements to the system. (Many of Stallman's
    co-workers had left to form two companies based on software
    developed at MIT and licensed by MIT; there appears to have been
    disagreement over access to the source code for this software).
    Stallman devised an alternative to the commercial software license
    and called it the GPL, or "GNU Public License". He also started a
    non-profit foundation, the <link xlink:href="http://www.fsf.org">Free
    Software Foundation</link> (FSF), which intended to develop an entire
    operating system, including all associated software, that would
    not be subject to proprietary licensing.  This system was called
    GNU, for "GNU is Not Unix".</para>

  <para>The GPL was designed to be the antithesis of the standard
    proprietary license.  To this end, any modifications that were
    made to a GPL program were required to be given back to the GPL
    community (by requiring that the source of the program be
    available to the user) and any program that used or linked to GPL
    code was required to be under the GPL. The GPL was intended to
    keep software from becoming proprietary. As the last paragraph of
    the GPL states:</para>

  <para><quote>This General Public License does not permit
    incorporating your program into proprietary
    programs.</quote>[1]</para>

  <para>The <link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link>
    is a complex license so here are some rules of thumb when using
    the GPL:</para>

  <itemizedlist>

    <listitem><para>you can charge as much as you want for
      distributing, supporting, or documenting the software, but you
      cannot sell the software itself.</para></listitem>

    <listitem><para>the rule-of-thumb states that if GPL source
      is required for a program to compile, the program must be under
      the GPL. Linking statically to a GPL library requires a program
      to be under the GPL.</para></listitem>

    <listitem><para>the GPL requires that any patents associated with
      GPLed software must be licensed for everyone's free
      use.</para></listitem>

    <listitem><para>simply aggregating software together, as when
      multiple programs are put on one disk, does not count as
      including GPLed programs in non-GPLed
      programs.</para></listitem>

    <listitem><para>output of a program does not count as a derivative
      work. This enables the gcc compiler to be used in commercial
      environments without legal problems.</para></listitem>

    <listitem><para>since the Linux kernel is under the GPL, any code
      statically linked with the Linux kernel must be GPLed. This
      requirement can be circumvented by dynamically linking loadable
      kernel modules. This permits companies to distribute binary
      drivers, but often has the disadvantage that they will only work
      for particular versions of the Linux kernel.</para></listitem>
  </itemizedlist>

  <para>Due in part to its complexity, in many parts of the world
    today the legalities of the GPL are being ignored in regard to
    Linux and related software. The long-term ramifications of this
    are unclear.</para>

</sect1>

<sect1 xml:id="origins-lgpl">
  <title>The origins of Linux and the LGPL</title>

  <para>While the commercial Unix wars raged, the Linux kernel was
    developed as a PC Unix clone. Linus Torvalds credits the existence
    of the GNU C compiler and the associated GNU tools for the
    existence of Linux. He put the Linux kernel under the GPL.</para>

  <para>Remember that the GPL requires anything that statically links
    to any code under the GPL also be placed under the GPL. The source
    for this code must thus be made available to the user of the
    program. Dynamic linking, however, is not considered a violation
    of the GPL. Pressure to put proprietary applications on Linux
    became overwhelming. Such applications often must link with system
    libraries. This resulted in a modified version of the GPL called
    the <link xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link>
    ("Library", since renamed to "Lesser", GPL). The LGPL allows
    proprietary code to be linked to the GNU C library, glibc. You do
    not have to release the source to code which has been dynamically
    linked to an LGPLed library.</para>

  <para>If you statically link an application with glibc, such as is
    often required in embedded systems, you cannot keep your
    application proprietary, that is, the source must be
    released. Both the GPL and LGPL require any modifications to the
    code directly under the license to be released.</para>

</sect1>

<sect1 xml:id="orphaning">
  <title>Open Source licenses and the Orphaning Problem</title>

  <para>One of the serious problems associated with proprietary
    software is known as <quote>orphaning</quote>. This occurs when a
    single business failure or change in a product strategy causes a
    huge pyramid of dependent systems and companies to fail for
    reasons beyond their control. Decades of experience have shown
    that the momentary size or success of a software supplier is no
    guarantee that their software will remain available, as current
    market conditions and strategies can change rapidly.</para>

  <para>The GPL attempts to prevent orphaning by severing the link to
    proprietary intellectual property.</para>

  <para>A BSD license gives a small company the equivalent of
    software-in-escrow without any legal complications or costs. If a
    BSD-licensed program becomes orphaned, a company can simply take
    over, in a proprietary manner, the program on which they are
    dependent. An even better situation occurs when a BSD code-base is
    maintained by a small informal consortium, since the development
    process is not dependent on the survival of a single company or
    product line. The survivability of the development team when they
    are mentally in the zone is much more important than simple
    physical availability of the source code.</para>

</sect1>

<sect1 xml:id="license-cannot">
  <title>What a license cannot do</title>

  <para>No license can guarantee future software
    availability. Although a copyright holder can traditionally change
    the terms of a copyright at anytime, the presumption in the BSD
    community is that such an attempt simply causes the source to
    fork.</para>

  <para>The GPL explicitly disallows revoking the license. It has
    occurred, however, that a company (Mattel) purchased a GPL
    copyright (cphack), revoked the entire copyright, went to court,
    and prevailed [2]. That is, they legally revoked the entire
    distribution and all derivative works based on the
    copyright. Whether this could happen with a larger and more
    dispersed distribution is an open question; there is also some
    confusion regarding whether the software was really under the
    GPL.</para>

  <para>In another example, Red Hat purchased Cygnus, an engineering
    company that had taken over development of the FSF compiler
    tools. Cygnus was able to do so because they had developed a
    business model in which they sold support for GNU software. This
    enabled them to employ some 50 engineers and drive the direction
    of the programs by contributing the preponderance of
    modifications. As Donald Rosenberg states "projects using licenses
    like the GPL...live under constant threat of having someone take
    over the project by producing a better version of the code and
    doing it faster than the original owners." [3]</para>

</sect1>

<sect1 xml:id="gpl-advantages">
  <title>GPL Advantages and Disadvantages</title>

  <para>A common reason to use the GPL is when modifying or extending
    the gcc compiler.  This is particularly apt when working with
    one-off specialty CPUs in environments where all software costs
    are likely to be considered overhead, with minimal expectations
    that others will use the resulting compiler.</para>

  <para>The GPL is also attractive to small companies selling CDs in
    an environment where "buy-low, sell-high" may still give the
    end-user a very inexpensive product. It is also attractive to
    companies that expect to survive by providing various forms of
    technical support, including documentation, for the GPLed
    intellectual property world.</para>

  <para>A less publicized and unintended use of the GPL is that it is
    very favorable to large companies that want to undercut software
    companies. In other words, the GPL is well suited for use as a
    marketing weapon, potentially reducing overall economic benefit
    and contributing to monopolistic behavior.</para>

  <para>The GPL can present a real problem for those wishing to
    commercialize and profit from software. For example, the GPL adds
    to the difficulty a graduate student will have in directly forming
    a company to commercialize his research results, or the difficulty
    a student will have in joining a company on the assumption that a
    promising research project will be commercialized.</para>

  <para>For those who must work with statically-linked implementations
    of multiple software standards, the GPL is often a poor license,
    because it precludes using proprietary implementations of the
    standards. The GPL thus minimizes the number of programs that can
    be built using a GPLed standard. The GPL was intended to not
    provide a mechanism to develop a standard on which one engineers
    proprietary products. (This does not apply to Linux applications
    because they do not statically link, rather they use a trap-based
    API.)</para>

  <para>The GPL attempts to make programmers contribute to an evolving
    suite of programs, then to compete in the distribution and support
    of this suite. This situation is unrealistic for many required
    core system standards, which may be applied in widely varying
    environments which require commercial customization or integration
    with legacy standards under existing (non-GPL) licenses.
    Real-time systems are often statically linked, so the GPL and LGPL
    are definitely considered potential problems by many embedded
    systems companies.</para>

  <para>The GPL is an attempt to keep efforts, regardless of demand,
    at the research and development stages. This maximizes the
    benefits to researchers and developers, at an unknown cost to
    those who would benefit from wider distribution.</para>

  <para>The GPL was designed to keep research results from
    transitioning to proprietary products. This step is often assumed
    to be the last step in the traditional technology transfer
    pipeline and it is usually difficult enough under the best of
    circumstances; the GPL was intended to make it impossible.</para>

</sect1>

<sect1 xml:id="bsd-advantages">
  <title>BSD Advantages</title>

  <para>A BSD style license is a good choice for long duration
    research or other projects that need a development environment
    that:</para>

  <itemizedlist>

    <listitem><para>has near zero cost</para></listitem>
    <listitem><para>will evolve over a long period of
      time</para></listitem>
    <listitem><para>permits anyone to retain the option of
      commercializing final results with minimal legal
      issues.</para></listitem>
  </itemizedlist>

  <para>This final consideration may often be the dominant one, as it
    was when the Apache project decided upon its license:</para>

  <para><quote>This type of license is ideal for promoting the use of
    a reference body of code that implements a protocol for common
    service. This is another reason why we choose it for the Apache
    group - many of us wanted to see HTTP survive and become a true
    multiparty standard, and would not have minded in the slightest if
    Microsoft or Netscape choose to incorporate our HTTP engine or any
    other component of our code into their products, if it helped
    further the goal of keeping HTTP common... All this means that,
    strategically speaking, the project needs to maintain sufficient
    momentum, and that participants realize greater value by
    contributing their code to the project, even code that would have
    had value if kept proprietary.</quote></para>

  <para>Developers tend to find the BSD license attractive as it keeps
    legal issues out of the way and lets them do whatever they want
    with the code. In contrast, those who expect primarily to use a
    system rather than program it, or expect others to evolve the
    code, or who do not expect to make a living from their work
    associated with the system (such as government employees), find
    the GPL attractive, because it forces code developed by others to
    be given to them and keeps their employer from retaining copyright
    and thus potentially "burying" or orphaning the software. If you
    want to force your competitors to help you, the GPL is
    attractive.</para>

  <para>A BSD license is not simply a gift. The question <quote>why
    should we help our competitors or let them steal our work?</quote>
    comes up often in relation to a BSD license. Under a BSD license,
    if one company came to dominate a product niche that others
    considered strategic, the other companies can, with minimal
    effort, form a mini-consortium aimed at reestablishing parity by
    contributing to a competitive BSD variant that increases market
    competition and fairness.  This permits each company to believe
    that it will be able to profit from some advantage it can provide,
    while also contributing to economic flexibility and
    efficiency. The more rapidly and easily the cooperating members
    can do this, the more successful they will be. A BSD license is
    essentially a minimally complicated license that enables such
    behavior.</para>

  <para>A key effect of the GPL, making a complete and competitive
    Open Source system widely available at cost of media, is a
    reasonable goal. A BSD style license, in conjunction with
    ad-hoc-consortiums of individuals, can achieve this goal without
    destroying the economic assumptions built around the
    deployment-end of the technology transfer pipeline.</para>

</sect1>

<sect1 xml:id="recommendations">
  <title>Specific Recommendations for using a BSD license</title>

  <itemizedlist>

    <listitem><para>The BSD license is preferable for transferring
      research results in a way that will widely be deployed and most
      benefit an economy. As such, research funding agencies, such as
      the NSF, ONR and DARPA, should encourage in the earliest phases
      of funded research projects, the adoption of BSD style licenses
      for software, data, results, and open hardware.  They should
      also encourage formation of standards based around implemented
      Open Source systems and ongoing Open Source
      projects.</para></listitem>

    <listitem><para>Government policy should minimize the costs and
      difficulties in moving from research to deployment. When
      possible, grants should require results to be available under a
      commercialization friendly BSD style license.</para></listitem>

    <listitem><para>In many cases, the long-term results of a BSD
      style license more accurately reflect the goals proclaimed in
      the research charter of universities then what occurs when
      results are copyrighted or patented and subject to proprietary
      university licensing. Anecdotal evidence exists that
      universities are financially better rewarded in the long run by
      releasing research results and then appealing to donations from
      commercially successful alumni.</para></listitem>

    <listitem><para>Companies have long recognized that the creation
      of de facto standards is a key marketing technique. The BSD
      license serves this role well, if a company really has a unique
      advantage in evolving the system. The license is legally
      attractive to the widest audience while the company's expertise
      ensures their control. There are times when the GPL may be the
      appropriate vehicle for an attempt to create such a standard,
      especially when attempting to undermine or co-opt others. The
      GPL, however, penalizes the evolution of that standard, because
      it promotes a suite rather than a commercially applicable
      standard. Use of such a suite constantly raises
      commercialization and legal issues. It may not be possible to
      mix standards when some are under the GPL and others are not. A
      true technical standard should not mandate exclusion of other
      standards for non-technical reasons.</para></listitem>

    <listitem><para>Companies interested in promoting an evolving
      standard, which can become the core of other companies' commercial
      products, should be wary of the GPL. Regardless of the license
      used, the resulting software will usually devolve to whoever
      actually makes the majority of the engineering changes and most
      understands the state of the system. The GPL simply adds
      additional legal friction to the result.</para></listitem>

    <listitem><para>Large companies, in which Open Source code is
      developed, should be aware that programmers appreciate Open Source
      because it leaves the software available to the employee when
      they change employers. Some companies encourage this behavior as
      an employment perk, especially when the software involved is not
      directly strategic. It is, in effect, a front-loaded retirement
      benefit with potential lost opportunity costs but no direct
      costs.  Encouraging employees to work for peer acclaim outside
      the company is a cheap portable benefit a company can sometimes
      provide with near zero downside.</para></listitem>

    <listitem><para>Small companies with software projects vulnerable
      to orphaning should attempt to use the BSD license when
      possible. Companies of all sizes should consider forming such
      Open Source projects when it is to their mutual advantage to
      maintain the minimal legal and organization overheads associated
      with a true BSD-style Open Source project.</para></listitem>

    <listitem><para>Non-profits should participate in Open Source
      projects when possible.  To minimize software engineering
      problems, such as mixing code under different licenses,
      BSD-style licenses should be encouraged. Being leery of the GPL
      should particularly be the case with non-profits that interact
      with the developing world. In some locales where application of
      law becomes a costly exercise, the simplicity of the new BSD
      license, as compared to the GPL, may be of considerable
      advantage.</para></listitem>

  </itemizedlist>

</sect1>

<sect1 xml:id="conclusion">
  <title>Conclusion</title>

  <para>In contrast to the GPL, which is designed to prevent the
    proprietary commercialization of Open Source code, the BSD license
    places minimal restrictions on future behavior. This allows BSD
    code to remain Open Source or become integrated into commercial
    solutions, as a project's or company's needs change. In other
    words, the BSD license does not become a legal time-bomb at any
    point in the development process.</para>

  <para>In addition, since the BSD license does not come with the legal
    complexity of the GPL or LGPL licenses, it allows developers and
    companies to spend their time creating and promoting good code
    rather than worrying if that code violates licensing.</para>

</sect1>

<sect1 xml:id="addenda">
  <title>Addenda</title>

<programlisting>
[1] http://www.gnu.org/licenses/gpl.html

[2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/

[3] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books,
    2000. Quotes are from page 114, ``Effects of the GNU GPL''.

[4] In the "What License to Use?" section of
    http://www.oreilly.com/catalog/opensources/book/brian.html

This whitepaper is a condensation of an original work available at
http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm

</programlisting>

</sect1></article>