The Blockchain & The Bazaar

Photo by Roberto Lopez on Unsplash

IP Law exists to incentivize creation and accomplishes this by artificially restricting the distribution of a creation so that the creator can charge for that creation.¹ Like any tangible product of labor, IP Law insists that the creator of a work should be considered its owner, so that the creator may derive economic value from it. Furthermore, if the law could not sufficiently protect a creator from infringement, then society will suffer from the lack of creators willing to create anything.

Yet, even in the absence of such incentives, people continue to create.² Extrinsic motivations such as monetary gain may play a very insignificant part. Put another way, humans will create for seemingly no monetary benefit at all. Those from the open-source software community, affectionately known as “hackers³,” tend to believe that the true value of a software is realized only when it is freely shared and improved upon rather than locked up and controlled by a single owner.⁴ These hackers inhabit a plain of ideas, a space so vast that it encompasses all possible ideas, good or bad.⁵ Within this vast plain, a community is formed. This community is dominated less by the drive of capitalism, and more by a gift exchange culture, where value is derived from the reputation and trustworthiness that is bestowed from providing a beneficial software to others.⁶

The open-source community has thrived by sharing ideas, information, and resources, instead of excluding others from those ideas. The way that the software is made, its “source code,” is more important than the software itself, because the source code is what contains the ideas from which more ideas can be adapted and improved upon. Proprietary software, by contrast, can only be used.⁷ One of the most famous examples of a successful open-source project is the Linux operating system, which is widely used today.⁸

The hacker community utilizes a commons-based peer production model, where an indeterminable number of contributors offer new software or improvements to an existing software, freely sharing the work to then be built upon by others.⁹ It is from this open, decentralized form of information gathering, exchange, and review that the best possible product springs forth. For those in the open-source community that believe strongly in this model, it is because the alternative would limit the sheer number of ideas offered. Large companies, by excluding the number of people with access to the source code, also then exclude the number of ideas going in to help produce that software. The hacker community would argue that such exclusion would lead to an inferior software.¹⁰

The hacker community is at odds with this outcome and is therefore at odds with any law that would exclude the free exchange of ideas. In the words of Richard Stallman, “free software is a matter of freedom, not price.”¹¹ In other words, open-source advocates have no issue with the sale of software, but rather the restricting of the implementation, modification, and improvement of that software.¹² The Free Software Foundation created a “General Public License”(GPL) with the goal of protecting the rights of software creators by (1) copyrighting the software; and (2) offering a license that gives legal permission to copy, distribute, and/or modify the software.¹³ Since the GPL, there have been numerous other licenses created to achieve similar goals.¹⁴

The primary purpose of the GPL is to protect the freedom to share and modify free software. For the hacker who merely exists to create new things, the freedom to create those things would indeed be what matters most. But, humans are more complex than that. There exists a wide variety of extrinsic motivators, all of which could factor into a person’s desire to create or modify software. Even in the absence of capitalism, there is still competition within the gift exchange paradigm. Even as new projects continue to flow into the Internet, there can still never be a guarantee that any of those projects will ever get finished, or will ever be found and improved upon by someone else. While it can certainly be said that the open-source community can tout a great number of successes, it cannot be ignored that every success stands on a graveyard of failures.

To build an open-source project is to build in what is famously known as the “bazaar-style,” which is to focus on community-building rather than the software itself.¹⁵ Building a bazaar requires one to recognize the implausibility of starting out with a completely new idea, and it is instead suggested that the community form around at least a runnable, testable prototype.¹⁶ The bazaar model is contrasted with the cathedral model.¹⁷ While the bazaar is open, disorganized, chaotic, and indeterminate in size, the cathedral is confined, organized, closed, and finite. As the bazaar benefits from being able to draw from a potentially endless pool of ideas, many of those ideas are destined to be lost and buried before they could ever be properly utilized. For every pure creator that passes ideas as freely as a Faraday magnet¹⁸, there are even more creators that are not motivated nearly as enough. Furthermore, the hacker “community” has grown a great deal since the early days of Linux, and what was once described as a potentially infinite plain of ideas, with the explosive growth of the internet now resembles more of a multitude of plains, untraversable from one plain to the other without some sort of infrastructure. Lastly, for the bazaar model to remain feasible, the open-source community must readily adopt technologies that improve organization and structure in an increasingly decentralized hacker landscape.

Blockchain technology addresses these concerns in several ways. The implementation of a blockchain can provide much-needed organizational structure to the wild domain, provide a means for a creator to derive value from a software or give it away for free if the creator chooses, and even provide an added level of flexibility, control, and transparency with the licenses attached to the software.

In the first section of this article, I will discuss three major problems affecting the open-source community: (1) the trend towards decentralization coincides a trend towards software authors having less control over their work; (2) the lack of attention given to the motivation to maintain and improve software rather than just create; and (3) safeguards against plagiarism and piracy remain unsophisticated. I will then briefly discuss existing solutions in IP law for these problems and why these solutions have proven inefficient.

In the second section, I will provide an overview of blockchain technology, asset tokenization, and smart contracts.

Finally, in the third section, I will discuss how these new technologies will remedy the problems that IP Law presently struggles to contend with in the world of open-source software. By embracing these new technologies, it will allow the open-source community to scale up to a size much larger than previously possible without losing structure, both incentivize creation and encourage maintenance and “scavenging” of existing projects, and lastly provide a more reliable way to both detect piracy and plagiarism, but also help those accused of these offenses to be absolved.

ISSUES

i. Decentralization

In this age of such rapid technological advancement, the concept of “decentralization” has become a hot-button word.¹⁹ Decentralization aligns well with the open-source movement because the open-source movement is, by nature, decentralized. The concept is gaining traction in other aspects of daily life. Part of the reason why cryptocurrencies like Bitcoin are viewed as revolutionary is because it is decentralized. In other words, it is not attached to any banking institutions or governments. The decentralized social media movement is gaining steam because of the attractiveness of the concept of not having all your personal information being stored and controlled by Facebook.²⁰ The open-source community has always been ahead of the curve in this regard because no hacker community is governed by any sort of leader to dictate how it operates, and members within the hacker community are free to share information with each other in any method they choose to, without having to store the data in an intermediary body. Decentralization aligns well with the bazaar-style production of software, and one can only expect an increasing number of technologies introduced to help facilitate rather than inhibit decentralization.

IP Law is not presently equipped to address this movement. If a software creator wishes to collaborate with others in a decentralized setting, in most instances, the creator must give his work freely. The creator cannot exercise any ownership rights over the software without any sort of agreement that governs the usage of the software. There are no terms and conditions put forth by an intermediary body like Github, which would exercise some level of control over the software stored on its platform.²¹ Currently, there are many licenses that can be attached to the software by the creator as a way to enumerate the rights the software author wishes to grant the recipient of that software. In practice, these licenses typically limit the amount of control a creator can exercise over his work.²² The GPL requires both the licensor and licensee to include the source code with the software so it can be freely modified, or even repackaged verbatim and redistributed. The GPL makes a point to note that it does not care whether you sell the software or give it away for free. But if the creator sells a product with its recipe attached to it, then that creator runs the risk of driving the value of the product to zero, since the licensee is free to just reproduce it and redistribute it for a cheaper price.²³ Not surprisingly, proponents of proprietary software are against the usage of licenses.²⁴ The giants in the industry, like Microsoft, are the entities who can be expected to vehemently protect their proprietary software. Companies like Microsoft understand that allowing the source code to be improved upon would create the risk of making the proprietary software obsolete and destroy its value. On the other end of the spectrum, a lone software creator does not belong to a large firm that works together to produce a profitable software, but instead collaborates within an environment where no one owns the software. Because a lone software creator likely could not afford a large team of skilled programmers to build a software, that creator is likely to avail himself in a landscape where he has essentially no rights to his craft. The creator can only sue for infringement if he asserts that he is the copyright owner²⁵, and even if the creator is successful in this regard, litigation for infringement claims can be expensive.²⁶ If IP Law is to progress and keep up with the technological movement trending towards decentralization, it must embrace technologies that bridge the disparity and enable smaller entities to exercise more control over their work.

ii. Motivation

Young hackers are moving away from the notion of having to stay in the same place of employment for long periods of time.²⁷ One of the motivations for participating in a gift exchange of software is to receive a reputational boost that one could point to as social proof of ability when looking for gainful employment.²⁸ If young hackers are not committed to stay long-term with their jobs in software development, then this part of the gift exchange paradigm falls apart. Whether they are unenthused or just unmotivated, young hackers are moving away from the paradigm of giving their work away for free simply for the purpose of procuring employment. Furthermore, those with the initial motivation to participate in the exchange in order to get the job are experiencing burn-out. Others are becoming disillusioned about their career choice and exiting the software development ecosystem entirely. If these programmers never want to touch software again, then the problem becomes even more obvious: the gift exchange is running out of gift givers.

In the very near past, it may have been a common view that the pecuniary incentive that accompanied gift culture was that the validation of skills could lead to a job with a FAANG company or some other high-paying tech job.²⁹³⁰ While the prospect of receiving gainful employment from a FAANG company might have been the end-all-be-all at one point, if that view is now diminishing, the motivation to participate in the gift exchange for this purpose also diminishes.

Much of the cited literature about the gift exchange culture does not contemplate this shift in hacker sentiment towards traditional employment. It has been well-established that humans tend to create things for various, hard-to-define reasons.³¹ Besides monetary incentive, it has been observed that hackers seek reputational benefits from participating within a community.³² The desire for economic benefit should not be discarded simply because there are other motivations at play.

In the absence of social benefits, there are very few motivating factors remaining to explain why a hacker would traverse a vast and hard-to-navigate landscape to seek out and improve an existing software, much less enlist the help of a community to help him do it. There is not as much emphasis placed on maintenance of a software as there is on software creation. There are many projects that are simply abandoned by their original creators. The reasons for the abandonment are numerous. The creator may lack the motivation to continue, or their job has become too rigorous to have the time to devote to side-projects, or the problem the programmer was attempting to solve has proven to be far above that programmer’s skill level. None of these reasons speak to the “worthiness” of a software to be heralded and protected by developers within the community and the consumers outside of it. The open-source community does not contemplate any kind of incentive for maintaining a piece of software beyond intangible boons like reputation among peers.

Licenses like the GPL present a problem for IP Law because in most cases, the licenses and IP Law are at total odds with each other. On one hand, there is a longstanding belief that software should not have an owner.³³ On the other hand, there is IP Law, which seeks to protect creators by artificially creating scarcity and give creators a better chance to derive economic benefit from owning those creations. The movement for free software would never support any notion that software should have an owner. So, in the absence of any social benefit one could receive, what benefit exists for a programmer who stumbles upon an abandoned project, desires to make improvements on it, but not be bound by the license to which it is attached? The GPL does not contemplate an expiration date for its terms. For any downstream conveyance made, the GPL automatically attaches to the newly conveyed software. The GPL does not differentiate conveyances from taking possession of a source code where no conveyance was made. It is reasonable, then, to conclude that any software to which the GPL is attached is covered by the GPL for far longer than the software would ever continue to be useful to the public, even if the software is clearly abandoned.³⁴³⁵ An abandoned work may remain abandoned, if there is not a strong enough incentive to modify it.³⁶ Contemplating a period of time after which all licenses would expire and allow an open-source “scavenger” to take a software free and clear may provide that extra incentive to maintain and improve upon abandoned software, especially for those entities primarily interested in deriving an economic benefit.

iii. Safeguards against Plagiarism

Lastly, tools to track and discourage plagiarism remain unsophisticated in the open-source community. As a result, the mechanism by which offenders are punished is hamstrung by human bias. Plagiarizing code without attributing credit to the original creator has always been, and continues to be, a cardinal sin in the hacker community. The channel by which plagiarizers are judged and subsequently exiled from the hacker community is a public forum where cases are presented, evidence is offered, and rebuttals are welcomed. But the community ultimately decides the fate of the accused, and if found “guilty” in the public eye, the sentence is ostracism.³⁷ The punishment for plagiarism in the programming community is harsh and effective. It achieves some of the goals of criminal law like discouraging recidivism, mostly because it almost certainly destroys the offender’s credibility inside of the community to the point where that offender will never rise to the level of influence they had before being outed for plagiarism. There is also a public good element within this punishment mechanism, because it discourages the members of the community from plagiarizing, for fear of the severe consequences. We may view that a plagiarizer being caught red-handed and subsequently outed and ostracized is justice served, but what about a member of the community who is accused but is actually innocent? Do they have adequate recourse to defend the claims against them? How does one defend against a plagiarism claim, especially when the work of the accused was developed and released after the allegedly plagiarized work? In the world of comedy, perhaps one of the more recent and famous allegations came against Amy Schumer, who defended clips of her routine that were very similar to the work of other comedians as “parallel thinking.”³⁸

It may be less apparent to the laymen, but like comedy, many programmers would consider coding to be an art form. Hackers start off with a problem and from that one problem there can emerge a seemingly infinite number of solutions, expressed in various different programming languages, and at varying degrees of complexity. When devising a program, a developer must first envision what the program must do in order to accomplish the task at hand. This involves diagramming and writing the instructions to the program in plain English, which is a practice commonly known as “pseudocode.”³⁹ At this point, the efficient and practical programmer will engage in another commonly held practice: “Don’t Reinvent the Wheel.” In other words, you can (and should) search Github for open source projects that already do at least a portion of what your program is intended to do, and then either fork the project or download a ZIP file of it. When the programmer first opens up the project file, the programmer is likely to find some non-functional code written in the form of a “comment.” That comment which almost always appears at the very top of the main file, will often have the name of the creator of the program as well as an email address to send questions and concerns, and then lastly, any instructions or restrictions the creator has placed on the use of the free program.

Furthermore, if the open-source project was taken from Github, then there will also likely be a “Read-Me” file, which usually contains any licensing information. Github encourages the developer to create a Read-Me file of their own or offers to automatically generate one on behalf of the developer. What the programmer does with this downloaded Read-Me text file and the commented code is entirely ethics-driven.⁴⁰ There is no mechanism written within any program found on Github that would flag code that had a commented signature from the original creator deleted or the Read-Me file text overwritten. A programmer is expected to maintain the original signature because doing otherwise would be considered immoral. But even though there is no huge impediment to plagiarizing, it is not so simple for a plagiarizer to copy a program wholesale and pass it off as their own by simply deleting a signature.

As stated above, coding is an art form, meant to be read and interpreted by humans, and therefore it must be written in a way that conveys that particular programmer’s interpretation of a solution to a problem. That interpretation will pass through many different phases of refinement based on a number of considerations such as readability, scalability, simplicity of the solution, and proper syntax. For example, a novice starts out writing what is known as “spaghetti code,” or long, discreet lines of code that are not organized in a simple, easy-to-read fashion, thus making collaboration very difficult because anyone besides the original programmer will not be able to understand how the program works and how to make modification and additions to it without breaking the original portion. The spaghetti code can be refined: similar objects can be grouped into classes, initialized variables can be protected and limited to a certain scope, and comments can be added to explain what each portion of the code does. A skilled programmer will not stop at simply writing a code that clearly conveys what the program is supposed to do, but will also consider the way to accomplish the task in the fastest amount of time and using the least amount of computing power. From inoperable pseudocode to an executable file ready to be packaged and run on other devices, this is the way in which a programmer births a program. But even with all these considerations going into the final product, the solution that the programmer reached was but one in the seemingly infinite sea of possible iterations of that program! A common misconception about software is that there is an “answer” like in mathematics. There may be a best solution, but even that is a subjective notion. There is no roadmap in coding for developing a new software, unless what you are trying to develop is something so simple and trivial that it provides no utility at all, for example, a program that prints “Hello World!” to the console. When you are viewing a finished code, you are viewing that programmer’s interpretation of the solution to a problem the programmer is trying to solve. That interpretation could be unique and creative, or it could be inefficient, imperfect, and obvious. Either way, it is much more difficult for two similar programs to reach a solution in the exact same, or very similar, way than a layman would think.

For all the aforementioned reasons, “parallel thinking” in programming is not common, but it is still a possibility. Given the fact that it is very easy to simply delete a program’s signature and ignore its license, and given that a person accused of plagiarism will likely be unable to prove themselves innocent, the open-source bazaar has proven to be lacking on both sides of the equation. Safeguards against plagiarism are unsophisticated, and the mechanism for punishment is a kangaroo court.

GPLs are meant to protect the rights of the author by copyrighting the software and granting the author the legal permission to copy, distribute, and/or modify the software. GPLs are feared by large companies, worried that their proprietary software will get “infected” by a licensed module, thereby exposing the entire program to being subject to the license. The GPL works great for companies that have the resources to protect their software in litigation.⁴¹ GPLs provide very little protection for a single hacker or a small community of hackers. The plagiarizer need only to disregard the moral code and cover their tracks well enough to likely escape detection and punishment.

BLOCKCHAIN, ASSET TOKENIZATION, AND SMART CONTRACTS

i. Blockchain

A blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a network.⁴² A ledger is a record of transactions, but the usage of the blockchain has been expanded to store digital representations of almost anything.⁴³ The first component of the blockchain, that it is shared, has to do with decentralization. There is no centralized body like a website or institution that owns or stores the blockchain. Instead, the blockchain is managed by a network of participating computers, which form the “nodes” of the network. Whenever a transaction takes place between two nodes in the network, all nodes in the network must agree to the validity of the transaction. In other words, all nodes in the network must reach a “consensus.”⁴⁴

The two most prominent consensus mechanisms are called “proof of work” and “proof of stake.” The “proof of work” model requires the computers to perform complex calculations that are hard to solve but easy for the network to verify. This process is called “mining,” and the computers doing the calculation are the “miners.”⁴⁵ Proof of stake is the second type of consensus mechanism used by blockchain networks to achieve distributed consensus, but instead of miners, the participants in the network are called “validators.”⁴⁶ Validators are responsible for the same thing that miners are responsible for in the proof-of-work model: ordering transactions and creating new blocks so that all nodes can agree on the state of the network. Proof of stake boasts the following improvements over the proof of work system: (1) better energy efficiency; (2) lower barriers to entry, i.e. you do not need expensive hardware with a lot of computing power to create new blocks; and (3) stronger immunity to centralization, as proof of stake should lead to more nodes in the network.⁴⁷

Instead of having one centralized entity that determines the validity of a transaction, there instead exists a collection of nodes connected to a blockchain. Proof-of-work or proof-of-stake are required to determine which node will add the next block (the next bundle of the latest transactions) gets added to the blockchain. In proof-of-work, a node is more likely to add the next block if it has more computational power. In proof-of-stake, the right to validate transactions is directly correlated to the number of tokens a validator has in the validator’s wallet.⁴⁸⁴⁹ The proof-of-stake system is being increasingly utilized in the blockchain technology space for any industry that is trending towards decentralization.⁵⁰ If the open-source software community embraces blockchain technology, it would have to do so by implementing a method through which various participants both inside and outside the community can securely transact with each other, and proof-of-stake is the most efficient consensus mechanism for accomplishing this.

ii. Asset Tokenization

Asset tokenization is the process of converting legal assets that have economic value into a digital token which can be stored on a blockchain.⁵¹ A digital token is a piece of software with a unique asset reference, properties, and/or legal rights attached.⁵² A digital token can be used to represent virtually anything, and the possibilities of asset tokenization are continuing to be explored. One of the most intriguing properties of asset tokenization is “fractionalization,” or the ability to divide up the interest in a unique, non-fungible asset and then transfer that interest in the form of these tokens.⁵³

iii. Smart Contracts

The last component of these new technologies is the smart contract. A smart contract is not a contract in a legal sense, but a program that runs on a blockchain. Users can interact with the smart contract by making a transaction which causes the contract to execute a function. The smart contract can define the rules of the transaction and then automatically enforce them without the need for oversight.⁵⁴ Smart contracts are permissionless, meaning anyone who can code can make a contract.⁵⁵ Smart contracts are composable, meaning other contracts can be called inside of other contracts and also deploy other contracts.⁵⁶ Lastly, smart contracts are secure because they cannot automatically incorporate external information and execute based on real-world triggers.⁵⁷

The adoption of these technologies will be instrumental in the success of the open-source community’s future. With the adoption of blockchain, the hacker community will be able to scale up to a size much larger than previously possible without losing structure. Utilizing smart contracts in a more open-range, decentralized environment will enable the hacker community to maintain the most effective elements of the bazaar model such as peer review, collaboration, and upvoting while keeping a clear, consistent record of ownership. By normalizing the tokenization of software, creation will be incentivized by giving hackers a new way to derive monetary benefit from their work. Better smart contracts will bridge the gap between IP Law and open-source licensing by incentivizing the maintenance and “scavenging” of existing projects, embracing the familiar reputational benefits that are already common and recognizable in the open-source community as well as establishing a clear path to ownership. Lastly, the adoption of blockchain and asset tokenization will provide a more reliable way to both detect piracy and plagiarism, but also help those accused of these offenses to be absolved.

DISCUSSION

i. Reaching Consensus

With the adoption of blockchain, the hacker community will be able to scale up to a size much larger than previously possible without losing structure. The hacker community is inherently decentralized, so taking advantage of a technology that is designed to be decentralized is the next logical step. There are numerous places across the vast landscape of the internet where hackers converge, with some never truly finding a home or discovering like-minded individuals that share the same passion. Instead of aimlessly bouncing around one website or forum to the other, or splitting time between different destinations, my solution requires hackers, hacker communities, and hacker websites to agree to cooperate on one blockchain.

The next challenge would be in deciding how these distinct communities will agree. These communities would need to agree on the following: who is the owner/author of the software; the price of the software; if the source code is free to be modified and redistributed, in whole or in part; and if not, when will it become free or under what conditions can it become free; and how to settle disputes. All these questions fall under the umbrella of establishing a clear, reliable protocol by which distant communities may transact with each other. The easiest way for decentralized hacker communities to transact with each other is to incorporate smart contracts. The terms for the usage of a particular software are freely shared between all parties belonging to the blockchain without the need for any sort of centralized governance for deciding how the software gets distributed. Furthermore, rights and restrictions can be clearly enumerated in the smart contract which remains on the blockchain.⁵⁸ If the author chooses to do so, the author can still use a license like GPL, but that license should be stored on the blockchain instead of being incorporated in source code. The immutability feature of the blockchain makes storage of all licenses on the blockchain the superior option.

Cooperating in a blockchain network will not impact the way hacker communities conduct their affairs. Bazaar-style open-source collaboration is a human-driven effort, and nothing should be done that would affect the way programmers meet, grow their communities, and reward valuable contributions. Hackers already participate in a loose mechanism that filters bad input out from good input, in a system of human-based peer review. On sites like StackOverflow⁵⁹ and Github, there are forums where users can ask questions and other users will either help them by offering an answer of their own or vote on a preexisting answer, and the best answer is pinned at the top. Blockchain technology merely provides the infrastructure upon which various communities can transact with each other in a reliable, transparent way.

ii. Incentives to Create, Maintain, and Scavenge

By normalizing the tokenization of software, creation will be incentivized by giving hackers a new way to derive monetary benefit from their work. Smart Contracts can offer a level of flexibility, control, and transparency that the GPL and other licenses cannot. Instead of relying on a standard template for protecting rights, the theoretical user interface would look something like a drop-down menu which would generate the smart contract after the user clearly defines his intentions in distributing the software. Acceptance of these conditions, whether that accompanies the payment of a fee or not, will be the prerequisite to gaining access to the stored software, and the transaction is subsequently recorded on the ledger. Tokenization also permits fractionalization, therefore allowing fractional ownership stake in the rights to a software. The benefits of this property are well-established⁶⁰, but it is unclear whether the most prominent licenses are fully up to the task of accommodating those benefits.⁶¹ GPL 3.0 requires modified works to be covered as a whole, while its predecessor GPL 2.0 was not as definitive.⁶² The commons-based peer production model only works if the software is modular, that is, it is easily able to be split into distinct parts and worked on separately before being combined.⁶³ Yet, with this need for modularity, the peer production model is also exposed to liability, especially in a decentralized environment where there is little to no oversight over how the contributors derive their contributions. This serves the purpose of furthering the agenda of the free software community, but it totally inhibits those hackers who do wish to derive economic benefit from their work.

The smart contract for the smart hacker will be customizable to suit his purpose. Similar to the way that ownership rights can be fractionalized by tokenizing, the modules within a software that are meant to be proprietary should be tokenized and made available for purchase from behind a smart contract. Because the software is tokenized, it will contain its own unique reference. Proprietary modules will also have a unique reference, and like all transactions occurring on the blockchain, the transfer of these modules will be easily traceable. The result of this is added transparency.

Better smart contracts will bridge the gap between IP Law and open-source licensing by incentivizing the maintenance and “scavenging” of existing projects, embracing the familiar reputational benefits that are in the spirit of bazaar-style development while providing a mechanism for adverse possession. In the context of this model, “scavenging” is the practice of searching for promising but abandoned projects and improving on them rather than beginning a totally new project. But in contemplating a mechanism for adverse possession, a hacker can also derive an economic benefit from scavenging, too.

In order to fully incentivize maintenance and scavenging, it must be made clear the benefit of finding communities of software that are already on the blockchain rather than starting completely anew. One way to accomplish this is already being tested in the crypto space with a process called “minting.”⁶⁴ Non-fungible tokens (NFTs) are tokens that are made to represent one-of-a-kind items like artwork. In order to be able to auction a piece of artwork, you must “mint” the artwork, which means you must generate its authentic key and pay the mining fee, or in simpler terms, pay the cost to have that new key added to the next block on the chain.⁶⁵ At the time of writing, it costs about $70–90 US dollars to mint a piece of artwork.⁶⁶ But once the artwork is minted and on the blockchain, its price can be modified, or the artwork can be bought and resold.⁶⁷ An artist can even determine the percentage in royalties to get from each subsequent sale.⁶⁸ Returning to open-source software, this “minting” fee creates a barrier to entry, much like the developer fees that Apple charges to use XCode or that Google charges to upload apps to its Play platform.⁶⁹⁷⁰ But in this context, for every new key generated, there must be a cost, while the cost to modify an existing work with an existing key remains zero. This not only incentivizes collaboration on projects with active communities surrounding them, but it also incentivizes scavenging, which in this context involves a community member hunting for abandoned but promising pieces of software.

iii. Safeguarding Against Plagiarism and Piracy

The adoption of blockchain and asset tokenization will provide a more reliable way to both detect piracy and plagiarism, but also help those accused of these offenses to be absolved.

Immutability is a crucial feature of blockchain systems. The ability to identify a unique piece of software and verify authenticity demands a system that cannot be altered or corrupted. Tokenizing software provides a more sophisticated safeguard against plagiarism and piracy thanks to this feature in blockchain. In tokenizing a piece of software, the creator registers the software with an authentic key which would replace the old practice of signing the program by adding non-functional comments within the code. Providing the creator with an encrypted key is, in fact, something that is already done. For example, when a software is “packaged,” or made ready to be delivered to all eligible devices through the Play Store or App Store, the package is encrypted so the source code cannot be reverse engineered. While it is unnecessary, and counterproductive, to maintain this level of security with an open-source program, the community can nevertheless benefit from such a feature in regard to signing the code with an authentic key because it provides a simple way by which that piece of software can be tracked.

Tokenization would ensure a level of authentication, verification, and immutability that would make plagiarism infeasible, thereby protecting both the creators of original works and the falsely accused. The process of “minting,” discussed in the above section, incentivizes collaboration and scavenging. It also discourages plagiarism. A long-standing goal in IP Law is to facilitate creators to derive economic value from the product of their labor, while at the same time discouraging infringement by making copying an original work economically infeasible.⁷¹ The problem that arises in this technological era, is that the overhead to copy source code is practically zero if you discount the computing power and the amount of storage space consumed. It is very easy to copy most open-source programs, and while most programmers do not seem to mind the mere practice of copying the work of another, the act of plagiarizing without giving due credit is viewed as an irredeemable sin. If widely adopted, the cost of minting should do its part in discouraging a petty hacker thief from taking a program and repackaging it as their own work. For the sake of argument, let us say that the cost to mint the project did not deter the thief. What happens next? Is it instant profitability? There are two results that are more likely. First, there will be a fast depreciation of the software, and second, public censure and ostracism. The reason for the first result is that in the open-source software space, a new software without a community suffers under the bazaar model. If a person cannot attract a community to surround the stolen software and ensure its consistent development, the thief is unlikely to derive a monetary benefit from it because that software will almost certainly become obsolete.

Plagiarizers are much less likely to get away with stealing source code if the system upon which all open-source programmers operate involves an immutable ledger. A person who sets up a profile on Github can download source code and upload it as their own without much of a problem. But if there was an immutable ledger on which that profile’s information was stored, that same thief would have to download the source code, erase the key, create an entirely new profile and then upload the source code as their own. The thief can make a new profile, but they can never hide the fact that they cannot change the date the profile was created, the number of projects they have, and the number of people with which they have connected. The timestamps would all be recent, and all other facts pertaining to the account would be visible to everyone, and immutable. Social proof is heavily relied upon in this day and age where everything can be published to the internet. Much like a Twitter “egg” troll account, less credence is given to those without a long paper trail of interactions. In similar fashion, a plagiarizer looking to pass stolen software off as their own is more exposed than ever, and if caught, there is nowhere to hide from an immutable record. There are longstanding mechanisms to flag and punish the offender which remain very effective. The punishment for stealing from the open-source community is ostracism and potentially a permanent ban from the platform.

CONCLUSION

If this theoretical model is accepted, the biggest challenge would arise in getting hackers to agree to participate. Blockchain technology is decentralized by definition. It incorporates many of the aspects that are heavily ingrained in the open-source hacker community, while addressing some of its shortcomings. The widespread adoption of these new technologies will not disintegrate the spirit of open-source hacking. Instead, they both embrace and amplify that spirit.

Citations:

1. Mark Lemley, IP In a World Without Scarcity, 90 New York University Law Review 460, 462 (2015).
2. Eben Moglen, Anarchism Triumphant: Free Software and the Death of Copyright (1999) (likening the inherent desire of human beings to create things on the Internet to Faraday’s Law, where if you wrap a coil of wire around a magnet and spun it, electrons flow from the magnet and through the wire. In this analogy, the internet is the wire, humans are the magnets, and software is the electrons).
3. See Eric Raymond, Homesteading the Noosphere, (2000) available at http://www.tuxedo.org/~esr/writings/cathedral-bazaar/homesteading/
4. Richard Stallman, Why Software Should Not Have Owners, www.gnu.org/philosophy/why-free.html (last visited Jan. 18, 2021).
5. See Raymond, supra note 3.
6. Id.
7. See Stallman, supra note 4.
8. Raymond, The Cathedral & The Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, 4 (2000) (Linux began from a piece of reused code from a project called Minix).
9. Yochai Benkler, Coase’s Penguin, Or, Linux and The Nature of the Firm, 112 Yale L.J. 7(2002)
10. See Moglen, supra note 2.
11. Stallman, supra note 4.
12. GNU General Public License Version 3, www.gnu.org/licenses/gpl-3.0.en.html (“[I]f you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.”)
13. Id.
14. Open Source Licenses by Category, https://opensource.org/licenses/category (last visited May 12, 2021).
15. Raymond, supra note 8, at 18.
16. Id.
17. Id., at 2–3 (describes the cathedral model as a centralized, isolated approach to building a software).
18. Moglen, supra note 2.
19. Decentralization definition, https://www.merriam-webster.com/dictionary/decentralization (In general, decentralization is defined as the dispersion or distribution of functions and powers). For usage in the context of blockchain, see https://aws.amazon.com/blockchain/decentralization-in-blockchain/ (Defining decentralization as “In blockchain, . . . refers to the transfer of control and decision-making from a centralized entity (individual, organization, or group thereof) to a distributed network. Decentralized networks strive to reduce the level of trust that participants must place in one another, and deter their ability to exert authority or control over one another in ways that degrade the functionality of the network).
20. Andrew Hayward, Why decentralization is the future for social media, (Jan 18, 2020), https://decrypt.co/16935/why-decentralization-is-the-future-for-social-media
21. GitHub is a code hosting platform for version control and collaboration that allows users to work together on projects from anywhere. https://guides.github.com/activities/hello-world/
22. GNU General Public License Version 3, https://www.gnu.org/licenses/gpl-3.0.en.html (“If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.”)
23. The problem with requiring a software author to include the source code along with the software can be analogized to movie theaters granting permission to bootleggers to record the theaters’ screenings. If $10 movie tickets had licenses printed on the backs that allowed reproduction and redistribution of movies played in theaters, the result would likely be that there would be several more copies, either in physical or digital form, that would exist. The mere existence of these extra copies, available for either a cheaper price or totally free, may hurt the movie theater’s sales. A license that requires an author of a software to give away the source code achieves a similar effect.
24. Moglen, supra note 2.
25. Lawrence Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, 139.
26. Rich Stim, Copyrighting Your Software — Why Bother? https://fairuse.stanford.edu/overview/faqs/software/ (last visited 5.12.2021).
27. Why Software Developers Leave, https://gitential.com/why-software-developers-leave/ (last visited May 12, 2021).
28. Moglen, supra note 2.
29. “FAANG” is an acronym for Facebook, Amazon, Apple, Netflix, Google, https://www.investopedia.com/terms/f/faang-stocks.asp
30. See Generally Moglen, supra note 2.
31. See Lemley supra note 1, at 487–494.
32. Raymond, supra note 3, at 11–12.
33. See Stallman, supra note 4.
34. GNU General Public License Version 3, https://www.gnu.org/licenses/gpl-3.0.en.html (The GPL states that “[i]f you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.” In making such a proclamation, the GPL aligns itself with what its drafters viewed as the best possible way to advance open-source software, but its terms achieve this by excluding anyone who would disagree).
35. Lawrence, supra note 25 (GPL relies on copyright law).
36. The problem with these licenses adhering to copyright law even in the event of abandonment can be illustrated in a case where a software developer acquires a clearly abandoned work, rebrands, repackages, and then sells it for a significant profit. The original author can make an infringement claim against this developer if it is found that the developer has violated the terms of the license. If the program meets the low barrier for the “originality” component of copyright law, but there are plenty of similar variants that exist, and the commercial success of the product was attributed more to the work put into marketing the software, does allowing the original author to be able to bring an infringement claim encourage or deter people from participating in the bazaar-style? See generally Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (Defendant violated the terms in an Artistic License by not including the original license in the redistributed software).
37. Richa Bhatia, Data Science Influencer Siraj Raval Admits To Plagiarism, Cites Work Pressure as the Reason, (Oct. 14, 2019), https://analyticsindiamag.com/data-science-influencer-siraj-raval-admits-to-plagiarism-cites-work-pressure-as-the-reason/ (popular YouTube educator was discovered to have plagiarized a quantum research paper).
38. Michael Tunnell, Did Amy Schumer Steal Jokes or was It Parallel Thinking? (Jun 3, 2016), https://medium.com/@MichaelTunnell/did-amy-schumer-steal-jokes-or-was-it-parallel-thinking-fabc20e9e13c
39. Pseudocode is ineffectual code written in plain English to describe what a program is supposed to do, https://www.geeksforgeeks.org/how-to-write-a-pseudo-code/
40. Raymond, supra note 3, at 24, 27.
41. See Oracle America, Inc. v. Google LLC, March 27, 2018, (conditions of the license were that the improvements of the code, or derivative code, had to be shared for free use. If somebody wanted to avoid this, but still use the APIs, or where they would be competing with the owners of the code, then they would need to pay a licensing fee. Google used the APIs without paying a licensing fee, but competed with Oracle’s product, which Oracle contended was a breach of copyright).
42. Definition of Blockchain, https://www.ibm.com/blockchain/what-is-blockchain.
43. Rita Matulionyte, Tokenizing Copyright: Can Blockchain Help with Arts Funding? (Oct. 31, 2019) (Article about artists being able to tokenize future copyrights to their projects to sell to investors for funding. The tokens represent equity in the project. When the project sells, the investors would get a share of the profits corresponding to the value of the tokens they bought. The investors would also be free to sell or otherwise transfer their tokens if they choose to).
44. Consensus is required in the world of digital currencies to address the issue of “double spending,” which would undermine the currency, https://www.coindesk.com/proof-of-stake
45. Ameer Rosic, Proof of Work vs Proof of Stake: Basic Mining Guide, (last visited May 12, 2021), https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/
46. Proof-Of-Stake (POS), (last updated Apr. 15, 2021), https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
47. Id.
48. Werner Vermaak, Crypto Staking Guide 2021, (Jan 19, 2021), https://coinmarketcap.com/alexandria/article/crypto-staking-guide-2021.
49. Tezos is an example of a cryptocurrency that uses the proof-of-stake consensus model. Tezos is a cryptocurrency and “self-amending crypto ledger” that relies on proof-of-stake consensus to add new blocks to its blockchain. Tezos token holders can choose to “delegate” their tokens to a validator, i.e. giving validators the right to use those tokens to participate in verifying a transaction. Or, if the Tezos holder owns at least 8.00 XTZ, the holder can set up a node of their own. The more delegated funds that node holds and receives, the greater the chance it has to produce blocks and earn rewards, usually in the form of more XTZ. Holders are incentivized to either delegate or set up their own node to participate in this proof-of-stake model. Tezos is just one example of the proof-of-stake model, https://tezos.com/. The second most popular cryptocurrency, Ethereum, will be switching from the proof-of-work model to the proof-of-stake model. Its benefits are easily apparent in the context of digital currency and blockchain technology, https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
50. Cardano is a blockchain and smart contracts platform that employs the proof-of-stake system. Cardano’s main applications are in identity management and auditing manufacturing processes in order to eliminate the market for counterfeit goods, https://www.investopedia.com/cardano-definition-4683961.
51. Mihai Malashevsky, Asset Tokenization & Legal Implications, (Nov. 27, 2018), https://malasevschi.wordpress.com/2018/11/27/asset-tokenization-legal-implications/.
52. Darko Stefanoski, Orkan Sahin, Benjamin Banusch, Stephanie Fuchs, Silvan Andermatt, and Alexandre Quertramp, Tokenization of Assets: Decentralized Finance (DeFi), Vol. 1, 12, (2020), https://assets.ey.com/content/dam/ey-sites/ey-com/en_ch/topics/blockchain/ey-tokenization-of-assets-broschure-final.pdf
53. Id.
54. Kevin Ziechmann, Introduction to Smart Contracts, (last updated Mar. 29, 2021), https://ethereum.org/en/developers/docs/smart-contracts/
55. Id.
56. Id.
57. Id.
58. See Lawrence, supra note 25. (There is a recognized distinction between licenses and contracts which turns on assent. By requiring a user to accept the terms of a license or smart contract before downloading, the distributor of the work would not have to be considered the copyright owner to pursue a contract claim).
59. According to the About page on Stack Overflow, it is a public forum “used by nearly everyone who codes to learn, share their knowledge, collaborate, and build their careers.” https://stackoverflow.com/company
60. Nicolas Weber, The History of Art Tokenization, Part II, (Feb. 6, 2021) https://beincrypto.com/the-history-of-art-tokenization-part-ii/ (arguing that tokenizing art allows for easier access to the market).
61. GNU General Public License Version 3, https://opensource.org/licenses/GPL-3.0 (“You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, . . . to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission of you have separately received it.”)
62. GNU General Public License Version 2, www.gnu.org/licenses/old-licenses/gpl-2.0.html(“These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.”)
63. Yochai Benkler, Sharing Nicely: On Shareable Goods and the Emergence of Sharing as a Modality of Economic Production, 114 Yale L.J. 273, 276–77 (2004).
64. Grace Kay, Selling Crypto Art Can Come with Huge Hidden Fees, Leading Some People to Lose Hundreds of Dollars, (Mar. 14 2021, 6:13 AM), https://www.businessinsider.com/nft-investing-crypto-art-what-is-a-gas-fee-explained-2021-3
65. Id.
66. Shashwat, How Much Does It Cost to Mint an NFT? (Mar 15, 2021), https://nerdschalk.com/nft-minting-cost/
67. I read this on the OpenSea website, which is an NFT marketplace, when I attempted to auction of piece of art myself. https://opensea.io/
68. Id.
69. The Apple Developer Program charges an annual fee of $99 USD. https://developer.apple.com/support/purchase-activation/#:~:text=Pricing,currency%20during%20the%20enrollment%20process; See also https://developer.apple.com/xcode/
70. Google charges a one-time fee of $25. https://www.androidauthority.com/publishing-first-app-play-store-need-know-383572/
71. Lemley, supra note 1, at 482.