|
|
| Why Program Code Isn't the Same as a Novel, by k12linux |
 |
|
Friday, July 16 2004 @ 01:04 PM EDT
|
Groklaw member k12linux has written what I found a very helpful explanation of why program code isn't the same as a novel. For those of us who are not programmers, it spells it out so clearly, I believe you will find it useful to understand the differences. You can extrapolate from the essay that code probably could use more carefully refined rules regarding copyright infringement, tailored to the realities of code.
**********************************************************
An Example of Why Program Code Isn't the Same as a Novel
by k12linux
Since Groklaw focuses mostly on legal aspects, lets set our example in a
courtroom. (Imagine a Matlock-style courtroom.) A man sits in the witness chair
to the judge's left side and on the opposite end of the room (behind rows of
spectators) is the exit. Our goal today is to get the witness out the door.
A novel's author may have the man leap out of the stand, grab the balif's gun,
take a prosecuting attorney hostage and back around the left side of the
spectator seating, around the back and then bolt out the door. Or, he might
exit normally. Or maybe he'll be dragged out. All of these options are not
only possible, but are in fact likely depending on the story. There are also an
infinate number of other variations and details an author could include.
Now lets look at a "program" to get the man out. Our program is
nothing but a set of instructions needed to reach our goal. But wait. First
everyone needs to realize that there are a few constraints. First, the guy on
the witness stand isn't terribly bright. In fact, he is pretty dumb and will do
EXACTLY what he is told to do.
Since we are only giving instructions and since that is all he really
understands, descriptive commentary isn't all that useful. Oh yeah, one more
thing. You have to write all the instructions down and hand them to our witness
before he starts moving. (No coaching as he goes... once started he won't pay
attention to anything but the piece of paper with the commands on it.)
So, lets begin giving our guy orders: Stand up. Turn 90 degrees to your left.
Walk forward 2 feet. Ooops.. he just fell on his face because we didn't say to
walk down the step from the stand. Ok, starting over. Stand, left 90 degrees,
step down, walk forward 1 foot. Turn right 90 degrees. Walk forward 3 feet.
Turn right 90 degrees. Walk forward 30 feet. Dang.. he just fell out the
window on the judges right. Better be more careful with our distances.
Ok, again. Up, left 90, down 1, forward 1, right 90, forward 3, right 90,
forward 10, left 90, forward 40, open door, forward 2, right 180, close door.
Done! Now we have a working "program."
Now how would another "programmer" do this job? If there are any
differences, it would be minimal. Maybe he'd turn left 180 near the end instead
of right, or maybe he wouldn't close the door. Is our programmer going to have
the guy jump up and take the bailif's gun then take a hostage? Not too darn
likely.
First of all, it doesn't help accomplish our goal of getting him out of the room
in the least. Second, it would be a lot more work. And I mean a LOT more. The
programmer doesn't have control of the bailif OR the hostage so now instructions
have to include telling our guy what to watch for (does the bailif dodge right?
Left? Back up?) and how to react to every action by the bailif and the hostage.
Would we have our witness go around the spectator seating area? First off it
would just slow us from reaching our goal and again, we would have to do more
work. More turns, more correct distances, checks for obstacles like breifcases,
etc. So again, not likely.
The result is that all "programs" written to get our witness from the
stand to the door and out are probably going to be very similar if not
identical. The goals of the programmer and the constraints he has to work by
dictate this. He/she does not have the same virtually infinate options as our
novel author. The author isn't even constrained by reality. In a book the
witness might teleport or become invisible.
And THIS is why patents on procedures are so dangerous. If you are the first to
patent and publish a procedure for "efficient egress of a witness from
stand via primary public portal" you've just blocked out the rest of the
world. This would be even though there might be hundreds of identical
"programs" used in other courtrooms around the world.
Lets compare this to the GPL way of doing things. I realize that other people
might want to use my program, so I name it WitnessEgress() and give the source
code out. Now nobody writing "courtroom procedures" software ever has
to write that stupid little program again.
Even better, they can improve on it. They could add checks for the number of
steps on the stand, it's location, tests for the best route to the exit. They
could add checks for someone thoughtlessly leaving their briefcase in the main
walkway and instructions to the witness how to deal with the situation.
In the end, I can take the vastly improved WitnessEgress() program and use it
myself. Not only don't I have to modify it anymore for every little change in
the room, I also didn't have to do all of that programming work myself. This is
why releasing programs as GPL isn't always as selfless of an act as it may seem.
Regardless of the reason, however, everybody benefits.
|
|
|
|
| Authored by: Anonymous on Friday, July 16 2004 @ 01:20 PM EDT |
| [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 01:21 PM EDT |
| [ Reply to This | # ]
|
- Turtle Graphics - Authored by: akStan on Friday, July 16 2004 @ 01:26 PM EDT
- Turtle Graphics - Authored by: Anonymous on Friday, July 16 2004 @ 01:30 PM EDT
- OT Open Source Paradigm shift - Authored by: airmech on Friday, July 16 2004 @ 02:02 PM EDT
- Microsoft links - from www.silicon.com - Authored by: rharvey46 on Friday, July 16 2004 @ 05:01 PM EDT
- Dilbert scores again! - Authored by: Anonymous on Friday, July 16 2004 @ 05:37 PM EDT
- SCO tackling ELF - hasn't this been discussed before? - Authored by: ankylosaurus on Friday, July 16 2004 @ 05:39 PM EDT
- SCO Holds its Own in AutoZone Suit - per Maureen O'Gara - Authored by: ankylosaurus on Friday, July 16 2004 @ 05:46 PM EDT
- Newsforge article on the supposed "failings" of the GPL - Authored by: noli on Friday, July 16 2004 @ 06:34 PM EDT
- MS patent war confirmed by HP - Authored by: Anonymous on Friday, July 16 2004 @ 07:48 PM EDT
- Slashdot Groklawed? - Authored by: rand on Friday, July 16 2004 @ 10:04 PM EDT
- Patents link - Authored by: bbaston on Saturday, July 17 2004 @ 12:48 AM EDT
| |
| Authored by: pooky on Friday, July 16 2004 @ 01:44 PM EDT |
Well illustrated! As a pseudo-programmer (I mainly write automation scripts for
tasks on Windows PCs) I know there's only so many ways to perform tasks on a
system, and when people go through similar training in school to use the same
languages on the same types of systems and OSs in the real world, people tend to
do things the same way. Sure, some programmers shine because they actually
comment their work or they write crypto-perl which is hard for non-experts to
decipher, but the meat of the programs they write to perform the same tasks on
systems are usually very similar if not identical.
This is where the theory behind non-literal copying breaks down. Non-literal
copying means the result is substantially similar in methods and structure to
the original even though the code isn't *identical*. This will always be true
for functions that perform the same task (there's only so many ways to open a
file for reading from a hard disk for example). Two programmers who never met
each other, EVER, who constructed functions to do the same thing will end up
with code that is similar in methods and structure. By SCO's theory, whichever
of these two people wrote their function last can be guilty of copyright
infringement if he/she ever had access (not looked at or used) to the others
work, say, on Sourceforge.
---
Veni, vidi, velcro.
"I came, I saw, I stuck around."
[ Reply to This | # ]
|
- similar function - Authored by: Yobgod on Friday, July 16 2004 @ 01:54 PM EDT
- similar function - Authored by: Anonymous on Saturday, July 17 2004 @ 01:29 AM EDT
- Why Program Code Is THE SAME as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 03:31 PM EDT
- Why Program Code IS the Same as a Novel, by k12linux - Authored by: cbc on Friday, July 16 2004 @ 03:36 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 05:03 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: chriseyre2000 on Saturday, July 17 2004 @ 04:10 AM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Sunday, July 18 2004 @ 07:55 PM EDT
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 01:50 PM EDT |
| Can we send this to the judge as a "friend of the court" brief? [ Reply to This | # ]
|
| |
| Authored by: DaveAtFraud on Friday, July 16 2004 @ 02:00 PM EDT |
| First,
have a good laugh and enjoy a "classic" programming joke. This joke has
been around for a while and there are a number of variations but it now nicely
illustrates a very applicable point.
The basis for the joke is that every
single one of the programs has exactly the same external behavior. They
all print the words, "Hello World" and then exit. Obviously, they are not
copies of each other since each implementation is in a different programming
language or for a different operating system, etc. This quite nicely
illustrates the fact that the external behavior of a program offers no
indication whatsoever as to whether it is a copy of another program.
So what's my point? First, several people could each implement
"WitnessEgress()" in any of several different ways, each with the same observed
external results and still not be copying each other. Second, if the programs
had been created by different authors, which one gets the patent and do the
other implementations infringe that patent?
---
Quietly implementing
RFC 1925 wherever I go. [ Reply to This | # ]
|
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 02:14 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: dopple on Friday, July 16 2004 @ 02:34 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: dopple on Friday, July 16 2004 @ 02:40 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 02:44 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 02:48 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: oldgreybeard on Friday, July 16 2004 @ 02:49 PM EDT
- Hello, world programs - Authored by: Anonymous on Friday, July 16 2004 @ 02:59 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: k12linux on Friday, July 16 2004 @ 02:59 PM EDT
- Google cache - Authored by: Anonymous on Friday, July 16 2004 @ 03:03 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 03:57 PM EDT
- Some good s/w humor - Authored by: ray08 on Friday, July 16 2004 @ 04:32 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Einhverfr on Friday, July 16 2004 @ 04:44 PM EDT
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:03 PM EDT |
#define/**/X
char*d="X0[!4cM,!"
"4cK`*!4cJc(!4cHg&!4c$j"
"8f'!&~]
9e)!'|:d+!)rAc-!*m*"
":d/!4c(b4e0!1r2e2!/t0e4!-y-c6!"
"+|,c6!)f$b(h*c6!
(d'b(i)d5!(b*a'`&c"
")c5!'b+`&b'c)c4!&b-_$c'd*c3!&a.h'd+"
"d1!%a/g'e+e0!%b-g(d.d/!&c*h'd1d-!(d%g)"
"d4d+!*l,d7d)!,h-d;c'!.b0c>d%!A`Dc$![7)35E"
"!'1cA,,!2kE`*!-s@d(!
(k(f//g&!)f.e5'f(!+a+)"
"f%2g*!?f5f,!=f-*e/!<d6e1!9e0'f3!6f)-g5!4d*b"
"+e6!0f%k)d7!+~^'c7!)z/d-+!'n%a0
(d5!%c1a+/d4"
"!2)c9e2!9b;e1!8b>e/!
7cAd-!5fAe+!7fBe(!"
"8hBd&!:iAd$![7S,Q0!1
bF
7!1b?'_6!1c,8b4"
"!2b*a,*d3!2n4f2!${4
f.
'!%y4e5!&f%"
"d-^-d7!4c+b)d9!4c-a 'd
:!/i('`&d"
";!+l'a+d<!)l*b(d=!' m-
a &d>!&d'"
"`0_&c?!$dAc@!$cBc@!$ b
< ^&d$`"
":!$d9_&l++^$!%f3a' n1
_
$ !&"
"f/c(o/_%!(f+c)q*c
%!
* f
&d+"
"f$s&!-n,d)n(!0i- c-
k) !
3d"
"/b0h*!H`7a,![7* i]
5
4
71"
"[=ohr&o*t*q*`*d
*v
*r ;
02"
"7*~=h./}tcrsth &t
:
r
9b"
"].,b-725-.t--// #r
[ <
t8-"
"752793?
<.~;b ].t--+r
/
#
53"
"7-r[/9~X .v90
<6/<.v;-52/={
k
goh"
"./}q; u vto hr
`.i*$engt$
$
,b"
";$/ =t ;v; 6
=`it.`;7=` :
,b-"
"725 = / o`. .d
;b]`--[/+
55/
}o"
"`.d : - ?5
/
}o`.' v/i]q
- "
"-[; 5 2 =` it
.
o;53-
. "
"v96 <7 / =o
:
d =o"
"--/i ]q--
[;
h.
/ = "
"i]q--[ ;v
9h
./
< - "
"52={cj
u c&`
i t
. o ; "
"?4=o:d=
o--
/ i
]q - "
"-[;54={
cj uc&
i]q
- -"
"[;76=i]q[;6 =vsr
u.i
/
={"
"=),BihY_gha ,)
"
,
o [
3217];int i, r,w,f
,
b
,x ,
p;n(){return r <X
X
X X X
768?d[X(143+ X r++
+
*d ) %
768]:r>2659 ? 59:
(
x = d
[(r++-768)% X 947
+
768]
) ?
x^(p?6:0):(p = 34
X
X
X )
;}s(){for(x= n ();
(
x^
( p
?6:0))==32;x=
n ()
) ;return x
; }
void/**/main X ()
{ r
= p
=0;w=sprintf (X X
X X X
X o
,"char*d="); for
( f=1;f <
*
d
+143;)if(33-( b=d
[
f++ X
] )
){if(b<93){if X(!
p
)
o
[w++]=34;for X(i
=
35
+
(p?0:1);i<b; i++
)
o
[w++]=s();o[ w++
]
=p?s():34;}
else
X
{for(i=92; i<b;
i
++)o[w++]= 32;}
}
else o
[w++ ]
=10;o
[
w]=0
;
puts(o);}
--
dhyang.c, 15th International Obfuscated C Code Contest
[ Reply to This | # ]
|
| |
| Authored by: webster on Friday, July 16 2004 @ 02:08 PM EDT |
Great. This or something very much like it in the courtroom is sure to be
utilized at trial by one of the experts.
---
webster[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:19 PM EDT |
| Lots of OS code deals with hardware specific tasks. Generally there's only a
few ways to accomplish a hardware task. There will be tons of similarity if
structure, methods, etc in code for that. If anything, most OSes probably steal
code from Intel's documentation, and certainly any OS code will look very much
like Intel's sample code because that's the only way to do
something.
Multitasking and multiprocessor OSes also have to deal with many
non-hardware issues which are common to all OSes, such as locking. There are
only so many ways to implement locks/semaphors/etc so that one processor won't
access data that's being updated by another processor or process and cause the
system to crash.
Then, as has been stated here frequently, many OSes choose
to adhere to POSIX standards. A standard says that there is a function named
foo() which takes a, b, and c as arguments, and does x, y, and z. It's clear
cut what these functions must do, and there aren't that many ways of
accomplishing those tasks in an efficient manner. Sure, there are a million
ways of doing it inefficiently... Anyone who noodles it through enough will
probably come up with the "same" solution others have.
Implementing a
standard is a bit like answering the question "how do I get to the courthouse
from here?". You'll probably give directions which are very similar to what
someone else would give. Maybe a landmark or two will be different -- maybe.
Does similarity here count as stealing a riff? It can't possibly, unless
the law intends for only allowing one person to implement a standard. [ Reply to This | # ]
|
- OS Code - Authored by: Anonymous on Saturday, July 17 2004 @ 01:05 AM EDT
- OS Code - Authored by: AJWM on Sunday, July 18 2004 @ 04:42 AM EDT
- OS Code - Authored by: MadScientist on Sunday, July 18 2004 @ 11:29 AM EDT
| |
| Authored by: Neil Wehneman on Friday, July 16 2004 @ 02:23 PM EDT |
PJ and k12linux,
What are the distribution rights on this piece? I may wish to reproduce / use
it in the future, and want to ensure that I don't infringe your copyright while
advocating reform of the same.
- Neil Wehneman
---
IANAL. But I hope to be one in a few years, focusing on copyrights, patents,
and the intersection of technology and law.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:24 PM EDT |
Programmed code, Novels, Music, whatever; copyright, initially intended to
support and help individuals should be there AS LONG it is submitted within 2
principles:
- Principle 1: society in General and its interests mustn’t be affected anyhow;
- Principle 2: Predicament of Freedom of speech through prohibitions amongst
DRM;
1) Where would science be, if all scientists would copyright or patent their
formula, inventions, calculations and publishing?
2) Unknown musicians benefit of free copying of their music, to make a name.
Sure copying is illegal and established artists /writers receive less income,
but on the other hand they got their fame because other knew or heart about
them.
3) Nothing gets created in a vacuum, so true innovation is a rare concept
indeed, since we all benefit from prior ideas, experiences. This implies music,
writings, coding etc and raises the valid question of what we truly can
copyright as being ‘self invented’.
4) How has final authority to proclaim a painting, music or program code to be
characterized as copyrightable art, and not some profound effective marketing
idea from a sales-manager to improve corporate performances? Why not copyright
that too.
I am not afraid of Microsoft throwing their patents on open sourced project,
since this would affect Principle 1, and lies beyond the purpose of the patent
system, and therefore yields to its fundament.
[ Reply to This | # ]
|
- IP again - Authored by: Einhverfr on Friday, July 16 2004 @ 04:53 PM EDT
- IP again - Authored by: Anonymous on Friday, July 16 2004 @ 05:00 PM EDT
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:28 PM EDT |
First off: Some proofreading would've helped this a lot.
Second: A programmer is not very limited in the ways he can solve a given
problem. The difference against a fiction writer is not that he is more limited,
it is that he has a different sense of of esthetics. Programmers, as well as
engineers in general have a common sense of esthetics, e.g. what constitutes a
'good' solution to a problem.
Some of the things which are considered 'good' is making the solution as simple
as possible, easily understandable, robust (i.e. not easily prone to
malfunction), extendable, and so on. Most programmers will agree on what a
well-written program is, despite small individual variations.
Fiction writers do NOT have a common sense of esthetics. What Stephen King
considers 'good' writing is not what Shakespeare would've considered 'good', and
neither would be in the taste of James Joyce.
The difference between computer code and fiction does not have anything to do
with the nature of computer code, it has everything to do with the nature of
programmers.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:29 PM EDT |
Lets compare this to the GPL way of doing things. I realize that other
people
might want to use my program, so I name it WitnessEgress() and give the
source
code out. Now nobody writing "courtroom procedures" software ever has
to
write that stupid little program again.
This is not quite true.
This code can only be used in software that is not for resale. For that you need
LGPL or Apache.
[ Reply to This | # ]
|
| |
| Authored by: rountree on Friday, July 16 2004 @ 02:30 PM EDT |
<q>Now how would another "programmer" do this job? If
there are any differences, it would be minimal.</q>
I'm afraid I don't agree.
1. If you gave this problem to a programming language
class, you'd get back a different answer from each
student. Any substantial similarity would be taken as
evidence of cheating. Even accounting for comments and
variable names, the underlying structure of the solutions
tend to be very, very different. And likewise, giving a
creative writing class the task of getting the witness out
of the courtroom in 100 words will produce no identical
solutions.
2. The example of "finding the shortest path" is a good
example of the non-uniquenes of software. Sure, the path
to take is obvious (and let's grant the efficient path is
unique), but how do you do error checking? How are the
other "objects" accessed in order to ascertain their
position, velocity, whatever? And what do you do if there
is an error? The best answers aren't nearly so obvious
here, and there are a large number of adaquate ones to
pick from. People will choose differently based on
experience, knowledge, and (apparently) darned cussedness.
3. Style in programming is just as evident as style in
literature. This isn't as noticable in collaborative
programming, but it's really, really evident when you
starting looking at code that's been lovingly crafted by
exactly one person. They have their set of quirks (which
are /plainly/ inferior to your set of quirks) and trying
to read it can be as unsettling as reading Pynchon or
Joyce for the first time.
Code is closer to literature than you might think. How
this should apply to copyright is a question I'll leave to
wiser heads than my own.
Best,
Barry
[ Reply to This | # ]
|
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 02:43 PM EDT
- I don't agree - examples - Authored by: Anonymous on Friday, July 16 2004 @ 03:06 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: blacklight on Friday, July 16 2004 @ 03:30 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 03:39 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Friday, July 16 2004 @ 03:41 PM EDT
- Hogwash - Authored by: pooky on Friday, July 16 2004 @ 04:00 PM EDT
- Hogwash - Authored by: rountree on Friday, July 16 2004 @ 05:37 PM EDT
- Hogwash - Authored by: Anonymous on Friday, July 16 2004 @ 09:49 PM EDT
- Hogwash - Authored by: Anonymous on Saturday, July 17 2004 @ 06:32 PM EDT
- Why Program Code Isn't the Same as a Novel, by k12linux - Authored by: Anonymous on Saturday, July 17 2004 @ 10:52 PM EDT
| |
| Authored by: RealProgrammer on Friday, July 16 2004 @ 02:36 PM EDT |
| The courtroom metaphor is very good, but it has some holes I'd like to
address.
There are lots of different ways to express the same idea in a
computer program. For instance (and my apologies to non-programmers), I can use
recursion or iteration; I can use procedures or objects. The resulting binary
may not be much different, and it may not act much differently, but the source
code I use to express the ideas will be very different depending on those
choices.
It's a very weak argument to say that the machine has no
decision-making ability. Even if that is true today, it probably won't be true
at some point in the future and it's best to build our legal system with that in
mind. I see an analog with training a dog: you program the computer not to bite
the neighbor, but he might do just that.
However, there are other
differences between literary works and program code.
-
A novel, once
written, need not be altered, ever. All programs, on the other hand, need to be
altered, upgraded, bug-fixed, and maintained.
-
A novel is interpreted
by the individual; it is a set of instructions for the brain of a human. A
computer program is interpreted by a machine, and by all machines in basically
the same way.
-
A novel's source code is right there for public viewing.
To try to say I can't write a program that acts the same as a copyrighted,
closed-source one is like saying I can't write a novel that acts like yours when
I'm not even able to read yours.
---
(I'm not a lawyer, but I
know right from wrong) [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 02:44 PM EDT |
This is an oversimplification. OK, in some circumstances the simplest, most
obvious algorithm may also be the best, but this is not always the case. If you
come up with a new, clever, algorithm for doing a task, then found someone
else's code using the same algorithm, you would have good grounds for suspecting
they copied your method. I agree this is beyond the scope of copyright, but I
don't see why it should not be covered by a patent, any more than if you
invented a new, clever, process for putting toothpaste in tubes.
Don't forget that patents are only supposed to be granted if they are
non-obvious (even if the patent system is struggling to apply this rule).
Martin[ Reply to This | # ]
|
| |
| Authored by: nylarthotep on Friday, July 16 2004 @ 02:47 PM EDT |
Article 970 of comp.lang.perl:
Path: jpl-devvax!pl-dexxav!lwall
From: lwall@jpl-dexxav.JPL.NASA.GOV (Larry Wall)
Newsgroups: news.groups,rec.arts.poems,comp.lang.perl
Subject: CALL FOR DISCUSSION: comp.lang.perl.poems
Message-ID: <0401@jpl-devvax.JPL.NASA.GOV>
Date: 1 Apr 90 00:00:00 GMT
Reply-To: lwall@jpl-devvax.JPL.NSAS.GOV (Larry Wall)
Organization: Jet Prepulsion Laboratory, Pasadena, CA
Lines: 61
It has come to my attention that there is a crying need for a place for people
to express both their emotional
and technical natures simultaneously. Several people have sent me some items
which don't fit into any
newsgroup. Perhaps it's because I recently posted to both comp.lang.perl and to
rec.arts.poems, but people
seem to be writing poems in Perl, and they're asking me where they should post
them. Here is a sampling:
From a graduate student (in finals week), the following haiku:
study, write, study,
do review (each word) if time.
close book. sleep? what's that?
And someone writing from Fort Lauderdale writes:
sleep, close together,
sort of sin each spring & wait;
50% die
A person who wishes to remain anonymous wrote the following example of
"Black Perl". (The Pearl poet
would have been shocked, no doubt.)
BEFOREHAND: close door, each window & exit; wait until time.
open spellbook, study, read (scan, select, tell us);
write it, print the hex while each watches,
reverse its length, write again;
kill spiders, pop them, chop, split, kill them.
unlink arms, shift, wait & listen (listening, wait),
sort the flock (then, warn the "goats" & kill the
"sheep");
kill them, dump qualms, shift moralities,
values aside, each one;
die sheep! die to reverse the system
you accept (reject, respect);
next step,
kill the next sacrifice, each sacrifice,
wait, redo ritual until "all the spirits are pleased";
do it ("as they say").
do it(*everyone***must***participate***in***forbidden**s*e*x*).
return last victim; package body;
exit crypt (time, times & "half a time") & close it,
select (quickly) & warn your next victim;
AFTERWORDS: tell nobody.
wait, wait until time;
wait until next year, next decade;
sleep, sleep, die yourself,
die at last
I tried that, and it actually parses in Perl. It doesn't appear to do anything
useful, however. I think I'm glad,
actually... I hereby propose the creation of comp.lang.perl.poems as a place for
such items, so we don't clutter
the perl or poems newsgroups with things that may be of interest to neither. Or,
alternately, we should
create rec.arts.poems.perl for items such as those above which merely parse, and
don't do anything useful.
(There is precedent in rec.arts.poems, after all.) Then also create
comp.lang.perl.poems for poems that
actually do something, such as this haiku of my own:
print STDOUT q
Just another Perl hacker,
unless $spring
Larry Wall lwall@jpl-devvax.jpl.nasa.gov[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 03:03 PM EDT |
Your program description is way too simple for the real world for starters. More
complex systems have many more variations.
But still, you could...
1. Create a generic program that can take any sequence of paths.
2. Automatically check door/blocks and finds path out.
3. Store in static. Or in database. Or according to commands on 'input' line.
4. Write goal seeking algorithm that tries "find exit" and ask and
re-evaluates repeatedly.
That's off the top of my head.
The variations once you've started just keep multiplying.
And yes, the most innovative, eloquent, and effective solution is *creative* and
takes real work to produce.
If you don't know this, you haven't programmed at a high enough level yet.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 03:21 PM EDT |
| What about interior designs? [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 03:25 PM EDT |
A number of people have posted why this argument isn't vaild to which I'd like
to add...
My biggest gripe with it is that the author put several constraints on the
programmer which were not present for the writer. Why does the programmer need
to have the witness leave OSPF style when the writer can have free reign? If
the writer were to be required to get the witeness out of the room as fast and
as effectiently as possible, how many variations of "the witness left the
room" do you really think you'd get?
Authors are constrained...By what style of book they are writing (western,
biography, hiaku, etc.), by the story so far (characters often have devolped
personalities and justified actuions much in the same way as programs have
functions and ), and by the current intent (e.g. getting the witness off the
stand quickly and efficiently).
So I have to ask, according to this author, are authors who write biographies
(auto or others) creative?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 03:28 PM EDT |
| The article is comparing apples and oranges. Both novels and software are
protected by copyright. In this they are very similar. Two authors, working
independently, are not likely to generate an appearance of copyright violation
even if they are attempting to do exactly the same thing.
We should be
comparing software patents to physical, non-software patents. Suppose, for
example, that two inventors were asked to come up with a pratical way to quickly
remove a dangerous prisoner from a crowded court room in a safe and secure
manner. Depending on how tightly the parameters were set, they might come up
with very similar ideas. To that extent, software and non-software patents are
similar.
The justifications for software patents are the same as for
hardware patents. If people want to attack the idea of software patents, the
argument made in the original posting is a poor one. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 03:37 PM EDT |
k12linux's explanation is so bad that it's not even wrong.
Experienced programmers are unlikely to dispute the assertion that productivity
varies by (at least?) a factor of 100 from the best programmers to the worst
ones. Similarly, programs written by different programmers to solve "the
same" problem will, more often than not, vary in ways that astonish even
those well versed in the art.
Different programmers might come up with "substantially similar"
solutions (code) for incredibly constrained problems, but such problems are
vanishingly rare.
Good programmers should be excused for being as offended by k12linux's analogy
as "literary" authors would be offended by an assertion that they can
do no better than "See Jane run." :-)
[ Reply to This | # ]
|
| |
| Authored by: arrg on Friday, July 16 2004 @ 03:55 PM EDT |
I could have patented [Print "hello"] back when I was learning BASIC
in Junior High and then sued all my fellow classmates for infringing on my
code.....
---
Time is funny stuff, space has it's points too.... - Hap[ Reply to This | # ]
|
| |
| Authored by: Vaino Vaher on Friday, July 16 2004 @ 04:13 PM EDT |
Some of you are arguing about the implementation of the above.
If you try to see beyond, the author has a real point to make:
If the mere implementation of a good solution (to whatever the problem may be),
by a patent-like protection mechanism would bar all other developers from using
a sufficiently similar solution, then:
- Each new implementation would have to choose a new solution to the same
problem
- Each consecutive solution would likely be worse than the previous (because the
best solutions are already protected by the patent-like mechanism)
- Every additional solution had to be investigated for similarities with
existing solutions.
+ As you can understand this would eventually rule out the possability to find
yet another feasible solution to any given problem.
+ Almost all effort would be put into investigating existing solutions (in order
to avoid them).
I.e: it would be very hard to get anything done at all.
Consider the Unix/Linux case:
- Mainframes had multitasking support.
- Therefore VMS et al would need a different way (than mainframes) of
implementing task switching
- Unix would not be able to use any of the above methods for implementing task
switching.
- OS/2 had to invent an additional (and unique way) of solving the same
problem.
- Linux would have to look into all of the above in order to avoid
similarities.
Crux: The above are closed-source. It would not even be possible to know how the
predecesors had solved the problem. Therefore it would be impossible to avoid
unintentional similarities.
Solution: Write the code any way that you can, and wait for the first lawsuit.
Then re-implement it in a different way and see if someone else will sue you.
Etc ad nauseum.
A possible way for solving things in an Orwellian world, but not an efficient
one.[ Reply to This | # ]
|
| |
| Authored by: Einhverfr on Friday, July 16 2004 @ 04:42 PM EDT |
Would any patent on WitnessEgress have to contend with the fact any aspects of
it that any computer engineer could design when confronted with the problem and
which had no other solutions would be "obvious"?
Hence if I have the witness turn left, can I argue that the rest of it was
obvious? OTOH, a patent on a routine for taking the Baliff's gun might be
stronger ;-)[ Reply to This | # ]
|
| |
| Authored by: Tomas on Friday, July 16 2004 @ 05:27 PM EDT |
Yes, indeed!
There SHOULD, logically, be an incredible number of similarities in the
instruction sets given the constraints of hardware, standards, programming
language, inputs, and expected results. No copying required...
Not only that, but by HAVING to meet the device's requirements (or the
standard's requirements), and reading what they are, one already has in their
head a rough outline and time order of what must be done. The code output
initially might be very similar.
Add to that the fact that neither UNIX nor Linux were written in a vacuum.
Yes, some one individual may have initially written how to do some specific task
to meet the requirements (hardware or standards), but then many others have
added their thoughts and polished the rougher edges until a more logical and
efficient version emerges.
That those two would be very similar is not some sort of magic or copying given
the restraints of programming language, hardware, and standards.
Not only do many programmers come up with very similar results independently
because of external constraints, once everyone starts chipping away at any odd
parts sticking out, it is the same reason river rocks all tend to be
roundish...
I'm not a programmer, though I've written some "C" and a lot of shell
scripts. Mine and most others I've seen end up looking a whole lot alike once
they are trimmed down to an efficient set of instructions.
To someone even less a programmer than I, it might seem as though all of us were
looking over each other's shoulders and copying each other and just making minor
changes so it wouldn't look like direct copies. Instead, for good code, the most
elegant and efficient way to accomplish a specific result, given specifc inputs
and identical restraints, is likely to be quite similar with no copying
involved...
And speaking of drivers...
My wife and I took a series of very complex and involved actions to drive to
work (20 miles or so each way through dense commuter traffic).
For the same inputs, constraints, and results, our actions are so similar that
you might think one copied the other.
You'd be wrong.
We each had been driving for years before we met, yet each had developed an
almost identical "program" to accomplish the task...
---
Tom
Engineer (ret.)
"Friends don't let friends use Microsoft."[ Reply to This | # ]
|
| |
| Authored by: Chugiak on Friday, July 16 2004 @ 05:49 PM EDT |
Blame PJ for baiting the programmers! ;-)
There is lots of disagreement over minutiae, but the fact remains that when you
apply constraints to your problem, you reduce the possible variations for your
solution. From the many testimonials from former students you can deduce the
following: some solutions were 'substantially similar' and some weren't.
Assuming all similarities are not the result of cheating, why then are there
ever ANY similarities in computer code? The answer that is obvious to me is
because the solutions are constrained to some degree, limiting the choices
individuals have in crafting a solution. Add to that style considerations that
are common practice or imposed by certain standards and you will end up with
fewer and fewer ways of crafting a solution.
This isn't to say that there are not creative ways of solving problems within
the established constraints. But the existance of various constraints coupled
with the best practices of those employing the programming arts will result in
much code that while not identical can be construed as having similar structure,
sequence, or organization.[ Reply to This | # ]
|
- Exactly - Authored by: Anonymous on Friday, July 16 2004 @ 06:13 PM EDT
- Not just one reason - Authored by: Anonymous on Friday, July 16 2004 @ 06:27 PM EDT
- Forest v Trees - Authored by: Anonymous on Friday, July 16 2004 @ 08:50 PM EDT
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 06:34 PM EDT |
| Take a look at this! (newsforge.com) [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 06:49 PM EDT |
| Instead of WitnessEgress(), use Egress(Witness); it is more general. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 06:51 PM EDT |
Ok here's a different take on your "Only one way to do it" example.
Even ignoring the code hiding in physics.h, my code looks nothing like yours
even though it solves the same problem.
Admittedly, I'm using a more complex world model that you, but I'm making fewer
assumptions about the layout of the courtroom than you are. Heck, I even handle
running into the baliff or a lawyer in the MoveToObject function.
Strangely enough, my code is actually more descriptive of the escape process
than yours.
<code>
#include <physics.h> //handles gravity, collisions, etc.
global scene oScene;
void main()
{
// initialize scene
oScene= new scene(COURT_ROOM);
kinematic_object oWitness= new
kinematic_object(oScene.getObject("Witness"));
oWitness.sit(oScene.getObject("WitnessChair"));
// begin escape
oWitness.stand();
oWitness.speak("Oh, crap! I'm double parked!", VOLUME_SHOUT &
VOICE_EXCITED);
// hop over the front of the witness box
oWitness.jump(3.5, 2);
oWitness.speed = oWitness.MAXIMUM_SPEED;
MoveToObject(oWitness, oScene.getObject("Gate"));
oWitness.manipulateSceneObject("Gate", OPEN_OBJECT);
MoveToObject(oWitness, oScene.getObject("ExitDoor"));
oWitness.manipulateSceneObject("ExitDoor", OPEN_OBJECT);
oWitness.move(2);
oWitness.faceObject(oScene.getObject("ExitDoor"));
oWitness.manipulateSceneObject("ExitDoor", CLOSE_OBJECT);
}
function MoveToObject(kinematic_object oWitness, scene_object oObject)
{
bool bAtObject = FALSE;
while(!bAtObject)
{
oWitness.faceObject(oObject);
oWitness.move(.01+scene.getDistanceBetweenObjects(oWitness, object)); //
ensure a collsion event will happen
scene_object thing = oScene.collsion(oWitness);
if(oThing != null)
{
if(oThing == oObject)
{
bAtObject = TRUE;
}
else
{
oWitness.shoveObject(oThing, 2, 1, 0);
// uses X,Y,Z distances
}
}
}
}
</code>
[ Reply to This | # ]
|
| |
| Authored by: mole on Friday, July 16 2004 @ 07:06 PM EDT |
Lets try writing some code to implement witness_egress() as a set of written
instructions for a witness on a piece of paper...
As suggested by
k12linux, we could hard code a set of steps customized to a particular
courtroom:
Stand up, walk forward 3 feet, turn right 90 degrees,
walk forward 10 feet,...
We could elaborate on this with
instructions of what to do in the event the witness encounters and obstacle (the
equivalent of establishing an event listener). This set of instructions should
work well for a particular courtroom, and would be easily modified for a similar
family of courtrooms, it could be localized into alternate languages (including
braille) and still work. The difficulty would be in adding reliable code to
handle obstructions (such a briefcases).
Alternately, we could try the
old keep turning right to exit the maze algorithm:
Stand
up
Step forward until you reach the exit
(Step forward means:
Take one
step forward, if you can't then turn right 45 degrees and step
forward)
This code would be very inefficient for most
courtrooms, but it generalizes readily to most courtrooms (and other settings),
and localizes readily, including into braille. A subset of courtrooms would,
however, trap witnesses using this code into an infinite loop.
Alternatively, we could try a variant on the sort of thing a witness might
normally do:
Stand up. Look at the exit. Imagine a straight
line between you and the exit. Bend the imaginary straight line
to avoid
obstacles in the path between you and the exit. Walk along the straight line
until you reach the exit. If you encounter an obstacle, imagine and bend a new
straight line to the exit.
This code should work readily and
elegantly for most courtrooms, but would fail entirely for a subset of
situations such as a blind witness.
These are three completely
different solutions to the problem, each with its own strengths and weaknesses.
I am sure that other folks could easily invent other entirely different and more
elegant solutions.
For any programming problem (including writing
"Hello World") there are a nearly infinite number of possible solutions,
most of
which are neither elegant nor efficient. For any simple programming problem,
there are very few good solutions. This is why there are courses on data
structures, algorithms, and design patterns. Programmers have recognized that
there are a set of good, efficient, elegant, robust conceptual tools that can be
applied to solving problems when writing code. Design patterns are very good
example of the truth behind k12linux's argument - programmers recognize that
sets of good solutions to particular design problems converge on conceptually
similar solutions.
However, as a problem gets more complex, the number of
different ways in which that problem can be solved in an elegant, efficient, and
robust way increase. The number of different ways in which different
programmers can assemble the basic building blocks of good code to solve the
problem increase. Provide very tight constraints on the problem, and the number
of good solutions will decrease, loosen those constraints and increase the
complexity of the problem and the number of distinctly different good solutions
will increase.
As soon as you move beyond very simple problems,
creativity becomes very important, and a program is like a novel - different
programmers can create different elegant and creative solutions to the problem.
This, I think, is illustrated by the examples above. For any relatively complex
problem, there is more than one way good way to solve that problem.
[ Reply to This | # ]
|
| |
| Authored by: farhill on Friday, July 16 2004 @ 07:32 PM EDT |
k12linux's post shows one side of the story, but IMO it misleads. Trivial or
tightly constrained tasks (in software or other engineering) will be implemented
in similar ways, while literature and most other arts are not tightly
constrained.
At larger scales there are far too many architectural and stylistic choices,
leaving so many options that two implementations are not likely to resemble each
other (though certain tightly constrained fragments may). At every scale, there
are general patterns which are widely known (either through observation, or
independent invention) to those skilled in the art.
Even things that look completely different on the surface can be exactly
equivalent in function. For example, one programmer might write WitnessEgress()
as a long series of things like Walkto(X,Y) etc, while another might define a
table of the actions and locations and iterate through them. The resulting
sequence of moves would be exactly the same, and performance would likely be
similar, but the code itself (and perhaps the legibility or maintainability)
would be rather different.
In programming, this is further clouded by the fact that there is a great deal
of common knowledge and known best practices, and there is a specific benefit
for making things which behave equivalently, even if the internals are
completely different.
I have no doubt that "look and feel" claims, software patents and so
on are hugely harmful to the advancement of software and the public good, but
this is true of *anything* that builds on previous knowledge. Literature too
builds on past works, and would be surely be harmed if someone could patent the
memes Sophocles or the archetype of the cowboy hero.
If you looked at literature at a broad or narrow enough scope, it would fall
into exactly the same sort of things SCO claims about linux. At the large scale
(structure and organization), you could say "Oh, thats just a retelling of
Oedipus, the fact it is set in the slums of a 22nd century moonbase is just
obfuscation". At the small scale, you could compare strings, and no doubt
find many instances of common constructs like "and then he said".
Non-literal copying is a slippery slope, no matter what you apply it to.[ Reply to This | # ]
|
| |
| Authored by: Tim Ransom on Friday, July 16 2004 @ 07:52 PM EDT |
of the 'actually, coders will write remarkably different code to achieve the
same result' argument are available under this article?
I find that the coders writing these posts are writing remarkably similar posts,
resulting in fairly even amounts of irony.
I would also contend that it is kludges that make up the bulk of what would be
'remarkably different' code. I have not seen any compelling arguments as to why
software should be treated the same as novels.
---
Thanks again,
[ Reply to This | # ]
|
| |
| Authored by: golding on Friday, July 16 2004 @ 07:56 PM EDT |
However, SCO have just bought the book of 'Genesis', so now we all have to pay,
as the character would not be able to move and the courtroom would not exist
except for genesis :-)
---
I opened my mouth and proved them right.[ Reply to This | # ]
|
| |
| Authored by: Kevin Kunreuther on Friday, July 16 2004 @ 09:54 PM EDT |
Another great example of why code patents are ridiculous and should be done
away with. Does anyone remember IBM's patent application for a method for using
the public restroom? And the patent office granted IBM the patent. Fortunately
saner heads prevailed at Big Blue and they made the method available as an open
patent. That should have been the wake up call at the patent office for putting
everything on hold and overhauling the entire patent system.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 10:01 PM EDT |
Linus started Linux about 13 years ago now. There has been a gradually growing
army of programmers helping ... so surely we must be getting close to converging
on the "one obvious way that a good programmer would implement a task"
implied by all the above posts?
But no, I see that in version 2.6 great tracts of the fundamental core of the OS
have bee rewritten ... not just in trivial polish the semi-colons kinds of ways,
but with wholesale re-writes using new algorithms to implement the same basic
external functions.
-Tony[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 10:06 PM EDT |
The point is not "there is only one way to get the witness out." The point is
that if you look at a small part of a novel you will have many ways to do the
same thing, but a small part of a program (a single function) will most likely
look similar if two skilled programmers write it separately.
And here is
why this example is relevant to the case:
The Sontag
Declaration describes how such an examination of code lineage would streamline
SCO's discovery efforts. Mr. Sontag provides an example of SCO's UNIX System V
source code for a print error function (perror.c), illustrating accumulated
modifications over time. The first version of the code appeared in 1981, and by
the time the seventeenth version appeared more than ten years later, the
perror.c code sequence was almost unrecognizable from the initial version. Yet a
careful review of the code reveals that the seventeenth and the initial versions
have the same structure, sequence, and organization -- the accepted test to show
substantial similarity.
If you took two skillful programmers
and said "write a function to print an error message passed as a pointer to a
string out to the console", how vastly different do you think each
implementation will be? SCO contends that because UNIX has such a function and
Linux implements a similar function that it is "evidence of non-literal
copying". Stupid, yes. Why would IBM contribute something this basic that has
probably been part of the kernel for a decade now? (I could check but I'm too
lazy.)
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 10:11 PM EDT |
| Everything in the article is true, but I'm not sure in itself it's a good
argument against copyrighting code. The problem is that the originality of code
scales with the complexity of the problem.
For example, if you asked a 100
coders to write a program to compute the average of a set of numbers, you'd get
100 very similar programs. Similarly, if you ask 100 writers to write a
paragraph about a typical conversation between a convenience store clerk and a
customer buying cigarettes, you'd get 100 similar paragraphs.
But if you
asked the coders to write software to perform facial recognition, you'd not only
get completely different structure of the program and code, you'd get different
facial recognition techniques. Just like you'd get different stories if you
asked writers to write a story about recognizing someone in a crowd.
To me,
it's not that software or algorithms shouldn't be copyrightable or patentable,
it's that they should pass the "obviousness" test. It seems odd to me that the
flyball governor would be patentable as a mechanical device or even an
electronic control system, but the same control system shouldn't be patentable
if the underlying algorithm is developed in software code instead. Some
algorithms are ingenious, creative, and useful (search engines, recognition
algorithms, encryption, etc.). Others are obvious and predictable ("one click"
shopping).
The question is what should be copyrightable and what should be
patentable. It seems to me that a non-obvious algorithm (the method itself, not
the code to implement it) should be patentable since it is an exact analogue of
mechanical or electrical creations. Now whether the written code should be
copyrightable is questionable. As this article points out, code is not like a
story. If anything, it's more like a manufacturer's instruction manual or
blueprints to assemble the patented item (mechanical, electrical, or
algorithmic). It's not a work of pure creation because it is restricted to
performing the required functions.
So are instruction manuals copyrightable?
I guess so, but copies have to be pretty close to be in violation. How many
manuals/tutorials are there on software and hardware that have similaries to the
manufacturers manuals? They have to be similar because they are constrained by
how the hardware or software actually works.
So, to me, that's the answer.
Treat software as you would treat an instruction manual.
[ Reply to This | # ]
|
- Yes and no - Authored by: Simon G Best on Saturday, July 17 2004 @ 09:32 AM EDT
- Yes and no - Authored by: Anonymous on Saturday, July 17 2004 @ 09:39 AM EDT
- Yes and no - Authored by: jbeadle on Saturday, July 17 2004 @ 10:05 AM EDT
- Yes and no - Authored by: Anonymous on Saturday, July 17 2004 @ 11:00 PM EDT
| |
| Authored by: Anonymous on Friday, July 16 2004 @ 10:28 PM EDT |
Code is more like a recipe. Restaurant A makes sauce X one way, restaurant B
makes sauce Y another. Both sauces are called BBQ and have the exact same
ingredients.
Goodness, the chefs have had this stuff figured out for a long time, without the
use of lawyers. Just because you type it into a computer doesn't make it
special.[ Reply to This | # ]
|
| |
| Authored by: algorithm on Saturday, July 17 2004 @ 01:06 AM EDT |
| ¿Por qué el código de
un programa no es lo mismo que una novela?
Did it myself. I *think* this
essay is under Creative Commons attribution-no commercial since that's what this
page says in the bottom, if it is not please correct me. [ Reply to This | # ]
|
| |
| Authored by: algorithm on Saturday, July 17 2004 @ 01:18 AM EDT |
This is not against the creativity of a programmer or its creation *as a
whole*.
This is a critique against taking ownership of procedures. As in, on an
equivalent example from an alternate dimension, a painter can't do watercolors
without paying royalties to someone. The *procedures* are cold and abstract, the
program as a whole is a very individual creation of the programmer.[ Reply to This | # ]
|
| |
| Authored by: urzumph on Saturday, July 17 2004 @ 04:59 AM EDT |
Pity there, I was actually agreeing with you there till the last paragraph.
For the most part, I wholly agree. I think programming the witness to grab the
bailiff's gun and take a hostage would be much more fun than programming it to
just walk out. However, if I was being paid to do it, and there was no obvious
gain by doing it that way I wouldn't, simply because I'd probably get fired for
wasting time. So, in this sense, What I am after is the most economic and simple
solution to the problem, which can be achieved in a limited number of ways.
Authors however, are trying to make the exit interesting (so it is enjoyable to
read), and that is what the publisher is after. The author could simply write
"and he left the court room", however, if the entire book was writen
like this, the publisher would never publish the book because it would be too
boring.
So as you can see, when programming for profit, the simplicity of the code and
the speed with which it can be writen are the critical factors, which for the
most part, lead to more simple programs, whereas authors are actively encouraged
to use their artistic flare.
As an example :
Programming at a job :
I would simply program the steps, as it is the least time consuming way
Programming for fun :
I would program a system based on waypoints or environment obstacle avoidance.
This would most definately be more complicated.
Note: Most people who know a little about programming will realise that while
the second will take a LOT more time the first time around, but if a lot of
movement is required, it should save time in the end. Because in the second
option, I own the code I wrote, I would be able to use it in other situations /
programs, whereby saving time in the future.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, July 17 2004 @ 05:27 AM EDT |
| I hope you have learnt a lot from this article PJ;-) [ Reply to This | # ]
|
| |
| Authored by: Dashing Leech on Saturday, July 17 2004 @ 07:10 AM EDT |
| You are completely missing the point and taking liberty with the context of
"creative". Yes, programmers can be "creative" in the sense of "creative
problem solving", much in the way a mathematician can be creative in coming up
with a proof or optimization to solve a problem. But that's a different meaning
of "creative" from "a work of imagination".
Writers are only restricted by
the syntax of language, and even then poetic license allows them to stray
outside this. But they are not restricted by function. While some purely
imaginative programming is possible (e.g., click on a checkbox and a rainbow
streaks across the screen with the sound of trumpets playing) it is pointless.
It is not that programmers actually do and not something anyone pays for. As
I've said elsewhere, a program is equivalent to an instruction manual. It is a
simple set of procedures to implement the functionality required. In fact,
"better" programming (and writing instruction manuals) does so in the most
straight-forward efficient manner possible.
As for the "creative problem
solving", that usually doesn't even apply to the code, it applies to the layout
or algorithms. For example, the "invention" of dockable toolbars was a creative
and useful function. But the creativity was coming up with the concept of how
they would work (as in sketches on a napkin), not in the code. Similarly, text
and image search algorithms are creative and inventive, but those are created in
concept and math (on paper) long before a line of code is written. Many such
algorithms are even created by people who don't know how to code a single line.
The coder just translates the algorithm into whatever language they're writing
in. And in these sorts of creative works, it's the algorithms that are the IP
and they are (and probably should be) patentable, not copyrightable.
The
closest thing I can think of as pure works of imagination in coding is writing
poems in a programming language, which is not really coding at all, it's just
the same as any other poem except in a different language.
So I challenge
you to find an existing programs that are truly a work of imagination, where the
code itself is the imaginative work and not the layout, function, or
algorithms.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, July 17 2004 @ 07:24 AM EDT |
Good point although I think this is a double edged sword and we could take
advantage of it. I mean, imagine if you will if we put together an organization
to put forward patents on all present GPL code and then push forward with new
patents on anything else. It would create a giant schism in software but we
couldn't afford to wait if such a rift were to occur. It would have to be as
soon as software patents began to show commercial software this was really all a
bad idea.
Tyme
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, July 17 2004 @ 09:17 AM EDT |
"Now nobody writing "courtroom procedures" software ever has
to write that stupid little program again."
The only difference I see between software patents and copyright protection of a
software program is that the above quote remains true. However, the difference
is, who gets to write that program. And what if that program needs improvment,
say in the security aspect? If you have a Monopoly entity who owns that patent,
owning that procedure, then it is their responsibility to improve the procedure
for benefit of all. And we have seen what happens when code falls into the hands
of a Monopoly and how the benefits travel from the top of the supplier pyramid
down to the consumer. It travels slowly if not at all.
The company gets rich, the people get poor. Government is suppose to be the
voice for the people to the companies. They should not spend their time play
towards special interests, but only for the best interests of people. And people
should be able to dictate how to define those special interests.
As it stands, government allows itself to compromise those protections and
allows companies like Microsoft to dominate the market like a Dictator. As far
as the US is concerned, The US government needs to reinforce and enforce
Constutionally defined Democracy on the US market. That means kicking the butt
of any US company if they stray from the rules of engagement. Tha means, the DOJ
needs to kick Microsoft's butt more.
And that means, more power for the people, less for the companies.
And that means no software patents. And enforcing the current Copyright laws.
[ Reply to This | # ]
|
| |
| Authored by: T. ProphetLactus on Saturday, July 17 2004 @ 09:49 AM EDT |
...seem to be a sort of simplified fit to the edges of the argument here. Say
you write a G-code program to produce a certain shape on a patented piece of
hardware. You can't claim a competitor has infringed the patent on your finished
part simply because his programs also contain exact matches for strings like
"G0 G43 Z0".
That should arcane enough to suit every taste LOL.
-TPL[ Reply to This | # ]
|
| |
| Authored by: brian on Saturday, July 17 2004 @ 09:50 AM EDT |
PJ's introduction is about "copyrights in software" and
k12linux's example is about "patents in software".
Confusion like this is why they are 2 different concepts
in law. SCO has appeared to waffel back and forth between
the 2 throughout the case and now it appears that Groklaw
is doing the same. This is what happens when you wrap 4
different concepts in law in one all encompasing phrase
called "Intellectual Property" and is really quite
rediculous.
Facts are facts. SCO has abandoned their trade secret
claims and don't hold patents at all. It is questionable
if they even own copyrights to the very code they are
trying to claim ownership to. "Non-literal copying" is SCO
trying to get patent claims into a case where none exist.
IBM will crush them in time and put all these SCO silly
theories to rest once and for all.
I for one will sit back and watch IBM smack the living
daylights out of SCO with glee...
B.
---
#ifndef IANAL
#define IANAL
#endif[ Reply to This | # ]
|
| |
| Authored by: Gerhard on Sunday, July 18 2004 @ 05:54 AM EDT |
There already was an exihibition on writing computer code in Germany,
prepared by "Museum fuer Angewandte Kunst (museum of applied art) in Frankfurt
am Main (FfM)", called "I love you, Computers viruses hackers culture", www.digitalcraft.org. It was presented in
FfM 23th May till 13th June 2002 and then started touring through
Germany.
Not every prose text qualifies for creativity.
Just
remember all those comments on the SCO case (in principle qualifying for
copyrightable prose), which tunred out to be just slightly modified press
releases, thus being almost identical in most places.
Not every program
is straight forward implementation of a unique algorithm.
Just because
there are indeed tasks that leave almost no freedom to the programmer, it is
still not reasonable to claim that there is no relevant freedom for creativity.
In fact, it is part of the profession of computer engineering _not_ to rewrite
trivial code in yet another indistinguishable variation, but to concentrate on
what is unique to the task.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, July 18 2004 @ 01:16 PM EDT |
Hello,
Something I've been *very* curious about for a long time. There is a clause in
the GPL somewhere that states, to the effect, that any program that links
against a GPL'd program/library, is a derrivative work. That is the major
difference, afaik, between the GPL and the LGPL. Has this novel theory ever been
tested in court? I ask, because, if we are going to use analogies with books, I
view linking as analogous to a footnote.
That is, when I write a program that *dynamically* links against a library
(for static linking, or in-line functions, this is a moot point, as the library
in question gets copied, in total, into your program file), basically I am
putting an instruction in my program that tells the computer: find this library,
load it into memory, find this routine, located in this library, load the
following data into the stack, and then jump execution to that routine.
It seems like dynamic linking provides an *extremely* clean seperation of one
author's code from another author's code, and thereby should not be viewed as a
derivative work, regardless of what Richard Stallman wants.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, July 18 2004 @ 06:19 PM EDT |
Of course, we all expect SCOG to lose. But let's say they win (just for grins).
Then the stage is set to take down Microsoft past, present, and future.
First, past: Microsoft didn't write DOS. It was from Seattle Computer. Any
derivatives then would be too. But Seattle Computer derived the code from
Turing principles, so when the Turing heirs exert their claims, Microsoft and
SCO will lose. Then, IBM, will sue, win (their computers predate the work of
Turing). Then, the Jacquard family and a bunch of spinsters in southern France
will sue IBM again, and the worlds computer systems will be seen for what they
are: derivative works of weavers.
Second, present: Microsoft didn't invent Windows. It was similar to Gem and to
Apple and most of all, to Xerox PARC. So, there current business will fall in a
series of lawsuits to Apple (they'll just sue again, like SCOG is trying to do
with the BSD angle), then they'll lose to Xerox, who will lose to the Turing
family, who will lose to IBM, who will lose to the Jacquard family. Even
Babbage won't matter.
Third, future: .Net is **NON LITERAL COPYING** of Java. Really. Both use
virtual machines, both use sandboxing and encapsulation or marshalling of
running code, both use just in time compilation and verification, both use
classes and class loading, they even both have code signing. So, Sun will
resume suits against Microsoft. They'll win, then they'll be sued by Stroustrup
and the Object Pascal folks, who will win, they'll be sued by IBM too (remember
SOM?), they'll all be sued by the Turing family, who will be sued by the
Jacquard family.
So if SCOG wins, a bunch of weavers will own the code. THe possible exceptions
have to do with languages based on predicate calculus, but those will eventually
fall to the heirs of Liebnitz and Newton.
Microsoft has another weakness; the newer Windows versions all have bugs and
leaks and weaknesses galore! Talk about non literal copying! "Already we
have found mountains of their bugs and they belong all to us"! All of this
of course will trace back to Lady Lovelace, the original programmer and thus,
the original bug generator (see ladies, even in programming you get blamed for
Original Sin ;)
No way out! Agh! All procedural languages and anything derived from them will
fall to the weavers. All bugs will fall to the Lovelaces. All non procedural
languages will fall to the Newtons.
BUT AT LEAST MICROSOFT WILL FALL! Nice work SCOG! Brilliant, simply
brilliant.
We just better hope the judge is as stupid, clueless, and susceptible to bribes
as Darl, or this whole mess won't come to pass and we'll all have to get back to
work for a living.
I'm pretty sure though, that Darl would like the outcome in either case; if
there's no more software, he can spend more time with his sheep. With him
flying around and spouting all over the world, they're getting lonely, you
know.
[ Reply to This | # ]
|
| |
| Authored by: valdis on Sunday, July 18 2004 @ 09:21 PM EDT |
| I've yet to see anybody who's managed to write a novel that makes sense when
read in either of two languages - but here's some examples of programs that make
sense in multiple languages:
A collection of polyglot
programs...
There's one that worked in 7 different languages - and note
that at the time, that sucker did work in all 7 - if it
fails to do so now, it's because the language has changed out from under it.
Deal with it - it happened to Shakespeare too...
Another one is both C code
and 'vi' editor macros. Gaak. :)
What drives people to do this? Rudy
Rucker explained the process fairly well in the intro to chapter 7 of his novel
"The Hacker and the Ants":
Hacking is like building a
scale-model cathedral out of toothpicks,
except that if one toothpick is out of
place the whole cathedral
dissapears. And then you have to feel around for the
invisible
cathedral, trying to figure out which toothpick is wrong.
Debuggers
make it a little easier, but not much, since a truly
screwed-up
cutting-edge program is entirely capable of screwing up the
debugger
as well, so that then it's as if you're feeling around for the
missing
toothpick with a stroke-crippled claw-hand.
But, ah, the dark
dream beauty of the hacker grind against the
hidden wall that only you can see,
the wall that only you wail at, you
the programmer, with the brand new tools
that you made up as you went
along, your special new toothpick lathes and jigs
and your real-time
scrimshaw shaver, you alone in the dark with your wonderful
tools.
Rucker really Does Get It, and I can sympathize -
novelists don't have to worry about all the prime-numbered chapters between 15
and 23 disappearing if they leave a comma out of a sentence in chapter 3. And
I've lost count of how many computer systems I've managed to crash its innnards
so badly that the debugger snow crashes as well...[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, July 19 2004 @ 11:11 PM EDT |
The example k12linux uses doesn't really compare the two. However I do agree
with his point of view.
If a programming language had as many keywords as the english language then no
two programs would be the same, unless you are talking about two very small
programs. Even in english, there are only so many ways to say "I read an
article on Groklaw".
A better analogy would be comparing operating systems to a fanatasy novel. Read
any two fantasy novels and you will find similarities. They will most likely
both have orcs, elves, wizards, and warriors in them. Both will have your
standard good vs evil theme and the hero of the day. If you compare the two
books you will probably find that there are several line of identical text.
However, just because 2 authors write about the same thing, with the same theme,
using the same ideas in the same context does not mean the one book is a
derivative or copied from the other. If I read both those books and they give me
some ideas for a fantasy book of my own, I am not stealing their books. Now,
imagine that an author could patent sentences or paragraphs. There are really
only so many ways to say something, and if those ways were patented, then in a
rather short period of time, no one could write a book without paying huge
royalties to idiots trying to make a fast buck.
Same with computer programs. Operating systems would be analogous to fantasy
novels. There are many out there and some are good and some bad, but they all
do the same things, with the same themes, using the same ideas in the same
contexts....... etc.. Only problem is that in computers, a "sentence"
or "paragraph" can be patented.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, July 20 2004 @ 09:13 AM EDT |
should you have asserted copyright/patent on this?
that way you can collect royalties/licence fees from every single automatic
hairwashing program, heck if you also make a patent application you may even be
able to specify the genericism of the algoritm and encompass car washes as well
as hair[ Reply to This | # ]
|
|
|
|
|
