Re: New OPL Draft

[Branden Robinson <branden@ecn.purdue.edu>]

On Fri, Jan 28, 2000 at 10:11:41AM +0000, Terry Dawson wrote:
> Branden,
> You can count my vote as a "Please don't".
[...]
> I've never bought the argument that documentation is different from
> software because documentation is more an expression of artistic work
> than software. I don't believe this at all. To portray "games level
> design" as an artistic form and software development as not, I believe,
> is to denegrate software development as a form devoid of imagination,
> creativity and inspiration. Is not the application itself the artistic
> expression in the same way that it is the painting, not the brush
> strokes that are the art of the canvas world?

I think you are overly enamored of your own analogies, so much so that
you're asserting a slippery slope argument with a JATO engine strapped to
your back, but I'll take the "please don't" part under advisement.

Ultimately, any Debian Free Content Guidelines (or whatever) we come up
with, if we choose to do so, are going to have be based on fairly objective
critera.

Flowery language about artistic expression and brush strokes upon the
canvas is well and good, but these concepts are subjectively evaluated.  I
wonder if you read my earlier remarks in this thread, where I asserted that
one man's art is another man's recipe.  Nowhere did I assert or imply that
programs cannot be works of art.  My premise is: qualification as art is
*irrelevant* when it comes to the license evaluation process of the (for
want of a better word) consumer of a work.  For the author, considerations
of art are likely to be paramount in guiding his or her selection of an
appropriate license.  Perhaps I did not make this point sufficiently clear.

Any DFCL enterprise is necessarily going to have to restrict itself from
making assertions about "artistic" versus "technical" intent, just as the
existing DFSG does.

What I propose boils down to this:

Is it a candidate for main/contrib/non-free?  If so, apply the DFSG.

Is it a candidate for data?  If so, apply the DFCG.

Our archive layout will not allow a package to into both, say, main and
data, so your aggravted relatvistic concerns about "what's non-executable
data and what isn't" have already been addressed by an accepted amendment
to policy.  So I suggest you refocus that aspect of your grief upon milk
that has already been spilt.  You may read
<http://www.debian.org/Bugs/db/38/38902.html> to see how the machete of
practicality has already been taken to your garden of subjectivity.

We decide first if a package is bound for data or not, before we worry
about its license.  What I suggest is that we may permit VPL (Verbatim
Public License) works into data.  It's far too early for me to crusade for
this; my mind isn't made up.  First I want to see if Open Content's
attempt at license revision bears worthwhile fruit.  Perhaps we will
want to confine the data section to freely modifiable works (a la RMS's
draft license).

The important issue is: with the introduction of the data section, which
won't contain software per se, we need a companion document to the DFSG
that will determine what is acceptable for admission into that section and
what is not.

Finally, I think you need to reflect on why we consider the freedom of the
user to modify and redistribute software our core principle.  Is it so we
can realize some collectivist utopia of artistic collaboration?  No.  It's
because we want computer systems that work as we desire.

-- 
G. Branden Robinson            |
Debian GNU/Linux               |     Please do not look directly into laser
branden@ecn.purdue.edu         |     with remaining eye.
roger.ecn.purdue.edu/~branden/ |

PGP signature