Re: New version of articulate available

[Graham Percival]

On Tue, Mar 22, 2011 at 04:08:18PM +0100, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> > On Mon, Mar 21, 2011 at 11:46:21AM +0100, David Kastrup wrote:
> >> The GPLv3 states under 5 "Conveying modified source versions"
> >
> > I don't see articulate.ly as a modified source version, unless I
> > misunderstand that term.
> 
> The whole Lilypond of tomorrow is a modified source version of today,
> containting parts that various authors licensed as their personal
> contribution under the GPLv3 to the Lilypond project.

So it's legally impossible for us to have part of the source tree
that's public domain (i.e. the snippets), part under FDL, part
under GPLv3, and part under the MIT license?

I do not believe that simply having something in the same tarball
(or git tree) means that they must have the same license.  If that
were true, then any attempt at a distribution (be it linux,
freebsd ports tree, macports) would go beserk.

> And are you going to guarantee that articulate.ly is not going to be
> changed by anybody but the original copyright holder?

Dump a comment at the top.  If anybody ignores that comment, it's
their fault.

> > To clarify, this only refers to something called "modofied source
> > version", right?  I mean, the docs are under GPL FDL 1.3+; this
> > paragraph doesn't somehow require that the docs are placed under
> > GPLv3, right?
> 
> I don't claim that I understand the FSF stance with regard to mixing FDL
> and GPL in Emacs (neither does Debian, by the way).  For Lilypond, the
> manual is not as thoroughly hyperlinked and integrated into the
> operation of the program, anyway.  Considering them separate makes more
> sense here.

IMO, considering a lot of things to be separate makes sense.  If
there is some legal reason why things cannot be separate, then
please share it.  Clearly if you compile C++ together, they are
not separate.  Other than that, it seems to me that something is
"separate" if we "consider it to be separate".

With regards to articulate.ly, you seem to want to "consider it to
be not separate", whereas I want to "consider it to be separate".
I have not heard any kind of legal test to decide if something is
"separate" or not.

> >> But making it an _integral_ part of Lilypond will not be feasible.
> >
> > You're talking about moving the code into a C++ performer, right?
> 
> Into _anything_ being run as an integral and substantial part of
> Lilypond operation.

Yes.  And I claim that having a file ending in .ly in a tarball
does *not* consistitute to be an "integral and substantial part".
Or, in other words, I think we can "consider them to be separate".

> > I'm not talking about that.  I'm talking about putting it in ly/, as
> > an optional include.  That's not "integral".
> 
> The XEmacs project has gone through about 18 months of pain in order to
> get their library code based migrated to GPLv3.  Those are mostly
> distributed as separate packages (in the "package tree"), maintained in
> a separate repository, that usually are just loaded by explicit demand
> of the user.

articulate.ly would be in the source tree (along with MIT-licensed
stuff), but would still "just loaded by explicit demand of the
user".

IMO, that counts as "separate", and "not an integral and
substantial part".  Would you feel better if we created a
directory called:
  ly/not-an-integral-part/
to store such files?


> > I think this is nonsense, not because of the copyright law (although
> > that certainly *is* nonsense!), but because as far as I can see,
> > articulate.ly only uses public interfaces[1], is not an integral part
> > of lilypond, and thus all these concerns are not valid.
> 
> If we document it as an integral part of Lilypond

So we document it as a non-integral part.

> and distribute it as
> an integral part of Lilypond and distribute it as an integral part of
> Lilypond, that seems like a bit of a stretch.

So we put it in the
  ly/not-an-integral-part/
directory.

> Apart from that, any
> artificial measures designed to _not_ make it appear an integral part of
> Lilypond are going to be a mistake and nuisance, because it or the
> equivalent of its functionality certainly _should_ become an integral
> part of Lilypond.

I'm not talking about whether somebody might want to add code to a
Performer.  I'm talking about the articulate.ly, created by Peter,
which is not going into a Performer or anything like that.

> And shooting the messenger is not going to particularly help.  Neither
> is postponing thinking about license problems.

I'm not shooting you.  I'm stating, for the record, which might
matter in some weird universe in which somebody tries to sue
somebody over this, that I see no legal reason why a text file in
a directory of a tarball, which is not compiled with other stuff,
and which requires explicit user request to include, should count
as an "integral" part of lilypond.  It is not loaded by default.
Users can include non-GPL'd .ly files at their whim.  Our source
tree contains other non-GPL'd files.

> Somewhat helpful may also be
> <URL:http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries>

articulate.ly is not a library.  It is not compiled.  It can go in
a "separate subdirectory", which is precisely point 2 on the
linked page... although I note that this page claims that you can
link to the .o file directly and it's not necessary to create a
separate .a library!  Wow, the FSF is actually more lenient about
libraries than I thought they were!

Cheers,
- Graham