My Best Teaching Is One-on-One


Of course, I team teach and do special lessons, etc.


But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.


It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.


Thursday, July 15, 2010

implementation constraints and software patents

I posted this on Groklaw, in response to some who were bringing out the Turing argument without thinking about it. I'll post it here, too, with some editing and comments: 

PHBs use the Turing Machine argument to justify using cheap CPUs (or simply the CPU "everyone else" is using) in applications those CPUs are not appropriate for.

There is a logical equivalence between CPUs, but the equivalence breaks down somewhat in the real world, where time and memory are ultimately limited.

And then the PHBs can't figure out why the project gets mired in engineering time working out tricks to somehow squeeze enough juice out of said CPU to get at least the most important features of the application to work.

And then they want to recoup the excessive costs of development (that could have been avoided, if they had been willing to use a better CPU) by getting patents on the inventions from the work.

And then, once they have the patents, it's all too easy to think that the patents must apply to any machine that does the same thing, not just to the tricks they used to get their functions running on the hardware they were stupid enough to choose.

This is precisely the reason patents are supposed to be specific. They are supposed to allow control over what has been invented, but not allow the limited control to monopolize the entire market.

Historically, there were a few cases where the patented invention was new and opriginal enough that it seemed to be reasonable to allow the patent (for the limited lifetime of the patent) to virtually monopolize the market for a particular kind of product. Those were supposed to be exceptions. Rare exceptions.

But everyone thinks (without thinking of the consequences) that it's unfair that their patent doesn't get the same treatment. Well, at least in physically embodied patents, the issues with freedom are obvious enough to keep the "It's unfair!" arguments at bay. Or, the issues were obvious enough for a long time. Apparently, the issues are no longer so obvious.

So, the PHBs have succumbed to the siren call of the illusion of monopoly control, and they sue the living daylights out of the market, and the profits from the suits is what enables them to put sell the product at the originally specified price that assumed that the cheap CPU would do the job without the extra development.

And their cheaper product (cheap by unfair means, mind you) now takes over that piece of the market on price instead of actual performance or other merit. (Two monopolies for the price of one, you could say.)

(You wonder what wonderful things could have happened, were the intel CPU not strangling the desktop, market? and now parts of the server and high-performance markets? Someday, maybe I'll have the time and resources to show you. It's hard to explain in the present market where people can't see the future for the marketing schemes of the rich and famous. If not, well, this world has a history of regularly rejecting the better way, so it won't be the first time.)

I'll personally accept the idea of software patents when the patent applications include the source code and hardware specified and the claims are limited to the specified source code and specified hardware and the specified combination thereof.

But patents on source code itself get really tangled up in the fact that source code is automatically transformed. It's hard to set boundaries on the transformations that are covered without being either overly restrictive or overly broad.

And that's why copyright makes more sense for source code. The way it should work is that there should be a copyright on the source code and a patent on the hardware and on the hardware combined with the source code. That is, the patent claims should only be for the hardware and the hardware+source code, and the claims on the source code itself should be copyright claims only.

Thus, dealing in the hardware is controlled by the patent on the hardware. Dealing in the software is controlled by the copyright on the software. Dealing in the combination is controlled by the patent.

Then software functions can be re-implemented (using clean-room techniques where necessary) for other hardware without infringing the patent, and this is as it should be.

I suppose the law may be missing a way to tie patent claims to copyright claims, if so, that is where the law should be changed, but we must be careful to avoid allowing the tying to defeat the intended limits on both patents and copyright.

Otherwise, there is no way to avoid being over-broad.

No comments: