license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+

[Mark Mitchell]

Mike Stump wrote:

> Unfortunately, I can't think of a solution that isn't totally gross
> that removes the entire point of generating documentation.  I think
> asking rms to design a solution to the problem might be necessary.  I
> think you're not the only person to use this technique in the world,
> and I think it would be nice if the FSF had a solution.  Don't plan
> on waiting for it though, could take a while.

I agree with Mike's comments.

I think that "literate programming" approaches (whether the full Knuth
version, or the more mild JavaDoc version, or auto-extraction of
command-line options or whatever) are valuable.  RMS, based on my
communications with him, is less convinced that they are valuable.  I
think he agrees that his opinions of the technical merits shouldn't
override a consensus opinion of the developers, but it does influence
how hard he wants to work on changing the licensing regime, and it is a
legitimately hard problem to solve.

The problem, fundamentally, is that when the FSF came up with a
difference license for documentation, that license -- whatever its
merits -- put "code" and "documentation" in two separate, unmixable,
buckets.   (The same problem exists with GPLv3, independent of its
merits as a license, in that it put GPLv2-only and GPLv3 code in
separate, unmixable, buckets.)  So, to the extent we don't want to
distinguish code and documentation, we now have a license barrier.

The FSF *cannot* solve this problem in the fully general case of non-FSF
code, since the FSF cannot make exceptions to GPLv3 code owned by third
parties.  The FSF can, however, add a license exception to GPLv3 for
GCC, or for all of its own code, and I believe it should.  I'll continue
trying to work with the FSF on this issue, but as Mike says this is
going to take a lot of time.

Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools.  If we use
those tools, and demonstrate their value, we're then in a stronger
position to say how generation of actual manuals is important.

Thanks,

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