Notes
Slide Show
Outline
1
Open Source Licensing:
Strategies and Tactics
2
Sabety +associates

  • Firm Overview:


  • A technology law and electronic media law practice based in New York City with an international clientele.


  • Top legal talent with extensive experience in engineering,  materials science, software, and media business affairs.


  • Services the needs of emerging technology ventures, ranging from software and e-commerce, through microelectronics to digital content production and digital media delivery.


  • Our clients rely on our strategic outlook that provides creative ways of reaching their goals.


  • Our our activities encompass early stage formation and funding of the venture, IP strategy, transaction planning, technology licensing, copyright licensing, patent and trademark matters.


3
Sabety +associates
  • Recent Projects:


  • Acquisition of the intellectual assets of a foreign software company;


  • Software licensing into a large telecommunications provider;


  • Development of a patent strategy in the crowded digital media field;


  • F.C.C. regulatory proceedings regarding digital television copyright protection.


  • Visit  www.sabety.net for more information.


  • Subscribe to our email newsletter, Technology Law and Electronic Media Update,
    • visit: http://www.sabety.net/news.html

4
Sabety +associates
  • We are called on to consider the Open Source licensing situation from a variety of standpoints:
    • Operator, e.g. Linux user;
    • Developer, e.g. software aggregator
    • Creator, e.g. startup considering open source strategy.
5
“Open Source” comes in varieties.
  • What is the purpose?
    • “Software wants to be free…”
    • “I don’t want to be sued…..”
    • “Cost of adoption is zero…..”
  • Different Open Source licenses address different strategic plans by the originator.
6
Read the contract:

anyone can create an open source type of license.
7
PHP and BSD license is to protect PHP and U.C. Berkeley:
  • THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE PHPDEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
8
GNU: Drafting Problems Increase Risk.
  • “You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”
  • “If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.”
  • “the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.”
9
Even the Lesser GNU threatens your trade secret.
  • “However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License.”
  • “you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.”
10
Risks of Open Source
  • 1. IP rights in the code gets all the attention.


  • But …. Don’t forget !


  • 2. Code functionality.
  • 3. Code Integrity.


11
Contextual Risk Profiles:
  • 1. Operator of the code.
  • 2. User of the code.
  • 3. Creator of the code.


12
Operator
  • Example: Big Co. uses an open source tool to manage its IT network.
  • What are the risks?
    • Infringement of the IP?  Probably low, but Big Co. has deep pockets and is inviting target.
    • Functionality? Controllable.
    • Security? More difficult.
13
Use of the Open Source code is typically less of an IP problem:
  • But beware: open source licenses may contain “pass through” licensing provisions.
  • SCO case teaches that the risk is not zero.
14
Creator of the Code
  • Example:  Smallco distributes a piece of code under open source license to promote their services.
    • IP rights? Larger risk: patent rights trump independent authorship. Liability scales with distribution.
    • Functionality? Low.
    • Security? Low.
15
Developer
  • Example:  Tech Co. uses open source modules to create product.
  • Issues:
    • Infringement of the IP? Higher. Downstream liability scales, and Tech Co. may lose control of their product.
    • Functionality? Low risk.
    • Security? Medium risk.
16
Its all about liability:
  • Can I guarantee that I own the IP?
  • Can I guarantee that it will work as intended?
  • Can I guarantee that it will not break, destroy or compromise the systems it runs on?
17
Pyramid Liability
18
Tension with software consumers:
  • Customers want to strengthen indemnities and warranties.
  • Code developers who have used open source modules have to be more vigilant.
  • Improve code quality assurance.


19
Code Development Management.
  • Police use of incoming code used in the project.
  • Have testing regimen in place as well.
20
Operator Strategy:
  • Choose lower risk projects for initial open source roll-out.
  • Require strong language in contracts for support, debug, quality assurance testing.
  • Invest in training staff to have familiarity with the ouvre.
  • Be vigilant about implementing security mechanisms to avoid a single point of failure in security.
21
Open Source Business Models.
  • Are there any?
  • The V.C. view:
    • “Something has to be proprietary.”
    • “Service businesses don’t scale.”
22
Open Source Hidden Costs:

  • QA costs money.
  • Certification of otherwise free code is valuable service.
  • Accurate documentation of source code is valuable tandem product.
23
To mitigate this, IBM says:
  • "We will guarantee the same [service-level agreements] for Linux that we do for proprietary OS’s," says Dan Frye, director of IBM's Linux Technology Center. "Response times, fix times, uptime—we'll sign all those same contracts for Linux.“
  • CIO magazine, March 15, 2003.
24
JBoss, Inc.
  • JBoss is to release software products for free but to charge for support, documentation, consulting and training.
  • “Our business model is the maintenance. We make money selling maintenance. Think of it as BEA but with no upfront licenses, only the maintenance part, which still is a [US]$250 million business for them.”
25
HP & IBM
  • Commoditize the OS (Linux)
  • Sell the services.
  • Sell the server.
  • Takes away OS adoption lock-in as an issue in a server farm sale.
  • Reduce software development costs.


26
Consider Real’s Helix product.
  • Open source media content management.
  • Open codec, open client.
  • Sort of open server.
  • Helix core will be a priced license at some volume.
  • Note: At last summer’s O’Reilly event, Richard Stallman is on record for saying Helix is not “open source.” So he was dragged off …
27
Consider: Outsourcing and Open Source.
  • How good is your “service” model if your code is open and someone else will service it at a fraction of your price.
  • We shall see …..
28
Open Source to Create Scaling.
  • Use open source to pursue rapid adoption, monetize later.
  • Open source in order to “commoditize the complement.”
  • Establish a certification or third party test is important to mitigate functionality and security risk.
29
Consider Monetizing Pass Through Product.
  • Crude Example:
    • Use and redistribution of this software for further use is free, provided that “use” means for academic research and product development purposes only.
    • Licensee shall only redistribute and sublicense subject to the same restrictions and permissions.
    • Developer shall be paid 12% of all gross proceeds of any kind from sale or license of a product developed using this copy of the software or any derivative or sublicensed copy thereof.
30
Enforcable?
  • Legally?
    Some commentators have challenged pass-through licensing provisions on anti-trust grounds.
  • Practically?  Depends. Patent rights help a lot.  How do you police it?
  • Still would require more substantial licensing covenants.
31
Is the world receptive to more complex Open Source agreements?
  • Depends on the cost-benefit tradeoff.
  • Greater complexity requires more strategic thinking about possible outcomes.
32
IBM’s Public License version 1.0
  • “its license agreement … states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange.”
  •  “("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") against any losses, damages and costs (collectively "Losses") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. “
33
More on IBM
  • “If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. “
34
Raising the stakes.
  • What is the strategy behind the license?
    • Destroy “pyramid liability.”
    • Beware: adoption of the license may hinder downstream company’s ability to enforce their patent rights.
    • Definitions of “Recipient” and “Contributor” appears to exempt IBM from the rule.
35
Sun Public License v. 1
  • More precision.
  • Very elegant document.
  • Contemplates a single license for all contributions, so no cascading documents.
  • More narrowly confines the covenant against patent suits to contributed code.
36
But remember: fancy contract terms don’t mean anything if the website doesn’t create a contract.
  • Click through agreements are enforceable only if the click through process properly “manifests assent to the terms.”
  • Opportunity to review the terms and decline.
  • Law more settled now than 4 years ago.
37
Conclusion
  • Building a business using open source software requires consideration and care.
  • Its not cost-free.
  • Roll your own open source license.
  • Avoid licensing pitfalls buried in the document.
  • Get legal advice for your specific situation.