Re: trampolines handling, important copyright question

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Sat, 2010-05-29 at 12:45 -0400, Robert Dewar wrote:
> Basile Starynkevitch wrote:
> 
> > Does any one know any name of a person from FSF who could give a
> > practical advice? I know nobody in person from FSF - unless there have
> > been some FSF people at some GCC summit I did attend.
> 
> You really can't expect to get free legal advice from the FSF. 


I don't seek legal advice. I am only seeking *practical* advice. 

In other words, I am not at all scared of legal issues (because AFAIK I
did nothing illegal - all the files involved have been either written by
me or generated by MELT which I have entirely written - of course I am
speaking of the MELT specific part of the GCC MELT branch; all the rest
is same as in GCC trunk, except for very few patches [perhaps a dozen
lines added to toplevel.c]). AFAIK the only current issue is that the
"make pdf" command inside MELT produces a file which perhaps cannot be
redistributed (but could be used -displayed on screen, printed on paper-
by the person which have typed that command). There is in my perception
no legal issue here for me (I believe that I won't go to jail, even in
the improbable event of traveling to the USA and I don't believe my
employer will have any financial issues neither; this is what I call
legal issues.).

What I am very scared of, is to make someone at FSF unhappy or angry
against me. I have a very fuzzy perception of the FSF [I'm living on a
different continent, I am not a native English speaker, etc..]. I don't
know who is an influent member of FSF and did met me once to be able to
put a face (mine) on MELT. Perhaps David Edelsohn or Diego Novillo or
Ian Taylor [or even Sebastian Pop] are important people at the FSF. I
really don't know (but I guess most of them are)! And I really don't
understand the difference (not in role, but in the set of people)
between GCC steering committee and FSF. I am guessing that they have
mostly the same people wearing different hats. If I remember correctly,
David Edelsohn did tell once at some GCC Summit that he is member of FSF
board, but I might have remembered incorrectly.


What I don't want to be, is to be the bad guy. I am trying my best to be
a good GCC & GNU citizen. 



And I do know that few people really care about GCC MELT. It is not
mature enough to attract a lot of people (and MELT's goals = prototyping
quickly passes inside GCC, probably "diagnostic" passes are not the main
role of GCC; MELT is a way to easily prototype GCC extensions which
otherwise should be coded as C plugins, and everyone knows that very few
people are interested in plugins, and not all of them could be
interested in MELT). But I don't want to make angry the few who might be
interested at it.

Besides, I don't want to keep a license issue on MELT; for instance, I
have hope that Debian people might sometimes package MELT, and for sure
they won't do it if there is some license issue which prohibit them to
redistribute a generated *pdf file in MELT.

If some FSF person tell me: you have to remove all the documentation
strings [ie all :doc annotations in gcc/melt/*melt files] from MELT, I
will sadly comply with that. If that happens, I would only lose many
hours of work... That would be quite sad for me, but nothing worse.
However, that would make MELT almost totally undocumented & unusable (by
other than me).



If some FSF person tell me: just remove all @include melt*texi commands
from gccint.texi and make an independent MELT documentation
allmeltdoc.texi (with the corresponding make melt-pdf target) and add
this or that copyright notice & license to it, that is ok, and probably
the best solution I could expect. But I don't feel autorized to do so
without approval from the FSF which owns the copyright on my code.



For instance, I have no idea if there are other FSF software with a GPL
licensed documentation (I guess that if there exist such a prior
example, it would help me), and I probably could not change a copyright
notice in a MELT file without external permission from FSF. At least I
won't do that on my own.

I am a computer professional, not a lawyer. (And even if I was a lawyer,
I am French, not American).



I never changed any legal habits [I mean the habits about notices on
licenses & copyright] in GCC or MELT. Concretely, every copyright notice
in a MELT file I did wrote myself bears the same copyright notice
[except the year, and perhaps the comment convention] than similar GCC
files. I even pushed that rule to have the MELT code generator copy the
copyright notice of a file like gcc/melt/warmelt-base.melt into the
corresponding generated files gcc/melt/generated/warmelt-base*.c: The
MELT syntax (comment ...) is exactly for that : adding a comment which
gets passed to the generated C code.



What surprises me a big lot, it that I would believe that copying a few
lines from code to documentation has already been done many times in GCC
(MELT is definitely not a precedent). With MELT :doc annotations, that
copying process is mechanized. And apparently, copying manually such
lines is acceptable (it has been done many times in GCC, e.g. in
descriptions of options, or in description of plugins, ...), but
mechanizing that copy is apparently becoming wrong. From my free
software hacker's perspective which is *not* a *legal* perspective, only
a technical one, we are really in a very strange world to forbid that
(or just to not having thought of that before). But as I said many
times, I am not a lawyer, and I understand not much about licenses (as a
crude example of mine misunderstanding, in my view, the main difference
between GPLv2 & GPLv3 is related to tivoization; this is probably very
simplistic and could be wrong).

And the set of lines which are :doc annotations in MELT is
proportionally quite small, very probably a few percents. There are
about 38KLOC of MELT code with a total of 637 :doc annotations (I don't
know exactly what is the mean length of a :doc annotation, but I would
guess it is two or three lines; most MELT primitives have a one line
annotation [which correspond to two paragraphs in the generated
documentation: listing all the formals & their type in a table...], the
biggest annotations are probably for some MELT classes - less than a
dozen lines.) and the generated meltgendoc.texi is 14KLOC, but most of
the generated *texi lines are (generated) texi directives (in particular
there are many @vindex and many @table-s; notably the usual table of
fields of every class, the table of formal arguments for every function
or primitive etc...). Put it in another way: Suppose you are designing &
implementing any kind of programming language in 2008 or 2010. You
certainly would want some kind of cross-referencer or pretty-printer,
and that is also a documentation generator.

So if I am asked to remove all the :doc annotation, I would be very very
sad, but that won't be a big deal (except of course that I would be
narcissically hurt & my morale would go down.). However the resulting
MELT will be almost completely undocumented, which I believe means be
completely unusable.

And please try to understand my position. Suppose you are designing a
DSL to code GCC extensions in (but you could extend to any DSL to code
any extension of any 4 millions line of code monster software). We are
in 2008 or 2010. Won't you also generate some kind of documentations
from sources? doxygen & gtk & Java are doing that since more than a
dozen years. In my technical view, designing a domain specific language
without any kind of documentation generator would be a big mistake in
2008 or 2010 that you won't have made neither. (Perhaps you would have
using a different technology, tool or terminology, but you surely would
have thought of generating documentation). So generating some kind of
documentation is a very natural process (so natural that I never
imagined it could be forbidden or against the GNU or the FSF goals, and
I never thought I would have to ask permission to do so.). Generating
documentation is a help to programmers -and MELT is a tool for
programmers-. And in the context of GCC, I thought that generating *texi
files is the best I could reasonably offer in a small time.


So my question is simply: what should I do to avoid the FSF becoming
angry against me, while still keeping the documentation of MELT (which
is currently implemented as :doc annotation)? This is not a legal advice
I want, more of a social one. Of course, separating the MELT
documentation from the GCC internals documentation is not a big deal for
me. Losing all the documentation would be sad.



###
In France, the free software organization I am member of is April [A
French organization of more than 5000 people and hundreds of corporation
which defend free software]. I tend to think I understand more April
than FSF, very probably a cultural issue.

For legal advice, I will ask my employer. But CEA lawyers are French
lawyers, not American. They have been able to design the CECILL license
(the french equivalent of GPL). http://cecill.info/

Regards.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***