On Tue, Jul 23, 2013 at 11:30 AM, Ben Finney <
ben+freesoftw...@benfinney.id.au> wrote:

> Ben Finney <ben+freesoftw...@benfinney.id.au>
> writes:
>
>

> Rather, my point is that these categories are not exclusive. Works
> commonly inhabit several of these categories simultaneously, and it's
> clearly false to say that no document is a program, or vice versa.
>
Glad this point has been cleared between us, so that we don't waste more
time in on the specific details of "what HTML or an XSLT script or a
LISP<http://xkcd.com/297/>program is"


>
> From that it follows that it's unjust to deny the freedoms that accrue
> for functional use of a work, merely because the copyright holder
> doesn't think it has functional use.
>
My argument is: "since one cannot make a clear distinction between <it's a
program> or <it's just data>", then "what the computer does to
render/obtain the desired result" should NOT be a criterion in judging the
copyrights (or, for the matter at hand, copylefts - still based on
copyright laws), or at the very least *should not be the sole or even the
main criterion in balancing the rights of the copyright holder and the
rights of the consumer*.

(mind you: to make the thing seven more interesting, the "copyright holder"
and the "consumer" aren't the only parts of the issue. Have a look
over the "author's
rights"<http://en.wikipedia.org/wiki/Authors'_rights#Distinction_between_common_law_copyright_and_civil_law_authors.E2.80.99_rights>and
tell me what you think Mark Twain would have the right to say and be
listened/obeyed about the
"sanitization"<http://morallowground.com/2011/01/04/nigger-removed-223-times-from-new-edition-of-mark-twain-classics/>of
HuckFinn)


>
> But even if the categories were exclusive, so what? Yes, there are some
> works which are clearly not programs *now*. Why deny a recipient the
> freedom to derive a program from a non-program?

On what basis should the
> copyright holder wield their power to declare that such-and-such work
> can never have a functional purpose in any derived form, and thus no
> recipient deserves the freedoms accruing to functional purposes?
>
*But nobody can interdict this. Copyright protects just the form of
expression, everything goes as long as you don't try to distribute another *
*form of expression** too close to the original!* (and, mind you, the
format of expression is not the same as the form of expression).
Examples:
1. ask Oracle how well it went for it when trying to enforce copyright laws
over the Java API?
2. When younger, I took the "RTF streams" containing the "Motif Widget API
specification" and "derived" a  set of C++ headers to "wrap the widgets" in
a form of expression I needed at that time - it is still entirely legal
even today.
3. there are a number of (OSS no less) ports of some vintage games which
implement the whole game logic but are not playable without the artwork of
the original game... if, as a consumer, you have those artworks, the game
play is almost indistinguishable from the original.

While the above are very clear-cut examples, I argue *that especially in
the digital world* nobody can stop anyone to derive* a new piece of
documentation* from an already existing one. Letting aside the obvious case
of "just write another book about how the program works" (one of many
examples here <http://oreilly.com/perl/>), there are other ways that allows
the "consumers" to benefit from derived works without breaking any law.
Here's an example: the "deriver" publishes her modifications as "a diff
over a certain edition/format of the original" together with a "script"
that warns the consumer about "you are about to modify an original work.
You can consume the derived work by yourself, but by doing so you *don't
get additional rights to distribute* the results of the conversion".

   1. the "copyright holder" of the original work cannot (or should not be
   able to) stop the "deriver" to publish her/his own work. It is a different
   form of expression all together (an exception to this is the DCMA-like
   laws. Fortunately, there are many jurisdictions in which DCMA-like laws do
   not apply, are prohibited to be applied against the "end user" or even
   against 
competition<http://www.bloomberg.com/news/2012-05-02/copyright-can-t-block-software-reverse-engineering-court.html>
Even
   so, we were discussing in a context in which DCMA is a moot point, isn't
   it?)
   2. the copyright holder cannot stop the consumer to do what he pleases
   with her/his own copy of the original work (as long as it is not
   distributed further outside the original license)

In the "physical world", the above is absolutely equivalent with the
"deriver" saying "Here's my set of margin/foot/endnotes and errata to the X
edition of the Y book published by Z. I give it to you as a set of
transparent masks for you to apply over the original pages, they'll black
out the modified text and replace it with mine, either in-place or as
margin notes with the page space is a constraint".
The only difference in the digital world: the graphical space is no longer
a constraint, the "derivation" (patching) can be applied directly. Except
for the means to do it, the two operations are equivalent.



> With or withough exclusive purpose-based categories, it is unjust to
> deny the software freedoms to any recipient of any software work merely
> on the basis of how the copyright holder thinks the work should be used.
>

"Derived works" are not necessarily good (e.g. "better or more
appropriate/fit-to-purpose than the original work" or "more or less
restrictive against software freedom") - they are just derived works. For
instance, I don't agree with the above mentioned "sanitization" of
HuckFinn; as a "consumer", I'm glad that I have an old edition (as old as
1932 for that matter. Smells and feels gorgeous on touch - whatever you
say, for me nothing beats a printed book).
Now, if only the "copyright holder" is allowed to exist (and the author(s)
would have nothing to say), who protects my right as a consumer to access
the *original* *work of the author*? My point here: there's not clear-cut
when the "restrictions" are bad and when they are beneficial.

Given the fact that today is possible for other authors to produce derived *
expressions* significantly different from the original *without huge costs*,
my POV:
1. I* *don't see the ability of an author to specify restrictions on what
can be done with the documentation *as a serious attack to the openness of
the said documentation*.
2. the "is a program/is just data" criterion carries a low relevance in
assessing the *openness of software* and the *openness of a documentation*


Adrian
_______________________________________________
Free-software-melb mailing list
Free-software-melb@lists.softwarefreedom.com.au
http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb


Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/

Reply via email to