libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] GFDL with Invariant Sections or other unmodifi


From: Michał 'rysiek' Woźniak
Subject: Re: [libreplanet-discuss] GFDL with Invariant Sections or other unmodifiable parts. Was: Final Thesis: H-node
Date: Sun, 19 May 2013 23:52:39 +0200
User-agent: KMail/1.13.7 (Linux/3.9-0.slh.5-aptosid-amd64; KDE/4.8.4; x86_64; ; )

Dnia niedziela, 19 maja 2013 o 18:39:52 Adam Bolte napisał(a):
> On 20/05/13 02:04, Michael Dorrington wrote:
> > On 19/05/13 16:50, systemsaviour.com wrote:
> >> On 20/05/13 01:08, Michał 'rysiek' Woźniak wrote:
> >>> Dnia niedziela, 19 maja 2013 o 15:39:57 Michael Dorrington napisał(a):
> >>>> On 19/05/13 14:20, Thomas Harding wrote:
> >>>>> Le 19/05/2013 14:52, Michael Dorrington a écrit :
> > [...]
> > 
> >>> Ask and ye shall receive:
> >>> http://rys.io/en/101.txt
> >> 
> >> The part above that got cut out in the [...] was when Michael said:
> >> 
> >> "I posted in December 2012 and January 2013 to this list about how
> >> including manuals which are under the GFDL with Invariant Sections or
> >> other unmodifiable parts (which is similar to a CC with ND licence) in a
> >> distribution makes that distribution non-free."
> >> 
> >> Yet the document you posted only covers points specific to CC-*-ND and
> >> GNU Verbatim licenses.
> >> 
> >> For the licenses in question, I agree with many of your points. However,
> >> those are entirely different beasts to the GFDL, which is the license
> >> that seems more commonly used for software documentation in GNU/Linux
> >> distributions. I don't see any of your concerns take issue with anything
> >> the GFDL does, given the strict limitations placed on non-variant
> >> sections.
> > 
> > Really?  That doesn't make sense to me.  You don't see any of the
> > article's concerns take issue with anything the GFDL does?  How about "I
> > DON'T WANT MY WORK TWISTED!" and "SOME WORKS SHOULD BE INVARIANT!" where
> > he argues these are invalid reasons to use a no derivatives licence
> > (such as GFDL with Invariant Sections or other unmodifiable part).
> > Actually, how about the whole article he posted.
> 
> Let's try and keep this civil.

+1

> When reading the article, consider the reasoning on each point as to why
> it says what it says. All arguments (but one which I'll discuss below)
> are basically "because someone might want to do X, Y, Z and we can't if
> it's non-free". But the invariant sections in GFDL don't cover the text
> in the scenarios given, so there does not appear to be cause for concern.

But they need to be redistributed with the text in question while at the same 
time being considered part of the work, and I can understand how that can be 
seen as a problem.

If any part of the work cannot be modified under a given license, the license 
is not libre. Period.

> Then there is the argument (not saying that I agree) that having the
> invariant section is pointless because things might be protected in
> other ways. How does this matter? What practical reason is there to
> remove those parts if they aren't harming anyone?

That's a strong assumption right here - that they "aren't harming anyone". I 
am not sure I completely agree. They do cause issues, as stated below.

> In my opinion, Debian (as an example) is missing out on a lot of GFDL
> documentation - but at what cost? As I indicated to you previously, I
> have yet to see an actual example of a GFDL non-variant section causing
> anyone grief.

It would be enough to just look at reasons why Wikipedia decided to go CC-By-
SA, and why WikiVoyage decided to not use GFDL at all. "Grief" is too strong a 
word, maybe, but there are valid arguments against using GFDL.

I do not have a strong opinion on this, mind you (and this is why GFDL is not 
mentioned explicitly in my text). But I do see how the invariant sections can 
be problematic.

> So back to my point; even if the non-variant section is
> pointless, it's on the people who have issue with it to explain why it's
> an issue - not for the FSF or the authors to drop it just for the sake
> of consistency or whatever it is that people are upset about.

From what I can tell GFDL with invariant sections is just an attempt at doing 
something CC-By-* with explicit attribution guidelines (you know you can 
decide how the CC-By-* mandated attribution is to look like for your work, 
right?[1]) does much better. GFDL and CC-*-ND/GNU Verbatim seem to come from 
different philosophical stances.

Specifically, I think that it would be worthy discussing/writing about how the 
same that GFDL tries to achieve with invariant sections can be achieved by CC-
By-* attribution guidelines in a way that is at the same time better, less 
cumbersome and less problematic to freedoms (as here the "invariant text" 
would be a part of the attribution, not of the work itself).

And I would really love to see the GFDL documentation move to CC-By or CC-By-
SA license (possibly with some specific attribution guidelines) to clear up 
the confusion and finally put this issue behind us all.

[1] http://creativecommons.org/licenses/by/3.0/legalcode -> Section 4(b)

> > I'd like know why you think GFDL with Invariant Sections or other
> > unmodifiable parts is good for free software manuals and yet for the
> > article posted you "agree with many of your [its] points".
> 
> What do you mean by "other unmodifiable parts"? The invariant sections -
> the "Secondary Sections" - appear to be quite specific in what they can
> do, which is the *only* reason they aren't a problem. Software
> documentation (as an example) under licenses like CC-*-ND are indeed a
> problem - no argument from me there. Again, let's not confuse the issue
> by brining unrelated licenses into this.

So for the time being for me GFDL is simply redundant, as CC-By-* can do the 
same thing while being less problematic (as it does not create some portions 
of the *work itself* that cannot be modified).

-- 
Pozdrawiam
Michał "rysiek" Woźniak

Fundacja Wolnego i Otwartego Oprogramowania

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]