public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Notes from the GROW'10 workshop panel (GCC research 	opportunities      workshop)
Date: Thu, 15 Apr 2010 08:26:00 -0000	[thread overview]
Message-ID: <4BC634F1.6030906@starynkevitch.net> (raw)
In-Reply-To: <mcrvdbtrcda.fsf@dhcp-172-17-9-151.mtv.corp.google.com>

Ian Lance Taylor wrote:
> Basile Starynkevitch <basile@starynkevitch.net> writes:
> 
>> My point is that academics can quite easily contribute to GPL
>> software, but much harder obtain the necessary legal authorizations to
>> transfer copyright to FSF. My intuition is that if (in a different
>> past & a different world which did not happen) GCC was only GPLv2+
>> without the FSF copyright requirement -exactly as Linux kernel is,
>> things would have been much different.
> 
> That is likely true, but it's something that we really don't want to
> change.  The FSF could and should make the copyright disclaimer much
> simpler--for example, you can do Google's copyright disclaimer on a
> web page (http://code.google.com/legal/individual-cla-v1.0.html).  But
> avoiding the copyright disclaimer entirely is what permitted, e.g.,
> the SCO debacle to occur.


 From what I understood of the runtime exception of GCC, plugins should 
be GPLv3 licensed but are not requested to be FSF copyrighted. Of course 
such plugin code is not inside GCC FSF (I am expecting it would be 
hosted elsewhere, e.g. on some university site; of course FSF owned 
plugins -like MELT- are different).

 From the point of view of an academic, that makes a significant 
difference. And even if he/she want to push code inside GCC (and for 
that he still will need the transfer to FSF, unless GCC changes a lot), 
convincing his big boss to sign a paper is less terrible when you 
actually have some code (in a plugin form) that really has some outside 
interest. In that (optimistic) situation, the academic could spend some 
of his time to get the legal papers signed.

Before the plugins, the academics could fork GCC (a huge non academic 
task) and work on his fork (practically unlikely) or should take the 
effort to get the legal papers signed before coding the first line of 
code (very hard, and very discouraging).

A university (or research institute) boss in big suit [able to sign 
legal papers] is probably more keen to sign a legal paper with the FSF 
once some code -from his university- exist which attracts outside 
interest, and not before.

And my personal preference on GCC licensing would be more a Linux-kernel 
like GPL with copyright belonging to authors employee (I don't feel a 
SCO like issue as a major threat today; it might have been ten years 
ago). That is much easier to get than a copyright transfer to FSF.

And GCC is probably less threatened today by legal issues à la SCO than 
by obesity, obsolescence, outside competition -eg LLVM- and perhaps even 
less interest by industry for the low level languages (C, C++, Ada) GCC 
is processing. Even in industry, scripting languages (or languages like 
Java or C# which are not practically significant for GCC) have more 
market share than a dozen years ago.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

  parent reply	other threads:[~2010-04-14 21:34 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11 14:01 Dorit Nuzman
2010-04-11 18:27 ` Chris Lattner
2010-04-11 19:38   ` Grigori Fursin
2010-04-11 20:25     ` Chris Lattner
2010-04-11 20:58       ` Grigori Fursin
2010-04-14 14:34 ` Grigori Fursin
2010-04-14 14:58   ` Steven Bosscher
2010-04-14 15:21     ` Manuel López-Ibáñez
2010-04-14 15:30       ` Steven Bosscher
2010-04-14 15:36       ` Diego Novillo
2010-04-14 15:50         ` Nathan Froyd
2010-04-14 15:57           ` Richard Guenther
2010-04-14 19:19             ` Tom Tromey
2010-04-14 16:06           ` Diego Novillo
2010-04-14 18:30             ` Richard Guenther
2010-04-14 18:49           ` Toon Moene
2010-04-14 19:52             ` Basile Starynkevitch
2010-04-14 20:31               ` Toon Moene
2010-04-14 20:43               ` Toon Moene
2010-04-14 21:02               ` Ian Lance Taylor
2010-04-14 21:34                 ` Manuel López-Ibáñez
2010-04-15  8:26                 ` Basile Starynkevitch [this message]
2010-04-15  8:38                   ` Manuel López-Ibáñez
2010-04-15 12:03                     ` Basile Starynkevitch
2010-04-15 12:07                       ` Andrew Haley
2010-04-15 12:15                         ` Steven Bosscher
2010-04-15 12:17                           ` Andrew Haley
2010-04-22  9:18                       ` Laurent GUERBY
2010-04-14 21:04               ` Nathan Froyd
2010-04-14 19:42           ` Ian Lance Taylor
2010-04-14 15:44       ` Duncan Sands
2010-04-15  9:05   ` Manuel López-Ibáñez
2010-04-16 12:36     ` Grigori Fursin
2010-04-16 17:15       ` Manuel López-Ibáñez
2010-04-16 17:40         ` Grigori Fursin
2010-04-27 12:40         ` Grigori Fursin
2010-04-27 16:31           ` Manuel López-Ibáñez
2010-04-27 18:42             ` Grigori Fursin

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=4BC634F1.6030906@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).