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.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Sunday, May 6, 2012

Copyrighting SSO (at least in APIs) Sure, you can rename, re-organize, and compile, iff ...

Another post on Groklaw:

If and only if Java had a macro-preprocessor like C, you could define a set of macros that mapped Dalvik APIs to Java APIs. And you could give Dalvik a macro-preprocessor, and write a set of macros to reverse the mapping, from Java APIs to Dalvik.

Of course, that not only fails to answer the question, but it also opens a whole new can of worms.

If you do such macro conversion, the combination of macro-preprocessor and the macro definition files will be just as infringing as the current Dalvik implementation is.

That is, if the jury says 10%, then the conversion macro-preprocessing stuff would have to be 10% infringing. Dalvik itself could be separated from the infringment arguments, but the macro-preprocessing stuff could not be.

But then there is that other can of worms, that I sometimes complain about. Lawyers would notice that the macro wall appears porous to them. They would miss the point of the conversion, and assume that macro-coated Dalvik infringes because Dalvik (even with deliberately different APIs) itself infringes, and pretty soon Oracle's lawyers would come after Ruby, Lua, and any other language more recent than Java, because all such languages can (in theory) be mechanically converted back and forth. One successful conversion, and it's offf to the races.

The reason software and other literature/fine art were supposed to be kept out of the patent pool is precisely this possibility of conversion. When you start abstracting things out to this level, everything becomes everything else. The patent with highest precedence is the dictator of the world, and, I'm not speaking metaphorically, I do mean the Constitutions of all Constitional government be damned.

Why am I suddenly talking about patents? Precisely because the argument about copyrighting APIs destroys the barrier between copyright and patent. Yeah. I mean that if you can claim and enforce copyright on APIs, in a few years some lawyer is going to twist that to the plots of novels, and so it goes.

If and only if we could get the lawyers to forever agree not to try to expand the claims on their patents, we could allow source code to be patented on the condition that changing one variable name must be considered equivalent to changing the shape or composition of one physical component, and that changing the compiler or run-time library would be equivalent to changing the physical implementation framework, and that changing the language would be equivalent to a complete re-implementation of the device in different technology, and completely beyond the claims of the patent. And the entire source code would have to be registered and published, just the same as the blueprints have to be registered in physically implemented patents.

Otherwise, you absolutely will open the door to abstracting away all barriers to frivolous litigation, and it's just a matter of time until the entire economy comes grinding to a halt under the burden.

And, now that you think about it, copyright is always a better fit for software than patents, when you place the proper requirements on software patents. The only real issue is how to protect a combination of software and machine, but even that is going to require a lot more specificity than is currently practiced, because a CPU can be used as a basis for arguments abstracting the patent out of the physical implementation.

Symbols are inherently abstract.

No comments: