Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-31 Thread Basile Starynkevitch
On Sat, 2010-05-29 at 22:40 -0700, Joe Buck wrote:
 On Sat, May 29, 2010 at 01:39:44AM -0700, Basile Starynkevitch wrote:
  ... I was told that
  generating a *texi file from (GPLv3+ licensed, FSF copyrighted) source
  code could be incompatible with the GFDL license of gccint.texi.
 
 The SC is trying to work something out with RMS on this (more generally,
 it's also an issue for libstdc++ and doxygen).  While I can't make
 promises, it seems he's open to coming up with some kind of solution that
 would allow this use, ideally without needing to involve lawyers.
 
 Unfortunately these things always take longer than you'd think that they
 should.


To my greatest  extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question  [gnu.org #579118]
to licens...@fsf.org since Karl Berry replied to me


 The FSF has already officially approved and recommended the strategy
 mentioned in your message, and throughout the thread: dual-license,
 under the GPL and GFDL, material that applies to both code and
 manuals,
 or is auto-generated from one to the other.
 
 In your case, you are generating documentation from the code.  So, put
 a
 license notice in the original (GPL'd) source files that the
 documentation so generated is also available under the FDL.
 Automatically insert an FDL license statement in the generated files.


Regards and thanks to everybody!

Cheers.

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




Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-31 Thread Robert Dewar

Basile Starynkevitch wrote:


To my greatest  extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question  [gnu.org #579118]
to licens...@fsf.org since Karl Berry replied to me



The FSF has already officially approved and recommended the strategy
mentioned in your message, and throughout the thread: dual-license,
under the GPL and GFDL, material that applies to both code and
manuals,
or is auto-generated from one to the other.

In your case, you are generating documentation from the code.  So, put
a
license notice in the original (GPL'd) source files that the
documentation so generated is also available under the FDL.
Automatically insert an FDL license statement in the generated files.



Regards and thanks to everybody!


Great, it's always good when you hit an established FAQ to which
the answer is already available


Cheers.





Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-31 Thread Mark Mitchell
Basile Starynkevitch wrote:

 To my greatest  extremely positive surprise, I got today an answer from
 the FSF (I really am very happy of such a quick answer)! I hope it OK to
 cite here part of the reply I've got to my question  [gnu.org #579118]
 to licens...@fsf.org since Karl Berry replied to me

From RMS' comments on the SC list, I'm not sure if Karl had full
context.  His answer is certainly reasonable as an explanation of how
you could create a project that had GPL'd code and GFDL'd manuals.
Whether or not it's an answer to how the FSF wants to deal with the code
it owns, however, is not obvious to me.

I have asked RMS to clarify.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713


Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-31 Thread Basile Starynkevitch
On Mon, 2010-05-31 at 12:51 -0400, Robert Dewar wrote:
 Basile Starynkevitch wrote:
 
  To my greatest  extremely positive surprise, I got today an answer from
  the FSF (I really am very happy of such a quick answer)! I hope it OK to
  cite here part of the reply I've got to my question  [gnu.org #579118]
  to licens...@fsf.org since Karl Berry replied to me
  
  
  The FSF has already officially approved and recommended the strategy
  mentioned in your message, and throughout the thread: dual-license,
  under the GPL and GFDL, material that applies to both code and
  manuals,
  or is auto-generated from one to the other.
 
  In your case, you are generating documentation from the code.  So, put
  a
  license notice in the original (GPL'd) source files that the
  documentation so generated is also available under the FDL.
  Automatically insert an FDL license statement in the generated
 files.
  
  
  Regards and thanks to everybody!
 
 Great, it's always good when you hit an established FAQ to which
 the answer is already available

I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
about the patch I intend to apply to the MELT branch (changing copyright
notice of gcc/melt/warmelt*.melt files there).

I also emailed k...@gnu.org about that.

If someone objects to this copyright/license notice change patch please
tell me as soon as possible.

Cheers.

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




Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-31 Thread Basile Starynkevitch
On Mon, 2010-05-31 at 22:46 +0200, Basile Starynkevitch wrote:
 
 I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
 about the patch I intend to apply to the MELT branch (changing copyright
 notice of gcc/melt/warmelt*.melt files there).
 
 I also emailed k...@gnu.org about that.

I have been asked by Karl Berry to wait several days before making that
patch. So I will.

Cheers.


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




possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-29 Thread Basile Starynkevitch
Dear Sir,

[adressed to licens...@fsf.org  g...@gcc.gnu.org]

[I assume you understand both GPL vs GFDL licenses  software
architecture]

I am a (write after approval) contributor to GCC, and the author of the
MELT branch of GCC (on which I am working since 2008 at least). So far,
I am the only contributor to that branch. I am covered by a copyright
assigment RT206238 (from my employer CEA to FSF). 

I am not at all a lawyer, just a plain research engineer, computer
scientist, working in a public French research organization (CEA,
www.cea.fr, approximately the French variant of the US DOE) and I don't
understand US particularities about licenses. I am French so do not
understand, use or know US laws.



In a few words, MELT is a lispy domain specific language, translated to
C code suitable for GCC, to write extensions to GCC (so an extension
coded in MELT is like a GCC plugin coded in C, except that the source
code is in my MELT dialect, not in C, and that the API gluing the MELT
extension to GCC is different  specific to MELT). MELT can be compiled
in principle as a GCC branch, or -by fetching only a few files from the
branch- it follows the GCC trunk (but I did not merge the trunk into
MELT since several weeks, for technical reasons).

MELT is bootstrapped, like GCC is. This means that the MELT translator
is written in MELT and generates its own C files (obviously, these
generated files are stored in the svn repository, exactly like generated
configure files are also stored there).

MELT [in the svn repository] is made of:

a. a runtime, coded in C, files gcc/melt-runtime.[ch] plus some few
changes w.r.t. gcc trunk in a few files (e.g. a few lines added to
gcc/toplevel.c)

b. the MELT translator, itself coded in MELT, files
gcc/melt/warmelt*.melt. These files have the same copyright comment as
every other GCC source file.

c. The C files machine-generated from the above (b) files, in
gcc/melt/generated/*.c. The copyright comment from (b) is mechanically
copied in these files.

d. extra MELT files illustrating some concrete extra GCC passes coded in
MELT, files gcc/melt/xtra*melt

e. an incomplete hand-written gcc/doc/melt.texi file documenting the
branch. This is a chapter of the GCC internals documentation (like
gcc/doc/gimple.texi is) and it is included from gccint.texi with
@include melt.texi


The MELT building procedure also generates in the build tree, from some
annotations inside the (b) sources files gcc/melt/warmelt*melt, a file
meltgendoc.texi; I asked on May 7th on the gcc list [in a detailed
message] http://gcc.gnu.org/ml/gcc/2010-05/msg00125.html for comments,
but did not get any answers. Later on, in the
http://gcc.gnu.org/ml/gcc/2010-05/msg00539.html thread, I was told that
generating a *texi file from (GPLv3+ licensed, FSF copyrighted) source
code could be incompatible with the GFDL license of gccint.texi.

More technical details appear in
http://gcc.gnu.org/ml/gcc/2010-05/msg00125.html so I won't repeat them
here. In particular, there is a link (to an attachment on the GCC wiki)
to the generated documentation in PDF.


The main point is that MELT is quite a big code (for a single coder),
and that the generated documentation, even if it is incomplete, buggy,
is the only reference documentation I have. Generating documentation
from source code is not a new practice (GTK did that for years).

What do you suggest me to do? (I would hope that future versions of GPL
or GFDL might permit generating document from source code, but they
won't come out soon).

Perhaps a solution could be to move all melt documentation outside of
the GCC internals documentation in the MELT branch, and to have a
meltdoc.texi documentation with a compatible license (someone suggest
using GPL for a documentation) and have it include both melt.texi 
meltgendoc.texi.

I certainly don't want (and probably legally cannot) to change any
license or copyright comment without permission probably from FSF (or
who else?).

Apparently, I was told that the current state of MELT documentation is
that it might have a conflict between GPL  GFDL and therefore might not
be redistributable, but I am not a lawyer at all and do not understand
at all these issues. My wish would be to have a documentation which some
linux distributions could provide  redistribute.

I would be very sad to lose all my (incomplete) documentation efforts.

I am waiting for your advices  would be happy to answer to any
technical questions. But I am not a lawyer, and not even a native
English speaker.

Respectful regards.

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




Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-29 Thread Basile Starynkevitch
On Sat, 2010-05-29 at 10:39 +0200, Basile Starynkevitch wrote:
 Dear Sir,
 
 [adressed to licens...@fsf.org  g...@gcc.gnu.org]

Apparently, some human at FSF got my email. 

An automaton send me:

 There is no need to reply to this message right now.  Your request has
 been assigned an ID of [gnu.org #579118].

That's hopefully good news!

Cheers.

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




Re: possible license issue (documentation generated from source) in MELT branch of GCC

2010-05-29 Thread Joe Buck
On Sat, May 29, 2010 at 01:39:44AM -0700, Basile Starynkevitch wrote:
 ... I was told that
 generating a *texi file from (GPLv3+ licensed, FSF copyrighted) source
 code could be incompatible with the GFDL license of gccint.texi.

The SC is trying to work something out with RMS on this (more generally,
it's also an issue for libstdc++ and doxygen).  While I can't make
promises, it seems he's open to coming up with some kind of solution that
would allow this use, ideally without needing to involve lawyers.

Unfortunately these things always take longer than you'd think that they
should.