This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFH: GPLv3


I'll start this by pointing out that (like Robert), I'm not an attorney.
But both of us have been familiar with GPL and related copyright issues for
well over a decade.

> When you post a patch to the mailing list, or apply it to a branch, you are
> acting as an agent of FSF.  You previously assigned your rights to the patch
> to the FSF.  (If you have not assigned your rights, then your patch will
> not be applied to the branch, so it doesn't matter.)
> 
> The FSF decides what licenses to apply to a patch.  It's not at all unclear
> what point the license applies:  at the moment FSF has said that all patches
> applied after August 1 are covered by GPLv3.

That seems confused.  First of all, when I post a patch to a mailing list,
it would seem to me that I am clearly doing so as an individual.  I don't
see any way at all that I could be viewed as an agent of the FSF.  I might
not even KNOW ABOUT the FSF, for example.  As to whether a person APPLYING
a patch is acting as an agent of the FSF, I'm not sure about that and I was
trying to figure that out.  But then I realized that it doesn't matter.

Let's go through the exact steps a patch takes and try to understand what
its copyright status is at that time.  For simplicity, let's say I'm
patching one of the few public-domain files so we can ignore the issue of
the patch being a derived work for now.  And let's also assume that my
patch has protectable content.

The instant I first write down the patch, I have created a copyrighted work
with me as the copyright holder.  What are the copying rights of that work?
Since I haven't established any, it can't be copied.  I now work on, debug,
test, and refine the patch.  None of those change its copyright status.

Now I post it on the GCC list.  I have an assigment on file that assigns my
changes to GCC to the FSF.  You could argue that such an assignment means
that the changes were assigned to the FSF when they were first written, but
I don't think that's the proper interpretation.  I think the assignment
gives the terms of any patch that I CHOOSE to assign to the FSF and we all
understand that the act of posting such a patch indicates the making of
such a choice.  But whichever is the case, at the time I post the patch,
its copyright is owned by the FSF.

But what are the terms under which that can be copied?  I haven't set them.
The FSF hasn't even SEEN the patch, so it hasn't set them!  You can't say
there's some default that applies to posted patches because, for example,
some are GPL and some are LGPL.  However, the assignment agreement gives
minimum terms that the FSF must follow should it later distribute it (I do
not believe that posting on the list, something that *I've* done, is
"distribution" in the sense of the assignment agreement).  Let's call those
terms the "mini-GPL".  My view is that, in the absence of any other
identifiable document that would establish terms, those are the terms.

Now what happens when the patch is applied?  The person applying the patch
(often its author) is verifying (on BEHALF of the FSF, but not necessarily
as its agent) that the legal status of the patch is acceptable for the file
its being applied to.  Whatever the license of that file, the mini-GPL is
"compatible" with it (the meaning of "compatible" is as in the GPL), so the
patch can be safely applied.

You might argue that as part of that application process, the person
applying it is acting as an "agent" of the FSF and choosing a license to be
used for the patch itself.  I disagree.  For one thing, there is no legal
basis for that person to be taking such an action as the agent of the FSF.
For another, there is no REASON to take such an action, so, in law, once
should not have presumed that it has occurred.  This means that the act
of applying a patch does not change its copyright status.

> You have it backward:  the base source doesn't determine the license status
> of the patch; the patch determines the license status of the source.  The
> most restrictive license applies.  Read the GPLv3.

You're missing the point and making an irrelevant statement, though your
statement that "the most restrictive license applies" is certainly correct.
I was talking about the state of the patch BEFORE it's posted and well
before it's applied to an official source file.

The point I was trying to make is that a patch rarely is like the above:
namely that it doesn't derive from any other work.  More normally, you
obtain a patch by modifying some file.  That modification creates a
"derived work" to which the original license applies.

Let's revisit the example above.  I take a file which, for the purpose of
this example will be GPLv2.  I modify that file to fix some bug.  That file
remains GPLv2 because its a derived work of a GPLv2 file and nobody has
changed its license condition (I COULD HAVE changed it to GPLv3, since
everybody has that right by the GPL, but I chose not to).  After I get
everything working, I make the patch.  This time, though, the patch is not
just my intellectual property: it's also derived from an FSF-copyrighted
work.  But since also contains my intellectual property, it has a dual
copyright: mine and the FSF.  At the time I post the patch, I'm assigning
my part of the rights in that patch to the FSF.  We now ALSO have the
question of which license that part has and the answer is the same, the
"mini-GPL", but now it's irrelevant because the copyright for the patch now
has only a single owner (the FSF) and one of the licenses (GPLv2) says that
if multiple licenses appy, the most restrictive is to be used and the
mini-GPL is less restrictive than the mini-GPL, so the patch is clearly
GPLv2.

When I apply the patch to the file, there's now only one license agreement
to consider, so no issue.

If you disagree with this result, please don't just quote generalities
but say exactly which step of the above analysis you disagree with.

> > Now, suppose I apply it to the GPLv2 version of the file. One could argue
> > that such file is now GPLv3 and I think that'd be correct.  But since the
> > parts of the file being patched are identical, the patch is
> > indistinguishable from one that's derived from GPLv2 text.  This strikes
> > me as a VERY murky legal areas.
>
> Sorry, it isn't at all murky.  If the original patch was covered under GPLv3,
> no matter how similar it might be to one which hypothetically might have
> been created under a different license, it remains GPLv3.  It's not whether
> the patch is indistinguishable, its that it was not independently developed.

But it WAS independently developed!  Let's suppose the purpose of the patch
was to change all occurences of "function1" to "function2".  That patch has
no protectable content, so the question of what license the PATCH ITSELF
has is irrelevant.  If I start with a GPLv2 file and do that edit, I still
have a GPLv2 file.  Likewise for the GPLv3 file.  I don't think there's any
question about that.  But now suppose that the only uses of "function1" are
in parts of the that have not changed (and there are no line-number
differences).  That means the changes to the files, expressed as diff
output, are identical.  Robert is quite right that you can have two
independently-developed identical objects that can have different
copyrights and the above is an example of such.  The problem is in tracking
which of these two identical things we're talking about once they've both
be posted on various lists: THAT'S where the murk comes in.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]