| Message ID | mcr1v5z7oa1.fsf@google.com |
|---|---|
| State | New |
| Headers | show |
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
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.
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
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
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.
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
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,
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
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.
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.
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).
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.
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.
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
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
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.
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.