Do I need permission to reimplement application programming interface calls/classes? Suppose MS Excel has an API so that other programs can communicate with it. Suppose I'm the developer of OpenOffice Calc, and I want other programs to be able to communicate with my program in like manner. So, for example, let's say Excel's API has a function called "run" and takes a formula as an argument. Calc's API would then also have a function called "run", which takes a function as an argument. Is that legal?
My opinion is that the copying of a single API endpoint, "run" that takes a function as an argument is not infringement. I can think of several lines of argument that get to this same conclusion: Originality: It doesn't exhibit the modicum of creativity required by the originality test. (Feist) Short phrases doctrine: It is a short word or phrase, which both the copyright office (Copyright Office Circular, 37 CFR 202.1) and courts (e.g. Hutchins v. Zoll) have declared ineligible for copyright. Merger: The merger doctrine allows reuse of an expression if it is one of only a very few number of ways of expressing an idea. I can't think of many other ways to express a function intended to run a function other than with the verb "run". Scènes à faire: It is not infringement to use an expression if it has become standard, stock, or common in a particular setting. Naming a function "run" is common in the programming community. Any one of these alone would be enough to rule out copyright infringement by taking this individual component of Excel's API. Note: Whether merger and scènes à faire are part of the originality/copyrightability analysis or part of the infringement analysis is not uniform across circuits. For example, the 6th circuit considers both merger and scènes à faire part of the copyrightability analysis. But, the 2nd and 9th circuits treat them as part of the infringement analysis and in the 9th circuit, they are affirmative defenses.
You can't grant or license that which is not yours. For example, the Slack terms of service say: We grant to Customer a non-sublicensable, non-transferable, non-exclusive, limited license for Customer and its Authorized Users to use the object code version of these components, but solely as necessary to use the Services and in accordance with the Contract and the User Terms. So Slack's agreement with Org A does not give A any right to let any other organization B use the software. It does not matter how A and B are related, nor whether B is nonprofit or for-profit, nor what A would be getting in exchange. If B wants to use it, they need to make their own agreement with Slack.
It's not clear exactly what you're asking, when you say "the company I work for" – i.e. are you asking "can they fire me?" (almost certainly they can, even if their TOS thinking is legally misguided – unless in your country there are laws that prevent firing employees). To be certain, you need to hire an attorney who is sufficiently savvy about web page technology that they can accurately judge what you are doing, and whether you can fruitfully resist their demands. You seem to be skeptical of their position because you are "not affecting their servers in any way". The TOS is not about affecting their servers, it is about affecting their intellectual property. It appears that your code does a number of the prohibited actions such as and perhaps most importantly "modify". If you have distributed a program that allows users to modify company content on their own computers, then the user might be in violation of the TOS, but not you (since you're not running a server that redistributes). However, I am betting that in order to create and test the program you had to violate the TOS. Additionally, you could be vicariously liable for the infringements of others, especially if this program can only be used to infringe on copyright, and you know this fact. That is pretty much the end of the legal part. As for how you should respond, your attorney, and not Law SE, deals in recommendations.
You could establish your own server which calls the API and maintains a counter, and have al your applications call that server, the server call the API, and the server can also return a count to the application, or even return a failure code if the count is too high. As for when the count turns over, a few days experiment should establish that, but given that the API is based in the EU, I would guess it turns over at midnight UTC (aka Greenwich mean time), but of course that is only a guess. Has the API management declined even to tell when the count rolls over? That seems odd. As to the legal obligations of the API management, it would be good practice for them to have the API return a count, but I don't see that they can be required to do that. I don't know of (and could not find) any law which mandates such a count. I do think that they should inform you of the time of day at which they roll the count over. I have not yet found a law which specifically requires this.
Forget about copyright or EULAs. In the UK this would be illegal under the Computer Misuse Act (1998) and you could be jailed for up to a year - specifically Unauthorised access to computer material. (1)A person is guilty of an offence if— (a)he causes a computer to perform any function with intent to secure access to any program or data held in any computer, or to enable any such access to be secured; (b)the access he intends to secure, or to enable to be secured, is unauthorised; and (c)he knows at the time when he causes the computer to perform the function that that is the case. This law has been applied even to simply altering parameters in a GET request to a website, so it is incredibly broad. Other jurisdictions have similar wording, so be aware!
It depends on what you are selling to the enterprises. You could be selling just a licence to use the program, and retain all the rights on the source code. You could be selling the rights to the source code. For #1, the source code is yours and you can do what it pleases with it1. In fact many programs offer both an open-source licence (which usually forces the user to make its changes to the code publicly available) and a commercial one (which allows the user to keep the modifications of the source code for themselves). For #2, the source code is no longer yours so it is not up to you to decide what to do with it. 1I am assuming no other agreements imposing limits on those; for example that none of your contracts to your customers have a clause forbidding you from making the code available to the public.
One cannot use the works of others unless one of the following applies: The copyright holder has given permission, usually in the form of a license, often explicit, but sometimes implied. The work is not protected by copyright. This can happen in several ways, but the most common is that the work is old enough that copyright has expired. In the US, works older than 1927 are currently out of copyright. So are some others, the rules are a bit complex. In many countries, if the author or creator died more than 70 years ago, the work is out of copyright. In some countries this is a different number, between 50 and 100 years. This is not likely to apply to a file distributed with current software. If an exception to copyright applies. In the US this would most likely be fair use. In the UK it would probably be fair dealing. In other countries there are a variety of exceptions that might apply, including personal use in some. AS a comment by Jen points out &quot;use&quot; here refers only to those rights protected by copyright, such as making and distributing copied, making nd distributing derivative works, and the like. (Displaying and publicly performing seem unlikely to apply.) Now lets consider the specific situation, and which if any of the reasons for lawful use might apply. License or other permission. There is no explicit license. Since the program is distributed to be run, there is an implicit license to make the sort of use of the file needed to run the program. If the documentation describes how to employ the file as part of running the program, there is almost surely an implied license to employ it in that way. There is not, however, permission to make copies unless that is needed to run the program. There is surely not permission to make derivative works of the file or distribute copies to others, even if you do not charge anything. Expired copyright This pretty clearly will not apply. Fair use This might apply, or might not. There isn't enough info in the question to tell, not even to make a good guess. If any use would be non commercial, that helps fair use a bit. If the use would be for a different purpose than the one the developers used it for, that helps fair use a lot. If the use of the file harmed the market for the program, or served as a substitute, that lean against fair use. without knowing what the file is, what it does, and how it might be used, one really cannot weven guess.
In Google LLC v. Oracle America, Inc., 593 U.S. ___ (2021), the US Supreme Court addressed the reproduction of a subset of the Java API. The majority assumed for the sake of argument that the Java API was protected by copyright, but went on to hold that the reproduction was a fair use. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google’s use of part of that API was a “fair use.” Unlike the Federal Circuit, we conclude that it was. So, it is an open question whether an API is protected by copyright, but the precedent from the Federal Circuit will be persuasive authority. The Federal Circuit held that the API is protected by copyright and the Supreme Court did not upset that conclusion. Second, the factors that led the court to conclude the reproduction of part of the Java API was fair use could turn out another way in another fact scenario. Some of the reasoning seems to generalize, but some seems specific to the Java development ecosystem. Briefly, the court recognized: API authorship is a creative process, but is &quot;functional in nature&quot; The reproduction was intended to assist interoperability; it was commercial; there was no evidence of bad faith The amount of code taken was a small amount of the entire Java work, an amount consistent with its goals The market harms to Oracle were dubious My prediction is that there will continue to be significant case-by-case uncertainty as to the applicability of the fair-use defence in this context.