trampolines handling, important copyright question

[Basile Starynkevitch]

On Sat, 2010-05-29 at 16:48 -0500, Gabriel Dos Reis wrote:
> On Sat, May 29, 2010 at 2:18 PM, Basile Starynkevitch
> <basile@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 licensing@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.