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

Power consumption

Apparently Punix consumes almost as much power when it's powered off as TI-AMS does when it's powered on and idle. :(

Punix draws about 6 milliamps when it's powered off, compared to the 90 microamps that TI-AMS draws (this means that Punix lasts about a week on a set of fresh batteries, while TI-AMS lasts for months). Punix also draws about twice as much current while powered on and idle: 16 milliamps versus 8 milliamps. The "busy" current draw is the same for both: about 32 milliamps.

Clearly something is drawing about 6 milliamps more in Punix than in TI-AMS (I suspect the LCD screen draws about 2 milliamps when it is on: 6+8+2=16). Tracing through both systems in TiEmu showed that both execute almost the same code while powered down. Both systems wake up once per second (to update the system clock) and execute about 500-600 CPU clock cycles before putting the processor back to sleep. As the CPU is active for only 0.005% of the time, I doubt it is responsible for the (relatively) high power consumption.

I need to see how much current PedroM draws in each case, and if it's low like TI-AMS, I'll have to see what it does during idle periods that Punix doesn't (or vice versa).

Update: PedroM draws almost the same amount of current as TI-AMS in all cases. I modified the cpupoweroff() function in Punix to look more like PedroM's Trap #5 handler (which is used for turning off the calculator), and now Punix draws nearly 120 microamps while powered off. This is still about 33% higher than either PedroM or TI-AMS, but it's much better than before. The current draw while Punix is powered on and idle is still about 16 milliamps. I need to change more stuff to reduce that figure; perhaps my Int 1 handler is too heavyweight.

Gopher site

I have a new Gopher site with TI calculator stuff!

If you have a Gopher client or a browser that supports Gopher, visit gopher://christop.mooo.com/ now!

If you have a lame browser (such as IE) that doesn't support Gopher, visit http://christop.mooo.com:70/ now!

If you want to add Gopher support to your browser, install the Overbite plugin for Firefox/Seamonkey or Chrome, then you can browse Gopher sites directly, without Web gateways.

Why do I have a Gopher site?

I use Gopher because it's simple and easy to publish hierarchically-organized content (primarily text files) and link to other sites—Web sites, other Gopher sites, or even FTP sites.

It's simple like FTP but better. It's organized like an organized Web site but simpler, because I don't have to mess around with graphics and style sheets and all that fancy, superficial stuff. I can just write a text file and an optional description for it, and it shows up on my site where I put it.

Lately I've been using the site for publishing Punix and other calculator-related project design documents. I've quite a few documents that I've not published anywhere else, so if you want to see some Punix designs happen before they happen anywhere else (if they ever do), you know where to go!

Beta 5 is released!

More than a year after the last release, I'm happy to announce the release of Punix beta 5!

All files: http://sourceforge.net/projects/punix/files/betas/

TI-89: punix-89-beta5.89u
TI-92+: punix-9x-beta5.9xu
Source: punix-beta5.tgz

New section in the README file:

What is new in Beta 5?

This is the first beta to run on real hardware! I am currently running Punix on my TI-92+. It's still highly incomplete, but the hardware drivers have been proven to work correctly on the Real Thing. As a real calculator has limited power (batteries), this release now supports power-off with the key combinations 2nd-ON or Diamond-ON.

This beta also includes a short clip from The Blue Danube Waltz (to demonstrate the audio capabilities) as well as preliminary grayscale support. The console font has been anti-aliased to take advantage of this new grayscale support.

For those who are interested in running this release on their own calculator, here are some quick installation instructions. First make sure that you have a GraphLink cable (or a homemade variant) and TiLP installed on your computer. TI-Connect might work as an alternative to TiLP, but I've never used it so I can't say whether it works.

1. Start TiLP and navigate to the directory that contains the .9xu/.89u file.
2. Pull out one of the calculator's batteries.
3. Reinsert the battery while holding the APPS key until the bootloader screen appears (It will say "Press I to install product code...").
4. Press "I". The bootloader should say "Waiting to receive..."
5. In TiLP, drag the appropriate .xxu file from the computer side to the calculator side. If you have a TI-92+, drag the .9xu file. If you have a TI-89, drag the .89u file. (Sorry, only these calculators are supported currently.)
6. Wait for the transfer to complete. This should take a couple minutes.
7. Punix will automatically boot after installation.

If the transfer fails, you may have to repeat step 5, or possibly steps 2 through 5.

Please be aware that Punix does not have an "Auto Power Down" (APD) feature yet, so you will have to power down the calculator with 2nd-ON when it is not in use.

How to install Punix on a calculator

I've gotten some interest and questions lately about installing Punix on a real calculator. Note that I have not yet uploaded a new version of Punix that will run properly on a real calculator. I will try to get the latest fixes and a new build uploaded sometime this week. Also note that Punix is experimental and incomplete. I cannot be held responsible for any damge it might cause to your calculator, no matter how unlikely that is. It hasn't damaged my calculator, and I haven't gotten any reports that it's damaged anyone else's calculator, but you have been warned.

Here's a short FAQ for those who want to try Punix on their calculator:

Q. Does Punix wipe the factory default OS?
A. Yes, Punix replaces the existing OS and all user files. However, you can download a new version of the TI-OS from http://education.ti.com if you decide to go back to the original OS.

Q. Which calculators does Punix run on?
A. Punix currently has the best support for the TI-92+, since that is the only TI-68k calculator that I own, but I will upload versions of Punix for the TI-92+, TI-89, TI-89 Titanium, and Voyage 200.

Q. Will Punix run on the TI-Nspire?
A. Nope. The TI-Nspire has completely different hardware than the TI-68k series. I don't have much interest in developing for the TI-Nspire anyway, so somebody else will have to port Punix, or maybe even a port of Linux, as the hardware seems to be capable of running Linux.

Q. How do I install Punix on a calculator?
A. You will first need to have a GraphLink cable (or a homemade variant) and TiLP installed on your computer. TI-Connect might work as an alternative to TiLP, but I've never used it so I can't say whether it works. Pull out one of the calculator's batteries and, while holding the APPS key, reinsert the battery. Keep pressing the APPS button until the bootloader screen appears so that it says Press I to install code... (it shouldn't take more than a couple seconds for the bootloader to appear). Press "I", and then in TiLP drag the appropriate .xxu file to the calculator. For example, drag the .89u if you have a TI-89 or the .9xu if you have a TI-92+. It will take about a minute or two to transfer and install Punix. Once it is installed, it will automatically boot into Punix. Be aware that Punix does not have "Auto Power Down" (APD) yet, so you will have to power down the calculator manually with 2nd-ON.

First time real calc!

I've been hesitant, until now, to install Punix on a real calculator, but I have finally done so. Here is a photo of my first test on a real TI-92+:

I was pleasantly surprised that it booted and functioned very much as it does in TiEmu. The grayscale is very slightly flickery, but it's tolerable. However, there are a few differences or glitches:

• Address error exceptions do not work. This exception works flawlessly in the emulator. All other exceptions work fine (eg, illegal instruction, division by zero, etc), so I have to figure out what's wrong with this one exception.
• LCD does not shut off with ctrl- or alt-ON. A single dark blue or black row of pixels stays on the screen, every time in a different row. The screen also fades back in weird when I turn the calc back on. I probably just didn't write to the LCD register(s) properly.
• Last, and perhaps the most worrisome difference, the clock speed is way off. A short timing indicates the calculator is about 33% too slow. The interrupt that should fire once per second (int 3) fires about 2 times in a 3-second period. The supposed 256-Hz (int 1) and programmable timer (int 5) also run proportionally slower, ie about 170 Hz and 5461 Hz (this should be 8192 Hz for audio). My batteries are fresh, and I'm fairly sure that I have a HW2 92+; Punix crashed badly in HW1 mode in TiEmu, so it'd probably crash on my real 92+ if it were HW1. Grayscale also wouldn't work correctly either.

This is a good start, but now I have a good sense of what needs to be fixed.

Update 2012-03-09: I have fixed all issues but the address error exception. Turns out I incorrectly wrote to the screen's hardware registers to shut it off, and the register that controls the OSC2 rate was set incorrectly. Grayscale is also less flickery as a result of fixing the rate, and audio output sounds just as good as it does in TiEmu (that is, like garbage :)).

Floating point, grayscale, scheduler, audio, and PS/2 keyboard?

While I haven't posted any updates lately, I've been working on Punix and occasionally posting my progress on the Cemetech forums.
I have also had family issues for the past few months now that have taken much of my free time.
Here's a summary of what I've done since last time:

• M68881 FPU emulator is still under development, but a few instructions work well so far: fmove, fadd, fmul, fsub, fabs, and fneg. Execution speeds for fadd/fsub and fmul are faster than the equivalent operations in PedroM (which uses a slower BCD floating-point format to be compatible with TI-AMS).
• Four-level grayscale! Currently only HW2 is supported, but that's probably more common than HW1 anyway. Text glyphs are also anti-aliased to take advantage of grayscale.
• The scheduler has been tested quite thoroughly by now. I recently stress-tested it by running a few dozen busy processes at various "nice" levels, while also playing audio. Surprisingly, playing audio at the base nice level (zero) with 43 busy processes resulted in smooth, skip-free sound.
• I'm playing with the idea of adding a PS/2 driver which will allow a user to plug a regular keyboard into the link port (with an appropriate adapter) and start typing away on it. This is a low-priority feature, but I'm the most excited about it at the moment.