Free Music License?

[Simo Sorce]

On Thu, 2005-08-18 at 22:12 +0200, Jeroen Dekkers wrote:
> At Thu, 18 Aug 2005 10:57:39 +0200,
> Simo Sorce wrote:

> > This is a question I would do too, why ...
> > Now before you can even think about the answer you should first ask
> > yourself, what limit to my freedom do something like that mean in the
> > case of a _documentation_ book ? Are they acceptable?
> > If you accept the limit on freedom posed by the GNU GPL (freedom to take
> > parts of the software without sticking to the license) as a good balance
> > you should think if an invariant section may be a good balance in the
> > case of a document, a book, an article, etc ...
> 
> What do I get back? With the GPL it's pretty easy to see: more Free
> Software. With the invariant sections, it's not really easy to see for
> me. I know that g++ probably wouldn't have been there if the GPL
> didn't require to free it. But would the GCC manual exist without
> invariant sections? I think it would. And maybe my imagination isn't
> good enough, but I really can't imagine that we would get less free
> documentation if we wouldn't allow invariant sections to be removed at
> least (which might be an acceptable compromise - although I'm not sure
> about it).

Ok, I buy out the argument that the objective of both licenses is to
foster more production of works, (I'm not sure this is the main
objective of the GFDL, but let's take it as an assumption). Given that
is documentation and software comparable in this regard ?
What's the culprit in the GPL? To protect freedom of the software
against proprietarization (protection) and to spread use of the GPL
license through usage of other GPL licensed code in new projects
(inheritance).
Is it the same for documentation?
I think the protection wise the GFDL is the same as the GPL. What about
inheritance? Well I do not think inheritance is so important for
documentation as it is for software. This different weight in the
importance of this factor, make it possible to reconsider the which
incentives are more important. An invariant section, might be a better
incentive for some authors to write documentation then the chance of
reuse of the writing. I do not know if this is a plausible thing, but we
should think some more on it. 
I'm not saying you're wrong, I'm just saying that as free software
programmers we may have a distorted way to look at things.

> Nobody says we should be referring to the new book as the previous
> book. But it's actually the GFDL which requires that! If I take the
> GCC manual, modify it however I want, and apply the front-cover
> clauses, I *must* put "a GNU manual" on the cover. So I'm even forced
> to do it.

I recognize this is a big problem.
One of the worst problem of the GFDL is the inability to break down a
work into pieces, like printing a chapter of the book each month on a
paper etc ...

> > Can you express which freedom of yours is being getting out by the GFDL?
> > What about the author freedom? Where's the balance? Why people that
> > whines against the GFDL has not yet been able to:
> > A) explain clearly which is the problem in a public article so that all
> > people can understand your illumination? 
> 
> It's pretty strange to hear on this list that caring about your
> freedom is whining. But anyway, your statement that the people not
> been able to do this is just false. Some Debian Developers wrote a
> pretty clear article about the GFDL, to give an example:
> http://people.debian.org/~srivasta/Position_Statement.html

Thanks for point me at this draft, it is indeed clear, and I was
delighted to finally see a clear concise text about the perceived
problems with the GFDL.

> To quote one part of it:
> 
> In addition to the simple restrictions of freedoms imposed by the
> Invariant Sections, they also cause practical problems:
> 
>  * Incompatibility with the GPL. It's GPL-incompatible in both
>    directions. This means that you can't legally extract text from a
>    GFDL'ed manual and put it into integrated help strings in a GPL'ed
>    program. And you can't extract code or comments from a GPL'ed
>    program and put it into a GFDL'ed manual. (Without getting explicit
>    permission to relicense from every copyright-holding contributor,
>    that is.)

I do not think this is a problem, it is the same problem you have
between many other free software licenses. Yes it is unfortunate that
they both come from the FSF but are incompatible, but it is just a
matter of taste.
Plus I think it is wrong to say you need the permission of every
copyright-holder to extract a portion of a work, you need permission
only from the contributor(s) that make that portion of the work imho,
but I do  not want to get in to legal as IANAL.

>  * Being forced to retain inaccurate Invariant Sections (or Cover
>    Texts, or Dedications).
> 
>  * Being forced to retain obsolete Invariant Sections (or Cover Texts,
>    or Dedications). Dated invariant sections would exacerbate this
>    problem.

These are annoying.

>  * Possibility of obsolescence, via changes in technologies (such as
>    the disappearance of printed matter, or the particulars of file
>    formats and access restrictions).
> 
>  * Being forced to retain technically inappropriate Invariant Sections
>    or Cover Texts, etc.

This have to do more with  the quality and proper use of the license,
but I agree these are annoyances.

>  * Being forced to retain Invariant Sections even in extremely
>    space-tight environments (such as a rescue disks, reference card,
>    PDA's, or embedded devices).

This may be a real problem even if rare.

>  * Being forced to retain untranslated Invariant Sections in a
>    translation.

This is annoying.

>  * Being unable to use material from the document for a new document
>    whose primary topic is that of an Invariant Section (because the
>    Invariant Section must be retained, and must be Secondary, but
>    would no longer be Secondary). This issue, where it can be very
>    difficult or impossible to repurpose chunks (eg copy a chapter
>    about regular expressions when one copies the just the regexp
>    code), is a significant degradation of freedom.

I do not understand this point very well.

>  * Invariant Section "bloat". The natural response to several of the
>    above problems is to add new Invariant Sections, saying "I think
>    the old Invariant Section is inaccurate/obsolete/offensive" or
>    "This is a translation of the old Invariant Section". These will
>    accumulate and will also be non-removable.

I think this is fiction, the natural response to a problem in an
invariant section is to add a NON-invariant section that can be updated
to say how much obsolete/wrong/whatever the original invariant section
is.
While it is possible that people may add other invariant sections I thin
it is unlikely and a clear desire of the authors to trash their own work
(which is also unlikely).

>  * Difficulty in modifying invariant sections of GFDLed documents not
>    under unified central control (need permission from many
>    contributors or their estates/agents, which becomes more difficult
>    with time).

Potentially a problem.

> > B) Propose a better license for documentation that address the same
> > problem that the GFDL try to solve?
> 
> I've actually been thinking about it. The main problem is lack of time
> and it wouldn't solve the current problems with all current GFDL
> works. I also heard that the FSF might fix the GFDL.

Yeah, it's a tough matter, now I recognize I was being provocative with
this question, I apologize.
 
> > No, saying: "the GNU GPL is the right one because it grants my freedom"
> > is not enough, sorry. 
> 
> Can you please say why we have this really big need for invariant
> sections and why this need is bigger than all the problems just
> mentioned? Because I haven't heard it and I asked for it in my
> previous mail.

Sorry, I'm not advocating invariant sections, what I say is that we
should carefully think if they are really so bad, if the balance in the
case of documentation can be different and if invariant sections may be
a good thing or not.

Based on this discussion I'm more and more convinced that being able to
strip out invariant sections (but being forced to change the name of the
resulting document and refer to the original one in a note) would be a
good thing, also being able to use excerpts of the main text in GPLed
works would be desirable (but not a must in my eyes).

> I don't see any freedom of expression taken away from the author. The
> author still has the freedom to write whatever he wants. I'm not
> forbidding the author to express himself. I'm just saying that I don't
> see a need to give the author of a manual the power to force his
> expressions on all future co-authors and readers of that manual.

I tend to agree with you, but I can also see why an author may want to
protect his ideas also on a written text. And as documentation does not
have the same properties as software and we refer to secondary sections
only I still can't decide whether invariant section are bad per se or
just bad in their long term consequences, I tend to favor the second
opinion right now, but more comments are welcome.

> > Please try to honestly answer to my question, if you can effectively
> > explain me these things, I'm willing to think about them and perhaps
> > change my mind. Please do not just rant for the sake of it, it makes no
> > sense and just weaken your position.
> 
> My freedom to do with the manual what I want. It's the same thing as
> with free software. There you also need to freedom to do with the
> things I want.

I think that freedom is not constrained more then the way they are
constrained with the GNU GPL.

> I can give an example. I have a manual of a program. Now I want to
> make a reference card based on the manual (so it's a derived work and
> also falls under the GFDL). But this reference card has to include all
> invariants sections, as a whole, because if it doesn't, I'm violating
> the GFDL. 

Yeah, I think this is one of the main problems of the GFDL, but a
reference card is easy to rewrite compared to software, so the problem
is much less serious than with software imho.

> Or what if the author of this manual writes that Bush is great and
> talks about that everybody should support the Republician Party. Then
> my freedom is restricted, because I can't remove it.

Yes this is an example of political views expressed by an author, while
I may disagree with his view I'm not sure I should be entitle to remove
them, I can always add a comment about the fact I do not agree with them
(and I'm not obliged to put my comment in an invariant section).

> Now a question to you. If I write a political text supporting Bush and
> print if everytime my programs starts up and write a license which
> says that you can't remove that text. Would it be Free Software?

This is a hard question. If the original program prints out Copyrights
notes by default, you can't change this thing in a GNU GPL program, but
it is considered a Free Software License. As this text is a non
functional part of the program I should think very carefully about not
considering it a Free Software License, even if on a first look I may
say it is not.

> And if wouldn't, why would the same license be Free Documentation?

Well I tend to think that different works have different characteristics
and freedom can not be claimed blindly.

> Is a documentation writer more important than a software writer?

I do not think it is a question about the importance of the author, it
is a question about the balance between the freedom of the user and the
rights of the author. With software the functional aspects of a program
are so important that the freedom to change it has more weight than the
right of an author to veto any change, that's different for a document
and it's non-functional aspects (like a dedication) imho.

> It's just
> some questions I have asked myself. Personally I've come to the
> conclusion that documentation might be treated a bit different because
> it is a bit different than software, but that the basic freedoms
> shouldn't be that much different.

I fully agree, the difficult thing here is to balance freedoms, as the
balance change in different kind of works imho.

Simo.

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Garofalo, 39 - 20133 - Milano
mobile: +39 329 328 7702
tel. +39 02 2953 4143 - fax: +39 02 700 442 399