Bug 44032 - internals documentation is not legally safe to use
Summary: internals documentation is not legally safe to use
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.6.0
: P3 blocker
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: documentation, internal-improvement
Depends on:
Blocks:
 
Reported: 2010-05-07 22:06 UTC by Jorn Wolfgang Rennecke
Modified: 2021-08-24 19:51 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-05-07 22:31:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2010-05-07 22:06:07 UTC
Because the internals documentation is distributed under the GFDL, it is not
safe to cut&paste examples or instructions from the documentation when writing
new code in GCC, since that code needs to be released under the GPL.
Documentation that pertains to the modification of a program must come with
a compatible license in order to be usable in a safe manner.
Comment 1 Steven Bosscher 2010-05-07 22:31:01 UTC
Ah, the old argument. But true. GCC internals documentation is almost constantly out of sync with reality because of this. It's been like this for years now and it is an underestimated problem.

Anyway, confirmed. 
Comment 2 Joseph S. Myers 2011-02-22 16:33:34 UTC
Joern, since the GFDL says:

    If your document contains nontrivial examples of program code, we
    recommend releasing these examples in parallel under your choice of
    free software license, such as the GNU General Public License,
    to permit their use in free software.

it ought not be controversial to add a statement that examples of code in the internals manual are also released under the GPL.  I'd advise preparing a patch adding a statement to the effect that

You can redistribute and/or modify examples of program code in this manual under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.

and sending the patch to RMS for legal review as well as gcc-patches for technical review.
Comment 3 Eric Gallager 2018-03-15 18:11:31 UTC
Is this fixed in the same way that bug 44035 was fixed?
Comment 4 Jorn Wolfgang Rennecke 2018-03-17 22:07:43 UTC
(In reply to Eric Gallager from comment #3)
> Is this fixed in the same way that bug 44035 was fixed?

No. 44035 was about the inability to fix, 44032 is about the
actual licensing state of the documentation.  A brief look at
gccint.texi shows that this file remains purely GFDL.
I suppose there are numerous other files likewise affected.

It can only be considered fixed if all the parts of existing
documentation that you might conceivably want to cut & paste into
GPLed code are suitably re-licensed, and we have put something in
place that the issue will generally not appear with new GCC
documentation.

If all documentation files that come with GCC were patched as
suggested in comment #2, that could be considered a solution,
as people who cut & paste the copyright blurb for new files
would pick up the new text.  Well, there might be a transition
period when backed-up patches and patches made with using older
baselines need to be vetted for necessary adjustments.

If only some documentation files are patches to have the
amended copyright blurb, as others have no applicable code
samples, the others should have a warning not to copy them to
new files that will have such samples.
Comment 5 Eric Gallager 2019-03-17 06:26:53 UTC
(In reply to Jorn Wolfgang Rennecke from comment #4)
> (In reply to Eric Gallager from comment #3)
> > Is this fixed in the same way that bug 44035 was fixed?
> 
> No. 44035 was about the inability to fix, 44032 is about the
> actual licensing state of the documentation.  A brief look at
> gccint.texi shows that this file remains purely GFDL.
> I suppose there are numerous other files likewise affected.
> 
> It can only be considered fixed if all the parts of existing
> documentation that you might conceivably want to cut & paste into
> GPLed code are suitably re-licensed, and we have put something in
> place that the issue will generally not appear with new GCC
> documentation.
> 
> If all documentation files that come with GCC were patched as
> suggested in comment #2, that could be considered a solution,

Joseph that was your comment... do you want to try it?

> as people who cut & paste the copyright blurb for new files
> would pick up the new text.  Well, there might be a transition
> period when backed-up patches and patches made with using older
> baselines need to be vetted for necessary adjustments.
> 
> If only some documentation files are patches to have the
> amended copyright blurb, as others have no applicable code
> samples, the others should have a warning not to copy them to
> new files that will have such samples.
Comment 6 jsm-csl@polyomino.org.uk 2019-03-18 22:07:40 UTC
I don't have anything further to add on this issue.  If you want a 
docstring relicensing review you should say so when submitting a patch; 
for other cases of relicensing not covered by that, ask RMS.
Comment 7 Eric Gallager 2019-07-05 21:15:46 UTC
Richard says the FSF doesn't object to combinations of GFDL code from the manual with GPL code from the source and that we can put a statement to this effect in the internals manual.
Comment 8 Eric Gallager 2019-10-05 04:20:44 UTC
(In reply to Eric Gallager from comment #7)
> Richard says the FSF doesn't object to combinations of GFDL code from the
> manual with GPL code from the source and that we can put a statement to this
> effect in the internals manual.

So, now that RMS is out at the FSF... does what he have to say on this issue even matter any longer, or do we have to ask someone else at the FSF now?
Comment 9 Eric Gallager 2021-04-21 06:09:48 UTC
(In reply to Eric Gallager from comment #8)
> (In reply to Eric Gallager from comment #7)
> > Richard says the FSF doesn't object to combinations of GFDL code from the
> > manual with GPL code from the source and that we can put a statement to this
> > effect in the internals manual.
> 
> So, now that RMS is out at the FSF... does what he have to say on this issue
> even matter any longer, or do we have to ask someone else at the FSF now?

Er, let me amend this: he's back in at the FSF, but out of the GCC Steering Committee... so I guess the question still remains, though: is his opinion the one that matters, or do we have to ask someone else?
Comment 10 Eric Gallager 2021-06-01 22:59:15 UTC
Does the update on copyright assignment policy affect this at all?
https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
My reading of this email seems to imply that it does:
https://gcc.gnu.org/pipermail/gcc/2021-June/236214.html
Comment 11 Jonathan Wakely 2021-06-02 10:36:41 UTC
I don't think the policy change affects this at all. There is no change to the licenses of any GCC code or docs.