Patchwork gengtype: emit a more appropriate copyright year in generated files.

login
register
mail settings
Submitter Basile Starynkevitch
Date Jan. 3, 2011, 10:40 p.m.
Message ID <20110103234036.aa76df35.basile@starynkevitch.net>
Download mbox | patch
Permalink /patch/77350/
State New
Headers show

Comments

Basile Starynkevitch - Jan. 3, 2011, 10:40 p.m.
Hello All,

The below patch against trunk rev. 168441 emit the current year in the
copyright notice of gengtype generated files.

############################ patch

###### gcc/ChangeLog entry

2011-01-03  Basile Starynkevitch  <basile@starynkevitch.net>
	* gengtype.c (create_file): Emit current year in copyright notice.

######

See discussion inside http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00085.html

This patch just generate a more intuitive copyright year. It does not handle 
more serious legal issues, like is the FSF the copyright owner of every gengtype 
generated file (probably not for all plugins using gengtype), and is the generated
gt*.[ch] files always GPLv3+ (a plugin author could choose another licence).

Comments are welcome.

Cheers.
Laurynas Biveinis - Jan. 5, 2011, 3:30 p.m.
I have no idea whatsoever about the legal issues there but it
previously emitted 2004, 2007, 2009 and now it would be only 2011. I
think there is a reason why the other source files enumerate many
years from the last two decades and not just give the latest one.

IIRC even a patch to shorten "1994, 1995, 1996, 1997" to "1994--1997"
etc. was rejected for some reason.

Given that, I'd leave things as-is and update copyright years
manually. (A comment at the top of gengtype.c stating "If you update
copyright year list here, consider updating it in hdr too" would be
nice though)

I also have no clue about the other legal issues you raise (license
and ownership of generated files).

--
Laurynas

2011/1/4 Basile Starynkevitch <basile@starynkevitch.net>:
>
> Hello All,
>
> The below patch against trunk rev. 168441 emit the current year in the
> copyright notice of gengtype generated files.
>
> ############################ patch
> Index: gcc/gengtype.c
> ===================================================================
> --- gcc/gengtype.c      (revision 168441)
> +++ gcc/gengtype.c      (working copy)
> @@ -1443,7 +1443,7 @@ static outf_p
>  create_file (const char *name, const char *oname)
>  {
>   static const char *const hdr[] = {
> -    "   Copyright (C) 2004, 2007, 2009 Free Software Foundation, Inc.\n",
> +    /* The copyright notice and year is emitted separately. */
>     "\n",
>     "This file is part of GCC.\n",
>     "\n",
> @@ -1465,15 +1465,24 @@ create_file (const char *name, const char *oname)
>   };
>   outf_p f;
>   size_t i;
> -
> +  int year = 2010; /* Default the current year to something sensible. */
> +  time_t now = 0;
>   gcc_assert (name != NULL);
>   gcc_assert (oname != NULL);
>   f = XCNEW (struct outf);
>   f->next = output_files;
>   f->name = oname;
>   output_files = f;
> -
> +  time (&now);
> +  if (now>0)
> +    {
> +      struct tm* nowtm = localtime(&now);
> +      if (nowtm)
> +        year = 1900 + nowtm->tm_year;
> +    }
>   oprintf (f, "/* Type information for %s.\n", name);
> +  oprintf (f, "   Copyright (C) %d  Free Software Foundation, Inc.\n",
> +          year);
>   for (i = 0; i < ARRAY_SIZE (hdr); i++)
>     oprintf (f, "%s", hdr[i]);
>   return f;
>
> ###### gcc/ChangeLog entry
>
> 2011-01-03  Basile Starynkevitch  <basile@starynkevitch.net>
>        * gengtype.c (create_file): Emit current year in copyright notice.
>
> ######
>
> See discussion inside http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00085.html
>
> This patch just generate a more intuitive copyright year. It does not handle
> more serious legal issues, like is the FSF the copyright owner of every gengtype
> generated file (probably not for all plugins using gengtype), and is the generated
> gt*.[ch] files always GPLv3+ (a plugin author could choose another licence).
>
> Comments are welcome.
>
> 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 mine, sont seulement les miennes} ***
>
Joseph S. Myers - Jan. 5, 2011, 3:54 p.m.
On Wed, 5 Jan 2011, Laurynas Biveinis wrote:

> IIRC even a patch to shorten "1994, 1995, 1996, 1997" to "1994--1997"
> etc. was rejected for some reason.

GNU policy was only recently amended to allow ranges, and only if there is 
a special statement in the package's README saying what they mean.  If we 
wish to use them then we should change all of GCC at once (and maybe 
change to update all files at the start of the year - also permitted by 
GNU policy - so updates don't need remembering at any other time).

Regarding generated files, GNU policy says "When a file is automatically 
generated from some other file in the distribution, it is useful for the 
automatic procedure to copy the copyright notice and permission notice of 
the file it is generated from, if possible. Alternatively, put a notice at 
the beginning saying which file it is generated from.".  But I don't think 
this applies to files only used in the build process, such as those 
generated by gengtype; only to those that are actually included in the 
source distribution or installed.
Robert Dewar - Jan. 5, 2011, 4 p.m.
On 1/5/2011 10:54 AM, Joseph S. Myers wrote:
> On Wed, 5 Jan 2011, Laurynas Biveinis wrote:
>
>> IIRC even a patch to shorten "1994, 1995, 1996, 1997" to "1994--1997"
>> etc. was rejected for some reason.
>
> GNU policy was only recently amended to allow ranges, and only if there is
> a special statement in the package's README saying what they mean.  If we
> wish to use them then we should change all of GCC at once (and maybe
> change to update all files at the start of the year - also permitted by
> GNU policy - so updates don't need remembering at any other time).

I really think ranges are far better. I have never understood the GNU
policy here. Since all major corporations such as Apple, Microsoft,
IBM and many others routinely use ranges, are we really supposed to
think that GNU knows better than all these other companies?? :-)
Nathan Froyd - Jan. 5, 2011, 4:08 p.m.
On Wed, Jan 05, 2011 at 03:54:07PM +0000, Joseph S. Myers wrote:
> On Wed, 5 Jan 2011, Laurynas Biveinis wrote:
> > IIRC even a patch to shorten "1994, 1995, 1996, 1997" to "1994--1997"
> > etc. was rejected for some reason.
> 
> GNU policy was only recently amended to allow ranges, and only if there is 
> a special statement in the package's README saying what they mean.  If we 
> wish to use them then we should change all of GCC at once (and maybe 
> change to update all files at the start of the year - also permitted by 
> GNU policy - so updates don't need remembering at any other time).

Yes, please, let's do this.  Can we legitimately convert "1994, 1996,
1998" etc. to "1994--1998"?  The policy suggests not, but I don't see
what the issue is in doing so.  Restricting it in that way makes doing
the conversion somewhat more tedious.

-Nathan
Joseph S. Myers - Jan. 5, 2011, 4:22 p.m.
On Wed, 5 Jan 2011, Nathan Froyd wrote:

> On Wed, Jan 05, 2011 at 03:54:07PM +0000, Joseph S. Myers wrote:
> > On Wed, 5 Jan 2011, Laurynas Biveinis wrote:
> > > IIRC even a patch to shorten "1994, 1995, 1996, 1997" to "1994--1997"
> > > etc. was rejected for some reason.
> > 
> > GNU policy was only recently amended to allow ranges, and only if there is 
> > a special statement in the package's README saying what they mean.  If we 
> > wish to use them then we should change all of GCC at once (and maybe 
> > change to update all files at the start of the year - also permitted by 
> > GNU policy - so updates don't need remembering at any other time).
> 
> Yes, please, let's do this.  Can we legitimately convert "1994, 1996,
> 1998" etc. to "1994--1998"?  The policy suggests not, but I don't see
> what the issue is in doing so.  Restricting it in that way makes doing
> the conversion somewhat more tedious.

If there were released versions (including released in version control - 
and I *think* this includes version control that only became public later, 
so changes in the old gcc2 repository that got integrated in the SVN 
conversion should count) of GCC with copyrightable changes somewhere in 
GCC in the intermediate years (1995, 1997 in that case), then as I read 
the policy regarding updating all files at the start of the year it would 
be OK to use 1994-1998 then, since for a year to be mentioned it only 
needs changes somewhere in GCC, not in that particular file.  So you can 
probably use <year>-2011 everywhere (for files originating in GCC, not for 
text coming from autoconf etc. or soft-fp or other imported code) for 
start years that are 1987 or later.  --version output only needs to 
mention the current year; copyright notices in manuals (there's sometimes 
more than one in a file because of manpages etc.) should give the range.
Joseph S. Myers - Jan. 5, 2011, 4:40 p.m.
I should add: the relevant GNU policy is:

http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
Basile Starynkevitch - Jan. 5, 2011, 5:57 p.m.
On Wed, 5 Jan 2011 15:54:07 +0000 (UTC)
"Joseph S. Myers" <joseph@codesourcery.com> wrote:
> 
> Regarding generated files, GNU policy says "When a file is automatically 
> generated from some other file in the distribution, it is useful for the 
> automatic procedure to copy the copyright notice and permission notice of 
> the file it is generated from, if possible. Alternatively, put a notice at 
> the beginning saying which file it is generated from.".  But I don't think 
> this applies to files only used in the build process, such as those 
> generated by gengtype; only to those that are actually included in the 
> source distribution or installed.

But now (and actually even in 4.5, although it was a nightmare)
gengtype also generates files for plugins. So if some entity or person
writes a GCC plugin with plugin.h plugin1.c plugin2.c source files (and
assuming that plugin has its own GTY-ed types), it makes sense to
generate a gt-plugin.h using gengtype.

Regarding copyright notices in generated source files, I see two
different cases: first, the common case when a generated file
corresponds to a single source file (the source file is the file
manually edited & written by a human programmer). This is the case of
bison, flex (and GCC MELT). In that case, the easiest thing to do is to
copy the copyright notice from the source to the generated code file.
In MELT, the (comment ...) syntax is exactly for that purpose!

But gengtype may generate a single gt*.h file from several source
files. And actually, the gengtype generated file gtype-desc.c contains
code generated from many GCC source files. Ok, that particular file is
relevant only at build time. However, in the plugin case, the generated
gt-plugin.h borrow information from all of plugin.h plugin1.c
plugin2.c

However, I still believe that the hard-wired copyright date (C) 2004,
2007, 2009 in the gengtype generated code is currently wrong, and that
putting the date of generation seems more logicial. 

As a concrete case, I don't understand why the gengtype generated files
of the MELT branch bears a copyright notice of (C) 2004, 2007, 2009.
These years are certainly wrong: in 2004, MELT did not exist, not even
in my head.

Maybe gengtype should be enhanced to understand more that just GTY
annotations. Eg a GTYCOPYRIGHTDATE(2007) or GTYCOPYRIGHTDATEINTERVAL
(2007,2010). But that won't happen quickly (and I am not sure it is
worth the effort).

Cheers.

Patch

Index: gcc/gengtype.c
===================================================================
--- gcc/gengtype.c	(revision 168441)
+++ gcc/gengtype.c	(working copy)
@@ -1443,7 +1443,7 @@  static outf_p
 create_file (const char *name, const char *oname)
 {
   static const char *const hdr[] = {
-    "   Copyright (C) 2004, 2007, 2009 Free Software Foundation, Inc.\n",
+    /* The copyright notice and year is emitted separately. */
     "\n",
     "This file is part of GCC.\n",
     "\n",
@@ -1465,15 +1465,24 @@  create_file (const char *name, const char *oname)
   };
   outf_p f;
   size_t i;
-
+  int year = 2010; /* Default the current year to something sensible. */
+  time_t now = 0;
   gcc_assert (name != NULL);
   gcc_assert (oname != NULL);
   f = XCNEW (struct outf);
   f->next = output_files;
   f->name = oname;
   output_files = f;
-
+  time (&now);
+  if (now>0) 
+    {
+      struct tm* nowtm = localtime(&now);
+      if (nowtm)
+	 year = 1900 + nowtm->tm_year;
+    }
   oprintf (f, "/* Type information for %s.\n", name);
+  oprintf (f, "   Copyright (C) %d  Free Software Foundation, Inc.\n",
+	   year);
   for (i = 0; i < ARRAY_SIZE (hdr); i++)
     oprintf (f, "%s", hdr[i]);
   return f;