Public awareness on blockchains recently gained traction, for they are often tied up with the much-ballyhooed bitcoin cryptocurrency or some breakthrough application (e.g. car transportation, land titles, food-supply chains, digital rights management, etc). So far little has been written on copyright in blockchains though, while it is central in the blockchain architecture.
It is well known that Blockchains refer to data structure, where transactions are aggregated in non-editable blocks linked to one another, or in other words to innovative data storage features committing to secure, enhanced, real-time and cost-slashing solutions (ledger technologies).
License Architecture as a Leverage Tool
The elephant in the room is that blockchains are inherently linked to copyright licenses! Legal instruments on software are key, since they determine how blockchains are built up, then released. What about open-source licenses? many may say. Here is one common misconception that using open-source software is equivalent to getting rid of copyright altogether.
Open-source licenses are actual pieces of copyright. They are quite diverse, and they should by no means be considered a free ride pass. In general software licenses should be paid close attention to and, if properly thought through, the architecture of licenses can even help leverage key strengths.
Blockchain Development Process
Let’s wind back a bit to understand software development process. Blockchains are made of a ledger protocol, plus a network, plus various cryptographic technologies. Depending on specific needs, pre-existing systems and business models as well, blockchains can be tailored as one sees fit: open/closed/consortium blockchains, permissionless/permissioned networks, distributed/shared ledgers, centralized/distributed consensus.
In 2018 no one develops software programs from the ground up. To create a blockchain-based application, a team of developers will have to write lines of code, in addition to using the Bitcoin blockchain (or any other blockchain) and–instead of re-inventing the wheel–incorporating whatever pre-existing code components and/or modules are necessary on top of that.
Developers and Legal Staff to Interact
To state the obvious, compliance shall encompass each and every license involved in the process. Hence when resorting to open-source licenses (as opposed to proprietary licenses), permissive licenses are often preferred over copyleft licenses. Permissive licenses have minimal requirements about modified versions of the software; copyleft licenses are far more restrictive, for they stipulate that derivative works shall be governed by identical terms.
As a matter of fact, interoperability issues should arise at some point, with hopes it occurs during the design stage. Later on during the implementation stage, it might be already too late. That is why recording all codes that have been (or that are planned to be) used should be done from the very beginning, and appropriate communication between legal staff and developers should be initiated and streamlined. Right from the onset.
Otherwise… the elephant in the room might cause great embarrassment.