Copyleft/guide
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

This material was accidentally pasted down with GPLv3§7 stuff,

Browse source 
but it's for GPLv3§6.
This commit is contained in:
Bradley M. Kuhn 2014-03-20 15:21:49 -04:00
parent 9de90679bb
commit dac68d1410
1 changed files with 49 additions and 50 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

99
gpl-lgpl.tex
View file

@ -2864,7 +2864,55 @@ give CCS to someone who has not purchased an object code download under
GPLv3~\S6(d). (Note: this does not change nor impact any obligations under
GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)
%FIXME: 6e, peer-to-peer
\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}
Certain decentralized forms of peer-to-peer file sharing present a challenge
to the unidirectional view of distribution that is implicit in GPLv2 and
Draft 1 of GPLv3. It is neither straightforward nor reasonable to identify
an upstream/downstream link in BitTorrent distribution; such distribution is
multidirectional, cooperative and anonymous. In systems like BitTorrent,
participants act both as transmitters and recipients of blocks of a
particular file, but they see themselves as users and receivers, and not as
distributors in any conventional sense. At any given moment of time, most
peers will not have the complete file.
% FIXME: rewrite a bit.
The GPL permits distribution of a work in object code form over a network,
provided that the distributor offers equivalent access to copy the
Corresponding Source Code ``in the same way through the same place.'' This
wording might be interpreted to permit BitTorrent distribution of binaries if
they are packaged together with the source code, but this impractical, for at
least two reasons. First, even if the source code is packaged with the
binary, it will only be available to a non-seeding peer at the end of the
distribution process, but the peer will already have been providing parts of
the binary to others in the network, functioning rather like a router or a
cache proxy. Second, in practice BitTorrent and similar peer-to-peer forms
of transmission have been less suitable means for distributing source code.
In large distributions, packaging source code with the binary may result in a
substantial increase in file size and transmission time. Source code
packages themselves tend not to be transmitted through BitTorrent owing to
reduced demand. There generally will be too few participants downloading the
same source package at the same time to enable effective seeding and
distribution.
% FIXME: rewrite a bit.
We have made two changes that recognize and facilitate distribution of
covered works in object code form using BitTorrent or similar peer-to-peer
methods. First, under new subsection 6e, if a licensee conveys such a work
using peer-to-peer transmission, that licensee is in compliance with section
6 so long as the licensee knows, and informs other peers where, the object
code and its Corresponding Source are publicly available at no charge under
subsection 6d. The Corresponding Source therefore need not be provided
through the peer-to-peer system that was used for providing the binary.
Second, we have revised section 9 to make clear that ancillary propagation of
a covered work that occurs as part of the process of peer-to-peer file
transmission does not require acceptance, just as mere receipt and execution
of the Program does not require acceptance. Such ancillary propagation is
permitted without limitation or further obligation.
% FIXME: where does this go?
Informing the peers is clearly enough; what seemed to be an additional
knowledge requirement was superfluous wording.
@ -3371,55 +3419,6 @@ use.
% FIXME: 7d-f
\section{GPLv3~\S7(e): Peer-to-Peer Sharing Networks}
% FIXME: rewrite a bit, maybe drop reference to bitorrent?
Certain decentralized forms of peer-to-peer file sharing present a challenge
to the unidirectional view of distribution that is implicit in GPLv2 and
Draft 1 of GPLv3. It is neither straightforward nor reasonable to identify
an upstream/downstream link in BitTorrent distribution; such distribution is
multidirectional, cooperative and anonymous. In systems like BitTorrent,
participants act both as transmitters and recipients of blocks of a
particular file, but they see themselves as users and receivers, and not as
distributors in any conventional sense. At any given moment of time, most
peers will not have the complete file.
% FIXME: rewrite a bit.
The GPL permits distribution of a work in object code form over a network,
provided that the distributor offers equivalent access to copy the
Corresponding Source Code ``in the same way through the same place.'' This
wording might be interpreted to permit BitTorrent distribution of binaries if
they are packaged together with the source code, but this impractical, for at
least two reasons. First, even if the source code is packaged with the
binary, it will only be available to a non-seeding peer at the end of the
distribution process, but the peer will already have been providing parts of
the binary to others in the network, functioning rather like a router or a
cache proxy. Second, in practice BitTorrent and similar peer-to-peer forms
of transmission have been less suitable means for distributing source code.
In large distributions, packaging source code with the binary may result in a
substantial increase in file size and transmission time. Source code
packages themselves tend not to be transmitted through BitTorrent owing to
reduced demand. There generally will be too few participants downloading the
same source package at the same time to enable effective seeding and
distribution.
% FIXME: rewrite a bit.
We have made two changes that recognize and facilitate distribution of
covered works in object code form using BitTorrent or similar peer-to-peer
methods. First, under new subsection 6e, if a licensee conveys such a work
using peer-to-peer transmission, that licensee is in compliance with section
6 so long as the licensee knows, and informs other peers where, the object
code and its Corresponding Source are publicly available at no charge under
subsection 6d. The Corresponding Source therefore need not be provided
through the peer-to-peer system that was used for providing the binary.
Second, we have revised section 9 to make clear that ancillary propagation of
a covered work that occurs as part of the process of peer-to-peer file
transmission does not require acceptance, just as mere receipt and execution
of the Program does not require acceptance. Such ancillary propagation is
permitted without limitation or further obligation.
% FIXME: removing additional restrictions