Was Microsoft Built on Stolen Goods?
eetimes.com
eetimes.com
You can read the promised report here, though: http://www.embedded.com/electronics-blogs/say-what-/4442498/...
[1] http://thenextweb.com/insider/2016/08/08/theres-a-200k-rewar...
http://www.cpm.z80.de/source.html
and MS-DOS v1.1
https://github.com/BlastarIndia/msdos
available for some time, and given that there's sort of always been bad blood between DR and Microsoft, I'm going to go with 'no' being the answer here. DR would be suing. Hell, if I were Microsoft's legal team and if the answer isn't 'no' I'd be crafting up a scary letter involving libel.
http://www.marketwired.com/press-release/zeidman-consulting-...
Whether APIs can be protected is the core of long legal feud between Oracle-Sun and Google over Java APIs used in Android.
Oh, and if system calls were copied, MS should be reminded that they supported Oracle's claim that APIs should be copyrightable... Sitting on two chairs much?
A good example of this kind of thing can be seen in how copyright law deals with executing programs. Suppose you have a copy of a copyrighted program on your hard disk. You tell your computer to execute it. To do that the computer reads the program from the hard disk and writes it into RAM.
Most people would say that a copy of the program has been made in RAM. That naturally leads to the question of the copyright status of that copy, and what, if any, permissions you should need from the copyright owner in order for making that copy to be legal.
It seemed apparent to most (including the majority of people in charge of writing copyright laws...) that if you are the lawful owner of a copy of a program you should be allowed to make a copy of that program in RAM in order to execute it. The question, then, is how to fit that in with copyright law.
There are at least a couple of ways to approach this.
1. Define it as not being a copy, and therefore out of scope for copyright law.
2. Acknowledge that it is a copy, but make an exception to the copyright owner's exclusive right to make or authorize making of copies.
The problem with the first approach is that it adds complexity to a layer of the law that it is really nice to keep simple. In law, like in many other fields, keeping the base simple and putting the complexity in upper layers leads to things being easier to understand, and easier to modify and fix without unintended consequences. It generally works out much better to keep the lower layers simple, especially the definitions of terms in the lower layers.
In the US they went with the second approach. They added an explicit exception to the copyright owner's rights that covered programs (17 USC 117).
A very similar argument could be made for APIs. 17 USC 102, Subject Matter of Copyright, is pretty simple:
Copyright protection subsists, in accordance with this
title, in original works of authorship fixed in any
tangible medium of expression, now known or later developed,
from which they can be perceived, reproduced, or otherwise
communicated, either directly or with the aid of a machine
or device.
It seems like an API would qualify under that. There is another part of 17 USC 102 that does put a limit on the part I quoted above: In no case does copyright protection for an original work of
authorship extend to any idea, procedure, process, system,
method of operation, concept, principle, or discovery,
regardless of the form in which it is described, explained,
illustrated, or embodied in such work.
One could argue that APIs fall under this, but it is not at all clear what aspects of an API are the ideas, procedures, etc., and what parts are not. We'll end up having to contemplate the difference between a thing and the name of a thing.It's the same problem as I described with copies on RAM. 17 USC 102 is part of the lowest layer, so should be kept simple, and so one can make the same argument that things are cleaner and safer by keeping an expansive interpretation of 102 and using fair use or something else at a similar level to authorize API copying for compatibility.
One of Microsoft's points in their brief when they asked CAFC to take the appeal was that this was the approach of prior courts that dealt with copying API elements for compatibility. They did not rule that APIs were not copyrightable. They instead found exceptions that limited the copyright owner's rights in the case of APIs and compatibility.
Argument against copyrightability of APIs is their different, more abstract nature than actual programs. I.e. they are meta information, rather than information itself. It's like abstract function vs function implementation, or idea vs its actualization. EU courts got it right, and they declared APIs explicitly uncopyrightable.