Re: O: gnu-standards -- GNU coding standards
On Sun, Apr 07, 2002 at 04:34:36PM -0500, Steve Langasek wrote:
> On Sun, Apr 07, 2002 at 11:56:59AM -0600, Joel Baker wrote:
> > The DFSG is an excellent place to start, but trying to apply it to things
> > which *are not software* is silly, and results in the sort of sillyness
> > which we're seeing now - will we see an Orphan message for GCC next?
> The issue is that the Debian Social Contract doesn't say "All software
> in Debian will remain 100% free", it says "Debian will remain 100% Free
> Software." Therefore, for something to be part of Debian, it must be
> Free Software, even if it's documentation. Now, this may be an
> oversight in the original phrasing, but this is the Social Contract that
> we've all agreed to uphold as Debian developers -- unless and until it's
> clarified to address the various issues that arise with other forms of
> data, we really don't have anything else we can point to when judging
> the license on documentation.
Pardon me, but I feel the need for a quote coming on.
"You keep using that word. I do not think it means what you think it means."
Take it tongue in cheek, please, it's not a flame. But it *is* meant to
point out that there is 'free' as in beer, 'free' as in software - and
'free' as in publication. If the Social Contract says that we are 100% Free
Software, then we have *no place* distributing documentation which isn't
software, do we?
Yes, it's hyperbole, but it also points out what I consider to be a really
glaring schism between what our social goals are, what we've written down
as our social goals (the codified form), and what we expect to meet them.
It happens. But it's also something that we need to address, or we're going
to end up in a very untenable position.
As for the social contract... it might be an oversight, but I think, as I
noted above, that it's a question, really, of what 'Free' means in this
context - and whether 'Free' as we apply it to code is really the right
definition to apply to something which isn't code; I would call it 'speech'
except that that could cause confusion with the traditional concepts that
come to mind when anyone in the US says 'free speech'.
> > I know we don't like 'patches only' software, but we *do* allow it - and
> > the basic assumption of most documentation is that it lives in a world in
> > which various forms of 'patching' are the *normal* method. I'm all for us
> > saying 'please try to minimize invariant sections', possibly even 'these
> > types of sections cannot be invariant to qualify for the DFDG', but if we
> > want to apply a standard to which the rest of the world will never allow
> > itself to be held to, we're going to take RMS's place as the zealots whom
> > large numbers of people ignore.
> I'm intrigued by this idea, and think it does indeed have a lot of
> merit. Documentation, after all, is akin to source code in the sense
> that both are intended as human-readable content, not as obscure
> instructions to be delivered directly to a computer. If we allow an
> author to place restrictions on how we can modify some kinds of source
> code while still considering the code free, why should the same not be
> allowed for other types of source code, like documentation?
Exactly - though the 'mapping' isn't precise, it seemed like a worthy
place to start. I can think of at least 3 commonly used methods of "make
a new document while preserving the old" (annotation, commentary, and
bibliographical reference). I wonder if perhaps someone who has more
familiarity with publishing "open" standards documents, white papers, and
the like could weigh in on what the community standard for "freedom" in
such things really means, and how that might map to what Debian now expects
of software to meet the DFSG.
I'll also note that, having read over the discussion on Debian-Legal, I
fail to see why we couldn't accept the GFDL as intended by the FSF, and
just file a bug against any package which disobeyed the intent of the
license as being non-free, just like we can do if an author mistakenly uses
code which can't be under the GPL or linked to it, and uses a GPL license.
[ Yes, this also goes well beyond the GFDL, but that is the most clear
example that comes to hand easily. ]
Joel Baker System Administrator - lightbearer.com
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org