Crypto Copycats Beware: Fair Use Of Financial Technology In Wake Of Oracle v. Google

Locke Lord LLP
Contact

Locke Lord LLP

FinTech companies beware: your use of code that was originally developed via open-source methods may not be shielded from future copyright infringement claims by the fair use doctrine. Recently, in Oracle America, Inc. v. Google LLC, 750 F.3d 1339 (2014), the United States Court of Appeals for the Federal Circuit decided that the doctrine of fair use did not protect Google from liability when during development of its mobile Android platform it selectively copied the structure, sequence, and organization of JAVA source code. Specifically, Google copied Application Programming Interface or “API” packages built using Oracle’s JAVA language, appended onto them Google’s own implementing code, and sold the combined code for use in Google’s Android operating system. While Oracle made its JAVA programming language open and free for anyone to use (e.g., an “open source” license), such use required Google to contribute back its innovations to the public, which Google did not do.1

The impacts of Oracle are significant and will have a lasting impact across the technology industry, including in the financial technology segment, where emergent financial platforms often have a relationship with the open-source community. Surging platforms such as Bitcoin, Ethereum, InterPlanetary File Systems, Monzo, Aragon, Humaniq, have origins in or a connection with open-source development, whether for the platforms themselves or for interlinking companion software products. As critical financial technology projects continue to be open-sourced, particularly with further developments in blockchain technology, additional companies will further contribute and reap the benefits from this community software development through the copying and refining of open-sourced code. By sampling some or all of these community data sources, these companies very likely will build their own proprietary platforms such as new cryptocurrencies, payment networks, collateral assignments tracking, or other financial transaction systems. 

However, the massive impact these technologies will have on the existing banking system has already invited, and will continue to invite, the entrance into the market of institutional technology and financial players. These established companies will likely use and develop these underlying source codes and then seek maximum enforcement of any potential intellectual property rights they may create, whether immediately or years down the line. This is being done in particular within the blockchain space at a rapid pace, with banks and technology companies making massive investments in recent years as to the application of decentralized ledger technology to their adjacent businesses.

As a result, it is conceivable that future developers of FinTech products, whether those that compete with or are compatible with these advances, may find themselves implementing some of the underlying code without a clear understanding of whether such use is allowed or prohibited. Indeed, platforms created via open source software licenses, which make the software available to the public for use and distribution under certain conditions, can still control the modification and distribution of their copyrighted material.2 However, as Oracle shows, there is no blanket prohibition against being sued for copyright infringement despite the existence of open source arrangements. It is now clear that the mere existence of open source licenses does not make copying such code a fair use in all circumstances. In Oracle, the Court was unpersuaded by Google’s fair use defense based on the mere existence of Oracle’s grant of an open source license to its JAVA programs. The Court instead cited the potential right of Oracle to enter new markets or create derivative works.3

Moreover, the Court in Oracle appears to argue that it is not fair use to incorporate source code subject to copyright into a new platform, even if the infringing party adds its own implementation code, when the implementation code does not have a different intrinsic purpose compared to that of the incorporated code.4 This is also heavily problematic for the FinTech industry. For example, if a digital wallet code was subject to copyright and a developer used portions of that code to design a digital currency bank, that use would likely be viewed as having the same intrinsic purpose as the incorporated code - namely, acting as a digital currency repository, thereby opening the later developer to claims of infringement.

This potential risk becomes more unclear when incorporating copyrighted encryption code, such as a particular type of blockchain code, into other unique code meant to implement a new form of digital currency, inventory tracking, or secure contract. To argue that the incorporated code is being used in a new context, such as in finance or commerce, would likely be unavailing for the same reasons Google’s “new context” argument in Oracle was rejected.5 Thus, any potential “fair use” defenses to those who choose to incorporate copyrighted encryption code into their financial technology products may be severely weakened in light of Oracle.

In conclusion, while development in the financial technology space presents a host of possibilities and enterprises, care must be taken when designing the architecture of any platform on which the business will be based. Regardless of the origins in the open-source community or the amount of implementation code that is added to copied source code, the fair use doctrine is not an ironclad defense to claims of infringement. Consulting with experienced intellectual property counsel early on in the process can ensure proper due diligence is taken before launching your financial technology for use by the public. The last thing a thriving business wants or needs is to find itself the subject of a multi-million dollar lawsuit targeting the heart of what makes the business money.

---

[1]  Although Oracle owns the copyright on Java SE and the API packages, it offers an open source license, which is a license to use the code free of charge, both declaring and implementing code, with the requirement that the user “contributes back” its innovations to the public. See Oracle Am., Inc. v. Google LLC, 2018 WL 1473875, at *2 (Fed. Cir. Mar. 27, 2018) (“Oracle II”) (citing Oracle Am. Inc. v. Google Inc., 750 F.3d 1339, 1350 (Fed. Cir. 2014) (“Oracle I”)). 

[2] Jacobsen v. Katzer, 535 F.3d 1373, 1381 (Fed. Cir. 2008) (“Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material.”)

[3]  Oracle II, at *22.

[4]  Oracle II at *13-16.

[5]  Id. at *15 (“because the [copyrighted code] was already being used in smartphones, Google did not ‘transform’ the copyrighted material into a new context and no reasonable jury could conclude otherwise.”)

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Locke Lord LLP | Attorney Advertising

Written by:

Locke Lord LLP
Contact
more
less

Locke Lord LLP on:

Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
- hide
- hide