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} ***
