MESSAGE
| DATE | 2013-06-30 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open
|
On Fri, Jun 28, 2013 at 09:50:43AM -0400, einker wrote:
> MySQL mistake is a wake-up call on open source ownership
> By Simon Phipps
> Created 2013-06-21 03:00AM
> http://www.infoworld.com/d/open-source-software/mysql-mistake-wake-call-open-source-ownership-221164
Richard warned Monty about this when it first started. In fact they had
a face to face about it at the NYLXS Dinner.
>
> MySQL mistake is a wake-up call on open source ownership
>
> There was a moment of panic in the open source community this week when a
> developer on the MariaDB fork of MySQL discovered that Oracle had quietly
> changed the license on all the man pages [1] for MySQL from GPL to a
> restrictive proprietary 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'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 not
> 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
> source with InfoWorld's Technology: Open Source newsletter [5]. ]
>
> This unique power exists in turn because Oracle owns the entire copyright
> 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 "contributor
> agreement" assigning ownership of the copyright to Oracle, which is not
> alone in this. Sun before them used contributor agreements to get full
> source ownership, and many other projects do the same.
>
> What are contributor agreements, and why do they exist? The need for them
> often arises from the interaction with open source and certain approaches
> 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
> assumption 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 confusing since
> there is (usually) only one open source license used; the second
> arrangement is usually a proprietary license or contract exempting the
> customer 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 commonly 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, guaranteeing
> the freedoms of its users, but the business owning the copyright makes
> money by selling benefits, such as the right to make derivatives under a
> different 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 your business got infected with that evil GPL viral license ..."
>
> Copyright aggregation
> In order to use this model, the business owning the copyright has to own
> the entire copyright to the software they are distributing. As a
> consequence, when any community member wants to add a modification or
> enhancement to the source code for the software, the owner demands the
> contributor must also hand over their rights to the addition. To achieve
> this, the copyright owner requires the contributor to sign a legal document
> for any involvement in the community that involves co-development.
>
> Usually called a "contributor agreement" (to the detriment of older
> arrangements that use that term for community participation agreements that
> don't actually aggregate copyright), the document gives rights amounting to
> ownership of the copyright in the new work to the copyright aggregator. It
> may also include other clauses, such as a statement of originality ("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 blame 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-development 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 contains software free from usage
> restrictions, with guaranteed freedoms to use, study, modify, and
> distribute it -- in other words, "free software." The community members
> each work at their own expense in order to achieve a shared outcome that
> benefits all, including themselves. When they create an enhancement, fix a
> defect, or participate in a design, they are not "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 copyright
> 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
> the same in the future. The presence of a "contributor agreement" that
> involves copyright aggregation may be a warning sign that the community
> using it has one member who is more equal than all the others.
>
> Communities whose members are termed "contributors" rather than "members"
> or "participants" may well be unequal places where your interests are
> subsidiary to those of the copyright owner. They are often dominated by
> users and fans of the software rather than by co-developers, since the
> inequality makes it hard or even impossible for genuine co-developers to
> align any fragment of their interests on equal terms. Indeed, 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
> (hopefully) customers that they can exploit without competition.
>
> Exceptions
> There can be justifications for having copyright aggregation by and for a
> community. When the beneficiary of the aggregated copyright is the
> community itself (in the case of a community hosted by a nonprofit
> foundation), there are benefits available that may outweigh the
> disadvantages. These include giving the foundation the legal right to
> enforce the copyright 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 adequately deal with patents, or to help in countries
> where copyright law is sufficiently different from U.S. law that the
> U.S.-centric concepts behind open source fail.
>
> Even with these benefits available, many communities choose not to
> aggregate their copyrights -- notably the Linux kernel, GNOME, and Mozilla
> communities. The policy [9] and guidelines [10] on copyright assignment by
> the GNOME Foundation is especially worth reading. Having diverse copyright
> ownership leads to a deeper mutual trust and an assurance that the playing
> field remains level. Insisting on copyright aggregation is one of the more
> certain 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" business models such as Apache-style open core or service
> subscriptions, it is less necessary for the businesses involved to
> aggregate copyright.
>
> Some foundations that avoid aggregation (such as Mozilla) do have a
> document termed a contributor agreement but given the purpose it serves it
> might be better termed a "participant agreement." This is because it mainly
> addresses community norms and specifically avoids copyright aggregation.
> Indeed, some suspect that vaguely using the term "contributor agreement" to
> describe agreements that also aggregate copyright is a tactic designed to
> screen the toxicity of copyright assignments from general view.
>
> How to flourish
> It may well be advisable to have a participant agreement 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
> copyrights or vest them in a nonprofit entity representative of and open to
> the community. In fact, avoid any institutional inequality and focused
> control. 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 community
> innovating and growing in ways you've not anticipated, as well as enhancing
> your reputation. As I've frequently said (although less frequently been
> heeded): Trade control for influence, because in a meshed society control
> gets marginalized whereas influence delivers success.
>
> This article, "MySQL mistake is a wake-up call on open source ownership
> [11]," was originally published at InfoWorld.com [12]. Read more of the
> Open Sources blog [13] and follow the latest developments in open source
> [14] at InfoWorld.com. For the latest business technology news, follow
> InfoWorld.com on Twitter [15].
>
> --
> Regards,
>
> Evan M. Inker
|
|
