MySQL mistake is a wake-up call on open source ownershipr>By Simon Phipps
Created 2013-06-21 03:00AM
foworld.com/d/open-source-software/mysql-mistake-wake-call-open-source-owne=
rship-221164">http://www.infoworld.com/d/open-source-software/mysql-mistake=
-wake-call-open-source-ownership-221164


MySQL mistake is a wake-up call on open source ownership

There w=
as a moment of panic in the open source community this week when a develope=
r on the MariaDB fork of MySQL discovered that Oracle had quietly changed t=
he license on all the man pages [1] for MySQL from GPL to a restrictive pro=
prietary license two months earlier. Prompted by the bug report, Oracle'=
;s staff quickly discovered that an error had been made in the build system=
and promised to immediately undo the change and restore the GPL to all of =
MySQL. Problem solved [2]!


All the same, the incident was a wake-up call to many. Although there&#=
39;s no reason why they should and have promised not to do so, Oracle could=
change the license for MySQL, or indeed any of the open source projects it=
owns, at any time without notice. Oracle is able to do this since, unique =
among the rest of the open source community around each project, they are n=
ot themselves bound by the open source license.


[ Simon Phipps tells it like it is: Why software patents are evil [3]. =
| Stay ahead of the key tech business news with InfoWorld's Today's=
Headlines: First Look newsletter [4]. | Track the latest trends in open so=
urce with InfoWorld's Technology: Open Source newsletter [5]. ]


This unique power exists in turn because Oracle owns the entire copyrig=
ht to MySQL, even to parts of it the company has not written. Why is that? =
It's because all contributors to the code have to sign a "contribu=
tor agreement" assigning ownership of the copyright to Oracle, which i=
s not alone in this. Sun before them used contributor agreements to get ful=
l source ownership, and many other projects do the same.


What are contributor agreements, and why do they exist? The need for th=
em often arises from the interaction with open source and certain approache=
s to business. They meet a need, but they can come at a significant cost to=
the health of the project. If you're starting a new project, it's =
worth understanding the bigger picture with a practical guide [6] to the as=
sumption that "everyone uses contributor agreements" because not =
everyone does. I'm by no means the first to tread this ground; this old=
but comprehensive article by LibreOffice developer Michael Meeks [7] ends =
with a useful list of other articles.


Dual licensing
One of the dimensions of the business of open source =
has been the dual-licensing [8] business model. The name is a little confus=
ing since there is (usually) only one open source license used; the second =
arrangement is usually a proprietary license or contract exempting the cust=
omer from some of the terms of the open source license. This can be better =
described as selling exceptions to the open source license, and it is commo=
nly done in conjunction with the GNU GPL, which has clauses some businesses=
regard as hard to accept.


Under this model, open source software is genuinely present, guaranteei=
ng the freedoms of its users, but the business owning the copyright makes m=
oney by selling benefits, such as the right to make derivatives under a dif=
ferent license, commercial terms that offer additional guarantees and (most=
famously) anything-but-the-GPL as the license under which the software is =
used. This last option means that dual licensing has often been associated =
with shady sales tactics along the lines of "it would be a shame if yo=
ur business got infected with that evil GPL viral license ..."


Copyright aggregation
In order to use this model, the business ownin=
g the copyright has to own the entire copyright to the software they are di=
stributing. As a consequence, when any community member wants to add a modi=
fication or enhancement to the source code for the software, the owner dema=
nds the contributor must also hand over their rights to the addition. To ac=
hieve this, the copyright owner requires the contributor to sign a legal do=
cument for any involvement in the community that involves co-development.r>

Usually called a "contributor agreement" (to the detriment of=
older arrangements that use that term for community participation agreemen=
ts that don't actually aggregate copyright), the document gives rights =
amounting to ownership of the copyright in the new work to the copyright ag=
gregator. It may also include other clauses, such as a statement of origina=
lity ("this is my work and I didn't plagiarize it"), a grant =
of patent rights, and even an indemnity ("if you get sued you can blam=
e me"). In most cases the author retains rights to any individual work=
in some form or receives a license back, but it's only the aggregator =
who owns the copyright to the whole system.


So what's the problem?
Open source can be defined as the co-deve=
lopment of software by a community of people who choose to align a fragment=
of their self-interest in order to do so. The commons in which they work c=
ontains software free from usage restrictions, with guaranteed freedoms to =
use, study, modify, and distribute it -- in other words, "free softwar=
e." The community members each work at their own expense in order to a=
chieve a shared outcome that benefits all, including themselves. When they =
create an enhancement, fix a defect, or participate in a design, they are n=
ot "working for free" or "donating their work" so much =
as they are "participating in co-development."


That favored word "contributor" gives a clue to the problem c=
opyright aggregation agreements cause. An open source community is an open,=
meritocratic oligarchy ruled by an elite who gain leadership based on the =
merits of their participation and skills, open equally to anyone who does t=
he same in the future. The presence of a "contributor agreement" =
that involves copyright aggregation may be a warning sign that the communit=
y using it has one member who is more equal than all the others.


Communities whose members are termed "contributors" rather th=
an "members" or "participants" may well be unequal plac=
es where your interests are subsidiary to those of the copyright owner. The=
y are often dominated by users and fans of the software rather than by co-d=
evelopers, since the inequality makes it hard or even impossible for genuin=
e co-developers to align any fragment of their interests on equal terms. In=
deed, this inequality is seen by some dual-license proponents as one of the=
attractions of the model as they seek a community of enthusiasts and (hope=
fully) customers that they can exploit without competition.


Exceptions
There can be justifications for having copyright aggregat=
ion by and for a community. When the beneficiary of the aggregated copyrigh=
t is the community itself (in the case of a community hosted by a nonprofit=
foundation), there are benefits available that may outweigh the disadvanta=
ges. These include giving the foundation the legal right to enforce the cop=
yright in certain jurisdictions, and the freedom to update the open source =
license later. They may also include the granting of additional rights such=
as patent licenses in the case where the open source license does not adeq=
uately deal with patents, or to help in countries where copyright law is su=
fficiently different from U.S. law that the U.S.-centric concepts behind op=
en source fail.


Even with these benefits available, many communities choose not to aggr=
egate their copyrights -- notably the Linux kernel, GNOME, and Mozilla comm=
unities. The policy [9] and guidelines [10] on copyright assignment by the =
GNOME Foundation is especially worth reading. Having diverse copyright owne=
rship leads to a deeper mutual trust and an assurance that the playing fiel=
d remains level. Insisting on copyright aggregation is one of the more cert=
ain ways a company can ensure that the open source community it is seeding =
will remain small and lack co-developers. With the rise of "value add&=
quot; business models such as Apache-style open core or service subscriptio=
ns, it is less necessary for the businesses involved to aggregate copyright=
.


Some foundations that avoid aggregation (such as Mozilla) do have a doc=
ument termed a contributor agreement but given the purpose it serves it mig=
ht be better termed a "participant agreement." This is because it=
mainly addresses community norms and specifically avoids copyright aggrega=
tion. Indeed, some suspect that vaguely using the term "contributor ag=
reement" to describe agreements that also aggregate copyright is a tac=
tic designed to screen the toxicity of copyright assignments from general v=
iew.


How to flourish
It may well be advisable to have a participant agree=
ment for your community, to ensure that everyone has the same understanding=
of and commitment to the project if they are sharing its evolution. But if=
you want your community to flourish, then you should eschew aggregated cop=
yrights or vest them in a nonprofit entity representative of and open to th=
e community. In fact, avoid any institutional inequality and focused contro=
l. Communities should be open by rule.


In my experience, attempting to retain control of a project you're =
starting or hosting leads to mistrust, contention, and a rules-based focus =
that diminishes your reputation. Relaxing control will lead to the communit=
y innovating and growing in ways you've not anticipated, as well as enh=
ancing your reputation. As I've frequently said (although less frequent=
ly been heeded): Trade control for influence, because in a meshed society c=
ontrol gets marginalized whereas influence delivers success.


This article, "MySQL mistake is a wake-up call on open source owne=
rship [11]," was originally published at InfoWorld.com [12]. Read more=
of the Open Sources blog [13] and follow the latest developments in open s=
ource [14] at InfoWorld.com. For the latest business technology news, follo=
w InfoWorld.com on Twitter [15].


--
Regards,

Evan M. Inker

MySQL mistake is a wake-up call on open source ownershipr>By Simon Phipps
Created 2013-06-21 03:00AM
foworld.com/d/open-source-software/mysql-mistake-wake-call-open-source-owne=
rship-221164">http://www.infoworld.com/d/open-source-software/mysql-mistake=
-wake-call-open-source-ownership-221164


MySQL mistake is a wake-up call on open source ownership

There w=
as a moment of panic in the open source community this week when a develope=
r on the MariaDB fork of MySQL discovered that Oracle had quietly changed t=
he license on all the man pages [1] for MySQL from GPL to a restrictive pro=
prietary license two months earlier. Prompted by the bug report, Oracle'=
;s staff quickly discovered that an error had been made in the build system=
and promised to immediately undo the change and restore the GPL to all of =
MySQL. Problem solved [2]!


All the same, the incident was a wake-up call to many. Although there&#=
39;s no reason why they should and have promised not to do so, Oracle could=
change the license for MySQL, or indeed any of the open source projects it=
owns, at any time without notice. Oracle is able to do this since, unique =
among the rest of the open source community around each project, they are n=
ot themselves bound by the open source license.


[ Simon Phipps tells it like it is: Why software patents are evil [3]. =
| Stay ahead of the key tech business news with InfoWorld's Today's=
Headlines: First Look newsletter [4]. | Track the latest trends in open so=
urce with InfoWorld's Technology: Open Source newsletter [5]. ]


This unique power exists in turn because Oracle owns the entire copyrig=
ht to MySQL, even to parts of it the company has not written. Why is that? =
It's because all contributors to the code have to sign a "contribu=
tor agreement" assigning ownership of the copyright to Oracle, which i=
s not alone in this. Sun before them used contributor agreements to get ful=
l source ownership, and many other projects do the same.


What are contributor agreements, and why do they exist? The need for th=
em often arises from the interaction with open source and certain approache=
s to business. They meet a need, but they can come at a significant cost to=
the health of the project. If you're starting a new project, it's =
worth understanding the bigger picture with a practical guide [6] to the as=
sumption that "everyone uses contributor agreements" because not =
everyone does. I'm by no means the first to tread this ground; this old=
but comprehensive article by LibreOffice developer Michael Meeks [7] ends =
with a useful list of other articles.


Dual licensing
One of the dimensions of the business of open source =
has been the dual-licensing [8] business model. The name is a little confus=
ing since there is (usually) only one open source license used; the second =
arrangement is usually a proprietary license or contract exempting the cust=
omer from some of the terms of the open source license. This can be better =
described as selling exceptions to the open source license, and it is commo=
nly done in conjunction with the GNU GPL, which has clauses some businesses=
regard as hard to accept.


Under this model, open source software is genuinely present, guaranteei=
ng the freedoms of its users, but the business owning the copyright makes m=
oney by selling benefits, such as the right to make derivatives under a dif=
ferent license, commercial terms that offer additional guarantees and (most=
famously) anything-but-the-GPL as the license under which the software is =
used. This last option means that dual licensing has often been associated =
with shady sales tactics along the lines of "it would be a shame if yo=
ur business got infected with that evil GPL viral license ..."


Copyright aggregation
In order to use this model, the business ownin=
g the copyright has to own the entire copyright to the software they are di=
stributing. As a consequence, when any community member wants to add a modi=
fication or enhancement to the source code for the software, the owner dema=
nds the contributor must also hand over their rights to the addition. To ac=
hieve this, the copyright owner requires the contributor to sign a legal do=
cument for any involvement in the community that involves co-development.r>

Usually called a "contributor agreement" (to the detriment of=
older arrangements that use that term for community participation agreemen=
ts that don't actually aggregate copyright), the document gives rights =
amounting to ownership of the copyright in the new work to the copyright ag=
gregator. It may also include other clauses, such as a statement of origina=
lity ("this is my work and I didn't plagiarize it"), a grant =
of patent rights, and even an indemnity ("if you get sued you can blam=
e me"). In most cases the author retains rights to any individual work=
in some form or receives a license back, but it's only the aggregator =
who owns the copyright to the whole system.


So what's the problem?
Open source can be defined as the co-deve=
lopment of software by a community of people who choose to align a fragment=
of their self-interest in order to do so. The commons in which they work c=
ontains software free from usage restrictions, with guaranteed freedoms to =
use, study, modify, and distribute it -- in other words, "free softwar=
e." The community members each work at their own expense in order to a=
chieve a shared outcome that benefits all, including themselves. When they =
create an enhancement, fix a defect, or participate in a design, they are n=
ot "working for free" or "donating their work" so much =
as they are "participating in co-development."


That favored word "contributor" gives a clue to the problem c=
opyright aggregation agreements cause. An open source community is an open,=
meritocratic oligarchy ruled by an elite who gain leadership based on the =
merits of their participation and skills, open equally to anyone who does t=
he same in the future. The presence of a "contributor agreement" =
that involves copyright aggregation may be a warning sign that the communit=
y using it has one member who is more equal than all the others.


Communities whose members are termed "contributors" rather th=
an "members" or "participants" may well be unequal plac=
es where your interests are subsidiary to those of the copyright owner. The=
y are often dominated by users and fans of the software rather than by co-d=
evelopers, since the inequality makes it hard or even impossible for genuin=
e co-developers to align any fragment of their interests on equal terms. In=
deed, this inequality is seen by some dual-license proponents as one of the=
attractions of the model as they seek a community of enthusiasts and (hope=
fully) customers that they can exploit without competition.


Exceptions
There can be justifications for having copyright aggregat=
ion by and for a community. When the beneficiary of the aggregated copyrigh=
t is the community itself (in the case of a community hosted by a nonprofit=
foundation), there are benefits available that may outweigh the disadvanta=
ges. These include giving the foundation the legal right to enforce the cop=
yright in certain jurisdictions, and the freedom to update the open source =
license later. They may also include the granting of additional rights such=
as patent licenses in the case where the open source license does not adeq=
uately deal with patents, or to help in countries where copyright law is su=
fficiently different from U.S. law that the U.S.-centric concepts behind op=
en source fail.


Even with these benefits available, many communities choose not to aggr=
egate their copyrights -- notably the Linux kernel, GNOME, and Mozilla comm=
unities. The policy [9] and guidelines [10] on copyright assignment by the =
GNOME Foundation is especially worth reading. Having diverse copyright owne=
rship leads to a deeper mutual trust and an assurance that the playing fiel=
d remains level. Insisting on copyright aggregation is one of the more cert=
ain ways a company can ensure that the open source community it is seeding =
will remain small and lack co-developers. With the rise of "value add&=
quot; business models such as Apache-style open core or service subscriptio=
ns, it is less necessary for the businesses involved to aggregate copyright=
.


Some foundations that avoid aggregation (such as Mozilla) do have a doc=
ument termed a contributor agreement but given the purpose it serves it mig=
ht be better termed a "participant agreement." This is because it=
mainly addresses community norms and specifically avoids copyright aggrega=
tion. Indeed, some suspect that vaguely using the term "contributor ag=
reement" to describe agreements that also aggregate copyright is a tac=
tic designed to screen the toxicity of copyright assignments from general v=
iew.


How to flourish
It may well be advisable to have a participant agree=
ment for your community, to ensure that everyone has the same understanding=
of and commitment to the project if they are sharing its evolution. But if=
you want your community to flourish, then you should eschew aggregated cop=
yrights or vest them in a nonprofit entity representative of and open to th=
e community. In fact, avoid any institutional inequality and focused contro=
l. Communities should be open by rule.


In my experience, attempting to retain control of a project you're =
starting or hosting leads to mistrust, contention, and a rules-based focus =
that diminishes your reputation. Relaxing control will lead to the communit=
y innovating and growing in ways you've not anticipated, as well as enh=
ancing your reputation. As I've frequently said (although less frequent=
ly been heeded): Trade control for influence, because in a meshed society c=
ontrol gets marginalized whereas influence delivers success.


This article, "MySQL mistake is a wake-up call on open source owne=
rship [11]," was originally published at InfoWorld.com [12]. Read more=
of the Open Sources blog [13] and follow the latest developments in open s=
ource [14] at InfoWorld.com. For the latest business technology news, follo=
w InfoWorld.com on Twitter [15].


--
Regards,

Evan M. Inker