From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: keep a gen 2013 snapshot on mirrors
Date: Fri, 15 Nov 2013 13:17:24 +0000 (UTC) [thread overview]
Message-ID: <pan$3e108$fd2e402e$e53a6146$e354bb8@cox.net> (raw)
In-Reply-To: CAGfcS_nX12uXP_uJuL9aLEnD+YNFXhPQabj1E0GCQwMkWKSsVw@mail.gmail.com
Rich Freeman posted on Wed, 13 Nov 2013 16:18:51 -0500 as excerpted:
> On Wed, Nov 13, 2013 at 3:49 PM, Roy Bamford <neddyseagoon@gentoo.org>
> wrote:
>> The GPL obliges us to keep such patches around for three years, iirc.
>> Don't we do that ?
>
> Why? We own the copyright on the patches (to whatever degree that
> they're copyrightable), so we don't need a license to distribute them.
> If somebody else wants to redistribute our patches they need our
> permission or they need to comply with whatever license we issue them
> under (likely the same as the upstream license so that our users don't
> have bindist issues).
IANAL of course, but as someone who cares about such things because he
knows they protect his rights, and who thus follows discussions such as
this rather closer than most...
For the GPL, the biggest concern is binary distribution, covered under
section three of the GPL (v2 at least), and this is where the three-year
clause appears. Because gentoo in-the-main only distributes sources and
any patches are generally distributed under the same license as the
primary package sources, that clause in general doesn't apply.
There are, however, two big exceptions to gentoo's sources-only
distribution, the installers and stage tarballs, and the packages CD/DVD
images. It is with these that there is some concern, and where gentoo
has in the past had GPL violations.
However, if you look at section three, there are three alternative
clauses. Complying with only one of the three is necessary (my rewording
of the GPLv2 license from the file in the tree, see the license itself
for the literal wording if there's any doubt):
3a) Accompany binaries/object code with complete source-code.
3b) Accompany them with a written offer for source code, valid for at
least three years from date of last distribution of binary/object code.
3c) Pass on the 3b offer you received from upstream. (Non-commercial
only, only applies to code unmodified from upstream and thus not to the
case under discussion.)
Since 3c is out for modified code, that leaves 3a or 3b. But the three
years of 3b ends up being a long time to track such things! Luckily,
there's still 3a, which if properly complied with, lets gentoo off the
hook for 3b.
What that means is this: Every time and place gentoo distributes
binaries, we must make available sources as well. If we're giving away
install-CDs at a conference, we better have a few copies of the parallel
sources CD, including our patches, available as well. (The stack of
sources CDs could of course be smaller, provided we're willing to remove
the stack of installer CDs until we burn a few more source CDs if they
ever run out.)
Similarly on the net, if we're distributing stage tarballs, we should
ensure that we have the sources available for download at the same time
as well.
Where gentoo screwed up in the past is that for quite awhile, we kept
past installer images available as well, "for historical interest". At
some point we were made aware of the fact that this was a violation of
the GPL if the corresponding sources, INCLUDING OUR PATCHES, were not
either directly available as well, or available on request for three
years, and we had to take those historical copies down.
But IIRC that was well over three years ago now, so AFAIK, we're out of
violation on at least the major scale, tho it remains possible that
someone representing gentoo at a conference might up and fail to ensure
those source CDs are made available with the installer CDs, for instance,
thus obligating us to a three-year-clock we might have problems actually
following up on, should someone make that request. I would hope that the
PR project folks properly brief all conference booth volunteers to ensure
that doesn't happen, however.
> The only thing we might need a license to redistribute are the parts of
> the patch that we didn't change, and upstream already provides those.
>
> I don't think patches are a derivative work.
To the extent patches are larger than the rather blurry "trivial" level,
I believe there's no question that they ARE derivative. In the case of
literal patches, literally and provably so, due to the context-diff which
literally includes lines from the original from which it is derived.
However, fair-use laws often allow "trivial" use, and while that's a
somewhat blurry line and fair-use laws definitely differ from country to
country, I found a reference in the FSF FAQ that says they use a 300-line
benchmark (tho that's in the "whole work" context):
http://www.gnu.org/licenses/gpl-faq.html#WhatIfWorkIsShort
While I think most would agree that a one-line patch is "trivial", I'm
not so sure about a 50-line patch tho it's nowhere near that 300-line
threshold, which itself is just the FSF benchmark, tho I'm not sure if
that FAQ context is applicable to patches or not.
However, given the above 3a clause and gentoo's efforts to comply with
it, I suppose the whole question of triviality becomes moot.
> At least, that's my understanding of copyright.
Likewise mine. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2013-11-15 13:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 18:58 [gentoo-dev] keep a gen 2013 snapshot on mirrors Francesco R.
2013-11-13 19:12 ` Rich Freeman
2013-11-13 20:49 ` Roy Bamford
2013-11-13 21:18 ` Rich Freeman
2013-11-15 13:17 ` Duncan [this message]
2013-11-15 13:38 ` [gentoo-dev] " Rich Freeman
2013-11-15 15:24 ` Duncan
2013-11-15 15:59 ` Peter Stuge
2013-11-14 0:27 ` [gentoo-dev] " Tom Wijsman
2013-11-14 13:17 ` Francesco R.
2013-11-14 14:01 ` Rich Freeman
2013-11-14 13:19 ` Lars Wendler
2013-11-14 19:49 ` Ian Stakenvicius
2013-11-13 19:16 ` Rick "Zero_Chaos" Farina
2013-11-14 4:38 ` Johann Schmitz
2013-11-14 13:09 ` Francesco R.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$3e108$fd2e402e$e53a6146$e354bb8@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox