Are computer programs protected by copyright? That issue was a hot one three decades ago when courts began to struggle with whether these intangible utilitarian objects could be protected. Were they machine parts outside the realm of copyright or literary works, the kind of subject matter that copyright protects? This issue was quickly resolved in favor of copyright protection, first by the courts in the US, Australia, Canada and elsewhere in a series of cases involving the Apple II operating system and in other cases, then by international conventions and treaties and worldwide copyright amendments by governments that wanted to be sure programs could not be blatantly pirated.
The decision to protect computer programs under copyright then led to a series of very important questions about the scope of their protection. Did copyright protect graphical users interfaces, application programming interfaces (APIs), program structure, sequence and organization (SSO), data and file formats and structures, and programming languages? Given that copyright does not protect ideas, systems, processes, functionality, or methods of operation, what parts of computer programs could be protected and could be copied without infringing copyright? Could computer programs be reverse engineered without infringing copyright and would creating interoperable or compatible programs infringe?
These issues have been the subject of numerous, sometime conflicting decisions, around the world for the last two decades. The answers significantly impact the important boundary between protecting original creative efforts and promoting innovation and hindering competition in the tech industry.
The scope of protection for programs is now in the forefront again in two continents. The issue is front and centre in the litigation between Oracle and Google over the protection of Java APIs used by Google in creating the Android operating system. It was also a major issue in the recent decision of the European Court of Justice in the SAS v WPL case.
Oracle v Google
Last month the jury in the Oracle v Google case returned a verdict finding that Google infringed copyright. The jury failed, however, to reach any verdict on whether Google’s copying was protected by fair use. The jury verdict was premised on the relevant portion of the Java APIs being protected by copyright. On May 31, 2012, District Court Judge Alsup ruled that while specific code used to implement methods or to carry out API functions or specifications are capable of being protected by copyright, the methods, functions, declarations or method headers and the arrangement of methods among various classes is not. In resoundingly rejecting Oracle’s claims, he stated “To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.”
Central to the Judge’s order were his findings about the scope of protection for computer programs under US copyright law. According to the judge, the case was controlled by the following principles:
- Under the merger doctrine, when there is only one (or only a few) ways to express something, then no one can claim ownership of such expression by copyright.
- Under the names doctrine, names and short phrases are not copyrightable.
- Under Section 102(b), copyright protection never extends to any idea, procedure, process, system, method of operation or concept regardless of its form. Functional elements essential for interoperability are not copyrightable.
- Under Feist, we should not yield to the temptation to find copyrightability merely to reward an investment made in a body of intellectual property.
Both Oracle and Google agreed that everyone is free to program in the Java language and that Google was free to use the Java language to write its own API. Google had also written fresh line-by-line code implementations of the Java APIs. This accounted for about 97 percent of them. There was no issue that this code infringed copyright. The core issue in the case is whether the methods, functions, declarations and the arrangement of methods among various classes in the 37 packages in the Java API is protected by copyright.
Judge Alsup made a number of specific findings in ruling that the portion of the JAVA APIs copied by Google are not protected by copyright. First, he ruled that Java methods are not protected by copyright.
“As long as the specific code written to implement a method is different, anyone is free under the Copyright Act to write his or her own method to carry out exactly the same function or specification of any and all methods used in the Java API. Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.”
His ruled that a method specification is not protected because it is an uncopyrightable idea and is barred from protection under the merger (interoperability) and names and short phrases doctrines. According to the Court:
This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different. To repeat the Second Circuit’s phrasing, “there might be a myriad of ways in which a programmer may … express the idea embodied in a given subroutine.” Computer Associates, 982 F.2d at 708. The method specification is the idea.
The method implementation is the expression. No one may monopolize the idea. To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision. Significantly, when there is only one way to write something, the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression. Therefore, there can be no copyright violation in using the identical declarations. Nor can there be any copyright violation due to the name given to the method (or to the arguments), for under the law, names and short phrases cannot be copyrighted.
In sum, Google and the public were and remain free to write their own implementations to carry out exactly the same functions of all methods in question, using exactly the same method specifications and names. Therefore, at the method level — the level where the heavy lifting is done — Google has violated no copyright, it being undisputed that Google’s implementations are different.
He ruled that the same principles are applicable to copyright protection for Java classes.
As for classes, the rules of the language likewise insist on giving names to classes and the rules insist on strict syntax and punctuation in the lines of code that declare a class. As with methods, for any desired functionality, the declaration line will always read the same (otherwise the functionality would be different) — save only for the name, which cannot be claimed by copyright. Therefore, under the law, the declaration line cannot be protected by copyright. This analysis is parallel to the analysis for methods. This now accounts for virtually all of the three percent of similar code.
The next question was whether Google was free to group its methods in the same way as in Java, that is, to organize its Android methods under the same class and package scheme as in Java. The rules of Java did not insist that these methods be grouped together in any particular class. Google could have placed its functions under other classes. But, Google decided not to do so.
Oracle argued that while no single name was copyrightable, Java’s overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods — was an original “taxonomy” and was protected as part of the structure, sequence and organization of the Java APIs. Judge Alsup rejected these arguments. He did so on several grounds. First, relying on the First Circuit Court of Appeals decision in the Lotus v Borland case, he held the overall arrangement to be not protectable as being “a command structure for a system or method of operation of the application programming interface.”
He also premised his legal conclusions on his ruling that copyright does not protect functional program elements essential for interoperability or compatibility.
Interoperability sheds further light on the character of the command structure as a system or method of operation. Surely, millions of lines of code had been written in Java before Android arrived. These programs necessarily used the java.package.Class.method() command format. These programs called on all or some of the specific 37 packages at issue and necessarily used the command structure of names at issue. Such code was owned by the developers themselves, not by Oracle. In order for at least some of this code to run on Android, Google was required to provide the same java.package.Class.method() command system using the same names with the same “taxonomy” and with the same functional specifications. Google replicated what was necessary to achieve a degree of interoperability — system using the same names with the same “taxonomy” and with the same functional specifications. Google replicated what was necessary to achieve a degree of interoperability —but no more, taking care, as said before, to provide its own implementations.
That interoperability is at the heart of the command structure is illustrated by Oracle’s preoccupation with what it calls “fragmentation,” meaning the problem of having imperfect interoperability among platforms. When this occurs, Java-based applications may not run on the incompatible platforms. For example, Java-based code using the replicated parts of the 37 API packages will run on Android but will not if a 38th package is needed. Such imperfect interoperability leads to a “fragmentation” — a Balkanization — of platforms, a circumstance which Sun and Oracle have tried to curb via their licensing programs. In this litigation, Oracle has made much of this problem, at times almost leaving the impression that if only Google had replicated all 166 Java API packages, Oracle would not have sued. While fragmentation is a legitimate business consideration, it begs the question whether or not a license was required in the first place to replicate some or all of the command structure. (This is especially so inasmuch as Android has not carried the Java trademark, and Google has not held out Android as fully compatible.) The immediate point is this: fragmentation, imperfect interoperability, and Oracle’s angst over it illustrate the character of the command structure as a functional system or method of operation.
In this regard, the Ninth Circuit decisions in Sega and Sony, although not on all fours, are close analogies. Under these two decisions, interface procedures required for interoperability were deemed “functional requirements for compatibility” and were not copyrightable under Section 102(b). Both decisions held that interface procedures that were necessary to duplicate in order to achieve interoperability were functional aspects not copyrightable under Section 102(b). Here, the command structure for the 37 packages (including inheritances and exception throws), when replicated, at least allows interoperability of code using the replicated commands. To the extent of the 37 packages — which, after all, is the extent of Oracle’s copyright claim — Sega and Sony are analogous. Put differently, if someone could duplicate the interfaces of the Sony BIOS in order to run the Playstation games on desktops (taking care to write its own implementations), then Google was free to duplicate the command structure for the 37 packages in Android in order to accommodate third-party source code relying on the 37 packages (taking care to write its own implementations). Contrary to Oracle, “full compatibility” is not relevant to the Section 102(b) analysis. In Sony, the accused product implemented only 137 of the Playstation BIOS’s 242 functions because those were the only functions invoked by the games tested… Our court of appeals held that the accused product “itself infringe[d] nocopyright.” Sony, 203 F.3d at 608 n.11. This parallels Google’s decision to implement some but not all of the Java API packages in Android.
Judge Alsup ultimately dismissed Oracle’s claim for copyright infringement based on copying of the Java APIs. In summing up his ruling he stated: “This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.”
Observations about the Oracle v Google case
The decision of Judge Alsup follows a long line of US cases that treats computer-related subject matter that must be copied for compatibility purposes as inherently not capable of being protected by copyright. In reaching his conclusions he relied on some of the leading cases dealing with the scope of protection for computer programs including Atari Games Corp. v. Nintendo of America, Inc., [1] Sega Enterprises v. Accolade, Inc.,[2] Sony Computer Entertainment Inc. v. Connectix Corp., [3] and Lotus Development Corp. v. Boland International, Inc.[4]. Judge Alsup claimed there were no decisions directly on point. Yet, there were other decisions supporting his opinion that he could also have referred to but didn’t including Baystate v. Bentley [5], Lexmark International Inc. v. Static Control Components Inc. [6], and Compaq Computer v. Procom Technology Inc.[7]
There is also another line of cases that treats material that must be copied to achieve compatibility or interoperability as any other part of a copyright work and protects it even where necessary for interoperability or compatibility provided it is original, subject to limiting doctrines such as merger, scènes à fair external constraints, and similar doctrines which are designed to ensure that copyright protects only expression and not ideas, methods, systems or processes that are embodied in a work. Without explanation, Judge Alsup cited none of these cases even though potentially directly relevant to his ruling. These include Apple Computer, Inc. v. Franklin Computer Corp,.[8] Mitel v. Iqtel, [9] Bateman v. Mnemonics, [10] Control Data Systems v. Infoware,[11] Dunn & Bradstreet v. Grace,[12] and Positive Software Solutions Inc. v. New Century Mortgage Corporation.[13]
Oracle has announced it plans to appeal the decision. If this case ultimately goes to the US Supreme Court (via the Circuit Court of Appeals), the clear circuit split in the US on this very important issue may finally be resolved.
SAS v WPL
Across the Atlantic, the ECJ recently released its reasons in the SAS Institute v World Programming Limited case. The court answered a series of questions posed to it by an English court dealing with the scope of protection for functional aspects of a program. The court answered the questions siding for the most part with the defendant on the issue of copyright protection for programming languages and the format of data files. However, anyone looking for a solid analysis of the issues will be disappointed with the decision.
The first set of questions addressed by the court were whether Article 1(2) of Directive 91/250 must be interpreted as meaning that the functionality of a computer program and the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and may, as such, be protected by copyright in computer programs for the purposes of that directive. The court answered this question in the negative saying.
In accordance with Article 1(1) of Directive 91/250, computer programs are protected by copyright as literary works within the meaning of the Berne Convention.
Article 1(2) of Directive 91/250 extends that protection to the expression in any form of a computer program. That provision states, however, that the ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under that directive.
The 14th recital in the preamble to Directive 91/250 confirms, in this respect, that, in accordance with the principle that only the expression of a computer program is protected by copyright, to the extent that logic, algorithms and programming languages comprise ideas and principles, those ideas and principles are not protected under that directive. The 15th recital in the preamble to Directive 91/250 states that, in accordance with the legislation and jurisprudence of the Member States and the international copyright conventions, the expression of those ideas and principles is to be protected by copyright.
With respect to international law, both Article 2 of the WIPO Copyright Treaty and Article 9(2) of the TRIPs Agreement provide that copyright protection extends to expressions and not to ideas, procedures, methods of operation or mathematical concepts as such.
Article 10(1) of the TRIPs Agreement provides that computer programs, whether in source or object code, are to be protected as literary works under the Berne Convention.
In a judgment delivered after the reference for a preliminary ruling had been lodged in the present case, the Court interpreted Article 1(2) of Directive 91/250 as meaning that the object of the protection conferred by that directive is the expression in any form of a computer program, such as the source code and the object code, which permits reproduction in different computer languages (judgment of 22 December 2010 in Case C?393/09 Bezpecnostni softwarova asociace [2010] ECR I?0000, paragraph 35).
In accordance with the second phrase of the seventh recital in the preamble to Directive 91/250, the term ‘computer program’ also includes preparatory design work leading to the development of a computer program, provided that the nature of the preparatory work is such that a computer program can result from it at a later stage.
Thus, the object of protection under Directive 91/250 includes the forms of expression of a computer program and the preparatory design work capable of leading, respectively, to the reproduction or the subsequent creation of such a program (Bezpecnostni softwarova asociace, paragraph 37).
From this the Court concluded that the source code and the object code of a computer program are forms of expression thereof which, consequently, are entitled to be protected by copyright as computer programs, by virtue of Article 1(2) of Directive 91/250. On the other hand, as regards the graphic user interface, the Court held that such an interface does not enable the reproduction of the computer program, but merely constitutes one element of that program by means of which users make use of the features of that program (Bezpecnostni softwarova asociace, paragraphs 34 and 41).
On the basis of those considerations, it must be stated that, with regard to the elements of a computer program which are the subject of Questions 1 to 5, neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program for the purposes of Article 1(2) of Directive 91/250.
The court’s decision was short on policy. But, on this question it sided against protection in order to foster competition in compatible programs.
As the Advocate General states in point 57 of his Opinion, to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.
Moreover, point 3.7 of the explanatory memorandum to the Proposal for Directive 91/250 [COM (88) 816] states that the main advantage of protecting computer programs by copyright is that such protection covers only the individual expression of the work and thus leaves other authors the desired latitude to create similar or even identical programs provided that they refrain from copying.
With respect to the programming language and the format of data files used in a computer program to interpret and execute application programs written by users and to read and write data in a specific format of data files, these are elements of that program by means of which users exploit certain functions of that program.
In that context, it should be made clear that, if a third party were to procure the part of the source code or the object code relating to the programming language or to the format of data files used in a computer program, and if that party were to create, with the aid of that code, similar elements in its own computer program, that conduct would be liable to constitute partial reproduction within the meaning of Article 4(a) of Directive 91/250.
As is, however, apparent from the order for reference, WPL did not have access to the source code of SAS Institute’s program and did not carry out any decompilation of the object code of that program. By means of observing, studying and testing the behaviour of SAS Institute’s program, WPL reproduced the functionality of that program by using the same programming language and the same format of data files…
Consequently, the answer to Questions 1 to 5 is that Article 1(2) of Directive 91/250 must be interpreted as meaning that neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.
A second set of questions addressed whether Article 5(3) of Directive 91/250 must be interpreted as meaning that a person who has obtained a copy of a computer program under a licence is entitled, without the authorisation of the owner of the copyright in that program, to observe, study or test the functioning of that program in order to determine the ideas and principles which underlie any element of the program, in the case where that person carries out acts covered by that licence with a purpose that goes beyond the framework established by the licence. The court reviewed the EU Directive and answered yes.
…Article 5(3) of Directive 91/250 must be interpreted as meaning that a person who has obtained a copy of a computer program under a licence is entitled, without the authorisation of the owner of the copyright, to observe, study or test the functioning of that program so as to determine the ideas and principles which underlie any element of the program, in the case where that person carries out acts covered by that licence and acts of loading and running necessary for the use of the computer program, and on condition that that person does not infringe the exclusive rights of the owner of the copyright in that program.
The last set of questions asked whether Article 2(a) of Directive 2001/29 must be interpreted as meaning that the reproduction, in a computer program or a user manual for that program, of certain elements described in the user manual for another computer program protected by copyright constitutes an infringement of that right in the latter manual.
The court’s answer to this question is puzzling. After having found that programming languages and file formats are not protected by a computer program’s copyright, the court nevertheless expressed the opinion that a compilation of a programming language’s elements contained in a program manual could be protected by copyright if found to be original (an author’s intellectual creation) and that copying these features in another program or program manual could be infringing.
It is apparent from the order for reference that the user manual for SAS Institute’s computer program is a protected literary work for the purposes of Directive 2001/29.
The Court has already held that the various parts of a work enjoy protection under Article 2(a) of Directive 2001/29, provided that they contain some of the elements which are the expression of the intellectual creation of the author of the work (Case C?5/08 Infopaq International [2009] ECR I?6569, paragraph 39).
In the present case, the keywords, syntax, commands and combinations of commands, options, defaults and iterations consist of words, figures or mathematical concepts which, considered in isolation, are not, as such, an intellectual creation of the author of the computer program.
It is only through the choice, sequence and combination of those words, figures or mathematical concepts that the author may express his creativity in an original manner and achieve a result, namely the user manual for the computer program, which is an intellectual creation (see, to that effect, Infopaq International, paragraph 45).
It is for the national court to ascertain whether the reproduction of those elements constitutes the reproduction of the expression of the intellectual creation of the author of the user manual for the computer program at issue in the main proceedings.
In this respect, the examination, in the light of Directive 2001/29, of the reproduction of those elements of the user manual for a computer program must be the same with respect to the creation of the user manual for a second program as it is with respect to the creation of that second program.
Consequently, in the light of the foregoing considerations, the answer to Questions 8 and 9 is that Article 2(a) of Directive 2001/29 must be interpreted as meaning that the reproduction, in a computer program or a user manual for that program, of certain elements described in the user manual for another computer program protected by copyright is capable of constituting an infringement of the copyright in the latter manual if – this being a matter for the national court to ascertain – that reproduction constitutes the expression of the intellectual creation of the author of the user manual for the computer program protected by copyright.
So what is the upshot of the case? Is it that under EU law a programming language cannot be protected by a computer program’s copyright but can be when those same elements are contained in a literary work like a manual? After three decades of copyright law protecting computer programs and numerous cases which have explored the proper scope of protection, is this the best the ECJ could do?
Ironically, the first court to consider the reasons in the SAS v WPL was Judge Alsup. the Judge presiding over the Oracle v Google case. He asked the litigants to file briefs which included answering a question on the implication of the case on the legal protection for APIs. Both parties were well aware of the SAS v WPL case and had disagreed about its potential relevance even before they before they were asked by the court to comment on it. In the end, Judge Alsup’s decision made no reference to the SAS v WPL case.
[1] 1993 WL 207548 (N.D. Cal. May 18, 1993)
[2] 977 F.2d 1510 (9th. Cir. 1993)
[3] 203 F.3d 596 (9th. Cir. 2000)
[4] F.3d 807 (1st Cir. 1995)
[5] 1996 US Dist. LEXIS 18233, Bentley copied the selection and organization of Baystate’s data files in developing a data translator designed to read the data files of Baystate’s program, CADKEY. The court held that copying data file elements for compatibility was not infringing. The case, however, did not include any substantive analysis of the issue.
[6] 387 F.3d 522 (6th Cir. 2004), Static Control’s Smartek chips contained a copy of Lexmark’s Toner Loading Program (TLP) to make its printer cartridges compatible with Lexmark’s printers. The TLP operated as a lockout code which was authenticated by a separate program in Lexmark’s printers. The court followed the Atari Games case referred to above quoting the statement that, “Program code that is strictly necessary to achieve current compatibility presents a merger problem, almost by definition, and is thus excluded from the scope of any copyright.”
[7] 908 F.Supp. 1409 (S.D. Tex 1995), Procom copied parameter values used by Compaq to monitor the performance of hard drives. A separate Compaq program dictated the order in which the threshold values had to appear on the hard drives. Procom copied both the ordering and the threshold values. The court held that copying the specific values was infringing as such copying was not necessary for compatibility. However, the ordering of the parameters on the drive could not be changed by Procom in order to be compatible with Compaq’s software. According to the court such copying for compatibility purposes “is a compatibility requirement that cannot be protected by copyright law. Both the scènes à faire doctrine and Section 102(b) of the Copyright Act preclude protection of such methods of operation.”
[8] 714 F.2d 1240, (3d Cir. 1983). The case followed in Apple Computer Inc. v. Formula International Inc., 725 F.2d 521 (9th Cir. 1984) – Franklin contended it could copy Apple’s operating system under the merger doctrine in order to sell Apple compatible personal computers that would work with application programs written for Apple computers. The court rejected that copying to achieve compatibility was a relevant consideration from a copyright perspective.
[9] 124 F. 3d 1366 (10th. Cir. 1997) – Iqtel copied a set of 4-digit coded instructions known as command codes used in Mitel telecom hardware to produce a compatible call-controller. The Court found that the command codes were not sufficiently original to be protected by copyright. However, the Court went on to hold that external constraints related to compatibility apply only if the original creator of the work is constrained by an external constraint.
[10] 79 F. 3d 1532 (11th Cir. 1996) – Bateman asserted his copyrights over an operating system (SBCOS) to prevent the Defendants (PAC) from selling a competing operating system that used the same system calls (APIs) to enable an application program to run on SBCOS on the new PAC OS. The court held that interface specifications were capable of being protected by copyright. However, the Court went on to emphasize that the scope of protection might be limited by various doctrines, including merger, scènes à faire, and fair use.
[11] 124 F. 3d 1366 (D. Minn. 1995) – The case dealt with the protection of Control Data’s APIs to its network operating system (NOS). The APIs were described as consisting of direct or literal lines of NOS source code, NOS input and output formats, NOS file layouts, NOS source code parameters, and NOS commands. Infoware sold an emulator product known as AlphaCyber to permit customers to use application programs designed to run under NOS on other hardware. The court granted Control Data a preliminary injunction against Inforware’s selling its NOS, rejecting the contention that external factors such as compatibility that affected the choices of the defendant’s programmers was relevant.
[12] 307 F. 3d 197 (3rd Cir. 2002) – Grace copied D&B’s Copy and Call commands in his computer program in order to enable it to work with a D&B program. The court rejected the argument that copying for the purpose of achieving interoperability was not infringement. It also expressly held that external constraints related to achieving interoperability must be assessed from the perspective of the author (e.g., D&B) of the original program and not the copier (Grace).
[13] 259 F. Supp. 2d 531 aff’d 90 Fed. App. 728 (5th. Cir. 2004) – New Century copied the SQL data structure from a program it had licensed from Positive to create a replacement program. The goal was for functional compatibility with the old program New Century was using. In a strongly-worded footnote the court rejected the commercial compatibility argument finding it “more in the nature of a fair use argument”.
1 comment
Barry,
Actually this makes perfect sense. Of course I used to work as a computer programmer, which means that I understand the concepts. I suspect that you haven’t done any programming, and therefore the concepts will look strange.
What it comes down to is:
1) The Interface is not copyrightable. The interface however can be covered by a “Design Patent.”To programmers the interface is the look and feel. Technically there is NO difference between the Windows XP/Vista/7 interface, the Mac OS X Leopard/Snow Leopard/Lion interface, and the K Desktop Environment used on Unix and Linux systems. There is however a difference in look and feel, which could be covered by a “Design Patent” but not copyright, since copyright only covers a specific implementation (i.e. the specific source code to make the interface).
2) The Application Programming Interface and the Computer Language are not copyrightable because for something to be copyrightable there has to be something creative. The language and the API are fixed, just as the language you would use addressing a judge in court is fixed. There is nothing creative if you have to use a specific form to call on the judge, is there?
3) The computer program itself will be copyrightable. Let’s take this particular blog post. In it you are delivering information to the reader. You could deliver the same information several ways, i.e. you could change the wording. This would not change the information, nor would it change the words used, they would just be in a different order. The order that you place them in is creative, and therefore copyrightable.
The basics are very simple, but I’m going to repeat them using a different and simpler example.
1) The English Language cannot be copyrighted. (Language)
2) The fixed format of the words you need to use to address a judge cannot be copyrighted. (API)
3) The words you use to address the jury can be copyrighted, in that you used the words in a creative way. (Computer Program)
Now there may be minor ways I’ve gotten the legal part wrong. I’m not a lawyer, though I’ve dealt with the legal system many times over the years.
I have however worked as a programmer, and based on what legal knowledge I have, this explanation is fairly close to reality.
Regards
Wayne