As I mentioned last week, I've been talking to the SC and RMS about the issue of automatically generating GFDL'd documentation from GPL'd code.
I will state explicitly up front a few topics I am not raising, because I do not think they are either necessary, or likely to be productive: * Whether or not the GFDL is a "free" license, or whether it's a good license, or anything else about its merits or lack thereof * Whether we can take things out of the current GFDL manuals and put them into GPL'd code The first is immaterial from the limited perspective of trying to figure out how to make it possible for us to make better (in terms of content) manuals more easily. The second issue *is* relevant, in that we might want to bring some of what's currently in manuals into the code, but I think it's less important than the question of whether we can auto-generate manuals from code on a going-forwards basis. And, it's simpler to work on one thing at a time. At this point, RMS has said, answered this question from me: "Can we take comments (not code) from FSF-owned GPL'd code and process them in some way that results in them being included in a GFDL'd manual?" by saying, in part: "If Texinfo text is included the .h files specifically to be copied into a manual, it is ok to for you copy that text into a manual and release the manual under the GFDL." In context, "you" means "the GCC maintainers" and the permission would be limited only to changes contributed to the FSF. This is specifically not permission for random people to do even this outside the context of the FSF repository. RMS acknowledges that this is a problem, but he says (and I agree) that we would need a GPL license exception to make this a fully general permission, and he says that will take a long time. This limited permission might be enough to solve some problems. For example, we could write TeXinfo in special comments for hooks, and have some script that pulled out the comments and generated a TeXinfo document listing all the hooks. But, it doesn't help with things more like Javadoc or Doxygen or Synopsis. (Disclosure: Stefan Seefeld, one of my fellow Sourcerers is the lead author of Synopsis.) These tools can parse the code, creating cross-references of various kinds, while also extracting documentation intended for users of the API. So, my question is this: is the permission above sufficient for what people want to do at this point? Or do we need more? And if we need more (as I suspect), can we be specific about what toolflow we want to follow and what content will be generated? It would help if I could show RMS inputs and outputs, not just with some random example, but with GCC itself. Is someone willing to apply enough effort to produce at least some fragments of documentation using some method, and document that method for me, so that I can provide it to RMS. (An obvious strategy generate these manuals under the GPL, rather than the GFDL, thereby dodging the issue. But, RMS does not want GCC having GPL'd manuals. Maybe if we show him what we want to do, he will conclude that GPL'd manuals are an acceptable outcome, and easier than trying to do license exceptions.) Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
