Patchwork [gccgo] Add notes about contributing patches

login
register
mail settings
Submitter Ian Taylor
Date Dec. 2, 2010, 11:23 p.m.
Message ID <mcr1v5z7oa1.fsf@google.com>
Download mbox | patch
Permalink /patch/74043/
State New
Headers show

Comments

Ian Taylor - Dec. 2, 2010, 11:23 p.m.
This patch extends the README files which will be in the gcc repository
to discuss contributing patches to the Go frontend and libgo.  Committed
to gccgo branch.

Ian
Alexandre Oliva - Dec. 3, 2010, 6:21 a.m.
Hi, Ian,

On Dec  2, 2010, Ian Lance Taylor <iant@google.com> wrote:

> +To contribute patches to the files in this directory, please see
> +http://golang.org/doc/gccgo_contribute.html .
> +
> +Changes to these files require a copyright assignment to Google.  This
> +is required to permit the changes to be copied to the gcc repository,
> +as Google has a copyright assignment with the Free Software
> +Foundation.

Hmm, I sense some disconnect in here.

If the goal is to ensure the copyright is held by the FSF, then people
who already have a copyright assignment to the FSF in place don't have
to go through the process of assigning copyright to Google.  Indeed,
they arguably should *not* do so, for this would amount to assigning the
same copyright to two different entities, which would be odd at best.

Now, if the goal is that Google gets a copyright assignment from all
contributors so that it can donate it to the FSF and get back a
permission to release the code under whatever terms it likes, I don't
think it would be in the best interest of the Free Software community,
the GNU project or the FSF (although I don't speak for any of the 3), to
advertise and encourage people to grant Google such permissions.

Indeed, the contributor license agreement mentioned below AFAICT does
transfer to Google the status of copyright holder of the contribution.
The agreement is just an all-permissive license, so Google's copyright
assignment with the FSF would be irrelevant WRT ensuring the FSF holds
the copyright over the contributed code is concerned.

> +http://code.google.com/legal/individual-cla-v1.0.html.

I have another issue with this agreement: it uses the term “intellectual
property”, against whose use the GNU project recommends.
http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty

It would be unfortunate if the GNU project were to require contributors
to be exposed sign agreements that accept and reinforce the use of this
misleading and confusing term.


Can you please clarify, and make sure that people who already have a
copyright assignment with the FSF in place need not go through this
process, that the documentation gives preference to that course over
granting Google a non-copyleft, all-permissive license?

Furthermore, could you please try to get Google to amend the web page so
as to use terms such as copyright and patents, rather than a term that
also brings concerns about trademarks, designs, hardware masks and trade
secrets, none of which are covered in the licensing agreement?

Could you also please try to get into the agreement some commitment back
from Google to always release the contributed code as Free Software?
Ideally, under the GPL?  It shouldn't be hard to get this commitment,
since contributions to GCC Go would naturally be derived from the GPLed
code whose copyright is held by the FSF.

This IMNALO (*) means Google wouldn't be actually losing any options as
to how to use the contributed code (save for any unknown-to-me loopholes
that Google is hopefully not going to attempt to exploit), developers
who care about the defense of users' freedoms wouldn't have to worry
about the risk that Google might be planning on misusing their
contributions, and they wouldn't have to worry whether they're breaking
copyright law by licensing under all-permissive terms code that, per the
license of the work on which they based it, they could only release
under the terms of the GPL.


Thanks in advance,


(*) In my not-a-lawyer opinion
Basile Starynkevitch - Dec. 3, 2010, 6:46 a.m.
On Fri, 03 Dec 2010 04:21:16 -0200
Alexandre Oliva <aoliva@redhat.com> wrote:

> Hi, Ian,
> 
> On Dec  2, 2010, Ian Lance Taylor <iant@google.com> wrote:
> 
> > +To contribute patches to the files in this directory, please see
> > +http://golang.org/doc/gccgo_contribute.html .
> > +
> > +Changes to these files require a copyright assignment to Google.  [...]
> 
> Hmm, I sense some disconnect in here. 
[...]
> 
> 
> Can you please clarify, and make sure that people who already have a
> copyright assignment with the FSF in place need not go through this
> process, that the documentation gives preference to that course over
> granting Google a non-copyleft, all-permissive license?


I also find all this strange & confusing.

If the social & legal rules for some subdirectories (eg gcc/go/ or
libgo/) of the GCC Trunk on svn are becoming different, I would think
it would be simpler (& less error prone) to put that subdirectory on
some other svn service, to ensure that a single svn commit to GCC trunk
(following the usual rules: contributor covered by legal document to
FSF, peer-reviewed patch) don't have several social & legal
requirements.

For me Basile, getting the legal papers was so painful that I will
never do that again. So if I need any bureaucratic work (i.e. to get
another legal signature from my employer) to be able to propose some
patch to gcc/go/ or libgo/ I prefer to avoid proposing such patches.

But I might be perhaps interested to contribute some tiny things to go.
Intellectually I could be interested by its garbage collector, or by
adding ability to dlopen some shared object producted by the GCC go
compiler into some go module (but of course I don't promise anything).

However, if sending a four line patch for gcc/go or libgo/ requires yet
another legal document, I won't even look inside these directories.

So definitely, a clarification is welcome. Can people (like me) already
covered by a copyright assignment to FSF send patches for gcc/go or
libgo/ or should they avoid that? 

Or is Google's goal to avoid any patch [to the gcc/go or libgo/ part of
FSF GCC trunk] which is not covered by an extra legal document with
Google?

I hope that legal rules to submit patches don't vary from one
subdirectory of the GCC trunk to another.

Cheers.

PS. Maybe my English understanding was bad, and I did not understood
all of Ian's message.
Ian Taylor - Dec. 3, 2010, 3:25 p.m.
On Thu, Dec 2, 2010 at 10:21 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>
> If the goal is to ensure the copyright is held by the FSF, then people
> who already have a copyright assignment to the FSF in place don't have
> to go through the process of assigning copyright to Google.  Indeed,
> they arguably should *not* do so, for this would amount to assigning the
> same copyright to two different entities, which would be odd at best.
>
> Now, if the goal is that Google gets a copyright assignment from all
> contributors so that it can donate it to the FSF and get back a
> permission to release the code under whatever terms it likes, I don't
> think it would be in the best interest of the Free Software community,
> the GNU project or the FSF (although I don't speak for any of the 3), to
> advertise and encourage people to grant Google such permissions.

The goal is specifically to permit the Go frontend that I wrote to be used with
non-GPL compilers.  Certainly Google is not going to release the code under
arbitrary terms; the terms are right there in the LICENSE file, basically a BSD
license.  I hashed these issues out with the FSF and the steering committee,
and they agreed that this was an acceptable approach.  In particular, you will
note that the code is divided into parts covered by the GPL and parts covered
by the BSD license, and my intent is to move all the gcc-specific parts into the
parts covered by the GPL.

> Indeed, the contributor license agreement mentioned below AFAICT does
> transfer to Google the status of copyright holder of the contribution.
> The agreement is just an all-permissive license, so Google's copyright
> assignment with the FSF would be irrelevant WRT ensuring the FSF holds
> the copyright over the contributed code is concerned.

I think we are still OK here given that the Go frontend when used with gcc
is still clearly covered under the GPL.

> Can you please clarify, and make sure that people who already have a
> copyright assignment with the FSF in place need not go through this
> process, that the documentation gives preference to that course over
> granting Google a non-copyleft, all-permissive license?

I don't think I can do that and still maintain the goals I have for the
Go frontend, goals that were ratified by the gcc steering committee and
the FSF.

> Furthermore, could you please try to get Google to amend the web page so
> as to use terms such as copyright and patents, rather than a term that
> also brings concerns about trademarks, designs, hardware masks and trade
> secrets, none of which are covered in the licensing agreement?

I am not going to get into that fight myself.  Instead, I encourage you
to write to Google's Open Source Office.

> Could you also please try to get into the agreement some commitment back
> from Google to always release the contributed code as Free Software?
> Ideally, under the GPL?  It shouldn't be hard to get this commitment,
> since contributions to GCC Go would naturally be derived from the GPLed
> code whose copyright is held by the FSF.

I can get that commitment for the specific case of Go, but the contributor
license agreement is used for many other Google projects as well.

Ian
Ian Taylor - Dec. 3, 2010, 3:28 p.m.
Basile Starynkevitch <basile@starynkevitch.net> writes:

> For me Basile, getting the legal papers was so painful that I will
> never do that again. So if I need any bureaucratic work (i.e. to get
> another legal signature from my employer) to be able to propose some
> patch to gcc/go/ or libgo/ I prefer to avoid proposing such patches.

Believe me, compared to the FSF process, it will be much much much
easier for you to sign the Google copyright assignment if you choose to
do so.  You can do it using a web form.

> So definitely, a clarification is welcome. Can people (like me) already
> covered by a copyright assignment to FSF send patches for gcc/go or
> libgo/ or should they avoid that? 
>
> Or is Google's goal to avoid any patch [to the gcc/go or libgo/ part of
> FSF GCC trunk] which is not covered by an extra legal document with
> Google?

As I mention in my reply to Alex, my goal (Google as such doesn't really
care) is to make it possible to use the Go frontend with compilers other
than gcc.  Therefore, yes, an extra legal document is required.

> I hope that legal rules to submit patches don't vary from one
> subdirectory of the GCC trunk to another.

I agree that that would be better but I don't see how to achieve all
these goals.

Ian
Richard Stallman - Dec. 3, 2010, 6:06 p.m.
This is a legal and political issue, not a technical one.  It should
not be decided on a technical basis.  The FSF needs to discuss it with
lawyers to decide on its approach.

Would you like to email me a summary of the issue, including the
facts?  Please cc brett@gnu.org.
Ian Taylor - Dec. 3, 2010, 6:48 p.m.
Richard Stallman <rms@gnu.org> writes:

> This is a legal and political issue, not a technical one.  It should
> not be decided on a technical basis.  The FSF needs to discuss it with
> lawyers to decide on its approach.
>
> Would you like to email me a summary of the issue, including the
> facts?  Please cc brett@gnu.org.

This issue was discussed by the GCC steering committee (which I am not a
member of) from November 2009 to January 2010.  In January 2010 I was
told that the approach I am now using would be OK.

That approach is: the Go frontend proper lives in a separate repository.
The repository is mirrored into the gcc sources, much like the classpath
repository is today.  The Go frontend proper is under a BSD license.
The complete Go frontend to gcc incorporates the Go frontend proper,
plus gcc specific parts like the conversion to trees, language hooks,
etc.  The gcc specific parts are under the GPL as usual.

Ian
Alexandre Oliva - Dec. 3, 2010, 6:58 p.m.
On Dec  3, 2010, Ian Lance Taylor <iant@google.com> wrote:

> The goal is specifically to permit the Go frontend that I wrote to be
> used with non-GPL compilers.

Ok, a license to Google, such as the one you link to from docs,
accomplishes that.  But it doesn't AFAICT assign copyrights to the FSF,
so we should change the wording in the docs to avoid giving anyone the
impression that signing the *license* agreement with Google is enough
for the copyright to be *transferred* to the FSF, or to get code into
GCC.  Or is it?

> Certainly Google is not going to release the code under arbitrary
> terms; the terms are right there in the LICENSE file, basically a BSD
> license.

If we could get commitment from Google to never release the code as
non-Free Software (BSD license with commitment to offer corresponding
sources, not Tivoize, and not otherwise get in the way of the exercise
of the four freedoms for whoever comes across the code at hand) would
satisfy that, I think, but IANAL.

> I hashed these issues out with the FSF and the steering committee,
> and they agreed that this was an acceptable approach.

Thanks for confirming that.  Still, I'm concerned about the wording that
makes it seem like a license to Google plus Google's assignment on file
with the FSF would have a similar effect as that of contributor's
transferring copyrights to the FSF.  It wouldn't, so I'm concerned that
the wording in the docs don't implement correctly the agreement with FSF
and SC, or (unlikely) that the agreement was approved without sufficient
understanding of the difference.

> In particular, you will note that the code is divided into parts
> covered by the GPL and parts covered by the BSD license,

Thanks, I hadn't realized (or had forgotten about) this.

>> Indeed, the contributor license agreement mentioned below AFAICT does
>> transfer to Google the status of copyright holder of the contribution.
  ^ 

Oops, I meant “does NOT transfer” here.  Apologies for that.

> I can get that commitment for the specific case of Go, but the contributor
> license agreement is used for many other Google projects as well.

If you can get it just for what's released as part of GCC, that's
already a very good thing.  Of course getting a broader commitment from
Google to respect users' freedom would be desirable as well, but I can
imagine there might be... difficulties to get that ;-)

Thanks,
Ian Taylor - Dec. 3, 2010, 7:18 p.m.
Alexandre Oliva <aoliva@redhat.com> writes:

> On Dec  3, 2010, Ian Lance Taylor <iant@google.com> wrote:
>
>> The goal is specifically to permit the Go frontend that I wrote to be
>> used with non-GPL compilers.
>
> Ok, a license to Google, such as the one you link to from docs,
> accomplishes that.  But it doesn't AFAICT assign copyrights to the FSF,
> so we should change the wording in the docs to avoid giving anyone the
> impression that signing the *license* agreement with Google is enough
> for the copyright to be *transferred* to the FSF, or to get code into
> GCC.  Or is it?

I agree that I miswrote the README files.  I've tried to clarify them
now.  I hope.


>> Certainly Google is not going to release the code under arbitrary
>> terms; the terms are right there in the LICENSE file, basically a BSD
>> license.
>
> If we could get commitment from Google to never release the code as
> non-Free Software (BSD license with commitment to offer corresponding
> sources, not Tivoize, and not otherwise get in the way of the exercise
> of the four freedoms for whoever comes across the code at hand) would
> satisfy that, I think, but IANAL.

What kind of statement would satisfy you here?  The Go license already
exists.  It is a BSD license, plus an explicit patent statement.  You
can see it in the gcc repository now in the files
gcc/go/gofrontend/LICENSE and libgo/LICENSE (two copies of the same
text).  Can you write the text you would like to see?

We're already trying to adjust this slightly because the Fedora project
wanted the patent grant and the license proper to be in two different
files.  The FSF had already agreed that the current text was OK for the
contribution to gcc.  I am now asking them whether it is OK to split it
up into two files to keep the Fedora project happy.  I sent them the
question three weeks ago and have pinged twice.  No reply as yet.

If you write new text, can you volunteer to get the FSF to sign off on
it?  Given past history I think it very likely that it will be easier to
get Google to agree than it will be to get the FSF to agree.

Ian
Alexandre Oliva - Dec. 3, 2010, 8:25 p.m.
On Dec  3, 2010, Richard Stallman <rms@gnu.org> wrote:

> The FSF needs to discuss it with lawyers to decide on its approach.

AFAICT the apparent legal issue, that was my concern, was not there.

It was just sloppy wording in the documentation that explained the legal
issues that had already been sorted out.

The documentation made it look like Google required a copyright
assignment for the Go front-end and library that are part of GCC, and
implied this had something to do with Google's copyright assignment to
the FSF.  Both statements were wrong, in several levels.

Google requires a very permissive license for contributions to these
components, not a copyright assignment.  So there's no conflict of
copyright assignments, and the fact that Google has a copyright
assignment on file with the FSF is an unrelated issue.

Furthermore, these components are not considered part of GCC, even
though they're in the GCC repository, so it's not clear that Google's
copyright assignment would even apply to them, even if Google actually
required a copyright assignment itself.


The other issue, which was unclear to me, was whether a copyright
assignment to FSF would suffice to modify these components that, in my
understanding, were part of GCC.  AFAICT that won't be enough, so their
presence in the GCC repository, with rules that no changes should be
installed directly on them, but rather turned over to Google's primary
repository to then be merged to the GCC repository, sets a bad precedent
within GCC.

We have other components that we import from third parties, some of
which are even maintained in the GCC repository, but local changes to
them are only discouraged, not forbidden, and no requirement applies to
them of granting non-copyleft licenses to third parties that don't at
least commit to respecting users' freedoms in return.

I understand the GCC SC has already long discussed and decided on this
issue, but I find it unfortunate that, to my knowledge, it was all
discussed, decided and recorded behind closed doors (I don't even know
what the agreement was), and that I'm now being harrassed by no less
than a GCC SC member for raising my concerns at the first opportunity,
and for going straight to a good friend of mine, who happens to be the
president of the affected organization, rather than through an SC that
seems to be (legitimately or not) interested in avoiding getting the
head of that organization involved or even informed of what appeared to
be a very serious legal issue that could get the FSF in trouble: the
apparent requirement of copyright assignments over the same code to two
different entitites.
Alexandre Oliva - Dec. 3, 2010, 8:27 p.m.
On Dec  3, 2010, Ian Lance Taylor <iant@google.com> wrote:

> the Google copyright assignment

Please don't call it a copyright assignment.  It isn't one.  It's a
license agreement.  Using an inappropriate term to describe it was what
got this discussion started.
Robert Dewar - Dec. 4, 2010, 4:55 p.m.
On 12/3/2010 3:27 PM, Alexandre Oliva wrote:
> On Dec  3, 2010, Ian Lance Taylor<iant@google.com>  wrote:
>
>> the Google copyright assignment
>
> Please don't call it a copyright assignment.  It isn't one.  It's a
> license agreement.  Using an inappropriate term to describe it was what
> got this discussion started.

That's a VERY important point. I often find that a key element
that people need to understanding "assigning" the copyright to
FSF is that the agreement in no way limits what they you can
do in the future (make future versions proprietary, issue
other licenses for the same version etc).
Richard Stallman - Dec. 7, 2010, 12:40 p.m.
Thanks for explaining how Go is set up.
I have one comment about the terminology.

      The Go frontend proper is under a BSD license.

To speak of "a BSD license" tends to cause misunderstandings.  There
are two different BSD licenses, and the difference between them is
important, since one of them would prohibit what we are doing.

See http://www.gnu.org/philosophy/bsd.html.
Ian Taylor - Dec. 7, 2010, 3:11 p.m.
Richard Stallman <rms@gnu.org> writes:

> Thanks for explaining how Go is set up.
> I have one comment about the terminology.
>
>       The Go frontend proper is under a BSD license.
>
> To speak of "a BSD license" tends to cause misunderstandings.  There
> are two different BSD licenses, and the difference between them is
> important, since one of them would prohibit what we are doing.
>
> See http://www.gnu.org/philosophy/bsd.html.

Thanks.  The specific license is as appended.

Ian

Copyright (c) 2009 The Go Authors. All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

   * Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
   * Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
   * Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Andrew Pinski - Dec. 7, 2010, 5:29 p.m.
On Tue, Dec 7, 2010 at 7:11 AM, Ian Lance Taylor <iant@google.com> wrote:
>   * Neither the name of Google Inc. nor the names of its
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission.


This is the bad form which is not IIRC GPL compatible at all.

-- Pinski
Andrew Pinski - Dec. 7, 2010, 5:36 p.m.
On Tue, Dec 7, 2010 at 9:29 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Dec 7, 2010 at 7:11 AM, Ian Lance Taylor <iant@google.com> wrote:
>>   * Neither the name of Google Inc. nor the names of its
>> contributors may be used to endorse or promote products derived from
>> this software without specific prior written permission.
>
>
> This is the bad form which is not IIRC GPL compatible at all.

Ok, this is not the form which is not incompatible.  And this why the
reason why "BSD" should not be mentioned when talking about this form
of the license.

-- Pinski
Richard Stallman - Dec. 8, 2010, 1:42 p.m.
That's the modified BSD license.  It is compatible with the GNU GPL.

The original BSD license is still used on some programs as far as I
know, and it is incompatible with the GNU GPL.  This is why it is
vague and misleading to use the term "BSD license" without specifying
which one.

Patch

diff -r 7f5419c6775b go/README
--- a/go/README	Wed Dec 01 13:57:04 2010 -0800
+++ b/go/README	Thu Dec 02 15:20:22 2010 -0800
@@ -31,3 +31,27 @@ 
 rethinking.  The frontend pays little attention to its memory usage
 and rarely frees any memory.  The code could use a general cleanup
 which we have not had time to do.
+
+Contributing
+=============
+
+To contribute patches to the files in this directory, please see
+http://golang.org/doc/gccgo_contribute.html .
+
+Changes to these files require a copyright assignment to Google.  This
+is required to permit the changes to be copied to the gcc repository,
+as Google has a copyright assignment with the Free Software
+Foundation.
+
+If you are the copyright holder, you will need to agree to the
+individual contributor license agreement at
+http://code.google.com/legal/individual-cla-v1.0.html.  This agreement
+can be completed online.
+
+If your organization is the copyright holder, the organization will
+need to agree to the corporate contributor license agreement at
+http://code.google.com/legal/corporate-cla-v1.0.html.
+
+If the copyright holder for your code has already completed the
+agreement in connection with another Google open source project, it
+does not need to be completed again.
diff -r 7f5419c6775b libgo/README
--- a/libgo/README	Wed Dec 01 13:57:04 2010 -0800
+++ b/libgo/README	Thu Dec 02 15:20:22 2010 -0800
@@ -21,3 +21,27 @@ 
 
 syscalls
   System call support.
+
+Contributing
+============
+
+To contribute patches to the files in this directory, please see
+http://golang.org/doc/gccgo_contribute.html .
+
+Changes to these files require a copyright assignment to Google.  This
+is required to permit the changes to be copied to the gcc repository,
+as Google has a copyright assignment with the Free Software
+Foundation.
+
+If you are the copyright holder, you will need to agree to the
+individual contributor license agreement at
+http://code.google.com/legal/individual-cla-v1.0.html.  This agreement
+can be completed online.
+
+If your organization is the copyright holder, the organization will
+need to agree to the corporate contributor license agreement at
+http://code.google.com/legal/corporate-cla-v1.0.html.
+
+If the copyright holder for your code has already completed the
+agreement in connection with another Google open source project, it
+does not need to be completed again.