Why We Still Oppose UCITA

Vagueness, inapplicability and measures that fall short—why we need to start fresh.

An attorney for Red Hat recently asked me to join her in requesting that the National Commissioners on Uniform State Laws (NCCUSL) reverse their 1999 decision to adopt UCITA, the Uniform Computer Information Transactions Act.

I've commented before on UCITA [see LJ, June 2002]. Readers of this column will recall that UCITA is a model code intended to be adopted by all states, so there is uniformity within software licensing law. UCITA provides default rules that apply when a software license omits essential terms. Another purpose of UCITA is to define what license terms are against public policy and thus cannot be enforced, even if they are included in a license.

On behalf of the Open Source Initiative, I wrote to the NCCUSL to oppose UCITA. I did so because UCITA does not address yet many of the major concerns of licensors and licensees of open-source software. Even though recent amendments to UCITA have begun to recognize our unique issues, the proposed law remains flawed, incomplete, confusing and biased toward licensors of proprietary software.

The drafters of UCITA have proposed several amendments to address our issues, but they still struck out with us. Here's what they proposed and why we continue to oppose it.

One recent amendment provides that “a copyright notice merely giving permission to use the software that is not part of a contract is not within UCITA.” This either is a truism (federal copyright law preempts state contract law anyway) or is inapplicable to the many open-source licenses intended to be contracts. I understand that this amendment purports to address the concerns of people using the GNU General Public License (GPL), a license whose author urges that it be treated exclusively as a copyright license. What about all the other licenses that satisfy the Open Source Definition (www.opensource.org/docs/definition.php) and whose authors intend to form a contract? This provision is of no help; it simply does not matter.

Another amendment excuses licensors from implied warranty obligations “if the software is free (no intent for profit or commercial gain from the transfer of the copy or from controlling use or distribution of the copy).” This amendment relies on a commercial definition of “free” as “free of charge” rather than the far more important conveyance of rights to use, copy, modify and distribute software, along with access to the source code that makes those rights meaningful.

The latter concept of freedom underlies the principles of the Free Software Foundation (www.fsf.org) and the Open Source Initiative (www.opensource.org), but it apparently plays no role in UCITA. The actual language in the UCITA provision is vague and confusing, relying as it does on phrases like “intends to make a profit” and “acts generally for commercial gain”. It will allow proprietary software vendors who hide their source code and limit the rights to copy, modify and distribute software to obtain the benefit of warranty exemptions, even though they actively obstruct their customers' ability to make the software “merchantable” and “fit for a particular purpose” by doing so.

A third amendment says reverse engineering for the purpose of interoperability cannot be prohibited by a license. This is an important step—albeit a baby step—toward affirming the fair use rights so badly damaged by the passage of the Digital Millennium Copyright Act. Unfortunately, because of federal preemption this provision is probably of limited effect. Furthermore, this idea is not the same as a strong statement by NCCUSL that a license provision that restricts or limits any fair use rights to software is unconscionable and against public policy. Such a broad provision would not solve the preemption problem, but it would make a valuable statement that may encourage Congress to restore the public benefit objectives that underlie copyrights and patents in the US Constitution. I am afraid that the current weak and limited UCITA amendment relating to reverse engineering will lull people into thinking that their former rights have been restored.

I believe that it will be important to start afresh with UCITA and consider the new environment in which open-source software competes against proprietary, closed software marketed by wealthy companies. UCITA is not particularly helpful to guide courts in interpreting or enforcing open-source licenses or to guide Congress in restoring fair use rights to the public. Without that, the Open Source community doesn't need UCITA.


email: lrosen@rosenlaw.com




Comment viewing options


Re: Why We Still Oppose UCITA

Anonymous's picture

I really think open source has nothing to do with licensing

terms and conditions. It could be open source but still have

licensing that precludes distribution of modifications. But

the one point that should be prominent is that if the user

is required to pay licensing fee of any kind, than a

warranty of like kind is justified. If it is free for use

upon download, with no charge for download, then no

warranty of fitness for use or support should be required.

This is probably a groundbreaking concept but I propose

that terms and conditions of warranty and liability be

restricted to commercial transactions. So if you download

apache source code and install and run, you have no support,

and no recourse if it causes any problems. But if you pay

for commercial versions of apache, then you should expect

support from the company you paid. This is all fair and


However, Microsoft sells their products with no recourse

if it doesn't work and no support for it either. You

have to pay extra for tech support. And even if you pay,

there is no guarantee that it will work. So why should free

software be held to a much higher standard than the

expensive commercial stuff that has no guarantee of anything

regardless of how much you pay for support?

Re: Why We Still Oppose UCITA

Anonymous's picture

The way I see it is that if the current form of UCITA passes, free as in no cost software will be fine and the no warrenty clause of the GPL will be fine, but it's the Open Source software that costs money that I'm worried about. In the eyes of this bill that would fall under commercial software, and as such the no warrenty clause of the GPL would be invalid for this kind of thing(like Mandrake Prosuite or any boxed Linux, or WineX, etc). And what about odd things like Darwin BSD that are both no cost and cost money depending on what you want?

UCITA needs to be thrown out and completely redrafted, I can't think of any other way it will be made to be fair. There is no way it can be ammended that much and still actually make sense to law makers.

Re: Why We Still Oppose UCITA

Anonymous's picture

If you are going to charge money for a product then you should be resposible for how the product works. I don't understand how software companies can say that it is their product and then say that they are not responcible when their product screws up. My biggest complaint about Micro$oft is that they don't take responsiblity for their products.

Re: Why We Still Oppose UCITA

Anonymous's picture

The idea is that when the customer gets the source, he can:

1. see if it really meets his requirements.

2. fix any problems

and (the most important part):

3. break the software himself.

Hardware (e.g. harddrives) come with "Warranty void if removed" stickers over the screws, so that if you get to the internal parts, you don't get any warranty. We try to expand the same idea to software, so that when you get to the internal parts (source) you don't get any warranty. However, the source to a GPL program cannot be placed under a sticker, people can get it from anywhere. So there is only one way to do it: If source is available, you don't get any warranty.

Re: Why We Still Oppose UCITA

Anonymous's picture


What kind of logic are you using to justify this statement? The mere possession of the source code for a particular application does not void a warranty since only changing the source code for the application be considered tampering - using your anology to hardware. Some users never look at the source code, but they should have the right to examine and even alter the source code should they so desire.



Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar



Learn More

Sponsored by Storix