Sat Nov 9 06:11:26 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2013-06-01

HANGOUT

2024-11-09 | 2024-10-09 | 2024-09-09 | 2024-08-09 | 2024-07-09 | 2024-06-09 | 2024-05-09 | 2024-04-09 | 2024-03-09 | 2024-02-09 | 2024-01-09 | 2023-12-09 | 2023-11-09 | 2023-10-09 | 2023-09-09 | 2023-08-09 | 2023-07-09 | 2023-06-09 | 2023-05-09 | 2023-04-09 | 2023-03-09 | 2023-02-09 | 2023-01-09 | 2022-12-09 | 2022-11-09 | 2022-10-09 | 2022-09-09 | 2022-08-09 | 2022-07-09 | 2022-06-09 | 2022-05-09 | 2022-04-09 | 2022-03-09 | 2022-02-09 | 2022-01-09 | 2021-12-09 | 2021-11-09 | 2021-10-09 | 2021-09-09 | 2021-08-09 | 2021-07-09 | 2021-06-09 | 2021-05-09 | 2021-04-09 | 2021-03-09 | 2021-02-09 | 2021-01-09 | 2020-12-09 | 2020-11-09 | 2020-10-09 | 2020-09-09 | 2020-08-09 | 2020-07-09 | 2020-06-09 | 2020-05-09 | 2020-04-09 | 2020-03-09 | 2020-02-09 | 2020-01-09 | 2019-12-09 | 2019-11-09 | 2019-10-09 | 2019-09-09 | 2019-08-09 | 2019-07-09 | 2019-06-09 | 2019-05-09 | 2019-04-09 | 2019-03-09 | 2019-02-09 | 2019-01-09 | 2018-12-09 | 2018-11-09 | 2018-10-09 | 2018-09-09 | 2018-08-09 | 2018-07-09 | 2018-06-09 | 2018-05-09 | 2018-04-09 | 2018-03-09 | 2018-02-09 | 2018-01-09 | 2017-12-09 | 2017-11-09 | 2017-10-09 | 2017-09-09 | 2017-08-09 | 2017-07-09 | 2017-06-09 | 2017-05-09 | 2017-04-09 | 2017-03-09 | 2017-02-09 | 2017-01-09 | 2016-12-09 | 2016-11-09 | 2016-10-09 | 2016-09-09 | 2016-08-09 | 2016-07-09 | 2016-06-09 | 2016-05-09 | 2016-04-09 | 2016-03-09 | 2016-02-09 | 2016-01-09 | 2015-12-09 | 2015-11-09 | 2015-10-09 | 2015-09-09 | 2015-08-09 | 2015-07-09 | 2015-06-09 | 2015-05-09 | 2015-04-09 | 2015-03-09 | 2015-02-09 | 2015-01-09 | 2014-12-09 | 2014-11-09 | 2014-10-09 | 2014-09-09 | 2014-08-09 | 2014-07-09 | 2014-06-09 | 2014-05-09 | 2014-04-09 | 2014-03-09 | 2014-02-09 | 2014-01-09 | 2013-12-09 | 2013-11-09 | 2013-10-09 | 2013-09-09 | 2013-08-09 | 2013-07-09 | 2013-06-09 | 2013-05-09 | 2013-04-09 | 2013-03-09 | 2013-02-09 | 2013-01-09 | 2012-12-09 | 2012-11-09 | 2012-10-09 | 2012-09-09 | 2012-08-09 | 2012-07-09 | 2012-06-09 | 2012-05-09 | 2012-04-09 | 2012-03-09 | 2012-02-09 | 2012-01-09 | 2011-12-09 | 2011-11-09 | 2011-10-09 | 2011-09-09 | 2011-08-09 | 2011-07-09 | 2011-06-09 | 2011-05-09 | 2011-04-09 | 2011-03-09 | 2011-02-09 | 2011-01-09 | 2010-12-09 | 2010-11-09 | 2010-10-09 | 2010-09-09 | 2010-08-09 | 2010-07-09 | 2010-06-09 | 2010-05-09 | 2010-04-09 | 2010-03-09 | 2010-02-09 | 2010-01-09 | 2009-12-09 | 2009-11-09 | 2009-10-09 | 2009-09-09 | 2009-08-09 | 2009-07-09 | 2009-06-09 | 2009-05-09 | 2009-04-09 | 2009-03-09 | 2009-02-09 | 2009-01-09 | 2008-12-09 | 2008-11-09 | 2008-10-09 | 2008-09-09 | 2008-08-09 | 2008-07-09 | 2008-06-09 | 2008-05-09 | 2008-04-09 | 2008-03-09 | 2008-02-09 | 2008-01-09 | 2007-12-09 | 2007-11-09 | 2007-10-09 | 2007-09-09 | 2007-08-09 | 2007-07-09 | 2007-06-09 | 2007-05-09 | 2007-04-09 | 2007-03-09 | 2007-02-09 | 2007-01-09 | 2006-12-09 | 2006-11-09 | 2006-10-09 | 2006-09-09 | 2006-08-09 | 2006-07-09 | 2006-06-09 | 2006-05-09 | 2006-04-09 | 2006-03-09 | 2006-02-09 | 2006-01-09 | 2005-12-09 | 2005-11-09 | 2005-10-09 | 2005-09-09 | 2005-08-09 | 2005-07-09 | 2005-06-09 | 2005-05-09 | 2005-04-09 | 2005-03-09 | 2005-02-09 | 2005-01-09 | 2004-12-09 | 2004-11-09 | 2004-10-09 | 2004-09-09 | 2004-08-09 | 2004-07-09 | 2004-06-09 | 2004-05-09 | 2004-04-09 | 2004-03-09 | 2004-02-09 | 2004-01-09 | 2003-12-09 | 2003-11-09 | 2003-10-09 | 2003-09-09 | 2003-08-09 | 2003-07-09 | 2003-06-09 | 2003-05-09 | 2003-04-09 | 2003-03-09 | 2003-02-09 | 2003-01-09 | 2002-12-09 | 2002-11-09 | 2002-10-09 | 2002-09-09 | 2002-08-09 | 2002-07-09 | 2002-06-09 | 2002-05-09 | 2002-04-09 | 2002-03-09 | 2002-02-09 | 2002-01-09 | 2001-12-09 | 2001-11-09 | 2001-10-09 | 2001-09-09 | 2001-08-09 | 2001-07-09 | 2001-06-09 | 2001-05-09 | 2001-04-09 | 2001-03-09 | 2001-02-09 | 2001-01-09 | 2000-12-09 | 2000-11-09 | 2000-10-09 | 2000-09-09 | 2000-08-09 | 2000-07-09 | 2000-06-09 | 2000-05-09 | 2000-04-09 | 2000-03-09 | 2000-02-09 | 2000-01-09 | 1999-12-09

Key: Value:

Key: Value:

MESSAGE
DATE 2013-06-28
FROM einker
SUBJECT Subject: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open source ownership
From owner-hangout-outgoing-at-mrbrklyn.com Fri Jun 28 09:50:43 2013
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 910BB16113E; Fri, 28 Jun 2013 09:50:43 -0400 (EDT)
Delivered-To: hangout-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 8188D161140; Fri, 28 Jun 2013 09:50:43 -0400 (EDT)
Delivered-To: hangout-at-nylxs.com
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169])
by mrbrklyn.com (Postfix) with ESMTP id 8333E16113E
for ; Fri, 28 Jun 2013 09:50:42 -0400 (EDT)
Received: by mail-ie0-f169.google.com with SMTP id 10so4260122ied.0
for ; Fri, 28 Jun 2013 06:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=Y7wVdF+l1ZLk0qLlwzVzNf7fWaeMpUMdrTSFiN6vY5k=;
b=r/f2k8hNkwd3HEjsnmFbaDamKftla4WXYAepShkmCMih4jXOEvlKZEzGDONJRgII+B
7H2qIzUN62MrWLfwDCv0pdicPoiMdu0ev6XjNLshutn33w43PXQj8NN+Pzg5ZE44qKDf
p6480Rg/46F15+0xUiYxMeWAUtSj4xnXrNqoVYOlmJaVUdSI2MfpJXl+rYoMjS/L5Mpx
FTAmM4ZoGHrIsrGaA3WZjkeTSHN2d5TiJAJveUlaj72cO7gvEQf8oSRCEknGux9okPJ0
BC46oCFUfc/xtrhT4BSnXvCNsNEUvjHB+sREVdG1gRzXnc2lqy7V2kIYpGI3S77vtUDm
XFhQ==
MIME-Version: 1.0
X-Received: by 10.50.106.114 with SMTP id gt18mr3931195igb.7.1372427443784;
Fri, 28 Jun 2013 06:50:43 -0700 (PDT)
Received: by 10.64.82.35 with HTTP; Fri, 28 Jun 2013 06:50:43 -0700 (PDT)
Date: Fri, 28 Jun 2013 09:50:43 -0400
Message-ID:
Subject: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open source ownership
From: einker
To: Hangout
Content-Type: multipart/alternative; boundary=047d7bd763fc44510604e0372a4a
Sender: owner-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com

--047d7bd763fc44510604e0372a4a
Content-Type: text/plain; charset=ISO-8859-1

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

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

--047d7bd763fc44510604e0372a4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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


--047d7bd763fc44510604e0372a4a--

--047d7bd763fc44510604e0372a4a
Content-Type: text/plain; charset=ISO-8859-1

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

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

--047d7bd763fc44510604e0372a4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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


--047d7bd763fc44510604e0372a4a--

  1. 2013-06-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Pharmacy Help (Bed-Sty)
  2. 2013-06-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] (fwd) NY Mets Finances
  3. 2013-06-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Linux on the desktop
  4. 2013-06-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Gerrymandering]
  5. 2013-06-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] hardware repair
  6. 2013-06-06 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] hardware repair
  7. 2013-06-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  8. 2013-06-06 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  9. 2013-06-07 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] hardware repair
  10. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Be Happy - we aren't on verizon
  11. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Be Happy - we aren't on verizon
  12. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Be Happy - we aren't on verizon
  13. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Be Happy - we aren't on verizon
  14. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] your phone service and you
  15. 2013-06-07 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] your phone service and you
  16. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] your phone service and you
  17. 2013-06-07 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Put your business in the cloud!
  18. 2013-06-08 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  19. 2013-06-08 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  20. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  21. 2013-06-09 Robert Menes <viewtiful.icchan-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  22. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  23. 2013-06-09 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  24. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  25. 2013-06-09 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  26. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  27. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  28. 2013-06-09 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  29. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  30. 2013-06-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  31. 2013-06-09 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  32. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  33. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: sort bug?]
  34. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: sort bug?]
  35. 2013-06-10 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  36. 2013-06-10 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  37. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  38. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  39. 2013-06-10 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  40. 2013-06-10 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  41. 2013-06-10 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  42. 2013-06-10 Kevin Mark <kevin.mark-at-verizon.net> Re: [NYLXS - HANGOUT] hardware repair
  43. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  44. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  45. 2013-06-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  46. 2013-06-11 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  47. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  48. 2013-06-11 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  49. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  50. 2013-06-11 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  51. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] html problem
  52. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  53. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] html problem
  54. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  55. 2013-06-11 Paul Robert Marino <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] hardware repair
  56. 2013-06-11 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] hardware repair
  57. 2013-06-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] televsion content wars
  58. 2013-06-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Troubles with hotel arraingments
  59. 2013-06-14 eminker-at-gmail.com Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  60. 2013-06-14 eminker-at-gmail.com Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  61. 2013-06-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  62. 2013-06-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  63. 2013-06-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  64. 2013-06-14 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Troubles with hotel arraingments
  65. 2013-06-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] secure mail - and security
  66. 2013-06-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] (fwd) Re: question about forwarding and sysfs entries
  67. 2013-06-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] (fwd) HTTP POST for file upload
  68. 2013-06-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] (fwd) Re: HTTP POST for file upload
  69. 2013-06-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] fishing dates
  70. 2013-06-16 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] So while you were away this weekend
  71. 2013-06-16 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: [NYLXS] Secure your email. Get your own email server and...
  72. 2013-06-16 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] So while you were away this weekend
  73. 2013-06-16 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] So while you were away this weekend
  74. 2013-06-16 Ruben <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] So while you were away this weekend
  75. 2013-06-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] biometrics - I can see you!!
  76. 2013-06-20 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] image galleries for the web
  77. 2013-06-21 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] image galleries - a REAL HACK
  78. 2013-06-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] A little fraud never hurt anyone
  79. 2013-06-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] github
  80. 2013-06-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] employment help
  81. 2013-06-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] kill count
  82. 2013-06-23 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] kill count
  83. 2013-06-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] what is the government doing?
  84. 2013-06-27 From: "Michael L. Richardson" <mlr52-at-michaellrichardson.com> Subject: [NYLXS - HANGOUT] Any thoughts on this, Sacramento State 8008 computer, the world's-first
  85. 2013-06-28 Ruben <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: New job Kansas City Perl developer roles available
  86. 2013-06-28 einker <eminker-at-gmail.com> Subject: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open source ownership
  87. 2013-06-30 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open
  88. 2013-06-30 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open
  89. 2013-06-30 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open source ownership
  90. 2013-06-30 From: "Paul Robert Marino" <prmarino1-at-gmail.com> Re: [NYLXS - HANGOUT] MySQL mistake is a wake-up call on open source ownership

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!