February 22, 2013

Copyright and software licenses

I'm going to take some time out from anything directly related to Punix to pose a discussion and some questions about copyright law and software licenses. This is kind of a follow-on to a (somewhat off-topic) discussion I had on Cemetech about software licenses as they relate to TI calculators.

(NB the following discussion focuses primarily on copyright and contract law in the US. Other countries have other laws, but I am not as familiar with the laws of other countries.)

Now, some members of Cemetech seem to believe that a license is necessary for using a piece of software. Some seem to believe that a piece of hardware (or a digital certificate in the memory of a hardware) is equivalent to a license to use the software. Some also seem to believe that, because the software is freely available directly from TI, the software can be freely redistributed by owners of the piece of hardware that it was preinstalled on or designed for.

First, is a license really necessary for using a piece of software? By "using" software I refer to practically anything up to but not including copying the software for others to use. So, is "using" software one of the exclusive rights granted to the owner of a copyright? If you say yes, then please back up your assertion with a reference to relevant statutory or case law.

Second, is a hardware device recognized by the legal system as a "license" to use or redistribute the software on that device? If a license is not needed to use the software (as I assert to be the case), then the status of the hardware as a license is moot. What about redistributing the software? Since the software on the device is copyrighted, redistribution requires an actual license from the copyright owner to grant that permission. Neither a hardware device nor a digital certificate stored on that device constitute permission to redistribute the software stored on that device, so what is the hardware/certificate a license for? What permission does it grant an owner of the hardware?

Third, I don't really think the last point deserves discussion, but I'll try anyway. I feel that I covered most of it already. Software that is distributed by the owner of a copyright, or by one of its licensees, cannot be redistributed without a license from the copyright owner. It does not matter how much or how little the software costs to purchase (or even free). It's as simple as that.

Imagine, if you will, that you buy some software and discover that it did not come with an End User License Agreement (EULA). What rights would you have with that software? Can you legally install and use it? Can you make a backup copy of it? Can you legally sell it? Can you legally make and sell copies of it? The answer to all questions but the last is yes. Without a license from the copyright owner, you have the right to install and use the software. You have the right to make a backup (or "archive") copy. You also have the right to sell the software—again, the one and only copy that you own; you can even sell the single copy that you made for archival purposes, after destroying the original copy, of course. This right is established by the First Sale Doctrine. You do not have the right to make and sell copies of the software. Then what rights does an EULA actually grant you?

What if a piece of software "requires" you to agree to the terms and conditions of an EULA before you can install the software? Remember, an EULA is not really a license but is really a contract. A license grants permission to do something that is not otherwise allowed in its absence. A contract must be signed before its terms and conditions go into effect. Clicking on "I agree" or a similar action constitutes agreement (I believe case law recognizes it as equivalent to a signature, but it is weaker because it is more difficult to prove), so you would then be bound by the terms and conditions of the contract, even though you get nothing in return by agreeing to most EULA's. Since copyright law explicitly allows software end-users to install and use software without the copyright owner's permission, I argue that signing a contract is not actually legally necessary in order to install and use that software. The EULA page in an installer is a technical measure designed to coerce a user into agreeing to it and binding himself to its terms and conditions. What if the EULA were bypassed completely without agreeing to it? It may be possible to install the software by manually copying files from the installation media to a computer's secondary storage device, for example. This is a technical issue rather than a legal issue. Also, I do not believe that the DMCA has any anything to say on the matter of bypassing the EULA because it is not a copy-protection mechanism.

I'm probably going out on a limb with this analogy, but bear with me. Suppose you wanted to visit a public park. All parts of this park are accessible to the public. When you arrive, a man is blocking the entrance of the park and presents you with a contract that you "must" sign before you can enter the park. The contract restricts your access to certain parts of the park which are normally accessible to the public. The man "looks" official but presents no proof of his authority to restrict access to the park or to predicate its access upon signing a contract. What should you do? Simply step past him. He may put up a fight and be extremely adamant about signing the contract (just as an installer makes it technically difficult to install the software without agreeing to an EULA), but you are under no obligation to sign a contract to do something you already have the right to do.

One argument put forth is that, since a copyright owner "owns" the software, they have the right to dictate how and under what conditions the software may be used. This is both true and false. It is true because the copyright owner is allowed to present a contract before the sale of the software, and the purchaser can either decline and not have the software or accept and have the software. It is false because the copyright owner has no right to restrict access to the software after the sale (though this doesn't stop most software people from trying). Once an end-user has purchased the software, they have the right to install and use it.

"But the end-user didn't buy the software. They only licensed it." Rubbish. This is an oft-repeated statement (usually by the software's copyright owners themselves), but it doesn't become more true the more it's said. It is true that a contract is in force during the purchase of most commercial off-the-shelf (COTS) software, but it's not the EULA. Instead, it's a contract of sale. This is an implied contract—recognized by case law—between the seller and the buyer. The copyright owner is not a party in this contract. Once the buyer and seller have fulfilled their obligations (the buyer pays the agreed amount and the seller gives the product to the buyer), the buyer becomes the owner of the software (not the owner of the copyright on the software but of a copy of the software). The buyer may then exercise his rights to install and use the software. The copyright owner is not involved in the sale in any form (other than being the copyright owners of the software being sold, which has no bearing on the sale).

Alright, so back to Punix....

I'm sad to say that I have spent very little time working on Punix since last September. I actually spend most hours of my day working on Linux on embedded devices at my job. I can take only so much low-level hacking in a day! And yes, I have had to dive into the Linux kernel itself to find and fix a bug. I fixed a bug in the bflt executable file loader which was triggered when the executable file (in an execve() call) cannot be loaded due to a shortage of memory. This out-of-memory condition is detected after the child process of a vfork() has released its memory resources, which puts the parent process back on the run queue. Then before the child user process resumes from the execve() system call, the parent process runs and smashes the child's stack. The next time the child process gets a time slice, it returns to a corrupted stack and promptly dies from an illegal instruction exception (SIGILL) or a bus exception (SIGBUS), presumably because the return address on the stack points to an invalid memory area. I just love working in a NOMMU environment!

(I can imagine, but didn't test, a different scenario in which a non-vfork()ed process fails to run execve() under the same conditions, but I think the process also would have released its own memory resources so that its memory no longer belongs to it and could potentially be reallocated to other processes. This could also lead to a crash in the best case or to silent data corruption in the worst case.)

By the way, this particular embedded system runs on a Motorola Coldfire CPU, which is a direct descendant of the M68000 processor that is found in the TI-68k calculators. It has fewer (simpler) addressing modes, its exception handling is different, and it has a number of other differences, but its instruction set is nearly identical to the M68000's. This similarity was very useful as I was debugging the kernel. (Actually, I've found that my experience with Punix has been very useful for a good portion of my job so far.)

I'm just amazed at how much can fit into 8MB of RAM on that system (full networking stack, web server with SSL, NTP client, FTP server, etc). I can only hope to fit some of those features into 256KB of RAM!

Somewhat recently I started working with an ARM-based system with 64MB of RAM and an MMU (hooray!), but it's just not as exciting. Debugging our software has become too easy. Program crashes don't bring down the whole system anymore. Oh well. I'll get by somehow. :D

No comments: