| Message ID | 20110103234036.aa76df35.basile@starynkevitch.net |
|---|---|
| State | New |
| Headers | show |
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} *** >
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.
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?? :-)
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
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.
I should add: the relevant GNU policy is: http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
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.
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;