Thu Dec 5 01:40:45 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 2021-08-01

HANGOUT

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

Key: Value:

Key: Value:

MESSAGE
DATE 2021-08-30
FROM From: "Free Software Foundation"
SUBJECT Subject: [Hangout - NYLXS] FSF copyright handling: A basis for distribution,
From hangout-bounces-at-nylxs.com Tue Aug 31 16:46:55 2021
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id CDE24163FD0;
Tue, 31 Aug 2021 16:46:47 -0400 (EDT)
X-Original-To: hangout-at-www2.mrbrklyn.com
Delivered-To: hangout-at-www2.mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 7BFCA163FCB; Tue, 31 Aug 2021 16:46:40 -0400 (EDT)
Resent-From: Ruben Safir
Resent-Date: Tue, 31 Aug 2021 16:46:40 -0400
Resent-Message-ID: <20210831204640.GA9096-at-www2.mrbrklyn.com>
Resent-To: hangout-at-mrbrklyn.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from mailout0p.fsf.org (mailout0p.fsf.org [209.51.188.184])
by mrbrklyn.com (Postfix) with ESMTP id A49F6163FB8
for ; Mon, 30 Aug 2021 19:00:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsf.org;
s=mailout0p-fsf-org; h=Date:To:Subject:From:MIME-Version:in-reply-to:
references; bh=KzD8ENuVU+ZRE3O/MKJzf65VvaNO9m9pXHAhSleq+Nw=; b=YERiLDccacDui9
r4AKisZQjxmdNpZXJ+fXnyxJ5DUVkZ5IlAsrqHsvvMTyLFP80OE91erxP3P6WYTJ+BQz0hcGFjBZQ
72EBwU34mZAGkpxtMXTJYNrlZp9JBUH5Yn1j/agDDPkw82XfFHH0VE1SQrKgz6f8sWUdJLjy47mkA
1/ZOd9tXnWrgR3WW0Bro55DcZHv/f4WrobM6uBcnjV+HPtX9KjZAzwV0fnapzAmADUAg3QK7yoIB0
qDHFG42E2wPnJQOZvuz4gKAm7stYmV18VMuzWU1gXbh+s/RPICeH39ooPtiTlKgzBqKLJ8aXNSfxR
IB4xS0QVLzk1At3sD+cA==;
Received: from crmserver2p.fsf.org ([2001:470:142:5::223]:43360)
by mailout0p.fsf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
(envelope-from )
id 1mKqGe-0005w5-3t
for ruben-at-mrbrklyn.com; Mon, 30 Aug 2021 19:00:40 -0400
Received: from localhost ([::1]:50120 helo=my.fsf.org)
by crmserver2p.fsf.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1mKqGd-0002p7-QP
for ruben-at-mrbrklyn.com; Mon, 30 Aug 2021 19:00:39 -0400
MIME-Version: 1.0
From: "Free Software Foundation"
job_id: 163908
To: Ruben Safir
Precedence: bulk
X-CiviMail-Bounce: crmmailer+b.163908.68905403.28d0598e969d0150-at-fsf.org
Date: Mon, 30 Aug 2021 19:00:39 -0400
Message-Id:
Subject: [Hangout - NYLXS] FSF copyright handling: A basis for distribution,
licensing and enforcement
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.30rc1
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Reply-To: Free Software Foundation
Content-Type: multipart/mixed; boundary="===============1851687585=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"

--===============1851687585==
Content-Type: multipart/alternative;
boundary="=_b28cd891e5bf040229410f1f73f78e49"

--=_b28cd891e5bf040229410f1f73f78e49
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8

*Please consider adding to your address book, which will
ensure that our messages reach you and not your spam box.*

*Read and share online:
*


Dear Ruben Safir,

Part of the Free Software Foundation (FSF's) core mission is to
advance policies that will promote the progress of free software and
freedom. Because copyright handling has been a topic of concern
lately, we are taking this opportunity to explain the four purposes
behind FSF copyright handling, as well as examine the impact of
potential alternatives.

For some GNU packages, the ones that are FSF-copyrighted, we ask
contributors for two kinds of legal papers: copyright assignments, and
employer copyright disclaimers. We drew up these policies working with
lawyers in the 1980s, and they make possible our steady and continuing
enforcement of the GNU General Public License (GPL).

These papers serve four different but related legal purposes, all of
which help ensure that the GNU Project's goals of freedom for the
community are met.

One purpose is to give explicit permission to include the material in
that GNU package. That is the most basic need.

The second purpose is to empower the FSF to go to court and say, "That
company is infringing our copyright when it tramples the freedom of
users, denying them the freedom that our license gives them." The
assignment does this by transferring the copyright to the FSF. (This
form of support for GNU is one of the original purposes for founding
the FSF.)

A third purpose is to make it possible to add additional permission to
specific pieces of code. For example, to take code released under GNU
GPL version-3-or-later and release it under GNU Lesser GPL
version-3-or-later.

Sometimes the individual author (or authors) of the code assign it.
Sometimes a company assigns copyright on its employees' writings. The
result is the same: The FSF gets the copyright.

There is an alternative to copyright assignment: instead of assigning
the copyright, the author can disclaim copyright on that material.
That means the material is effectively in the public domain. This
achieves the first and third of those purposes described above, but
not the second. It could weaken our copyright claim if it happened for
a large part of the program, but it's no problem if this occurs only
for a small part of the program.

Another alternative is to give the FSF an unlimited perpetual
nonexclusive license for the material. This is different from
disclaiming copyright in that the author continues to hold the
copyright, but, in practical terms, they are effectively equivalent:
Both achieve the first and third purpose but not the second.

We have preferences about these alternatives, which depend on the
situation, but we are flexible when possible.

The fourth purpose is to protect the community from the danger of
employers' surprise claims. What happens if J. R. Hacker contributes
some code, and we use it, all with good will and believing that to be
valid; but then Hacker's employer says, "That code belongs to us!
Hacker wrote it while on the job, working for us, so it's a 'work made
for hire.' You never had the right to distribute it, and we're going
to sue _all_ of you. Or maybe only some selected victims if that seems
advantageous."

The way we prevent this is by asking Hacker to get an employer
copyright disclaimer before contributing material. That way, Hacker's
employer will either sign, saying, "Ok, Hacker, you can contribute
your changes to that program," or refuse to sign, which warns Hacker
not to write contributions to that program while employed by that
employer. (We hope the employees of such companies find new, less
stingy employers soon.) This approach has saved us from a number of
messy situations, because some contributors asked their employers to
sign disclaimers and were refused. We could not use their code, but at
least everyone involved avoided getting in legal trouble.

The employer disclaimer also deals with the employer's patents and
interface copyrights that might cover the contributor's code.

We don't need an employer disclaimer in every case. If an individual
says, "I am an independent contractor; no employer could have a claim
on this work," that's clear cut, so we don't ask for an employer
disclaimer from the nonexistent employer.

Sometimes there is no individual contributor, in a legal sense,
because the employer assigns the copyright. Legally, that's solid.
(It's good that some people get paid to contribute to free software.)

These four purposes are related in a complex way, and not all are
applicable to every contribution. But each one is clear in concept.
One purpose is to give us permission to use the code, another the
power to defend it, a third to relicense it. The fourth purpose is to
make sure no marauding employers have an opportunity to wreak havoc.

The maintainers of some GNU packages would like to use a simple
mechanism instead of these legal papers. It is called a "Developer
Certificate of Origin" (DCO), and it makes a rough attempt at serving
the first purpose and the fourth purpose. It does not try to achieve
the second purpose, or the third one. Also, it is sloppy: the existing
DCOs don't make it clear who is the author of the code in a
contribution.

What about protecting against employer surprise claims? Instead of the
employer's signature saying, "We commit not to attack you," the DCO
gives us an employee's signature saying, "I certify that no employer
can claim rights to this code and attack you." It may do some good,
but it is hardly equivalent.

We think we can accept some amount of code from individual
contributors using DCOs instead of copyright assignments, for some
packages. To avoid weakening our protection for the whole community,
we need clear and careful DCOs, designed to make the copyright facts
clear.

Careful use of DCOs means that each contributor should _sign only for
personal contributions_ and identify clearly what they consist of.
Thus, Contributor A would sign a DCO only for the material that A
contributes. If A would like us to include code copied from some
released free program with a suitable compatible license, maybe we
can. But a DCO from A is a non-solution as regards the legalities.
Contributor A should instead show us what code that is, and where it
comes from, so we can think about the best way to use code from there.

If A wants us to install code written by B, we don't want A to sign
claiming, "I have the right to contribute this code (which I got from
B)." If B wrote the code, we want B to contribute it, not someone else
on B's behalf. Also, concretely, we need to know which code was B's
and which was A's -- so we can register the copyright in the United
States. Even though we think of DCOs as an inferior choice, we are
thinking of developing a DCO that does the DCO job right.

A few lines of code contributed under a clear DCO are not a problem,
but as the part of a package contributed under a DCO increases, so
does the effect of the DCO's drawbacks. This goes double if a sloppy
DCO is used.

To avoid weakening our protection for the whole community against
employer surprise claims, DCOs should be accompanied by the usual
employer disclaimers. Sadly, using DCOs would make relicensing code to
move it into certain libraries a precarious and unwieldy proposition,
relying on getting agreement of the other copyright holders or
removing their code.

Accepting corporations as copyright holders of code in GPL-covered
software packages risks causing a particular problem: a corporation is
unlikely to join in a GPL enforcement action against its subsidiary,
its parent, another subsidiary of its parent, its supplier, or its
client. Thus, even projects that use DCOs should not accept them from
corporations.

As our community well knows, the power of big tech corporations is
increasing, and their influence over organizations in the free
software community is increasing too. Some of them are opposed to GPL
enforcement, which is an increasing problem. This is not the time to
weaken our legal defenses; we must keep them strong.

###

P.S. You can learn about the assignment process by reading our
[Contributor's Frequently Asked Questions (FAQ)
guide](https://www.fsf.org/licensing/contributor-faq)

The FSF would like to thank the many community legal experts who
reviewed this article and provided valuable suggestions based on their
knowledge of these complex legal issues. Among the expert reviewers
were Deb Peckham and Carlo Piana.

Support the FSF's Licensing & Compliance Lab:

* If you are not already signed up, you can keep up to date on
upcoming legal issues by joining the [licensing & compliance mailing
list][1].

* Support our work by [donating][2] to the FSF.

[1]: https://my.fsf.org/civicrm/mailing/subscribe?reset=1&gid=1524
[2]: https://donate.fsf.org

Sincerely,

Free Software Foundation


--
* Follow us on Mastodon at , GNU social at
, Diaspora at ,
PeerTube at , and on Twitter at -at-fsf.
* Read about why we use Twitter, but only with caveats at .
* Subscribe to our RSS feeds at .
* Join us as an associate member at .
* Read our Privacy Policy at .

Sent from the Free Software Foundation,

51 Franklin St, Fifth Floor
Boston, Massachusetts 02110-1335
United States


You can unsubscribe from this mailing list by visiting

https://my.fsf.org/civicrm/mailing/unsubscribe?reset=1&jid=163908&qid=68905403&h=28d0598e969d0150.

To stop all email from the Free Software Foundation, including Defective by Design,
and the Free Software Supporter newsletter, visit

https://my.fsf.org/civicrm/mailing/optout?reset=1&jid=163908&qid=68905403&h=28d0598e969d0150.
--=_b28cd891e5bf040229410f1f73f78e49
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

































Free Software Foundation








Please consider adding info@fsf.org to your address book, which will
ensure that our messages reach you and not your spam box.



Read and share online:
https://www.fsf.org/blogs/licensing/FSF-copyright-handling





Dear Ruben Safir,



Part of the Free Software Foundation (FSF's) core mission is to
advance policies that will promote the progress of free software and
freedom. Because copyright handling has been a topic of concern
lately, we are taking this opportunity to explain the four purposes
behind FSF copyright handling, as well as examine the impact of
potential alternatives.



For some GNU packages, the ones that are FSF-copyrighted, we ask
contributors for two kinds of legal papers: copyright assignments, and
employer copyright disclaimers. We drew up these policies working with
lawyers in the 1980s, and they make possible our steady and continuing
enforcement of the GNU General Public License (GPL).



These papers serve four different but related legal purposes, all of
which help ensure that the GNU Project's goals of freedom for the
community are met.



One purpose is to give explicit permission to include the material in
that GNU package. That is the most basic need.



The second purpose is to empower the FSF to go to court and say, "That
company is infringing our copyright when it tramples the freedom of
users, denying them the freedom that our license gives them." The
assignment does this by transferring the copyright to the FSF. (This
form of support for GNU is one of the original purposes for founding
the FSF.)



A third purpose is to make it possible to add additional permission to
specific pieces of code. For example, to take code released under GNU
GPL version-3-or-later and release it under GNU Lesser GPL
version-3-or-later.



Sometimes the individual author (or authors) of the code assign it.
Sometimes a company assigns copyright on its employees' writings. The
result is the same: The FSF gets the copyright.



There is an alternative to copyright assignment: instead of assigning
the copyright, the author can disclaim copyright on that material.
That means the material is effectively in the public domain. This
achieves the first and third of those purposes described above, but
not the second. It could weaken our copyright claim if it happened for
a large part of the program, but it's no problem if this occurs only
for a small part of the program.



Another alternative is to give the FSF an unlimited perpetual
nonexclusive license for the material. This is different from
disclaiming copyright in that the author continues to hold the
copyright, but, in practical terms, they are effectively equivalent:
Both achieve the first and third purpose but not the second.



We have preferences about these alternatives, which depend on the
situation, but we are flexible when possible.



The fourth purpose is to protect the community from the danger of
employers' surprise claims. What happens if J. R. Hacker contributes
some code, and we use it, all with good will and believing that to be
valid; but then Hacker's employer says, "That code belongs to us!
Hacker wrote it while on the job, working for us, so it's a 'work made
for hire.' You never had the right to distribute it, and we're going
to sue all of you. Or maybe only some selected victims if that seems
advantageous."



The way we prevent this is by asking Hacker to get an employer
copyright disclaimer before contributing material. That way, Hacker's
employer will either sign, saying, "Ok, Hacker, you can contribute
your changes to that program," or refuse to sign, which warns Hacker
not to write contributions to that program while employed by that
employer. (We hope the employees of such companies find new, less
stingy employers soon.) This approach has saved us from a number of
messy situations, because some contributors asked their employers to
sign disclaimers and were refused. We could not use their code, but at
least everyone involved avoided getting in legal trouble.



The employer disclaimer also deals with the employer's patents and
interface copyrights that might cover the contributor's code.



We don't need an employer disclaimer in every case. If an individual
says, "I am an independent contractor; no employer could have a claim
on this work," that's clear cut, so we don't ask for an employer
disclaimer from the nonexistent employer.



Sometimes there is no individual contributor, in a legal sense,
because the employer assigns the copyright. Legally, that's solid.
(It's good that some people get paid to contribute to free software.)



These four purposes are related in a complex way, and not all are
applicable to every contribution. But each one is clear in concept.
One purpose is to give us permission to use the code, another the
power to defend it, a third to relicense it. The fourth purpose is to
make sure no marauding employers have an opportunity to wreak havoc.



The maintainers of some GNU packages would like to use a simple
mechanism instead of these legal papers. It is called a "Developer
Certificate of Origin" (DCO), and it makes a rough attempt at serving
the first purpose and the fourth purpose. It does not try to achieve
the second purpose, or the third one. Also, it is sloppy: the existing
DCOs don't make it clear who is the author of the code in a
contribution.



What about protecting against employer surprise claims? Instead of the
employer's signature saying, "We commit not to attack you," the DCO
gives us an employee's signature saying, "I certify that no employer
can claim rights to this code and attack you." It may do some good,
but it is hardly equivalent.



We think we can accept some amount of code from individual
contributors using DCOs instead of copyright assignments, for some
packages. To avoid weakening our protection for the whole community,
we need clear and careful DCOs, designed to make the copyright facts
clear.



Careful use of DCOs means that each contributor should sign only for
personal contributions
and identify clearly what they consist of.
Thus, Contributor A would sign a DCO only for the material that A
contributes. If A would like us to include code copied from some
released free program with a suitable compatible license, maybe we
can. But a DCO from A is a non-solution as regards the legalities.
Contributor A should instead show us what code that is, and where it
comes from, so we can think about the best way to use code from there.



If A wants us to install code written by B, we don't want A to sign
claiming, "I have the right to contribute this code (which I got from
B)." If B wrote the code, we want B to contribute it, not someone else
on B's behalf. Also, concretely, we need to know which code was B's
and which was A's -- so we can register the copyright in the United
States. Even though we think of DCOs as an inferior choice, we are
thinking of developing a DCO that does the DCO job right.



A few lines of code contributed under a clear DCO are not a problem,
but as the part of a package contributed under a DCO increases, so
does the effect of the DCO's drawbacks. This goes double if a sloppy
DCO is used.



To avoid weakening our protection for the whole community against
employer surprise claims, DCOs should be accompanied by the usual
employer disclaimers. Sadly, using DCOs would make relicensing code to
move it into certain libraries a precarious and unwieldy proposition,
relying on getting agreement of the other copyright holders or
removing their code.



Accepting corporations as copyright holders of code in GPL-covered
software packages risks causing a particular problem: a corporation is
unlikely to join in a GPL enforcement action against its subsidiary,
its parent, another subsidiary of its parent, its supplier, or its
client. Thus, even projects that use DCOs should not accept them from
corporations.



As our community well knows, the power of big tech corporations is
increasing, and their influence over organizations in the free
software community is increasing too. Some of them are opposed to GPL
enforcement, which is an increasing problem. This is not the time to
weaken our legal defenses; we must keep them strong.



#



P.S. You can learn about the assignment process by reading our
Contributor's Frequently Asked Questions (FAQ)
guide



The FSF would like to thank the many community legal experts who
reviewed this article and provided valuable suggestions based on their
knowledge of these complex legal issues. Among the expert reviewers
were Deb Peckham and Carlo Piana.



Support the FSF's Licensing & Compliance Lab:






Sincerely,



Free Software Foundation








--=_b28cd891e5bf040229410f1f73f78e49--

--===============1851687585==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout

--===============1851687585==--

--===============1851687585==
Content-Type: multipart/alternative;
boundary="=_b28cd891e5bf040229410f1f73f78e49"

--=_b28cd891e5bf040229410f1f73f78e49
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8

*Please consider adding to your address book, which will
ensure that our messages reach you and not your spam box.*

*Read and share online:
*


Dear Ruben Safir,

Part of the Free Software Foundation (FSF's) core mission is to
advance policies that will promote the progress of free software and
freedom. Because copyright handling has been a topic of concern
lately, we are taking this opportunity to explain the four purposes
behind FSF copyright handling, as well as examine the impact of
potential alternatives.

For some GNU packages, the ones that are FSF-copyrighted, we ask
contributors for two kinds of legal papers: copyright assignments, and
employer copyright disclaimers. We drew up these policies working with
lawyers in the 1980s, and they make possible our steady and continuing
enforcement of the GNU General Public License (GPL).

These papers serve four different but related legal purposes, all of
which help ensure that the GNU Project's goals of freedom for the
community are met.

One purpose is to give explicit permission to include the material in
that GNU package. That is the most basic need.

The second purpose is to empower the FSF to go to court and say, "That
company is infringing our copyright when it tramples the freedom of
users, denying them the freedom that our license gives them." The
assignment does this by transferring the copyright to the FSF. (This
form of support for GNU is one of the original purposes for founding
the FSF.)

A third purpose is to make it possible to add additional permission to
specific pieces of code. For example, to take code released under GNU
GPL version-3-or-later and release it under GNU Lesser GPL
version-3-or-later.

Sometimes the individual author (or authors) of the code assign it.
Sometimes a company assigns copyright on its employees' writings. The
result is the same: The FSF gets the copyright.

There is an alternative to copyright assignment: instead of assigning
the copyright, the author can disclaim copyright on that material.
That means the material is effectively in the public domain. This
achieves the first and third of those purposes described above, but
not the second. It could weaken our copyright claim if it happened for
a large part of the program, but it's no problem if this occurs only
for a small part of the program.

Another alternative is to give the FSF an unlimited perpetual
nonexclusive license for the material. This is different from
disclaiming copyright in that the author continues to hold the
copyright, but, in practical terms, they are effectively equivalent:
Both achieve the first and third purpose but not the second.

We have preferences about these alternatives, which depend on the
situation, but we are flexible when possible.

The fourth purpose is to protect the community from the danger of
employers' surprise claims. What happens if J. R. Hacker contributes
some code, and we use it, all with good will and believing that to be
valid; but then Hacker's employer says, "That code belongs to us!
Hacker wrote it while on the job, working for us, so it's a 'work made
for hire.' You never had the right to distribute it, and we're going
to sue _all_ of you. Or maybe only some selected victims if that seems
advantageous."

The way we prevent this is by asking Hacker to get an employer
copyright disclaimer before contributing material. That way, Hacker's
employer will either sign, saying, "Ok, Hacker, you can contribute
your changes to that program," or refuse to sign, which warns Hacker
not to write contributions to that program while employed by that
employer. (We hope the employees of such companies find new, less
stingy employers soon.) This approach has saved us from a number of
messy situations, because some contributors asked their employers to
sign disclaimers and were refused. We could not use their code, but at
least everyone involved avoided getting in legal trouble.

The employer disclaimer also deals with the employer's patents and
interface copyrights that might cover the contributor's code.

We don't need an employer disclaimer in every case. If an individual
says, "I am an independent contractor; no employer could have a claim
on this work," that's clear cut, so we don't ask for an employer
disclaimer from the nonexistent employer.

Sometimes there is no individual contributor, in a legal sense,
because the employer assigns the copyright. Legally, that's solid.
(It's good that some people get paid to contribute to free software.)

These four purposes are related in a complex way, and not all are
applicable to every contribution. But each one is clear in concept.
One purpose is to give us permission to use the code, another the
power to defend it, a third to relicense it. The fourth purpose is to
make sure no marauding employers have an opportunity to wreak havoc.

The maintainers of some GNU packages would like to use a simple
mechanism instead of these legal papers. It is called a "Developer
Certificate of Origin" (DCO), and it makes a rough attempt at serving
the first purpose and the fourth purpose. It does not try to achieve
the second purpose, or the third one. Also, it is sloppy: the existing
DCOs don't make it clear who is the author of the code in a
contribution.

What about protecting against employer surprise claims? Instead of the
employer's signature saying, "We commit not to attack you," the DCO
gives us an employee's signature saying, "I certify that no employer
can claim rights to this code and attack you." It may do some good,
but it is hardly equivalent.

We think we can accept some amount of code from individual
contributors using DCOs instead of copyright assignments, for some
packages. To avoid weakening our protection for the whole community,
we need clear and careful DCOs, designed to make the copyright facts
clear.

Careful use of DCOs means that each contributor should _sign only for
personal contributions_ and identify clearly what they consist of.
Thus, Contributor A would sign a DCO only for the material that A
contributes. If A would like us to include code copied from some
released free program with a suitable compatible license, maybe we
can. But a DCO from A is a non-solution as regards the legalities.
Contributor A should instead show us what code that is, and where it
comes from, so we can think about the best way to use code from there.

If A wants us to install code written by B, we don't want A to sign
claiming, "I have the right to contribute this code (which I got from
B)." If B wrote the code, we want B to contribute it, not someone else
on B's behalf. Also, concretely, we need to know which code was B's
and which was A's -- so we can register the copyright in the United
States. Even though we think of DCOs as an inferior choice, we are
thinking of developing a DCO that does the DCO job right.

A few lines of code contributed under a clear DCO are not a problem,
but as the part of a package contributed under a DCO increases, so
does the effect of the DCO's drawbacks. This goes double if a sloppy
DCO is used.

To avoid weakening our protection for the whole community against
employer surprise claims, DCOs should be accompanied by the usual
employer disclaimers. Sadly, using DCOs would make relicensing code to
move it into certain libraries a precarious and unwieldy proposition,
relying on getting agreement of the other copyright holders or
removing their code.

Accepting corporations as copyright holders of code in GPL-covered
software packages risks causing a particular problem: a corporation is
unlikely to join in a GPL enforcement action against its subsidiary,
its parent, another subsidiary of its parent, its supplier, or its
client. Thus, even projects that use DCOs should not accept them from
corporations.

As our community well knows, the power of big tech corporations is
increasing, and their influence over organizations in the free
software community is increasing too. Some of them are opposed to GPL
enforcement, which is an increasing problem. This is not the time to
weaken our legal defenses; we must keep them strong.

###

P.S. You can learn about the assignment process by reading our
[Contributor's Frequently Asked Questions (FAQ)
guide](https://www.fsf.org/licensing/contributor-faq)

The FSF would like to thank the many community legal experts who
reviewed this article and provided valuable suggestions based on their
knowledge of these complex legal issues. Among the expert reviewers
were Deb Peckham and Carlo Piana.

Support the FSF's Licensing & Compliance Lab:

* If you are not already signed up, you can keep up to date on
upcoming legal issues by joining the [licensing & compliance mailing
list][1].

* Support our work by [donating][2] to the FSF.

[1]: https://my.fsf.org/civicrm/mailing/subscribe?reset=1&gid=1524
[2]: https://donate.fsf.org

Sincerely,

Free Software Foundation


--
* Follow us on Mastodon at , GNU social at
, Diaspora at ,
PeerTube at , and on Twitter at -at-fsf.
* Read about why we use Twitter, but only with caveats at .
* Subscribe to our RSS feeds at .
* Join us as an associate member at .
* Read our Privacy Policy at .

Sent from the Free Software Foundation,

51 Franklin St, Fifth Floor
Boston, Massachusetts 02110-1335
United States


You can unsubscribe from this mailing list by visiting

https://my.fsf.org/civicrm/mailing/unsubscribe?reset=1&jid=163908&qid=68905403&h=28d0598e969d0150.

To stop all email from the Free Software Foundation, including Defective by Design,
and the Free Software Supporter newsletter, visit

https://my.fsf.org/civicrm/mailing/optout?reset=1&jid=163908&qid=68905403&h=28d0598e969d0150.
--=_b28cd891e5bf040229410f1f73f78e49
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

































Free Software Foundation








Please consider adding info@fsf.org to your address book, which will
ensure that our messages reach you and not your spam box.



Read and share online:
https://www.fsf.org/blogs/licensing/FSF-copyright-handling





Dear Ruben Safir,



Part of the Free Software Foundation (FSF's) core mission is to
advance policies that will promote the progress of free software and
freedom. Because copyright handling has been a topic of concern
lately, we are taking this opportunity to explain the four purposes
behind FSF copyright handling, as well as examine the impact of
potential alternatives.



For some GNU packages, the ones that are FSF-copyrighted, we ask
contributors for two kinds of legal papers: copyright assignments, and
employer copyright disclaimers. We drew up these policies working with
lawyers in the 1980s, and they make possible our steady and continuing
enforcement of the GNU General Public License (GPL).



These papers serve four different but related legal purposes, all of
which help ensure that the GNU Project's goals of freedom for the
community are met.



One purpose is to give explicit permission to include the material in
that GNU package. That is the most basic need.



The second purpose is to empower the FSF to go to court and say, "That
company is infringing our copyright when it tramples the freedom of
users, denying them the freedom that our license gives them." The
assignment does this by transferring the copyright to the FSF. (This
form of support for GNU is one of the original purposes for founding
the FSF.)



A third purpose is to make it possible to add additional permission to
specific pieces of code. For example, to take code released under GNU
GPL version-3-or-later and release it under GNU Lesser GPL
version-3-or-later.



Sometimes the individual author (or authors) of the code assign it.
Sometimes a company assigns copyright on its employees' writings. The
result is the same: The FSF gets the copyright.



There is an alternative to copyright assignment: instead of assigning
the copyright, the author can disclaim copyright on that material.
That means the material is effectively in the public domain. This
achieves the first and third of those purposes described above, but
not the second. It could weaken our copyright claim if it happened for
a large part of the program, but it's no problem if this occurs only
for a small part of the program.



Another alternative is to give the FSF an unlimited perpetual
nonexclusive license for the material. This is different from
disclaiming copyright in that the author continues to hold the
copyright, but, in practical terms, they are effectively equivalent:
Both achieve the first and third purpose but not the second.



We have preferences about these alternatives, which depend on the
situation, but we are flexible when possible.



The fourth purpose is to protect the community from the danger of
employers' surprise claims. What happens if J. R. Hacker contributes
some code, and we use it, all with good will and believing that to be
valid; but then Hacker's employer says, "That code belongs to us!
Hacker wrote it while on the job, working for us, so it's a 'work made
for hire.' You never had the right to distribute it, and we're going
to sue all of you. Or maybe only some selected victims if that seems
advantageous."



The way we prevent this is by asking Hacker to get an employer
copyright disclaimer before contributing material. That way, Hacker's
employer will either sign, saying, "Ok, Hacker, you can contribute
your changes to that program," or refuse to sign, which warns Hacker
not to write contributions to that program while employed by that
employer. (We hope the employees of such companies find new, less
stingy employers soon.) This approach has saved us from a number of
messy situations, because some contributors asked their employers to
sign disclaimers and were refused. We could not use their code, but at
least everyone involved avoided getting in legal trouble.



The employer disclaimer also deals with the employer's patents and
interface copyrights that might cover the contributor's code.



We don't need an employer disclaimer in every case. If an individual
says, "I am an independent contractor; no employer could have a claim
on this work," that's clear cut, so we don't ask for an employer
disclaimer from the nonexistent employer.



Sometimes there is no individual contributor, in a legal sense,
because the employer assigns the copyright. Legally, that's solid.
(It's good that some people get paid to contribute to free software.)



These four purposes are related in a complex way, and not all are
applicable to every contribution. But each one is clear in concept.
One purpose is to give us permission to use the code, another the
power to defend it, a third to relicense it. The fourth purpose is to
make sure no marauding employers have an opportunity to wreak havoc.



The maintainers of some GNU packages would like to use a simple
mechanism instead of these legal papers. It is called a "Developer
Certificate of Origin" (DCO), and it makes a rough attempt at serving
the first purpose and the fourth purpose. It does not try to achieve
the second purpose, or the third one. Also, it is sloppy: the existing
DCOs don't make it clear who is the author of the code in a
contribution.



What about protecting against employer surprise claims? Instead of the
employer's signature saying, "We commit not to attack you," the DCO
gives us an employee's signature saying, "I certify that no employer
can claim rights to this code and attack you." It may do some good,
but it is hardly equivalent.



We think we can accept some amount of code from individual
contributors using DCOs instead of copyright assignments, for some
packages. To avoid weakening our protection for the whole community,
we need clear and careful DCOs, designed to make the copyright facts
clear.



Careful use of DCOs means that each contributor should sign only for
personal contributions
and identify clearly what they consist of.
Thus, Contributor A would sign a DCO only for the material that A
contributes. If A would like us to include code copied from some
released free program with a suitable compatible license, maybe we
can. But a DCO from A is a non-solution as regards the legalities.
Contributor A should instead show us what code that is, and where it
comes from, so we can think about the best way to use code from there.



If A wants us to install code written by B, we don't want A to sign
claiming, "I have the right to contribute this code (which I got from
B)." If B wrote the code, we want B to contribute it, not someone else
on B's behalf. Also, concretely, we need to know which code was B's
and which was A's -- so we can register the copyright in the United
States. Even though we think of DCOs as an inferior choice, we are
thinking of developing a DCO that does the DCO job right.



A few lines of code contributed under a clear DCO are not a problem,
but as the part of a package contributed under a DCO increases, so
does the effect of the DCO's drawbacks. This goes double if a sloppy
DCO is used.



To avoid weakening our protection for the whole community against
employer surprise claims, DCOs should be accompanied by the usual
employer disclaimers. Sadly, using DCOs would make relicensing code to
move it into certain libraries a precarious and unwieldy proposition,
relying on getting agreement of the other copyright holders or
removing their code.



Accepting corporations as copyright holders of code in GPL-covered
software packages risks causing a particular problem: a corporation is
unlikely to join in a GPL enforcement action against its subsidiary,
its parent, another subsidiary of its parent, its supplier, or its
client. Thus, even projects that use DCOs should not accept them from
corporations.



As our community well knows, the power of big tech corporations is
increasing, and their influence over organizations in the free
software community is increasing too. Some of them are opposed to GPL
enforcement, which is an increasing problem. This is not the time to
weaken our legal defenses; we must keep them strong.



#



P.S. You can learn about the assignment process by reading our
Contributor's Frequently Asked Questions (FAQ)
guide



The FSF would like to thank the many community legal experts who
reviewed this article and provided valuable suggestions based on their
knowledge of these complex legal issues. Among the expert reviewers
were Deb Peckham and Carlo Piana.



Support the FSF's Licensing & Compliance Lab:






Sincerely,



Free Software Foundation








--=_b28cd891e5bf040229410f1f73f78e49--

--===============1851687585==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout

--===============1851687585==--

  1. 2021-08-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Wykoof like
  2. 2021-08-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Chaim Deutsch
  3. 2021-08-02 G?bor Szab? <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #523 - How to improve your Perl?
  4. 2021-08-07 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Hangout - NYLXS] New Tee Shirts
  5. 2021-08-08 Luis Falcon <falcon-at-gnuhealth.org> Re: [Hangout - NYLXS] [Health] pgadmin4
  6. 2021-08-08 Axel Braun <axel.braun-at-gmx.de> Re: [Hangout - NYLXS] [Health] pgadmin4
  7. 2021-08-08 From: "Schanzenbach, Martin" <mschanzenbach-at-posteo.de> Subject: [Hangout - NYLXS] GNUnet 0.15.0 released
  8. 2021-08-09 G?bor Szab? <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #524 - Object::Pad
  9. 2021-08-11 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout - NYLXS] IEEE EMBS Public Forum on Healthcare Tech
  10. 2021-08-16 G?bor Szab? <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #525 - Vacation time?
  11. 2021-08-17 NYOUG <execdir-at-nyoug.org> Subject: [Hangout - NYLXS] Upcoming Events for Oracle Professionals
  12. 2021-08-19 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout - NYLXS] IEEE EMBS Public Forum on Healthcare Tech
  13. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  14. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  15. 2021-08-20 Qontinuum <qontinuum-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  16. 2021-08-20 Jeff Pohlmeyer <yetanothergeek-at-gmail.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  17. 2021-08-20 Jeff Pohlmeyer <yetanothergeek-at-gmail.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  18. 2021-08-20 Qontinuum <qontinuum-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  19. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  20. 2021-08-20 Qontinuum <qontinuum-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  21. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  22. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  23. 2021-08-19 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  24. 2021-08-10 Dudemanguy <dudemanguy-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] [s6] starting oneshots as non
  25. 2021-08-09 Javier <je-vv-at-e.email> Re: [Hangout - NYLXS] [artix-general] [s6] starting oneshots as non
  26. 2021-08-09 Dudemanguy <dudemanguy-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] [s6] starting oneshots as non
  27. 2021-08-09 Javier <je-vv-at-e.email> Subject: [Hangout - NYLXS] [artix-general] [s6] starting oneshots as non root
  28. 2021-08-20 Qontinuum <qontinuum-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  29. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  30. 2021-08-20 Qontinuum <qontinuum-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  31. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  32. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] [artix-general] mirror dns issues with orion
  33. 2021-08-20 winfried szukalski <szukw000-at-arcor.de> Subject: [Hangout - NYLXS] [png-mng-implement] Reading single MNG image
  34. 2021-08-19 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout - NYLXS] IEEE EMBS Public Forum on Healthcare Tech
  35. 2021-08-20 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  36. 2021-08-20 From: "Donald Robertson, III, FSF" <info-at-fsf.org> Subject: [Hangout - NYLXS] Meeting every Friday: Help us update the Free
  37. 2021-08-21 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout - NYLXS] [artix-general] iptables blocking dns queries
  38. 2021-08-21 Javier <je-vv-at-e.email> Subject: [Hangout - NYLXS] [artix-general] [thunderbird-artix] TB calendar
  39. 2021-08-23 G?bor Szab? <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #526 - Politics in Programming?
  40. 2021-08-22 artist <artist-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] [thunderbird-artix] TB
  41. 2021-08-23 mayer ilovitz <pmamayeri-at-gmail.com> Subject: [Hangout - NYLXS] JP 8/20/21: Yes,
  42. 2021-08-23 G?bor Szab? <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #526 - Politics in Programming?
  43. 2021-08-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] genes Genes Jeans
  44. 2021-08-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] [artix-general] squashed initramfs.img
  45. 2021-08-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Actually - it is a bug with xfs root file systems
  46. 2021-08-25 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [artix-general] Actually - it is a bug with
  47. 2021-08-26 From: "Pat Schloss" <pschloss-at-umich.edu> Subject: [Hangout - NYLXS] [mothur] mothur v.1.46.0 release and other
  48. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Subject: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  49. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Subject: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  50. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Subject: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  51. 2021-08-28 Luis Falcon <falcon-at-gnuhealth.org> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  52. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  53. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  54. 2021-08-27 Luis Falcon <falcon-at-gnuhealth.org> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  55. 2021-08-27 Kevin Cole <dc.loco-at-gmail.com> Subject: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  56. 2021-08-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Future of Fashion - today..
  57. 2021-08-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Really we are reaching the end of humanity...
  58. 2021-08-30 Lee Shallis <gb2985-at-gmail.com> Subject: [Hangout - NYLXS] [png-mng-implement] Own implementation
  59. 2021-08-29 Luis Falcon <falcon-at-gnuhealth.org> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  60. 2021-08-28 Kevin Cole <dc.loco-at-gmail.com> Re: [Hangout - NYLXS] [Health] My GNU Health merely crashes...
  61. 2021-08-31 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Fwd: Control your computer with code,
  62. 2021-08-30 From: "Free Software Foundation" <info-at-fsf.org> Subject: [Hangout - NYLXS] FSF copyright handling: A basis for distribution,
  63. 2021-08-25 David Booth <david-at-dbooth.org> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads? [EXT]
  64. 2021-08-25 Jacques Deguest <jack-at-deguest.jp> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  65. 2021-08-25 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads? [EXT]
  66. 2021-08-25 Brad Van Sickle <bvs7085-at-gmail.com> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  67. 2021-08-24 David Booth <david-at-dbooth.org> Subject: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  68. 2021-08-10 From: "Tammer, Rainer" <Rainer.Tammer-at-schulergroup.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX
  69. 2021-08-11 Steve Hay <steve.m.hay-at-googlemail.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX
  70. 2021-08-10 Steve Hay <steve.m.hay-at-googlemail.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX
  71. 2021-08-28 Alexandre Prokoudine via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] screen interface too small to use
  72. 2021-08-28 Kerry Jones via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] screen interface too small to use
  73. 2021-08-25 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] language
  74. 2021-08-25 Fons de Wit <fons.de.wit-at-orange.fr> Subject: [Hangout - NYLXS] [Gimp-user] language
  75. 2021-08-25 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads? [EXT]
  76. 2021-08-25 David Booth <david-at-dbooth.org> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads? [EXT]
  77. 2021-08-25 Jacques Deguest <jack-at-deguest.jp> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  78. 2021-08-25 Brad Van Sickle <bvs7085-at-gmail.com> Re: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  79. 2021-08-24 David Booth <david-at-dbooth.org> Subject: [Hangout - NYLXS] Sharing read/WRITE data between threads?
  80. 2021-08-10 From: "Tammer, Rainer" <Rainer.Tammer-at-schulergroup.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX
  81. 2021-08-11 Steve Hay <steve.m.hay-at-googlemail.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX
  82. 2021-08-10 Steve Hay <steve.m.hay-at-googlemail.com> Re: [Hangout - NYLXS] Problem compiling mod_perl on AIX

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