documentation

[Matthew C. Weigel]

On Thu, 30 Aug 2001, SamBC wrote:

> They still work as guidelines, which is after all all they are.

The OSD is a set of criteria for approving licenses.  It is not
guidelines, it is the set of hard and fast rules the community -
through Debian and then the OSI - has worked on to decide,
definitively, whether a piece of software is open source.

For documentation, it can serve as nothing more than a set of
guidelines.

> > For instance, would 4. Integrity of The Author's Source Code
> > (either one) mean that you could distribute modified PDFs of a
> > patch-only document (since PDF is definitely not the "form of
> > choice" for editing documents, and should probably qualify for
> > being a binary), but not TeX?  What about HTML - should it be
> > considered a "binary" form that you can distribute modified, or a
> > "source" form that you can restrict to patches-only?
>
> I guess so - after all, TeX is not a viewing-friendly format.

So, by this logic, were Greg to have an "open" PDF under the terms he
wanted, then a) there would have to be a source form, and b) people
could distribute derivative PDFs, and pristine "source" + patches.

If he were to distribute a Word document, would it be binary or source?
If it's binary, what *is* the source on which he can require pristine
source + patches?  If it's source form, what is the binary form which
people can distribute modified versions of?

As with programs, it is imperative to the utility of open source that
*usable* derivative works be distributed.

The OSD and FSG are *inappropriate* for documentation.

> Things like HTML make life more difficult, and would have to be a
> per-license matter, with each document having a specific 'source
> form' - in something like TeX or SGML.

No, this is an issue that needs to be addressed in general.  We could
pull back to man pages, and nroff source, which most man programs now
format on the fly.  You have to be able to distribute derivative works,
ready to use, just like with programs.  If there *is* a source format,
then it can have a restriction to patches, but a) there must be a
binary format, b) it must be the most useful format for viewing, and c)
the distribution of modified works in that format can not be
restricted.

So, if the assumption of the presence of a source form were eliminated,
I can see the OSD being "good enough."

Once again, without additional consideration, the OSD is *not* good
enough for this purpose.

> > Yes.  If we started with the assumption that "printout" was the
> > final output, akin to binary executables, they would be fine -
> > you'd download the source in, for example, TeX, apply the patches
> > included with your version of the software, and print it out.  But,
> > most documentation is now viewed online, in 'raw' formats like HTML
> > or nroff.  What's more, you have - between HTML, man2html.cgi, and
> > PDF plugins - the ability and motivation to distribute modified
> > documents willy nilly.
>
> Or apply the patches and then render into a more widely viewable format.

On your computer.  My web server can't do it for you.  And that's the
problem.

> These questions have many possible answers usually applicable to a
> smaller range of cases

But these are the questions that the OSD *does not address*, that are
very important for documents.

> > There's a slim chance someone in the OSI is reading this, or your
> > responses to it (at least the new webmaster hasn't killfiled me).
> > Perhaps someone can explain why it *hasn't* been approved?  Shouldn't
> > it be a priority, so that the much-respected W3C can get a spot on
> > sourceforge.net?
>
> They haven't listened yet... I hold out little hope.

Russ once accused me of never talking to the OSI, because I didn't send
anything to osi at opensource.org, so I will send a message to that
address (Cc'ed here, so that hopefully they'll respond publicly as they
should) so that they can understand that they are DOING SOMETHING WRONG
by neither approving the W3C license nor addressing any shortcomings
they might perceive.

The last time this was a problem, they were DOING SOMETHING WRONG by
deciding to not approve the APSL without any sort of public notice.
-- 
 Matthew Weigel
 Research Systems Programmer
 mcweigel at cs.cmu.edu ne weigel at pitt.edu

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3