- Understanding Free And Open Source Software
- FLOSS And Rights
- The Ownership Problem Of FLOSS
This paper builds upon the theories of ownership and property developed by Anthony Honoré and Stephen Munzer and looks at what ownership of a digital good, specifically here Free, Libre and Open Source Software (FLOSS), looks like. The aim is to understand ownership of FLOSS in terms of rights and to assess their distribution between custodian (creator/developer) and user. The research made here will be guided by the question as to who specifically owns FLOSS and how and to whom the rights of ownership are distributed to.
The first section will introduce important vocabulary (Software, Free Software, Open Source Software) and make clear the underlying assumptions made here and on what theories those are built upon. It will help us gain an understanding of the FLOSS movement and the main device by which FLOSS rights are distributed: licenses.
In the second section we will analyze FLOSS in terms of rights. The theory of ownership used later on will be based on certain relations of rights-distributions between two parties. The analysis happening here will be the groundwork to understand FLOSS in terms of ownership.
Building upon that, the third section will introduce Honoré’s theory of ownership whilst also touching upon Munzer’s theory of property. It will then look at FLOSS and answer the question whether such software can be owned according to Honoré’s theory of ownership.
This will allow us then to answer the question as to who “owns” FLOSS and if said “ownership” resembles the traditional concept of ownership. The last section will then very briefly sketch out what a theory of ownership for digital goods could look like.
2. Understanding Free and Open Source Software
Before we start with the analysis of the rights distribution I will define and elucidate the core concepts and terms which are of vital importance for understanding the matter at hand.
Since we are going to be talking about Software a lot, it is important to at least be able to grasp what is meant by software here. I will follow the definition of software put forward by Suber which defined software roughly as a digital “pattern that is readable and executable by a machine”1. This definition is neither airtight nor is it without its flaws but it is close enough and luckily, since the matter at hand ist not heavily dependent on our definition of software, it will suffice for our purposes.
2.2 Free Software Definition
What does it mean for software to be called “Open Source” or “Free” and in what relation do those terms stand to licenses? Since Open Source, both the term and the movement, originated from Free Software, we will look at the term “Free Software” and the Free Software Foundation first.
In “What is free software?”2 the Free Software Foundation explicitly names the criteria that make a certain software free. “Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software”3. It is important to note here that the Free Software Foundation uses the term “freedom” incorrectly. All the “freedoms” named above are of course first and foremost rights given to the user. “Free” does not mean that such software should have no price, be free, it means that such software is liberated and grants the users freedom.
It does of course not help that most free software is both, free to purchase and free as in granting liberties to the user4.
Later on in the article, the definition is broken down to four freedoms (freedoms 0-3) which enable the rights named above. In Hohfeldian terms those freedoms would be something equal to privileges. If all four freedoms are met by a certain software we can speak of “Free Software.”5
There are two things I want to point out: Firstly, it makes a lot of sense to think of the four essential freedoms in terms of rights. They grant rights to the user and take a lot of rights away from the developer/creator/custodian. They do not place restrictions or duties on the user (in most cases) but some on the developer/creator/custodian (more on that later). Secondly, the vehicle that allows software to grant rights and place restrictions to/on users and developers are licenses.
2.3 The Open Source Definition
“The Open Source Definition” names ten criteria that need to be met for software to be Open Source. Such software needs to meet the following criteria6:
- Free Redistribution (there are no costs associated with redistribution)
- Source Code (is included)
- Derived Works (are permitted)
- Integrity of The Author’s Source Code
- No Discrimination Against Persons or Groups
- No Discrimination Against Fields of Endeavor
- Distribution of License (license is attached to the software)
- License Must Not Be Specific to a Product
- License Must Not Restrict Other Software
- License Must Be Technology-Neutral
If a software license meets all those criteria, it is Open Source software7. The definition for Open Source is more technical compared to that of Free Software: the last four items are not so much part of ideological thinking as they are part of legal thinking. The annotated version of the Open Source definition explains that those criteria are mostly to avoid “license traps”8. But if we look at the other criteria we do see that they are not that different to the four freedoms discussed above: the user has the right to redistribute the software, he has access to the source code and derivative works are possible.
2.4 Free, Libre and Open Source Software
Both institutions clearly state that the means through which one can achieve their software to be Open Source or Free is through the licensing of said software. They both have lists on their websites9 which list all the licenses they found to be in order with their catalogues. The Free Software Foundation, in contrast to the Open Source Initiative, does not only assess third party licenses, they actively develop and maintain a free software license (as fig-1 will show, it also meets the criteria of Open Source) called the GNU General Public License (GNU GPL or just GPL) and two derivatives of that license. The GNU GPL is of course the license most recognized with free software. The Open Source Initiative maintains no such efforts, they solely assess licenses by third parties.
If we look at some popular licenses in Table 1 and look at by whom they are approved (OSI and/or FSF) a quite interesting picture emerges10.
|License||Open Source||Free Software|
|CDDL-1.0||Yes||Yes, incompatible with GPL|
|EPL.1.0||Yes||Yes, incompatible with GPL|
|CC0||Not officially approved||Yes|
It becomes obvious when we look at those popular licenses that it does not matter into what camp one falls11. Since this paper is concerned with legal rights and both institutions are approving pretty much the same licenses, we will be treating Open Source and Free Software as derivatives of the same thing: FLOSS12. We will also see when looking at FLOSS in terms of rights that both movements are talking about the same rights, legally speaking. They must be talking about the same thing, same licenses grant the same legal rights.
Chopra and Dexter tried to assess the difference between Free and Open Source Software and concluded:
While the FSD and OSD fundamentally agree on the nature of software freedom, they enumerate these freedoms using radically different language; there is much moral and instrumental significance in this difference13.
They make several important points in this conclusion. The first is that there is some fundamental form of agreement between those two institutions: They approve of the same licenses. Ideologically and in their wording, though, they are very distinct. Which lets them conclude that they enable different moralities but: in terms of legal rights, both enable the same rights because the same licenses are approved. Whether moral rights equal legal rights is another discussion worthy of having, albeit not one to be discussed here.
The discussion will further on focus on the Open Source Definition because it is much more fine-grained and captures everything present in the Free Software Definition with a more detailed description.
Let me summarize: This section helped us gain an understanding of what software is and what we will mean when we talk about FLOSS. It also argued in discussing both Open Source and Free Software why we will be able to merge those two in the further discussion. Merging those two together is of importance because it let’s us discuss a broad part of software licenses in one swoop.
The next section will introduce Hohfeld’s theory of rights and we will then look at the Open Source Definition and assess the rights enabled and disabled by it’s licenses following a framework created by Douglas for looking at software and their rights distribution.
3. FLOSS And Rights
The last section helped us gain an understanding of the core terminology and concepts we will be using. It also made a first nod as to what exactly we will be looking at: The rights distribution of a license that meets the requirements for software propounded by the Open Source Initiative.
3.1 The Hohfeldian Theory Of Rights
Hohfeld’s theory differentiates between 4 types of “fundamental legal relations” that all come in bundles of correlatives14.
- privilege - no-right
- right - duty
- power - liability
- immunity - disability15
Some confusion by Hohfeld’s theory was generated by his usage of the term “right”. All of the types of legal relations listed above are usually thought of as rights but he exclusively used “right” to describe one side of those relations. What he understands as a right, the correlative to duty, can also be understood as a claim or a rights-claim16. His intention in using the term in such a way was to narrow the very broad and undifferentiated usage of the term he found to be present in judicial reasoning17.
This means that if Linus has the privilege (most modern philosophers have used the term liberty) against Richard to access the source code of a certain software, that Richard has a corresponding no-right against Linus that Linus not access the source code. Hohfeldian rights are always two-person relations (no more, no less). The same scheme applies for the other three rights-correlatives: If Linus has a right that Richard help him develop a C-Compiler because Richard promised so, Richard has a correlative duty to help Linus develop said C-Compiler and so on.
Although rough, this short section already shows how powerful the Hohfeldian theory is for the matter at hand: due to its dual nature, it will allow us to examine exactly what we want: the rights distribution between a rights holder (developer/owner/custodian) of a certain software and the user of a certain software18. Every right we will be analyzing is distributed between a user and a rights-holder and the Hohfeldian theory will allow for a proper analysis of those rights.
3.2 Software rights
David Douglas has developed a framework based upon the works of Honoré and Hohfeld for assessing software licenses in terms of “how various rights and duties over software are shared between owners and users”19. The framework he developed presupposes that ownership of software is possible and it understands ownership of software as something that grants rights as well as that it poses duties for both the user and the developer20. His framework is a list of rights (access, use, read, attribute, duplicate, reward, transfer, imitate, modify, responsibility, distribute, decompile, reuse, revenue, manage, assign) that are in a user - custodian relationship. The list of rights should be exhaustive enough to be able to assess any software license in terms of rights. So for example a license that grants the right of reuse grants a right (privilege) to the user and has a correlating no-right for the custodian, which very much applies to the Hohfeldian scheme of correlatives briefly discussed above21. Douglas’ framework also makes the important distinctions between creator, custodian and user: “The creator is the party who originally wrote the software, while the custodian is the party controlling how others can use the software. The creator and the custodian will often be the same.”22.
This distinction will be important later on when we will be looking at the problem of ownership for FLOSS.
Douglas’ framework is not flawless. It is not exactly clear why those rights, and only those rights he names are constitutive for the assessment of a software license, they do, however, capture all the aspects present in the four freedoms that have to be met by free software, as his own assessment proves.23
What seems more puzzling though is that only the custodian-user relationship is covered by the framework. Why, since he already makes that distinction, is the custodian - creator relationship not covered? His statement that custodian and creator often fall together is highly questionable at least, if not plainly wrong. The one-man shop approach to software development is a thing of the past and almost every software is developed as a team effort with multiple creators. This is especially true for any variant of FLOSS. Most proprietary software has one clear custodian, usually a legal entity such as a corporation. FLOSS usually doesn’t, which is of course a conundrum that remains unsolvable when using a Hohfeldian theory. Douglas also overlooked another important thing, he thinks that “it is necessary to assume that software can be owned” in order for his framework to work24. As we will see in the last section of this paper, it is still a very useful framework even if no one “owns” the software directly, at least according to standard theories of ownership.
Despite its flaws, we will use this framework for the analysis of the Open Source Definition in the following section because it still provides powerful tools to assess how the most important rights, in terms of software ownership, are distributed between user and custodian/creator.
3.3 The rights distribution of Open Source Software
One important point has to be made here: Douglas’ framework was meant to be applied to software licenses. We will apply it here to the Open Source Definition, which is not a software license25. It is the building block that encapsulates every important aspect a Open Source License should cover. If a newly created license were to be found as Open Source, it would have to meet the rights the Open Source Definition enables, which is what we will be assessing. For that it is necessary to have a closer look at the first four criteria put forward by the Open Source Initiative.
Points 5,6,8 & 9 of the Open Source Definition are all worded negatively: 5.No Discrimination Against Persons or Groups, 6.No Discrimination Against Fields of Endeavor, 8. License Must Not Be Specific to a Product, 9. License Must Not Restrict Other Software. That means that those points needn’t be explicit in the wording of a license, it means that wording violating those terms in a license would not be accepted by the OSI. Since they are not explicitly present in a license, I will disregard them in my further discussion. I will further disregard points 7 & 10: 7. Distribution of License, 10. License Must Be Technology-Neutral. Those cover mere technicalities and are used to avoid licensing traps.
All points named here (5-10) point to rights that are also not covered by the Douglas-framework. They are not covered by it because they are not concerned with the relation user-custodian, which is what we will be looking at.
The first four annotated points of the Open Source Initiative are:
1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of The Author’s Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.26
Point 1 of the definition enables first and foremost the right to distribute the software which Douglas calls a user privilege and a custodian no-claim right, which would be a user privilege and a custodian no-right in Hohfeldian terms. Distribution requires one to duplicate the thing that is to be distributed beforehand, hence the right to duplicate (privilege for the user, no-right for the custodian) is implicitly demanded. It also enables the right to revenue which gives the user the privilege to profit from selling the software whereas the custodian has the no-right to interfere.
The second point enables a couple of other rights: The right to read, which gives a user the privilege to read the source code and the custodian the no-right to not let the user read the source code. This enables implicitly also the right to access which is again a privilege on part of the user and a no-right on part of the custodian.
In it’s third point, the Open Source Definition enables the right to modify. The user is at liberty to take the source code and change it as he pleases while the custodian has a no-right against the user’s actions27. The right to modify also enables one serious omission from the Definition: The right to use. Douglas names the right to use (again:privilege for the user, no-right for the custodian) a prerequisite for the right to modify, which is of course right, modification is only possible if one uses something, thus must the right to modify enable the right to use. Also enabled is the right to reuse which allows a user to take parts or all of the source code and use it for some other software she is developing which is again a no-right on part of the custodian. The right to reuse has as a prerequisite, the right to imitate, which gives a user the privilege to imitate the functionality of a program without actually using the source code used by said program. This is again, a no-right on part of the custodian.
Lastly, the fourth point enables some important rights for the custodian. It may enable the right to attribute, which is a duty on part of the user, she can not claim non-derivative works to be of her own doing, and a rights-claim on part of the creator (not custodian)28. By opening up the possibility that derivative works would have to have different names, the fourth point also enables the right to manage which gives a custodian the power to oversee a project and also the immunity to do so. It is important to note here that a Open Source License may do so. It is not a requirement, which means that the right to manage may be enabled by some Open Source Licenses but not by others. The same is true for the right to attribute but every major license seems to enable the right to attribute.
In his analysis of Free Software Licenses Douglas also looked at so called Copyleft licenses, which are one special branch of FLOSS-Licenses. Such a license requires derivative works to carry the same license as the original work, which prohibits the bundling of FLOSS with or in proprietary software29. As Douglas rightfully notes “Copyleft denies users the right to manage in order to prevent them limiting the rights of other users”30. As Table 1 showed, the GNU GPL, which is a Copyleft license, is accepted by the Open Source Initiative. A Open Source License may therefore give a custodian the right to manage, disallow the right to manage to every user or be agnostic about it.
The case of Copyleft is special since it does not readily fit into the correlative scheme set out by Hohfeld.
In copylefting software, the custodian not only denies the right to manage to the user, she also denies it to herself.
Let me illustrate this: Linus writes software, which he licenses under a non-copyleft Open Source License which gives him the right to manage (The Apache2 license for example). If Richard were to make a derivative work, Linus would have a power over Richard concerning some factors of his derivative work. Consider the same scenario with a copyleft License: Linus does not hold any power over Richard, nor can he make successful claims: Richard may be under a liability but not against Linus specifically. In waiving the right to manage, Linus also waived his power over Richard. Richard may be under the duty to license his derivative work under the same license but Linus can not make any claims against him since qua licensing he does not have control over this matter anymore. But this is, of course, exactly the point: The right correlative has shifted, everyone could now make claims, legal claims, against Richard if he is violating his duty concerning the license of his derivative work. In giving up his right to power, no one can have power over the software anymore, this is what the copyleft clause in the license ensures, Linus gave everyone the right to make claims against Richard to uphold his duty whilst also affirming that every other right enabled by the software license be upheld in all future use cases.
To summarize, let us have a look at Table 2 which captures all the rights enabled by the Open Source Definition and how they are distributed.
|(Manage)||Disability and Liability||Power and Immunity (Creator)|
In summary, this section briefly sketched out Hohfeld’s theory of right correlatives and argued for the power in thinking of rights as correlatives. Next we discussed a framework developed by Douglas for assessing the rights distribution of software. In a third step we had another look at the Open Source Definition and used the Douglas-framework to evaluate the rights distribution of said definition. Since we now have an overview over the rights FLOSS enables, we will be able to gauge how those rights relate to standard theories of ownership. The next section will look at the theories of ownership and property created by Honoré and Munzer and after a discussion of those theories try to answer our main question: Can FLOSS be owned according to standard theories of ownership?
4. The Ownership Problem Of FLOSS
Now that we have almost everything in place, we only need to discuss one thing before we can start and try to answer the question that has been guiding us so far: Who owns FLOSS? The only missing piece of the puzzle are the standard theories of ownership against which we will be comparing the rights enabled by an Open Source License. The next section will do just that in that it will discuss the ownership theory by Honoré and the property theory by Munzer since those two theories and the terms they are about are heavily related. If something is someone’s property, it usually means that this someone owns this something. The subsequent subsection will get to the analysis of our main question.
4.1 Standard Theories of Ownership And Property: Honoré & Munzer
One thing we need to understand about the ownership theory put forward by Honoré is that it was published in 1961 and did not have digital goods in mind. His approach to ownership was, similar to Hohfeld, based on a legal approach, which led him to define ownership provisionally as “the greatest possible interest in a thing which a mature system of law recognizes”31. It was also based upon rights which led him to describe ownership as having certain rights (not all rights need to be present to be able to speak of ownership).
Those rights are: possess: means to have control over a thing “as the nature of the thing admits”32,use, manage: “how and by whom the thing owned shall be used”33, income of the thing: means to forego personal use but profit from the thing by letting others use it and earn income, capital: “the power to alienate the thing and the liberty to consume, waste or destroy the whole or part of it”34, security: to remain the owner over time, incidents of transmissibility: to be able to transmit ownership to someone else, incident of absence of term, prohibition of harmful use: “An owner’s liberty to use and manage the thing owned as he chooses”35, liability to execution: ownership can be taken away and Residuary Character36.
If all of those rights or at least most of them are present37, we can speak of ownership. Honoré may have thought of owning things other than physical goods but his theory is clearly best suited when used for actual, physically present things.
Munzer extends the theories of Honoré and Hohfeld and proposes a “sophisticated” understanding of property which means that “[t]he idea of property […] involves a constellation of Hohfeldian elements, correlatives, and opposites; a specification of standard incidents of ownership and other related but less powerful interests; and a catalog of things (tangible and intangible) that are the subjects of these incidents”38. Important to Munzer’s notion of property is that “property also includes less powerful collections of incidents that do not rise to the level of ownership”39. He calls those lesser instances of property “limited property”40. Munzer points out that understanding property in Hohfeldian terms has the advantage that one can more accurately describe the relations between persons and things when it comes to property. The disadvantage is of course that it is really difficult to know when the term “property” will be applicable and when it will not be. As Munzer himself admits his theory does not offer a clear answer as to what property is, but it allows for a clear path of assessment: After listing the rights present in a thing, we only need to decide whether those rights amount to “ownership, limited property rights, or something else”41.
4.2 Owning FLOSS
The analysis of the rights distribution of the ten point Open Source Definition revealed the following: a user of a Software licensed under Open Source has the privilege to distribute, duplicate, revenue, read, access, modify, use, reuse and imitate, the duty to attribute and depending on whether the creator preserves the right to manage a disability and a liability to manage or a duty to not manage. The custodian on the other hand has the no-right to distribute, duplicate, revenue, read, access, modify, use, reuse and imitate, the right to be attributed and depending on whether she reserves the power to manage a power and immunity against the user or a right.
What makes it difficult to speak about ownership or property relating to FLOSS is that the custodian - user role can be inverted at any time, as the user wishes: the so called forking of software projects.42 Such a fork could be done by any user that wishes to do so. It would usually mean that the forked project would carry on under a different name but contain the same software(source code)43.
Before we look at this problem in detail, let us first consider the ownership problem with fixed roles between custodian and user.
The custodian in our analysis has three possibilities as to how her rights are distributed: In any case she has a bunch of no-rights, a right to attribution and either the power and immunity to manage, the right to non-management or neither of those. So in the strongest rights scenario a custodian has the right to attribution and the right to manage. That is it. This reveals the fatal flaw used in my argumentation: We can not look at the custodian - user relation as fixed, it would otherwise mean that if anyone at all would own the software, it would certainly be the user, not the custodian. Someone holding only the rights to manage and to be attributed can not be called the custodian of anything. This also points to one flaw of Douglas’ framework, it is of course wrong to think that the custodian holds barely any rights and the user holds all of them, every right the user holds is also held by the custodian and it is not held by the custodian qua her being a user, it is held by her qua licensing. Or to put it another way, the custodian can only waive rights she possesses, therefore all rights that the user gains need to have been held by her at one point in time. Now, giving every one else certain rights means that those rights are shared by everyone but the original rights-holder still possesses them because everyone does.
The easiest solution to accommodate for this problem is extending the Hohfeldian terminology with another correlative (which is applicable to cases extending the dual nature of legal relations)
shared-privilege – shared-no-right
That is admittedly quite a mouthful but it captures the paradoxical case in which the custodian holds the privilege as well as the correlating no-right pretty neatly without changing much about underlying relations. A shared-privilege, as the name clearly states is non-exclusive, a right that needs to be held by more than one party by definition. Otherwise we would have to argue why a custodian would hold at the same time a no-right as well as the correlation privilege44.
We now have two questions to answer: Does the strongest case a custodian can have (power and immunity to manage is reserved by the custodian) constitute as ownership, limited property rights or else? And secondly, if we would come to think of the rights she has as sufficient, would they also remain sufficient if we accommodate for the case that every user can become a new custodian of such a software? Or to put this second question a little more bluntly, What difference remains between custodian and user rights-wise?
In the strongest case we can make, a custodian of a software that is licensed as Open Source has the shared-privilege to distribute, duplicate, revenue, read, access, modify, use, reuse and imitate, the right to attribution and the power and immunity to manage. Or in Honoré’s terms the custodian holds the rights to possess (only in a non-exclusive form), use, manage, income of the thing, incidents of transmissibility, incident of absence of term, prohibition of harmful use, liability to execution and residuary character. She lacks the rights to capital (can not be destroyed) and security in a strict sense (can be forked at any time). The user, on the other hand holds exactly the same rights, except the right to manage in the sense that the license of a derivative work can not be freely chosen.
If we were to only look at the rights held by a custodian in the strongest case, we could conclude that ownership is present and possible for FLOSS although the rights to capital and security were missing.This conclusion, however, would be blatantly wrong.
First, all rights present in the custodian are also present in the user with the exception of the right to manage and second, the core point to the rights Honoré named for ownership is that they are exclusive. Ownership is one’s exclusive right to income, one’s exclusive right to possess etc. Something that can only entitle one owner, not several. There can be of course several people benefiting from the same thing but this usually means that they all own part of something which is then again the legal owner of the thing they are benefiting from.
The easy way out would of course be to abandon the concept of ownership altogether, something that interestingly wouldn’t be the case for the concept of property, since we could very well argue that FLOSS describes a digital good which only allows for limited property, property namely limited by the fact that the rights to the property are shared.
What I think to be much more reasonable is what I proposed, to extend the Hohfeldian vocabulary and allow shared-privileges and shared-no-rights. Which then would mean for Honoré’s theory that we include the possibility of “shared ownership” and that FLOSS would be one of the poster childs for shared ownership45. One must always call to mind that the Hohfeldian theory was developed for clarifying judicial reasoning and that many common law practices are always dual in nature (plaintiff - defendant) and do not allow for more complex approaches (not that in itself law wouldn’t already be complex enough).
This point here is exactly where the Hohfeldian theory reaches its limits.
4.3 A New Kind Of Owners For Digital Goods
Ownership is something that is very much related to time. It may make sense to speak of Linus owning something at t whereas at t it could be completely nonsensical to argue that Linus owns the very same thing. That is to say that, of course there was once an owner of FLOSS, namely at those moments of time when it already existed but did not yet contain a license or a FLOSS license. As soon as something becomes licensed as FLOSS, it is not owned by anybody specifically anymore. If it is owned, it is collectively owned by everyone that uses it. Not by the creator, not by the custodian, not by Richard nor by Linus. The only thing a custodian could prevent is people using the same name and the same logo (things that can be trademarked and copyrighted even when using a FLOSS-license) for their derivative work (that need not be derivative at all). Therefore, even in the strongest cases possible is it so, that the custodian holds the same rights as the user does and that therefore, if we came to call the bundle of rights they share ownership over some property, then it must be shared ownership and distributed property.
As I said before, these findings do not take away from the traditional conception of ownership, they do extend it. Creators choosing a FLOSS-license do not so much give away their rights as they do share them. If we allow for our conception of ownership to extend beyond the exclusivity it’s standard understanding maintains, we open the doors for a new concept of ownership and even more so for a new kind of owner. Owners that think of their property as a commodity, something that is of more value to them (and in retrospect to anyone else) if they share the rights they have in said commodity.
The basis for understanding “ownership” of FLOSS has been laid out here and been argued for. The next question one would have to answer is what the moral implications of this kind of ownership are and more generally speaking how founded the ownership of proprietary software (which does have a clear custodian) is. A good starting point for answering those questions would be Lawrence Becker’s theory which is looking at the moral implications of property rights.46
After discussing Hohfeld’s theory of rights, Honoré’s theory of ownership, Munzer’s theory of property and Douglas’ framework of software rights we are finally able to answer the question that led us to the examination of all those theories: Who “owns” FLOSS? Does the “ownership” of such software resemble the ownership enabled by traditional concepts of ownership? These questions have been answered in full but let me repeat the answers here.
FLOSS does not have a specific owner. Nobody can be the owner of FLOSS because the rights that are necessary to own something are shared and not exclusive. The rights do not pertain to one entity. Every single user has the possibility to make derivatives of FLOSS and can therefore become a custodian with the same rights as the custodian before her.
The kind of ownership that is enabled by FLOSS does resemble traditional concepts of ownership with the one caveat that the relationship that defines those rights to ownership can be reversed at any time. Custodian can become user and user can become custodian. I proposed to extend the Hohfeldian correlatives with the pair shared-privilege and shared-no-right to avoid the paradoxical problems the constant reversal of roles poses. One can very easily hold a correlative shared-privilege as well as the correlative shared-no-right because both are shared and therefore not exclusive whereas it would be paradoxical to purport that someone holds a privilege whilst also holding the correlating no-right.
This paper, as I think, successfully showed that although traditional concepts of rights and ownership do not perfectly fit to FLOSS that they are still very powerful and capable tools that help a lot in understanding the complex distribution of rights that is enabled by FLOSS. It remains to be seen as to how exactly a theory of ownership for digital goods, one that is not specific to some licenses, would look and how much of its ancestry could be incorporated.If you liked this article you should have a look at a recent article I wrote. It looks further at the problem of ownership and software enabled hardware devices. Do you own your smartphone? Answers can be found here. Since you already read this article, you can skip the first two paragraphs and jump straight to the third section.
Becker, Lawrence C. 1980. “The Moral Basis of Property Rights.” Nomos 22. JSTOR: 187–220.
Berry, David M. 2008. Copy, Rip, Burn: The Politics of Copyleft and Open Source. London: Pluto Press.
Black Duck. 2016. “Top 20 Open Source Licenses.” Link.
Carey, DAVID H. 1993. “Should Computer Programs Be Ownable?” Metaphilosophy 24 (1/2). Wiley: 76–84.
Chopra, Samir, and Scott D Dexter. 2008. Decoding Liberation: The Promise of Free and Open Source Software. New York: Routledge.
Dean, Sam. 2016. “From ownCloud to Nextcloud: A Proven Cloud Innovator Launches a Promising New Platform.” Link.
Douglas, David M. 2011. “A Bundle of Software Rights and Duties.” Ethics and Information Technology 13 (3). Springer: 185–97.
Ernst, Neil A., Steve M. Easterbrook, and John Mylopoulos. 2010. “Code Forking in Open-Source Software: A Requirements Perspective.” CoRR abs/1004.2889.
Free Software Foundation. 2016a. “Licenses.” Link.
———. 2016b. “Various Licenses and Comments About Them.” Link.
———. 2016c. “What Is Copyleft?” Link.
———. 2016d. “What Is Free Software?” Link.
Hohfeld, Wesley N. 2010. Fundamental Legal Conceptions. as Applied in Judicial Reasoning. Edited by Walter Wheeler Cook. Clark, New Jersey: The Lawbook Exchange, Ltd.
Honoré, Anthony M. 1961. “Ownership.” Oxford Essays in Jurisprudence 107. Oxford: Oxford University Press: 107–47.
Johnson, DEBORAH G. 1985. “Should Computer Programs Be Owned?” Metaphilosophy 16 (4). Blackwell Publishing Ltd: 276–88.
———. 1993. “A Reply to ‘Should Computer Programs Be Ownable?’” Metaphilosophy 24 (1/2). Wiley: 85–90.
Munzer, Stephen R. 1990. A Theory of Property. Cambridge: Cambridge University Press.
Open Source Initiative. 2016a. “Licenses & Standards.” Link.
———. 2016b. “Licenses by Name.” Link.
———. 2016c. “The Open Source Definition.” Link.
———. 2016d. “The Open Source Definition (Annotated).” Link.
———. 2016e. “What Is Free Software and Is It the Same as Open Source?” Link.
Perry, Thomas D. 1977. “A Paradigm of Philosophy: Hohfeld on Legal Rights.” American Philosophical Quarterly 14 (1). [North American Philosophical Publications, University of Illinois Press]: 41–50.
Robles, Gregorio, and Jesús M. González-Barahona. 2012. “A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes.” In Open Source Systems: Long-Term Sustainability: 8th Ifip Wg 2.13 International Conference, Oss 2012, Hammamet, Tunisia, September 10-13, 2012. Proceedings, edited by Imed Hammouda, Björn Lundell, Tommi Mikkonen, and Walt Scacchi, 1–14. Berlin, Heidelberg: Springer.
Suber, Peter. 1988. “What Is Software?” The Journal of Speculative Philosophy. JSTOR, 89–119.
Vetter, Greg R. 2008. “Claiming Copyleft in Open Source Software: What If the Free Software Foundation’s General Public License (Gpl) Had Been Patented.” Mich. St. L. Rev. HeinOnline, 279.
Suber 1988, 94↩
Free Software Foundation 2016d↩
Free Software Foundation 2016d↩
And it never will have a price for every user. Since access to the source code is one of the prerequisites, a technically well-versed person will always be able to compile software themselves from the source code and make it executable.↩
Looking at those essential freedoms in more detail would show us that Richard Stallman’s (founder of the FSF and author of the four freedoms) first thoughts about free software were not of the legal kind. He mostly had the end-user in mind, not the profits and the intellectual property of an organization. The bottom line nowadays is of course much more pragmatic: The Free Software Foundation (FSF), the governing body behind free software, approves and disapproves certain licenses and also maintains one (with several derivatives) on its own. Basically, if a software is licensed under a license approved by the FSF it is free software. If the license is not approved, even if it would enable all four freedoms, it is not.↩
Open Source Initiative 2016c. Everything in brackets by the author.↩
Sometimes developers refer to their software as open source when it actually isn’t. Open Source does not mean that the source code is available on a code hosting website. Access to the source code is a precondition for both free and open source software but it is only one criterion. What makes software open source is that the license it is licensed under is recognized by the Open Source Initiative as open source. The same counts of course for free software.↩
Open Source Initiative 2016c↩
Open Source Initiative 2016a; Free Software Foundation 2016a↩
For a list of the most popular open source licenses see (Black Duck 2016). All information used for this table was taken from Open Source Initiative 2016b; Free Software Foundation 2016b.↩
Both institutions solely focus on software licenses. There are, however, efforts by other parties to create licenses with the same rights for other goods, most notably the Creative Commons Licenses. The Free Software Foundation even approves one of those licenses, the CC0, see Table 1 for that.↩
Some advocates of free software have since started to look for alternative terminology. Projects like LibreOffice for example use “Libre” as their term of choice since it states more clearly that the liberty of the user and not “without price” is of the essence here. Hence the inclusion of Libre in the term FLOSS↩
Chopra and Dexter 2008, 38. See on this issue also Open Source Initiative 2016e which states the differences between those two camps from the sight of the Open Source Initiative.↩
Hohfeld 2010, 36↩
Hohfeld 2010, 36.↩
See Hohfeld 2010, 36–38↩
Hohfeld 2010, 38↩
For a detailed discussion of the power and usefulness of the Hohfeldian Theory see Perry 1977.↩
Douglas 2011, 185↩
See on the issue of software ownership Johnson 1985; Carey 1993; Johnson 1993.↩
See the different rights and their relationships on Douglas 2011, 191.↩
Douglas 2011, 188↩
Douglas 2011, 196↩
Douglas 2011, 187↩
Applying his framework to a definition rather than to a license is something he does himself when he applies his framework to the Free Software Definition. See Douglas 2011, 196f.↩
Open Source Initiative 2016d↩
Douglas 2011, 193↩
Two things: I will not treat the possibility of a non-enabled right to attribute any further simply because this right is enabled by every important Open Source License and since it is also not an important right for discussion ownership. Second point: It is questionable whether it is really the creator that holds the right of attribution, it seems much more sensible to think of it as it being held by the custodian and the custodian being under the duty to attribute the creators of the software it holds the rights for. Most software projects have quite a few creators that all work under the same umbrella (project) and are identified by the project (custodian) not the creators. This usually also means that the custodian needs to be attributed, not the individual creators.↩
Free Software Foundation 2016c. See on the issue of Copyleft licenses also Vetter 2008; Berry 2008.↩
Douglas 2011, 196↩
Honoré 1961, 108↩
Honoré 1961, 113↩
Honoré 1961, 116↩
Honoré 1961, 118↩
Honoré 1961, 123↩
For all non directly cited descriptions here see Honoré 1961, 113–28.↩
SeeMunzer 1990, 22: “ordinary usage allows ownership to be qualified”.↩
Munzer 1990, 23↩
Munzer 1990, 23↩
Munzer 1990, 23↩
Munzer 1990, 43↩
See Robles and González-Barahona 2012, 2f) for a definition of forking as well as a study as to how forking happens and what its repercussions are. See also Ernst, Easterbrook, and Mylopoulos 2010 on this issue.↩
Not even established projects maintained by a company are invulnerable to such efforts. See Dean 2016 for an article that describes the recent forking of ownCloud (Think Dropbox but Open Source and deployable by anyone on their own hardware) into Nextcloud.↩
I do not question that it might be possible to argue for someone holding both a privilege as well as a corresponding no-right but I do think that it would muddy the waters which the Hohfeldian theory helped clean up quite a bit.↩
See also Honoré’s own discussion of what he calls “split ownership” in Honoré 1961, 142–44.↩
Becker 1980. One might also have to look again at the questions raised by Johnson 1985 and by Carey 1993.↩
Should there be a market for everything? Or are there limits to what we can and should sell? This article looks at the objection from corruption by Michael Sandel. Sandel argues that some goods are corrupted if we start to sell them. I'll argue, that however much I'd like Sandel to be wright, that market goods are not corrupted when they are for sale.
At least some parts of our lives are guided by personalization algorithms. Google does it, Facebook does it, Twitter does it. The question is how biased those algorithms are. This article examines how an algorithmic system can show bias and how bias is introduced into such a system.
Did you ever look at your smartphone and wonder whether it does really belong to you? If you have, this article tries to examine exactly that question. If I own a device with software on it that is controlled by other entities, am I really the owner of the device? If you've never wondered, you should start wondering and this article will tell you why.