The EFF is leading an effort to ensure computer APIs are not copyright eligible. When I read the post on Slashdot, I thought it was a good idea. As I read the notice on the EFF’s website, I realized, there are substantive ideas behind the effort. It seems that 77 computer scientists, many of which are leading thinkers in the field of computers, are collectively saying that copyrighting computer API is not a good idea.
Several parties are involved in the matter and I have absolutely nothing to say about that because what is important is the concept itself. The question is, should computer API be copyrighted, patented, etc.? Let’s look at the related questions. The questions related to this in terms of societal imperatives is centrally pertinent. During my thinking on this, I realized 3 questions to explore related to this issue.
Questions Related to Should Computer API be Copyrighted
Several questions in this matter are universal concerns in terms of creation. They form the elements that determine how important the main question is and what the answer might be. Those questions are:
- What does the creator of a work, expect of their work?
- What is the value, if any, owed to the creator of a work when they share that work?
- When a creator discloses work, do they control the work?
None of us can reasonably say as to the extent of value a person places on their work. What we can say is that computer based works of a functional nature requires a level of effort that implies purpose in the work’s creation. The author of a computer based work, namely, computer software or hardware, has a purpose to the work. Some computer software not publicly disclosed in any form may have been created for purposes of exploratory research or self-fulfilling activity. We can observe, however, most works disclosed publicly, particularly in the medium of publications (technical literature for example those that teach use of an API) and most especially the Internet are expected to be shared and used fully by those granted access to those works. Access, once granted, cannot practically be revoked nor qualified due to the nature of the exchange and usage medium. A reasonable expectation, is that the transparent nature of computer networks and computer storage (volatile and persistent) warrants an inherent expectation that information openly shared is made available without qualification except as to limit more restrictive qualification. It means that information residing in a naturally none-encrypted state, once shared in that state by the author(s), past or present, becomes integrated in the wider body of work in the public domain.
All work has value and the nature of exchange determines the magnitude of value as perceived by the parties in an exchange. Value does not have to be based or defined by financial currency. It can be something else altogether. Privately, the value that the author of a work derives from work not publicly disclosed is manifold and is usually conceptual, or self-gratifying, or otherwise personally utilitarian. Work shared publicly in terms of computer based software does deserve just a single measure of value. Attribution. The value of work in a medium of disclosure (namely the Web) means that the value owed to the author is to attribute the origination of that work to the appropriate author. This though is not critical enough to serve as the basis for financial remuneration when those disclosing have disclosed to a general audience implied in their choice of distribution medium (say the Web). The arguments for financial remuneration would center on scarcity which does not apply largely to works described in this context, ever presented in an unfettered distribution medium. Instead, those who create a work should derive perpetual recognition of their role. More specifically, it may be worth considering the support model for software as a basis for remuneration.
I have implied where control exists in this discussion. It is indeed dependent on scarcity of the resource created. A computer API is a resource. It is a conceptual resource made substantive by the processes it represents and reflexively by the underlying activities that underlay the API. The fundamental nature of an API, explicit in what the acronym means, is that it exists to be known. If theoretically, the processes that underlay an API could be hidden or made fully opaque, the named entries to those underlying processes would still need to be known if the API is to be, an API that serve to allow other computer software to access it as a gateway to those processes. I say theoretically, because hidden processes in computer software is not proven to be possible in the entire span of decades digital computers have existed. That is to say, the nature of computers as inherently mathematical constructs of a fully rational nature means that all processes can be known depending on requisite knowledge the encoding and structural mechanisms in operation. API then known entries to these processes that are themselves inherently knowable and thus the span of control is severely limited compared to equivalent physical-mechanical representations.
My Own Use of Copyright in Software
Much of code I have published on this blog and others (MG Tech, Open Tech, and MG on GitHub) I have assigned copyright. I did so not for the virtues of copyright related to software but to leave no ambiguity as to my intent how others may use such code. That is to say my intent is to permit others to use the code in such a way that does not cause downstream users from being restricted in the use of that very code. If it is decided that copyright is inapplicable to software code that could establish the assumption that software code is not restricted in use. Particularly as API in which other code has to communicate through the API and the software has to communicate with other code’s API. This symbiosis among code is inescapable. That and other points related to software is something I understand inherent to my past and present practice of constructing working code that is fully dependent on correct implementation and existence of system and application technical interfaces. I cannot, in principle, adopt a philosophy of restricting other’s use of code I issue as I am the beneficiary of publicized information (books, articles, seminars) and the transparent structure of computer systems without which defining systems may be far less achievable.
The unrestrained, reciprocal process of contribution in which both great, good, and bad ideas are all shared and input is what makes the entire systems of information technology go. Even with commercial technology in which source code is withheld and binaries are published, the participants in the creation of those binaries entered into a commercial situation with knowledge gathered from a open and transparent environment. A situation could exist in which copyright becomes a means of attribution, but as to restricting the use of software, that seems a path towards undermining technological advancement as well as rolling back the momentum of technological understanding.
A legal concept that could apply to an entire body of software not disclosed is trade secret. Once disclosed, a trade secret ceases to be secret. Most downloadable computer software released over the Web does not fall under this provision while those parts of websites not accessible to the view source mechanism and unable to be derived by others in general could be trade secrets if so declared. The control of these software interfaces whenever they are routinely disclosed does not exist. Measures to exert control begins to abridge wider societal imperatives that the 77 computer scientists could expound upon in great detail. The expectations may need to be better balanced and perhaps realigned to the original state of very limited qualification. Value then becomes the essential matter to be resolved in favor of attribution or financial remuneration. Trademarks could help with the former while in the naturally open platform of the Web as few things if any, including copyright, may be relevant for the latter.