GFDL and documentation freedom (was: Re: FS/OSS license: not quite enough of a requirement)

[Alexandre Oliva]

On May 16, 2007, Rahul Sundaram <sundaram at fedoraproject.org> wrote:

>>> There is there no guarantee that it will be used properly.

>> The point being?

> It is open to abuse.

This is a red herring.

If someone modifies a GFDLed text in an abusive way, adding an
invariant section, the community can just ignore that change, or go
back to the previous published version of that document and start from
that.

If the original author published the first version of a text under the
GFDL with an abusive invariant section, the community can just ignore
that whole document, or realize that the if the GFDL didn't provide
the author with means to publish that document in such a way that
nobody could modify or remove that portion, he might as well have
chosen another license that provided him with this ability, and then,
depending on the chosen license, we might all end up worse off.

Under this light, I ask: so what?

>>> If anybody adds text like say "Free software sucks" in a invariant
>>> section then we can't include that documentation

>> Why not?

> Unrelated to technical content.

And?  We ship the GPL.  We even ship its preamble.  How is any of that
related to technical content?  Why should this even matter?  And, more
importantly, how does the presence of invariant sections actually gets
in the way of the exercise of any of the freedoms?

>> Documentation is not software.  Licenses are not software.  I'm trying
>> to discuss software freedom issues.  What are you trying to prove with
>> this distraction?

> It is not a distraction from a distribution view point. We don't
> distribute just software. When discussing freedom in software how it
> applies to document is very related.

I see.  It is a major distraction from the point I was trying to make
in this thread, but it is indeed a relevant discussion for Fedora.
Please accept my apologies.  I'm changing the subject to reflect the
change of focus, such that it doesn't feel like a distraction any more
;-)

>> So can software licenses and copyright notices.  So what are you going
>> to do, ban software licenses and copyright notices because they can be
>> abused?

> Invariant sections in document has nothing in common with license and
> copyright notices.

Except that one of the main purpose of invariant sections *is* to
contain a copy of the license the program is under.

Look, for example, at GCC's documentation.  Start here:

http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gcc/copying.html

Advance to the following section.

How could the manual possibly cover the licensing terms of the program
*and* of the manual itself if they couldn't be invariant sections?
How could they even comply with the licensing terms of the license
documents themselves, that don't permit modification?

Now go back to chapter 16.  That's the sort of content that some
poeple who want to rewrite history (*) might qualify as abusive.  But
is that an invariant section?  Surprise!  It isn't!

(*) from what's written in the last paragraph of section 2 in
http://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 

Now go back to chapter 15.  That's another invariant section.  Is it
abusive?  I don't think so.  I think it's useful.  I think it's very
good that nobody can remove that piece of advice.  Sure, it's probably
a whole page, so it might be abusive in a very short document.  But
the GCC manual is several hundred pages long.  So that's ok.  And,
again, that particular chapter is under a license that wouldn't permit
integration as a section that wasn't invariant.

>> Oh, non-Free firmware can also be abused.  Can we ban it too, pretty
>> please? ;-)

> How are you helping? There is still no packaging draft presented.

What does packaging have to do with this?

The freedom promise darft was presented about a week ago.  Still no
comments, still no wiki page.

As for the other document I mentioned, I'm still waiting for feedback
from other FSFs members.

Meanwhile, we're discussing applying firmer standards to documentation
than to software, as if that even made sense.  As if invariant
sections could possibly become a more serious issue than being unable
to improve, or get someone else to improve, the software that runs on
one of the CPUs attached to a computer, just because it's called by
this distracting term firmware.

As if invariant sections could possibly become a more serious issue
than being forced to publish modified versions of a program only
intended for internal use, somehow notifying the original author about
it in a timely fashion (what if it turns out to be impossible?  you've
already distributed the program by then!), or being restricted in how
much one can charge for the distribution of the program in source form
only?

In case it's not clear, I'm talking about the Reciprocal Public
License, that is held as an Open-Source License, but it quite
obviously disrespects the freedoms to modify and to distribute
modified versions of the program, by imposing unreasonable (and
business-unfriendly!) conditions on them.
http://www.fsf.org/licensing/licenses/index_html#NonFreeSoftwareLicense
http://www.opensource.org/licenses/rpl.php
http://www.opensource.org/licenses/alphabetical

I can't tell whether it was a mistake by OSI to approve it, or a bug
in the OSD itself, since it was originally (DFSG) intended as a set of
objective criteria with the same meaning as that of the FSD.

Now, I don't know whether any software in Fedora is under this
license.  But our policies permit software under this license to be
integrated.

But then, all of a sudden, businesses built around charging for the
service of distributing *only* source code in physical media, which
from the Free Software goals of Fedora they might take for granted,
would become copyright infringers, for making a profit out of Fedora
source media sets.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}