The world of software development is a dynamic ecosystem, powered by innovation and collaboration, but also inherently linked to complex intellectual property issues. At the heart of many of these discussions, a judicial case has polarized industry for over a decade: Oracle vs Google. This legal saga, focusing on copyability Application Programming Interfaces (API) and on the limits of the “fair use”, he raised fundamental questions about the nature of creativity in the code, the balance between protection and innovation, and the very foundations on which the modern software is built. The original article, dating back to 2016, reflected a critical moment in which the decision of the appeal court affirmed the copyrightability of the API, but the verdict of the jury on the fair use of Google was still subject to intense debate and skepticism, with the author Peter Bright expressing concern for a weakening of copyright in the software. However, the story did not stop there. The final decision of the U.S. Supreme Court in 2021 added a definitive chapter, tipping in part the perspective and consolidating an understanding of the fair use that, although specific, has lasting ramifications. This article aims to deepen and extend the topics raised in the original piece, examining the complexity of copyright in the context of software, the inherent value of API design and the long-term implications of this historic judgment for innovation, competition and the entire technological landscape. We will analyze how jurisprudence has tried to districate the tangle between “idea” and “expression” in the code, explore the different facets of fair use, and discuss the concrete repercussions for developers, companies and future evolution of programmatic interfaces, going beyond the initial forecasts to understand the real impact of a case that has redefined the boundaries of intellectual property in the digital age. The discussion will also expand to explore alternative approaches to software protection, such as patents and open-source licenses, and how industry and law will continue to adapt to the new challenges posed by emerging technologies such as microservices and AI generation, which constantly shape how APIs are created, distributed and used. Finally, we will reflect on the legacy of Oracle v. Google as a constant warning about the need for a delicate balance between the recognition of creative merit and the promotion of a fertile environment for the continuous technological evolution, a crucial balance to support the growth and resilience of the software industry globally.
The Historical Juridic Battle: Oracle vs Google and API Copyright
The dispute between Oracle and Google, culminated in the decision of the U.S. Supreme Court of 2021, represents one of the most significant legal battles on intellectual property in the technological field, reshaping the understanding of the copyright applied to Application Programming Interfaces (API) and the concept of “fair use” in the software. The story began with Oracle accusing Google to copy 11,500 lines of Java code, including the “structure, sequence and organization” of 37 Java APIs, to build the Android operating system. Initially, the district court ruled that APIs were not copyrighted, considering them functional “ideas”. However, a crucial breakthrough occurred when the Federal Circuit Court of Appeal reversed this decision, stating that the SSO of an API is actually susceptible to copyright protection, equating it to a form of “creative expression” rather than a simple functional “idea”. This sentence laid the groundwork for the second debate, the fair use, which saw a jury believe that Google’s use was lawful. The original piece by Peter Bright, written in this context of 2016, expressed his skepticism towards the jury's decision on fair use, claiming that this interpretation was too wide and could overly weaken copyright protection in the software, pushing itself beyond the cases of true interoperability. His analysis was based on the premise that, although copyright is not the perfect tool for software, it was “the best of a bad deck” and that a laxist interpretation of fair use could undermine the foundations on which innovation is based in code. The Supreme Court of the United States, in 2021, provided the final decision, confirming that Google’s use of Java APIs in the Android ecosystem was fair use. However, the Supreme Court’s reasoning has been disconnected by a general statement on API’s non copyrightability or a broad redefined fair use throughout the software. The Court, in a decision 6-2, assumed a pragmatic approach, avoiding deciding on the copyrightability of the Java API itself, but assuming pro argument that they were. The decision focused mainly on the fourth factor of fair use (the effect on the potential market) and, above all, on the first factor: the “character and purpose of use”, in particular if it were “transformative”. The Court held that Google had used Java APIs to create a new smartphone program, a highly innovative and transformative platform, different from the desktop environment and servers for which Java was originally designed. The use of those 11,500 lines of code, a very small fragment of the millions of total lines of Java, was seen as necessary to allow Java programmers to access a new platform more easily, thus promoting creativity and innovation. This “transformative” perspective was crucial, since it recognized that although Google had copied a part of the API, the final purpose was not simply to replicate Java, but to enable a new and distinct ecosystem. The Supreme Court decision, therefore, did not declare that APIs are never protected by copyright, nor opened doors to an indiscriminate copy. Rather, it has established that, in specific circumstances and with sufficiently transformative use and for a predominant public interest, the copy of functional elements of an API can fall within the boundaries of fair use. This approach “case by case” has provided a precedent that emphasizes the role of innovation and the creation of new platforms as determining factors in the analysis of fair use, placing itself as a significant evolution compared to the most rigid point of view expressed in the original article.
The Basic Dualism: Idea vs. Expression in Software and APIs
The heart of the debate on intellectual property in software lies in the fundamental dualism between idea and expression, a central concept in copyright that is however notoriously difficult to apply to functional works such as code. Copyright, by its nature, protects thecreative expression of an idea, not the idea itself. If an idea can only be expressed in a limited number of ways, or if the expression is so intrinsically linked to the idea that it cannot be separated, the “merger doctrine” applies, which denies copyright protection to the expression itself, since protecting the expression would in fact mean monopolizing the idea. In the context of software, this distinction is particularly labile. The literary source code is universally recognized as an expression and therefore protected by copyright. However, the software is also, by definition, highly functional. Its code lines are often dictated by practical needs and optimal technical solutions, which makes it difficult to distinguish where the mere function ends and the expressive creativity begins. The original article emphasizes how a simple fragment of code as a = b + c; is too functional to justify copyright, while an entire “operative system” is clearly an unprotectable idea. But among these extremes, there are layers of abstraction – code blocks, functions, libraries – in which idea and expression mix inextricably. To address this complexity, US courts have developed approaches such as the doctrine of “structure, sequence and organization” (SSO), introduced in case Whelan v. Jaslow (1986). Initially, the SSO was interpreted fairly broadly, extending the protection to non-literal elements of the code that were not strictly governed by functional requirements, even leading to consider violations of copyright “clonate” user interfaces. This approach, however, has been criticized for approaching too much to the protection of algorithms and ideas, purposes not covered by copyright. Subsequently, the jurisprudence has refined this vision. The case Computer Associates v. Altai (1992) has introduced the test “abstraction-filtration-comparison”, recognizing that the “ideas” exist at every level of a program. This test involves abstracting the program into its structural components, filtering unprotected elements (such as ideas, public domain elements, functional elements dictated by efficiency or standard, or those subject to the merger doctrine), and finally comparing the remaining expressive elements. From Altai onwards, copyright protection for non-literal elements of the software has become more restricted, focusing mainly on the literary source code, leaving a protection void for many aspects of software design. APIs, as highlighted in the original article and as a focal point of Oracle v. Google, are located precisely in this grey area. An API is not only a “behavioural contract” or a functional abstraction; it is also a set of literal code (class names, methods, parameters, package structure) and a series of design choices that define how developers will interact with a library or service. Although functional requirements can strongly influence the design of an API (for example, function length() for a string), they do not eliminate creativity. How the original article illustrates with examples of java.lang.String.length() compared to C++ std::string.size(), some decisions are dictated by the function, but others, such as the choice to provide different data structures or the approach to iterators (Java with “fence posts” against C++ with pairs of iterators), reveal distinct and creative design choices. These decisions, which influence usability, flexibility and ergonomics for the developer, constitute a form of expression. It is not just code; it is way in which that code is structured, called and organized to facilitate human interaction and machine, and this “maniera” is the fruit of a significant creative process. The ability of an API to balance expressive power and ease of use for developers is an artistic enterprise that deserves consideration, and its structure, sequence and organization reflect choices that go beyond the mere inevitable functionality. The legal battle has thus crystallized this tension, with the Supreme Court which, while not deciding on general copyrightability, implicitly recognized the value of these design choices in the context of fair use, placing emphasis on the transformation and empowerment of new forms of creativity.
The Hidden Art: Creativity, Design and Economic Value of APIs
The original article captures a crucial aspect of API design that is often underestimated: its artistic and creative dimension, which goes far beyond the mere mechanical functionality. The creation of aApplication Programming Interface (API) effective is not a purely scientific or engineering enterprise; it is an art that requires insight, far-sightedness and a deep understanding of the needs of developers. The goal is to create a “language” and a “structure” that not only allow different software components to communicate, but that make this communication intuitive, powerful and efficient. A well-designed API is like a well-made sculpture or a well-composed musical piece: there is an intrinsic logic, but also an elegance that distinguishes it. This “art” is manifested in different forms. First, in consistency and consistency: a quality API maintains design patterns, conventions and predictable behaviors across all its parts, reducing cognitive load for the developer. Secondly, in simplicity and ergonomics: the best APIs hide the complexity below, offering clear and easy-to-use interfaces that allow developers to focus on the logic of their application instead of managing the complexity of the API itself. This includes the choice of methods and classes that are self-explanatory, error management in a predictable way and the provision of data structures suitable for the problem. Third, in modularity and flexibility: a well-designed API allows developers to use only the parts they need, without being burdened with irrelevant features, and adapts to future usage scenarios. Finally, in documentation and support: even the brightest API is useless without clear documentation that guides developers in its use. These design elements, far from being dictated by purely functional requirements, are the result of countless creative decisions made by software engineers and architects. Each choice, from the name of a method to the structure of a package, from the logic of an iterator to the management of I/O flows, contributes to creating a user experience (Developer Experience – DX) that can make the difference between widespread adoption and oblivion. The original article rightly emphasizes that “many APIs... are poorly designed” and mentions the API for C strings as an example of interface that makes “easy use incorrect and difficult to correct use”. This contrast highlights the added value of creative design: Java APIs copied by Google (as java.util for data structures, java.sql for the SQL interface, or java.io/java.nio for I/O routines) were the result of years of refinement and represented a familiar and consolidated “language” for millions of developers. This design work has a huge economic value. A well designed API not only attracts developers, but also creates a ecosystem. Companies like Apple (with its iOS API), Amazon (with AWS), Google itself (with its search APIs, maps, etc.) and Oracle (with Java) have built entire empires around the ease with which developers can integrate and build over their platforms. APIs become the “access point” for functionality, services and data, generating network effects that increase the platform’s value. This value translates into licenses, services, products and, ultimately, into a dominant market position. Therefore, copyright protection for the “structure, sequence and organization” of an API is not merely an academic question, but reflects the recognition of intellectual capital and creative work invested in its design. If the design of an API was considered a simple freely copyable functional idea, there would be less incentive to invest time and resources in creating intuitive and complete interfaces. The risk is that companies limit themselves to copying the best existing practices, instead of innovating and investing in new and better solutions. The Supreme Court decision on Oracle v. Google, while justifying the use of Google through fair use, in a certain sense validated the idea that APIs have an intrinsic value that goes beyond the literal code, and that creative design choices within them contribute significantly to their value and identity. The Court did not deny the possibility that APIs are copyrightable, but rather modulated its analysis on way in which they were used, recognizing the importance of context and transformation for innovation. This suggests that art and creativity in the design of APIs, although difficult to incasellate in traditional legal categories, are tangible and fundamental elements for technological progress.
Fair Use and interoperability: A Precarious Equilibrium for Innovation
The concept of “fair use” nel diritto d’autore è un meccanismo essenziale per bilanciare la protezione dei creatori con la promozione dell’innovazione e della libertà di espressione. Consente l’uso non autorizzato di opere protette da copyright in determinate circostanze, senza richiedere il permesso o il pagamento al detentore del copyright. Il suo riconoscimento si basa su quattro fattori chiave: 1) lo scopo e il carattere dell’uso (incluso se l’uso è commerciale o per scopi educativi, e se è “trasformativo”), 2) la natura dell’opera protetta da copyright, 3) la quantità e la sostanzialità della porzione utilizzata rispetto all’opera nel suo complesso, e 4) l’effetto dell’uso sul mercato potenziale o sul valore dell’opera protetta. L’articolo originale di Peter Bright analizza tre schemi di utilizzo delle API: il “consumo senza re-implementazione” (il più comune, non problematico per il copyright), la “re-implementazione di terze parti autorizzata esplicitamente” (come le specifiche C/C++ o POSIX, in cui l’autorizzazione è implicita o esplicita), e la “re-implementazione interoperabile”. Quest’ultima categoria è quella in cui il fair use assume la massima importanza e dove la tensione con il copyright diventa più evidente. L’interoperabilità, la capacità di sistemi diversi di lavorare insieme, è stata a lungo riconosciuta come un interesse pubblico significativo e spesso giustifica la copia di codice o di API. Progetti come WINE e ReactOS, che mirano a fornire implementazioni alternative dell’API Win32 di Microsoft per consentire l’esecuzione di software Windows su altri sistemi operativi, sono esempi classici di questo tipo di uso. Microsoft non ha progettato Win32 per essere re-implementato da terzi, né ha concesso autorizzazioni esplicite; tuttavia, l’obiettivo di questi progetti è l’interoperabilità, che è stata storicamente considerata una giustificazione valida per il fair use, persino attraverso tecniche di reverse engineering. Google, nel caso delle API Java per Android, si è trovata in una posizione ambigua. Se da un lato Sun (e Oracle) avevano promosso l’interoperabilità di Java, arrivando a combattere Microsoft per la sua implementazione non conforme, il progetto Android di Google non aveva l’obiettivo primario di essere una piattaforma Java “interoperabile” nel senso tradizionale. Android ha copiato un sottoinsieme delle API Java e ha deliberatamente scartato altri elementi, creando un ecosistema “Java-like” ma non “Java-compliant”. L’articolo originale critica questa scelta, definendola una “scorciatoia competitiva” piuttosto che un tentativo genuino di interoperabilità, e sostenendo che, per questo motivo, l’uso di Google non avrebbe dovuto qualificarsi come fair use. La Corte Suprema degli Stati Uniti, nella sua sentenza finale, ha affrontato proprio questa delicata distinzione. Sebbene abbia riconosciuto il valore delle API Java e il lavoro creativo che le sottende, ha concluso che l’uso di Google era un fair use, ponendo un’enfasi particolare sul primo fattore: il “carattere e lo scopo dell’uso” e la sua natura “trasformativa”. La Corte ha osservato che Google ha preso solo ciò che era necessario delle API (le “naming conventions” e l’organizzazione) per consentire agli sviluppatori Java di lavorare su una nuova piattaforma per smartphone, Android, che ha rappresentato un significativo passo avanti tecnologico rispetto ai sistemi desktop e server per cui Java era stato originariamente concepito. Questo uso è stato considerato “trasformativo” perché ha permesso la creazione di un nuovo ecosistema di applicazioni per smartphone, piuttosto che semplicemente replicare l’ecosistema Java esistente. La Corte ha riconosciuto che l’introduzione di un nuovo sistema operativo per smartphone era di grande beneficio pubblico, e che permettere agli sviluppatori di utilizzare un linguaggio di programmazione e un set di API familiari riduceva la barriera all’ingresso e promuoveva l’innovazione. Questo ha rappresentato un equilibrio precario: da un lato, non si è negata la potenziale copyrightability delle API, dall’altro si è riconosciuto il ruolo cruciale del fair use nel promuovere l’innovazione e la concorrenza, specialmente in settori in rapida evoluzione come quello tecnologico. La decisione della Corte Suprema, quindi, ha consolidato l’idea che l’interoperabilità, insieme alla trasformazione e al beneficio pubblico, può giustificare la copia di elementi espressivi di un’API, ma con un’analisi attenta e contestuale che non apre la porta a una copia indiscriminata. Questo pone un precedente importante, sottolineando che il fair use non è un “passaporto” per la copia, ma uno strumento per bilanciare gli interessi dei titolari dei diritti con quelli della società nel suo complesso, in particolare quando si tratta di abilitare nuove forme di creatività e competizione in un nuovo mercato.
La Ramificazioni del Verdetto: Impacts on Software Industry and Copyright
The U.S. Supreme Court ruling in case Oracle v. Google has had deep and complex repercussions on the software industry and the future of copyright applied to API. Sebbene la decisione abbia concluso una decennale battaglia legale, non ha fornito risposte semplici, ma piuttosto ha aperto nuove domande e ha consolidato un approccio sfumato alla protezione della proprietà intellettuale nel settore tecnologico. L’impatto più immediato e forse il più dibattuto è stato l’apparente “vittoria” per Google e, per estensione, per la comunità degli sviluppatori che temevano che una vittoria di Oracle avrebbe soffocato l’innovazione. Molti hanno interpretato la sentenza come un via libera per il riutilizzo di API per scopi “trasformativi”, riducendo il rischio legale per le aziende che desiderano costruire su infrastrutture esistenti senza dover negoziare costose licenze. Questo ha alimentato un senso di maggiore libertà e ha potenzialmente incoraggiato la creazione di nuovi ecosistemi software, come Android stesso, che hanno beneficiato della familiarità di un linguaggio e di un’architettura di programmazione esistenti. D’altra parte, per i detentori di copyright e le aziende che investono massicciamente nella creazione di API innovative, la decisione ha sollevato preoccupazioni. Se il “fair use” è interpretato troppo ampiamente, potrebbe esserci meno incentivo a creare API complesse e ben progettate, sapendo che i concorrenti potrebbero riutilizzarne le parti essenziali senza compenso. L’articolo originale di Peter Bright esprimeva proprio questa preoccupazione nel 2016, temendo che la decisione della giuria sul fair use avrebbe “indebolito ulteriormente il copyright sul software”. La sentenza della Corte Suprema, pur non sposando completamente questa prospettiva, ha comunque posto un limite all’estensione della protezione del copyright, specialmente in contesti di riutilizzo “trasformativo”. Tuttavia, è fondamentale sottolineare che la Corte Suprema non ha dichiarato che le API non sono copyrightabili in linea di principio, né ha formulato una regola generale per tutti i casi di fair use nel software. La sua decisione è stata “stretta e specifica”, basata sui fatti unici del caso Google-Android e sull’analisi dei quattro fattori del fair use in quel contesto. Questo significa che ogni futuro caso di copia di API dovrà essere valutato individualmente, e la “trasformatività” dell’uso sarà un fattore critico, ma non l’unico. Un’altra ramificazione importante riguarda il open source software. Many open source licenses, such as the GNU General Public License (GPL), are based on the copyright force to impose their terms (for example, the obligation to make the modified source code available). If copyright on APIs is systematically weakened, the ability of these licenses to protect and propagate free software could be compromised. However, the Supreme Court decision did not weaken copyright to the point of undermining open source licenses; rather, it clarified that fair use is a valid defense even in software contexts, which could push open source projects to be more explicit on the terms of use of their APIs. For developers, the sentence brought some clarity, while maintaining a degree of uncertainty. On the one hand, there is greater confidence in the ability to inspire existing API structures to create new platforms. On the other hand, the lack of a universal “urea rule” for fair use means that companies and individual developers must proceed with caution, considering carefully whether their use is actually “transformative” and does not damage the original work market. This could lead to greater use of legal advice or more complex licensing strategies to mitigate risk. Ultimately, the decision Oracle v. Google did not solve the “war” between copyright and innovation in software, but rather moved the battlefield. He strengthened the idea that copyright must adapt to technological reality, balancing the protection of creative value with the need to promote new forms of expression and competition. He pointed out that the functionality of the software makes its copyright protection intrinsically different from that of a novel or song, requiring a subtler and more contextual analysis that considers the impact on technological progress and public benefit. The debate will continue, and with it the evolution of legal and business strategies in the software world.
Beyond Copyright: Alternatives and Complements for Software Protection
Given the recognition that the copyright, although it is “the best tool of a bad deck” for software protection, it has intrinsic limitations due to the functional nature of the code, it is essential to explore the alternatives and complements to safeguard intellectual property in the technological field. None of these tools are perfect alone, but a strategic combination can offer more robust and adaptable protection to the different facets of software and API. One of the most obvious alternatives to copyright is patents. Unlike copyright, which protects expression, patents protect “ideas” or, more precisely, new inventions, not obvious and useful. In the context of software, this means that a patent can cover an algorithm, process method, or specific functionality implemented by the software. For example, a patent could protect an innovative data compression algorithm or a new way to manage transactions in a database, rather than the source code that implements that algorithm. Patents offer stronger protection against functional copying, but are expensive to obtain and maintain, require a complex analysis of “new” and “non-obvious” and have a limited duration (typically 20 years). Moreover, not all software is patentable, because many innovations are considered too abstract or banal to meet the strict patentability requirements. Another important tool is commercial secrets (trade secrets). This type of protection applies to confidential business information that gives a competitive advantage and that is not public domain. For software, this may include proprietary algorithms, internal system architectures, development methodologies, source code not publicly distributed and, in some cases, also aspects of API design if kept secret. Unlike patents and copyrights, commercial secrets do not require registration and their protection is potentially unlimited, provided that the company takes reasonable steps to keep its secrecy. However, protection ceases if the secret is discovered independently (for example, through legal reverse engineering) or disclosed without authorization. For APIs, this means that while the external behavioral contract can be known, internal implementation and optimization details can remain commercial secrets. I contracts and licensing agreements represent a third pillar. Many companies protect their software and APIs not so much with copyright or patents in a strict sense, but through contractual terms imposed on users. End User License Agreements (EULA) for “shrinkwrap” software or Service Terms (ToS) for cloud-based APIs or microservices specify what users can or cannot do with software or API. These contracts may impose restrictions on decoding, modifying, distributing or creating derivative works, extending protection beyond the limits of copyright. Although powerful, these agreements are binding only for the parties that accept them and may be subject to legal disputes about their validity or scope. The open source licenses (like GPL, MIT, Apache) offer a completely different paradigm. They do not aim to “protect” in the traditional sense of limiting use, but rather to facilitate the collaboration and sharing of code. However, these licenses are still based on the copyright force to enforce their terms. For example, the GPL uses copyright to request that any derivative work is also released under GPL (the concept of “copyleft”). In this sense, open source licenses are not alternative to copyright, but rather a way to use copyright to achieve specific sharing and collaborative development goals. For APIs, this means that an open source API can be freely used, studied, modified and distributed, promoting interoperability and open innovation. The decision Oracle v. Google, while supporting fair use for Google, did not undermine the validity of these tools. It has rather clarified the context in which copyright can be applied to APIs and has strengthened the idea that, in a rapidly changing technological world, effective IP protection requires a multi-layered and flexible approach, combining copyright for expression, patents for functional inventions, commercial secrets for proprietary knowledge and contractual agreements to define the rules of use. This integrated approach allows companies to innovate and protect their investments while guaranteeing that innovation and competition are not unduly suffocated.
The Future of APIs and Emergency Legal Challenges
Today's technological landscape is in constant and rapid evolution, and with it emerge new legal challenges for the protection of Application Programming Interfaces (API) and software in general. The Supreme Court Judgment in Oracle v. Google has provided an important clarification, but has also highlighted the intrinsic complexity in applying copyright laws designed for traditional creative works to highly functional entities such as APIs. Looking at the future, different technological trends promise to put further pressure on existing legal frameworks. The rise of microservices and architecture API-first It's one of these. In this paradigm, applications are no longer monolithic, but are disassembled in small independent services that communicate with each other exclusively through API. Each microservice exposes one or more well defined APIs, becoming both a consumer and a functional provider. In such a fragmented and interconnected environment, the “structure, sequence and organization” (SSO) of the API becomes even more crucial for the efficiency and stability of the entire system. The clear definition of interfaces, consistency in the design and management of errors, and ease of integration are design elements that will require protection. The question is: in an ecosystem where thousands of different APIs interact, until the fair use extends to allow the creation of new microservices that replicate existing features? The growing spread ofArtificial Intelligence (AI), in particular code generation tools and low-code/no-code platforms, introduces a further dimension of complexity. These tools can automatically generate code fragments, functions or even entire APIs based on natural language descriptions or existing code models. If an AI generates an API that is “substantially similar” to an existing API and copyright protected, who is responsible for the violation? The creator of AI, the user who supplied the input, or is the output itself protected by copyright (and by whom)? The ability of the AI to “learn” from vast corpus of existing code raises questions about the source of training data and the nature of the derived work generated. In addition, APIs are becoming the “access point” not only for code, but also for data and machine learning models. Data APIs allow programmatic access to huge data sets, while AI model APIs allow developers to integrate advanced AI capabilities in their applications without having to train or manage complex models. The protection of these APIs, which often expose proprietary data or the internal logic of an AI model (which could be patentable or a commercial secret), will require a combined analysis of copyright, patents, commercial secrets and contractual terms. The globalization Software and API also means that companies operate in different jurisdictions, each with their own copyright laws and fair use interpretations or equivalent concepts (such as “fair dealing” in some common law jurisdictions). A specific decision of the United States Supreme Court, however influential, does not automatically translate into a legal precedent in Europe, Asia or other parts of the world. The lack of international harmonization on intellectual property laws for software and APIs creates uncertainty and challenges for global companies. Finally, the need for a continuous balance between protection and innovation remains the biggest challenge. Laws must be flexible enough to adapt to rapid technological changes without suffocating creativity or competition. This could require new forms of legislation, or more agile interpretations of existing laws, which recognize the value of API design and ecosystems that create, while promoting openness and interoperability when needed. The future of the API is brilliant, but its trajectory will inevitably be shaped by legal decisions that will address these emerging challenges, trying to find a balance that favours both creators and collective innovation.
