Re: documentation x executable code
On Fri, Jan 07, 2005 at 09:18:55AM -0500, Dale E. Martin wrote:
> > other things distributed with (and required to be distributed with) free
> > software are "secondary" and may be invariant. e.g. copyright notice and
> > license text.
>
> [...]
> So is your point the project _could_ decide that only licenses that allow
> for license changes should be allowed?
i don't see how you could possibly get that interpretation from what i said.
> > because it's part of the culture that you not do these things. it's
> > certainly unethical, possibly illegal in some jurisdictions, and would
> > result in mass protest and censure. why should it make any difference
> > whether these cultural expectations are explicitly spelled out or not?
> > you wouldn't get away with doing it either way.
>
> > in short, declaring the GFDL to be non-free because of it is just pedantic
> > quibbling of the worst sort.
>
> On the other hand, if there is an expectation that what would be marked
> invariant under the GFDL remain invariant even without the clause, then
> clause is annoying at best. The question in my mind is if it also violates
> DFSG 3, which it seems to on the face of it.
the GFDL allows modifications and derived works, and it allows them to be
distributed under the same terms. that meets the requirements of DFSG 3.
it has some restrictions on HOW it may be modified, but those restrictions are
explicitly permitted by DFSG 4.
> Unlike you, I don't think "append-only" patches meet DFSG 4 as per the
> example in my previous email.
DFSG 4 does not limit what kind of patches are allowed, it does not specify
any particular format, or that it be usable by any particular program, or that
it be usable by any program at all. it uses the generic term "patch".
> You seemed to agree that they wouldn't in source code; I'm not sure why you
> think they are sufficient elsewhere.
because documentation isn't software, no matter what some people who prefer an
infinitely arbitrary and inconsistent language try to say. append-only
doesn't work for software because you need to be able to change and delete
things in order to make the patched software work.
you don't need that for attribution or philosophical rants (i.e. secondary
sections in documentation) - in fact, it is necessary to NOT delete or change
things in order for it to continue functioning. append-only is the
appropriate form of modification for this.
> (Because these sections are necessarily inconsequential?)
and that too.
> > what i'd like to see is the anti-GFDL zealots defend their position with
> > credible argument that the GFDL is non-free, rather than just claim that it
> > is.
>
> I think the argument is that invariant sections violate DFSG 3 & 4. It
> seems pretty clear to me as they are currently written. (I'm sure you're
> aware of the other issues with the GFDL in addition to invariants, but they
> seem to be the most controversial.)
if that is the argument, then the logical and inescapable conclusion is that
license texts ALSO violate the DFSG because they also are invariant sections.
it's not credible, and not only because it ignores (rewrites, even) debian
history.
> > (BTW, i can see why you mistakenly thought i said that invariant
> > sections are necessary for documentation, when what i said was that
> > it was a practical necessity for us to ignore them when evaluating
> > software for DFSG-freeness)
>
> So if we wanted to spell it out in the DFSG, would there need to be
> verbage about the invariant sections that are special cases? Or is
> your argument that they're allowed simply by precedent/common sense or
> whatever and that the DFSG need not spell it out?
i would have thought that common-sense would be enough.
it used to be.
obviously, it isn't these days.
> > but, to answer your question, the practical necessity *for us*
> > (i.e. debian) is obvious. we wouldn't be able to distribute GPL software
> > at all if we didn't ignore the fact that the license text is non-free,
> > that the software distribution contains invariant section(s).
>
> DFSG 3 only requires the license must allow modifications to be distributed
> under the same license, not any license. The GPL allows this so I don't
> think this argument holds.
huh? did you actually read what i wrote? your response isn't even
tangentially related to what i said.
> > NOTE: "section(s)" is plural because copyright notice and license are two
> > different things. one is an assertion of copyright. the other is a
> > license to use/modify/distribute/etc. so there are at least two things
> > that we de-facto accept as being legitimately invariant.
>
> This has been addressed ad-nauseum.
actually, it hasn't. it's been mostly ignored because nobody wants to
acknowledge that we already accept invariant sections, and that we wouldn't
even be able to distribute our OS if we didn't.
> > we also accepted that the GNU Manifesto was *always* required to be
> > distributed along with the emacs manual, so there is a third invariant
> > section that we have always regarded as being legitimate - this is not
> > new since the GFDL, it was always a requirement of the license[1]. this
> > has always annoyed some people, but it has always been regarded as not
> > important enough to quibble about. this was the case when we debated and
> > wrote the DFSG years ago, and has been the case since, but now some
> > zealots are trying to change that and impose their own insane
> > interpretation.
>
> I don't think this is a fair representation.
how can an accurate summary of history not be a "fair representation"?
if there's some inaccuracy in my summary, please point it out.
> If invariants are allowed, I think they need to be addressed in the
> DFSG. If they're not, they're not. I don't find this to be "insane" in
> any way. Reasonable people can disagree of course.
invariants are allowed, and always have been. i've already proved that, so
i'm not going to bother doing it again.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: