On Sat, 2010-05-29 at 16:48 -0500, Gabriel Dos Reis wrote: > On Sat, May 29, 2010 at 2:18 PM, Basile Starynkevitch > <bas...@starynkevitch.net> wrote: > > > I don't seek legal advice. I am only seeking *practical* advice. > > yet, you are largely talking about legal issues in substance.
More licensing issues than legal ones. "Legal" issues are those putting people (or entities) at risk (jail, or losing millions of euros/dollars or whatever currency you like). We are certainly not in that case. We are more in the case like when some old GCC code still mentionned GPLv2 while the transition was made to GPLv3. Not a big deal in practice. > > > What I am very scared of, is to make someone at FSF unhappy or angry > > against me. > > sorry to be this blunt but if you are not engaging in questionable activity > with > GCC, you are not"important" enough to get people at FSF mad at you :-) You > may get people on this list annoyed, by insisting on issues largely peripheral > to GCC development proper. Although FSF holds copyrights on GCC, it is > largely an entity distinct from the GCC community -- who is the primary reader > of this mailing list. Perhaps the question becomes: whom should I ask permission to add an exception to MELT code's license to permit it to generate a *texi documentation, or alternatively to relicense all existing melt*texi files under GPL (so MELT documentation becomes GPL and there are no more GFDL vs GPL conflict). Or should I ask only my employer's lawyers if I can add such an exception to some MELT specific files without asking anyone at FSF? But thanks for your positive answer. And probably licens...@fsf.org will give me in a few weeks a practical advice on licensing; ideally a permission to change a copyright notice & license on some (very few) files. At least some human on @fsf.org did read my email asking for advice. My main concern is that AFAIU in the current state of MELT the generated *pdf file could perhaps not be redistributed. This implies that any Linux distribution willing to package MELT won't be able to include the generated pdf file in the package. In practice, I will continue to code inside MELT, occasionally adding :doc annotations as I did before. Basically, I am adding :doc annotation to every new "public" MELT name. I will give up my :doc annotations only if somebody asks me (and so far nobody did). What surprises (& disappoints) me a big lot is the recent GCC Steering Comittee "decision" [or at least email] to discourage generating documentation from code. In 2010, it seems against the current technical trends. And if changing such a decision requires FSF blessing in a matter similar to the plugin licensing (which took more than a year, and perhaps even more than two), I am not optimistic. And that kind of decision won't help immediately GCC to regain popularity. Perhaps our coding rules, as documented on the web site, should have a sentence like "avoid generating documentation from code". I would even dare supposing that such kind of rules already have the effect that GCC is not well documented. Developers are too shy to risk documenting their code (especially outside source files) and there are no incentive to add structured comments (or annotations) inside our source files since such documentation seems unwelcome. This is a chicken & egg situation that might discourage newscomers to enter GCC. Actually, and this could concern all of the GCC community, I believe on the contrary that we should have structured comments (in all our code) and the tools generating documentation from it (like GTK does). Efforts to generate documentation from code should not be discouraged, they should be strongly welcomed. Ideally, most of our header files should be as structured as those from GTK. But if this is "forbidden" nobody will start even thinking of it. I don't believe that documentation will be mostly written by people who do not contribute code. It did not happen before, and I see no reason it will happen in the future. Cheers.
