Tuesday, October 8, 2013

"R" is for Remedy

The traditional definition of a contract is “offer, acceptance and consideration.”  I offer Seller $100 for a car.  Seller accepts; I hand over the money.  Seller is obliged to turn over the keys.

But what if Seller does not?
What if Seller hands over the keys to a vintage Yugo, rather than the ’57 Chevy I saw in the drive?
If I discover the car lacks an engine, an interior, tires, or I don’t like the color?
I need a remedy.
The contract outlined does not contain any remedies, let alone any warranties.  As a result, my only recourse is to the standard remedies provide by contract law:
Money damages. 
The “benefit of the bargain,” or the money I would have made had the deal gone through.  In this case, I am out the $100 I paid to Seller, but also planned to sell the car for a $500 profit.  Arguing whether Seller is liable for that $500 would enrich the lawyers for both sides.
Restitution.
Full return of the money or property given as consideration.  Regarding the car, Seller might simply offer to give me my money back.
Rescission.
The contract is set aside as the result of fraud, mistake, duress or undue influence.  Rescission would not be available in the car transaction, as described.  Money or other property given as consideration is returned.
Reformation.
The court rewrites the contract to correct errors or inequities.  Courts are reluctant to grant reformation, believing it is the duty of the parties to their homework before executing an agreement.  More, the parties are always free to rewrite their contract privately, without recourse to the courts.
Specific Performance.
The court orders one party to hand over the goods or perform the services specified in the contract.  Available only if money damages are inadequate – for example if the goods or services are not available from any other source.  Generally not available, however, in contracts for personal services, as courts regard compelling someone to perform work against his or her will to be too close to slavery.  Beyond that, who would want vital services performed by someone not committed to doing their best?
These remedies are often insufficient, at least in the context of an IT transaction.  Remedy is available only after the fact, generally after much litigation and is typically limited to money damages.  The advantages expected from a new system, such as reduced costs, increased productivity or competitive advantage, generally cannot be recovered, not to mention the value of the time employees might have spent trying to correct a faulty system.  To compound the loss, the costs of litigation generally cannot be recovered.

The statutory remedies, then, do little to address the needs of the aggrieved IT buyer, who needs a system that works, on time, and for the agreed price.  Thus the best remedy for a faulty system, or a simple disagreement with the vendor, is diligence in identifying the business need the new system will address, in designing the system and in setting an implementation plan designed to identify and solve problembs before the system enters productive use. 

Wednesday, September 18, 2013

Open Source - Reciprocal Licenses


THE FINE PRINT

Open Source – Reciprocal Licenses

Open source software is now a fact of life. The Apache HTTP Server software is an integral part of the Web, while Unix and its progeny are common Enterprise tools. Individual users may surf the Web via Mozilla Firefox, replace Microsoft Office with Open Office or Libre Office, and Ubuntu offers an alternative to both Microsoft Windows and the Apple OS. More, open source “software foundries” have proliferated, offering new programs and programming tools at little or no cost. Download, install and use.

If only it were that easy.

Open source” code is distributed under a license that permits users to freely access and alter the underlying source code; licenses for proprietary software, in contrast, routinely forbid such efforts. In addition, open source products are offered free of charge. It is an attractive proposition – good software, readily available (from the Internet) at little or no cost. However, while open source code may be “free,” in the sense that no licensing fee is required, but it is not “free” of legal restrictions. A variety of “open source licenses” have been developed by different members of the open source community. Open source developers are generally free to chose which license will apply when they make their products available to the public. Moreover, a program constructed from a variety of open source products could be subject to a number of different open source licenses. The license analysis can become rather complex.

One feature of open source licenses that causes concern is the “reciprocity” requirement, which provides that when open source code is combined with proprietary code, the resulting product must be released as open source. Such a requirement would be unacceptable to users who make their money licensing proprietary software.

But this description is overly broad. Only some open source licenses contain a reciprocity requirement; some do not. Perhaps the best known example is the GNU General Public License (“GPL”), version 2 of which provides:

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

b) 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.

Two things should be noted regarding this “reciprocity” provision:

  • It applies to works that one distributes or publishes, not works that one creates for private (in-house) use.
  • It permits one to publish proprietary products “along side” open source:
To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.
------- http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean (September 18, 2013).
A simple question remains: Does the benefit provided by a program governed by a reciprocal license exceed the costs of releasing the resulting product without charge and with no protection for the source code?


Per GNU, the current reciprocal open source licenses are:

  • GNU General Public License (GPL) version 3 (#GNUGPL) (#GNUGPLv3)
  • GNU General Public License (GPL) version 2 (#GPLv2)
  • GNU Lesser General Public License (LGPL) version 3 (#LGPL) (#LGPLv3)
  • GNU Lesser General Public License (LGPL) version 2.1 (#LGPLv2.1)
  • GNU Affero General Public License (AGPL) version 3 (#AGPL) (#AGPLv3.0)
  • GNU All-Permissive License (#GNUAllPermissive)
  • Apache License, Version 2.0 (#apache2)
  • Artistic License 2.0 (#ArtisticLicense2)
  • Clarified Artistic License
  • Berkeley Database License (a.k.a. the Sleepycat Software Product License) (#BerkeleyDB)
  • Boost Software License (#boost)
  • Modified BSD license (#ModifiedBSD)
  • CC0 (#CC0)
  • CeCILL version 2 (#CeCILL)
  • The Clear BSD License (#clearbsd)
  • Cryptix General License (#CryptixGeneralLicense)
  • License of the ec fonts for LaTeX (#ecfonts)
  • eCos license version 2.0 (#eCos2.0)
  • Educational Community License 2.0 (#ECL2.0)
  • Eiffel Forum License, version 2 (#Eiffel)
  • EU DataGrid Software License (#EUDataGrid)
  • Expat License (#Expat)
  • FreeBSD license (#FreeBSD)
  • Freetype Project License (#freetype)
  • License of the iMatix Standard Function Library (#iMatix)
  • Independent JPEG Group License (#ijg)
  • License of imlib2 (#imlib)
  • Intel Open Source License (#intel)
  • ISC License (#ISC)
  • Mozilla Public License (MPL) version 2.0 (#MPL-2.0)
  • NCSA/University of Illinois Open Source License (#NCSA)
  • OpenLDAP License, Version 2.7 (#newOpenLDAP)
  • License of Python 2.0.1, 2.1.1, and newer versions (#Python)
  • License of Python 1.6a2 and earlier versions (#Python1.6a2)
  • License of Ruby (#Ruby)
  • SGI Free Software License B, version 2.0 (#SGIFreeB)
  • Standard ML of New Jersey Copyright License (#StandardMLofNJ)
  • Unicode, Inc. License Agreement for Data Files and Software (#Unicode)
  • The Unlicense (#Unlicense)
  • License of Vim, Version 6.1 or later (#Vim)
  • W3C Software Notice and License (#W3C)
  • License of WebM (#WebM)
  • WTFPL, Version 2 (#WTFPL)
  • X11 License (#X11License)
  • XFree86 1.1 License (#XFree861.1License)
  • License of ZLib (#ZLib)
  • Zope Public License, versions 2.0 and 2.1 (#Zope2.0)
  • WxWidgets License (#Wx)
------ http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses (September 18, 2013).
Further Reading:

For a more detailed discussion of the definition of “open source,” see the Web site of the Open Source Initiative at: www.opensource.org.

Open source software presents issues other than reciprocal licenses. For a discussion of all those issues, see:
Intellectual Property Deskbook for the Business Lawyer, Third Edition; Intellectual Property Committee of the American Bar Association, 2013 (Chapter 11).

For a detailed discussion of reciprocal licenses, see: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses



Wednesday, September 4, 2013

Is Your Confidential Information Adequately Protected?

Commercial nondisclosure agreements typically provide that confidential information will be kept in confidence, provided only to employees who have a need to know and who have been informed that the material is to be protected. In the event an employee breaches confidentiality, his/her employer is expected to pay for any damages that result.

It is less common to encounter agreements that require individual employees to be personally bound by the duty of confidentiality. The reason given is a valid one – individual employees generally do not have the means to pay for the damages that can result from unauthorized use or disclosure of confidential information.

This approach overlooks two exposures:

1. An employer has limited control over the actions of an employee. They may fire him or her, but that may not be a deterrent if the employee believes he/she has something valuable to sell.

2. Disclosure of certain information, such as personal financial records, requires immediate action.

Money damages collected months later may not begin to restore a damaged reputation, or the cost of regulatory proceedings.

Consider requiring employees who receive you confidential information to agree, individually, to keep your information in confidence and to grant you the right to seek immediate injunctive relief against them should they breach that confidence.