What’s blockchain? Software. And what happens with software nowadays? Software innovation models rely on open source as a cornerstone for software development. Thus, it is not surprising to see technologies such as Distributed Ledger Techs (DLT), and more specifically blockchain in this case, to rely on open source innovation and business models where both ‘open’ and closed proprietary models interact via hybrid business models.
In a former post – in Spanish – I analyzed the legal features and risks to take into account when it comes to design an IPR policy for a blockchain consortium, relying to a certain extent on open source and more specifically integrating standard essential patents within its policy. The case that I am about to analyze exposes several risks that an open source (or similar) project can potentially bring to the company’s desk, in this case in a blockchain/cryptocurrency software development process.
Preliminary stages of a nice European IP & blockchain case:
In the present case – Jelurida IP B.V. v. Apollo Fintech, LTD. case C/13/686678, according to the Court’s decision for an activation of a preliminary injunction from Jelurida’s side, both Jelurida and Apollo are two fintech software companies. The former is based in Switzerland and develops/maintains the ‘Nxt software’ enabling the ‘Nxt Blockchain’, by means of which companies can create their own crypto-tokens, among other things; and the latter is based in Hong Kong and offers the ‘Apollo currency’ a blockchain-based cryptocurrency.
Jelurida was established back in 2016, but already before its creation the Nxt software was already alive, since already three years, as it popped up in 2013 in GitHub with a mix of two different open source licenses, the MIT license (permissive/commercial) for the UI user software, and the GPLv2 license (restrictive) integrated within a Developer Agreement, for the Nxt software. At this time, the developers were individuals running fictitious names. Once Jelurida was created, some of the developers of the Nxt software (4) agreed to transfer their IPRs – copyright – to Jelurida, one can guess they were part of Jelurida’s team or had signed a prior commitment with the firm. Since then, Jelurida made the Nxt software and its source code available to third parties under the «Jelurida Public License» («JPL»), which in short, is similar to the GPLv2 while it integrates specific technical terms for the blockchain space (thus, the Nxt software license changed from the GPLv2 to the JPL).
When it comes to Apollo, back in 2018 it developed the Apollo Currency and made it available online. As it was based on the Nxt software, Apollo complied with the JPL license, and besides, integrated the JPL license on a ‘LICENSE.txt file in its GitHub account. However, more than one year later, in 2019, Apollo removed the JPL text from its account (the license does not appear in its version 1.44.2) and re-integrated it almost one year later when releasing version 1.44.3.
Due to the lack of the JPL license in Apollo’s GitHub during a period of 10 months between 2018 and 2019, Jelurida claimed by means of a preliminary injunction in the Netherlands – Amsterdam, as – supposed – ‘owner’ of the software and related copyright, a break of the licensing terms from Apollo’s side.
Regarding the ownership and right to exploit the Nxt software. The parties are heavily disputing the ownership of the Nxt software and the lawfulness of Apollo’s use of the Nxt software. On the first element, the software was originally developed by 14 developers, the question remains whether all of them assigned their respective copyright on the code contributed to Jelurida, which apparently is not the case. From this basis, Apollo holds that Jelurida cannot solely exploit the Nxt software under the JPL license.
For the time being, according to the Court, this is not sufficient to presume that Jelurida is not entitled to exploit the Nxt software: “It would have been Apollo’s responsibility to clarify which of these core developers are actually asserting rights to the Nxt Software and that they have not actually granted permission for Jelurida to exploit the Software”.Besides, the Court does not see sufficient proof material for the moment being to achieve a conclusion on the ownership rights of the Nxt software, however, it concludes, at this stage of proceedings, that Jelurida might exploit it under the JPL license. (Sidenote: under Dutch law, indivisible works might be enforced individually by each of the contributor to the work, unless agreed otherwise – Art. 26 of the Dutch Copyright Act – translated by Mireille van Eechoud here).
Regarding the copyright infringement. Apollo holds that the modification of the Nxt software from its side by adding 400,000 code lines has led to a substantially different product which thus qualifies as an independent work from the Nxt software. Jelurida, from its side, submitted an expert report comparing the code base of the Nxt public blockchain platform to Apollo’s code base. The expert found that “Between 60% and 73% of the functions of the Nxt Software correspond to at least 50% of the functions of the Apollo Software. Three-quarters of those corresponding functions are identical. Of those corresponding functions, 93% of the code lines can be traced back to the core developers of the Nxt Software”. So far, according to the court “Apollo is likely to have infringed Jelurida’s copyright in the Nxt Software (…) by copying a significant part of the Nxt Software code, to the extent that it was not authorized to do so under the JPL”.
Finally, on the grounds of compliance with the JPL license. The discussion is based on Apollo’s removal of the JPL text from the LICENSE.txt file, even though it alleges to have maintained the JPL in the source code and has moved the license to the 3rd party licensed file. Besides, it included an additional license for the added new code, it was the only copyright holder in the LICENSE.txt file and did not included a JPL copyright notice in the software package of its version 1.44.2. The latter facts amounted to a violation of JPL’s Sections 2.1, 2.2, and thus a revocation of the permission to modify and distribute the Nxt software under Section 5 of the JPL license. In words of the Court: “in line with what has been considered (…) makes it prima facie plausible that Apollo has infringed the copyrights of Jelurida”.
To be continued…
There are some promising quids not resolved (yet) at this preliminary stage of the process. For instance, what share of the source code is owned by Jelurida? And, with regard to it, as held by the Court: “Whether the Nxt tokens – in which the core developers (…) are indicated by a pseudonym, and which are provided with a GPG public key and a Nxt account number – can be qualified as written documents showing the intentions of the parties, signed by the party intending to transfer the copyrights, partly depends on the question whether the authenticity and identity of the parties mentioned therein can be established with sufficient certainty”. Last but not least: Are all developers’ copyright transfers to be assessed under Dutch law? (concerning this case, according to Art. 47 of the Dutch Copyright Act – translated by Mireille van Eechoud here, the law only applies to works that have been published for the first time in the Netherlands).
Practical insights regarding open source strategy:
Do not obviate/underestimate the role and prerogatives of the sponsor:
The sponsor of the project is the one who starts and does the foreground investments on the project, normally. Subsequently, it can relinquish the control over the software due to new entrants which might co-lead the project with the sponsor – e.g. share the leadership. As a sponsor of an open source project, you might change the licensing conditions over the software, or over some specific parts of it, during the lifetime of the project. This prerogative is sometimes underseen by contributors and implementers of the software which, suddenly one day, might realize that the licensing conditions have changed since already several months and they are not complying with the licensing conditions (or they are giving away their software developed on the basis of the open sourced one). Check periodically the licensing conditions of the open source software you are using or contributing to, and do not just check the file LICENSE.txt in GitHub, for instance, but rather all the files (and the source code).
Be transparent and clear:
It is advisable to place/attach the open source license in a file like ‘LICENSE.txt’ so as to avoid any potential issues as in the present case, even if the license might also be integrated within the source code (not so easy to target among all the source code and sometimes you need to have a specific software tool to track it) or in a different file with other information. You must provide the FULL license text, not just a simple reference to it. Be as clear – and diligent – as possible (same with the copyright notice), as non-compliance with the license might entail infringement of IPRs granted by the license – i.e. ‘you do not comply = license termination = you do not have a license and you are implementing a copyrighted product = copyright infringement’. The Hamburg Regional Court in Welte v. Fantec – 14/06/2013 case 208 O 10/13 – here a post in English, already pronounced itself on the valid enforceability of the GPLv2 and the obligation to provide the source code (and what does it mean).
So, so, so…What’s coming next?
In the next weeks we will be discussing practical considerations dealing with collective defensive patent mechanisms (and open source) in the blockchain and crypto space, on the one hand, and afterwards in another post we will analyze the Cryptographic Autonomy License, promulgated by Holochain and approved few months ago by the Open Source Initiative (and potentially the Jelurida Public License, which is not an open source license but it is based on one and integrates specific blockchain contractual clauses).
Un abrazo, amigos.