This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Announcing new docstring relicensing maintainers


I'd like to explain the rules that apply to this relicensing:

* If any text is to be licensed under both the GPL and the GFDL, there 
must be copies under both licenses checked in.  There may be a tool that 
helps propagate changes from one copy to the other.  This is the scheme we 
already have with target.def and tm.texi, where genhooks will update 
tm.texi following a change to target.def (or tm.texi.in) and may be used 
for other cases as well.

* The text being relicensed (from GPL to GFDL or vice versa - generally so 
that the same text can be used in two places, under the two licenses) must 
be a doc string - that is, text describing a particular interface, whether 
internal (such as a target hook) or external (such as a machine-specific 
asm constraint), that it has been decided makes technical sense to keep 
with the (GPL) definition of that interface (such as a target hook 
definition in target.def, or a target's constraints.md file)) but also to 
include in the (GFDL) manuals (such as tm.texi and md.texi).

* The relicensing must be approved in each case, in addition to the usual 
technical approval of the patch.  The new relicensing maintainers may 
approve such relicensing, as may the Steering Committee.

Thus, it is now possible for patches converting target macros to target 
hooks to include the documentation, based on the old GFDL documentation 
for the target macro, in target.def, provided one of the relicensing 
maintainers approves that part of the patch.  I hope to move existing hook 
documentation from tm.texi.in to target.def (it should be possible to 
automate that move); I think there are some cases where it was also wanted 
to move text from comments into the doc strings in target.def (and so to 
tm.texi) though that is probably harder to automate.  If we can get to the 
point where every target hook has a doc string, it will then be possible 
to give errors in genhooks when they are absent (and so avoid future hooks 
being added without documentation).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]