Re: ChangeLog licensing issues
Joseph S. Myers wrote: >> But if identifieres were OK, wouldn't that mean that auto-generating >> documentation that shows hook names along with argument types and names >> are also OK? > > I do not see any copyright issues with the hook names and argument types > and names. With the bodies of the descriptions of the semantics of the > hooks (in .texi or comments), yes, but not with the names and types of > hooks and their arguments. I agree. Joern, I don't think anything in the ChangeLogs that you are writing is going to be a problem. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
targethook argument names (Was: Re: ChangeLog licensing issues)
Quoting "Joseph S. Myers" : I do not see any copyright issues with the hook names and argument types and names. With the bodies of the descriptions of the semantics of the hooks (in .texi or comments), yes, but not with the names and types of hooks and their arguments. If that is actually the case, then there is a bit more code that I could consolidate between the struct targetm definition and its documentation. For some hooks, however, we'd have to decide on a single name for some arguments first: declare_constant_name expression: exp or expr? print_operand, print_operand_address FILE *: file or stream? print_operand_address address: addr or x? dfa_new_cycle dump file: dump_file or dump? last_sched_cycle or last_clock? cur_cycle or clock? resolve_overloaded_builtin parameter list: params or arglist? fold_builtin nargs or n_args? builtin_reciprocal tm_fn or md_fn? memory_move_cost register class: rclass or class
Re: ChangeLog licensing issues
On 20 June 2010 16:37, Joern Rennecke wrote: > > I spent a lot of time before getting the target hook code, comments and > documentation consistent, only to be told that the GCC maintainers have > no authority to move information from code or comments into documentation > or vice versa. For what is worth, as a GCC contributor, I really appreciate what you are trying to do and it is really sad that contributors have to fight to contribute to a project, specially in areas where the project is generally acknowledged as deficient and way behind alternative ones. Cheers, Manuel.
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > Quoting "Joseph S. Myers" : > > > I suggest you recalibrate your understanding of the scope of copyright to > > be less expansive rather than supposing it to apply to "file names, > > function names and identifiers". > > But if identifieres were OK, wouldn't that mean that auto-generating > documentation that shows hook names along with argument types and names > are also OK? I do not see any copyright issues with the hook names and argument types and names. With the bodies of the descriptions of the semantics of the hooks (in .texi or comments), yes, but not with the names and types of hooks and their arguments. -- Joseph S. Myers jos...@codesourcery.com
Re: ChangeLog licensing issues
Quoting "Joseph S. Myers" : I suggest you recalibrate your understanding of the scope of copyright to be less expansive rather than supposing it to apply to "file names, function names and identifiers". But if identifieres were OK, wouldn't that mean that auto-generating documentation that shows hook names along with argument types and names are also OK? I don't see any fundamental difference between writing stuff like 'change type of argument foo of func to bar and rename to baz' to put it into a ChangeLog, and running a program to adjust a piece of documentation to reflect such a change. Arguing for its application to such elements may be accepted in certain industries based around the use of copyright, patent and trademark laws, DRM and closed software and devices against the public interest; it is not appropriate for work as part of the Free Software Movement. It's not that I want copyright be applied so broadly, but I'm trying to avoid a situation where my patch becomes unusable because of such issues. I spent a lot of time before getting the target hook code, comments and documentation consistent, only to be told that the GCC maintainers have no authority to move information from code or comments into documentation or vice versa. If the FSF wants its maintainers to have certain freedoms when handling the source code they handle on behalf of the FSF, it is best if this is spelled out in licences and/or policies, since national copyright regimes vary, contain legal uncertainties, and are subject to change.
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > So it appears that writing ChangeLog entries for code from a branch where > I have no (longer) a connection with the original submitter requires > getting permission from the FSF to use the file names, function names > and identifiers mentioned, at least to the extent that they haven't been > mentioned in a ChangeLog before. I suggest you recalibrate your understanding of the scope of copyright to be less expansive rather than supposing it to apply to "file names, function names and identifiers". Arguing for its application to such elements may be accepted in certain industries based around the use of copyright, patent and trademark laws, DRM and closed software and devices against the public interest; it is not appropriate for work as part of the Free Software Movement. -- Joseph S. Myers jos...@codesourcery.com
Re: ChangeLog licensing issues
Quoting "Joseph S. Myers" : On Sun, 20 Jun 2010, Joern Rennecke wrote: What license / licenses are the ChangeLogs of GCC distributed under? ChangeLogs are licensed under the permissive terms given in the license notices at the bottom of each ChangeLog file, Oops, I missed that bit. So it appears that writing ChangeLog entries for code from a branch where I have no (longer) a connection with the original submitter requires getting permission from the FSF to use the file names, function names and identifiers mentioned, at least to the extent that they haven't been mentioned in a ChangeLog before. Lest someone things ChangeLog entries are trivial, I'm currently working on a patch of over 600 KB, and after going through 6% of that, I've gathered some 6KB of ChangeLog entry so far. Although the branch has ChangeLogs, they are not covering all new file & function names (with deadlines and company 'restructuring', this is sometimes unavoidable), and what there is also has some back-and-forth changes, and things that got moved into different functions and files during merges. So what should I do in this situation? Spend some days to write a new, proper ChangeLog entry to then wait some month for the FSF to authorize - or not - its use in a ChangeLog? Spend even more effort to censor anything from the ChangeLog entry that was not previously mentioned in a ChangeLog entry? Or should I just slap a laconic 'merge from XXX branch' on an indented version top of the old branch-specific ChangeLog entries?
Re: ChangeLog licensing issues
On Sun, 20 Jun 2010, Joern Rennecke wrote: > What license / licenses are the ChangeLogs of GCC distributed under? ChangeLogs are licensed under the permissive terms given in the license notices at the bottom of each ChangeLog file, which were the terms the FSF recommended for "rough documentation" at the time I added the notices to the files. (Since then, an additional sentence "This file is offered as-is, without any warranty." has been added to the recommended notice, though the instructions say "There is no urgent need to update existing files".) -- Joseph S. Myers jos...@codesourcery.com
ChangeLog licensing issues
What license / licenses are the ChangeLogs of GCC distributed under? This is of practical importance when I want to amend incomplete ChangeLogs or use information from a ChangeLog to complete comments and/or documentation, or want to write a ChangeLog for fixing a misspelling in code or documentation that is not replicated in the ChangeLog entry for the original contribution. Can I use function names from GPLed code to put them in a ChangeLog? Can I use names of sections or concepts, or misspellings in GFDLed documentation (like {trunk,branch}/gcc/doc/*.texi, which shares its ChangeLog with GPLed code in {trunk,branch}/gcc), to put them in a ChangeLog? Can I use narrative text from a ChangeLog to put it into a comment in GPLed code or in GFDLed documentation? Note, I do not reside in the USA, so AFAIC I can't use the USA's 'fair use' provisions directly. (If someone else uses them to effectively relicense affected matter, I suppose I can work with the resulting work).