Part of the problem is that there are a number of completely orthogonal ways to aggrieve an author: Infringement of Copyright, Infringement of Moral Rights (droit d'auteur, unauthorized alteration of the work or attribution), Plagiarism, Breach of Contract, etc.
Here he's asserting his Moral Rights. Alteration is covered in the US by All Rights Reserved as it'd be a derivative work, but you'd have to lean on trademarks and libel/slander to fully enforce your rights regarding attribution.
I understand exactly how the OP feels. I still get like that, even when I have explicitly released something as open-source.
The way I see it if someone contributes to your codebase you still have the right, and the obligation, to veto that code if you don't feel it matches your philosophies and quality standards. Asserting your preferences is the only way the code is still going to be 'yours'. If your idea of good code matches up with other people's, great! If not, the code will still be 'your baby'.
The author has inadvertantly stumbled upon a part of hacker culture with wide-ranging implications, that is almost never discussed—and that is that people expect that you publish code because you want it to be changed, and not simply read. This stems from a deeply-rooted tradition in programming of not reading a codebase until you have a problem with it that you must fix. People don't "read for pleasure" in the programming world; they don't even read to learn—have you ever had a school assignment that charged you with reading more than 1KSLOC? The only reason, as a programmer, I will ever "cd src/", is that I am on a mission to fix a problem. Therefore, publishing code but reserving the right to derivative works, looks a bit like gloating, or showing off—"look what I did! Look how smart I am! It's no benefit to you... but look!"
This makes perfect sense in the art world (and writing is a form of art), as you never really "derive" from a piece of art; instead, you first look at the mechanisms by which it communicated its message to add those techniques to your repitoire of skills, and then re-use those skills on your own works. That makes perfect sense in an artistic medium, where any single stroke or word or note may be chosen from an infinitude of options—but programming requires formal grammar—a finite set of ways of expressing each concept—and thus there is relatively little merit in studying the technique by which a single problem was solved.
On a separate note, for the first few paragraphs he seems to be completely unaware of the medium of fan-fiction—which is about as core to "the culture of online fiction" as you can find.
People don't "read for pleasure" in the programming world; they don't even read To learn—have you ever had a school assignment that charged you with reading more than 1KSLOC? The only reason, as a programmer, I will ever "cd src/", is that I am on a mission to fix a problem.
Seriously? As a programmer, the problem I'm often on a mission to fix in /src is that I haven't learned enough.
Yes: you are in a minority within a minority. Of the programmers who read to further their education after school is done with (an already-small number), most will be complacent to read books, or blogs, or at the most journal articles. The number who dive into a foreign codebase—that is, one they have no association with and don't rely on for anything—without the expectation of eventually contributing something (i.e. In OSS) is vanishingly small.
Random rails and jquery plugins tend to be terribly documented and frequently make easy to fix design errors. I read code all the time -- if I am committing it to the repo, I want to be sure I know how it works. For "black box" things I usually won't delve that deep, but if it really needs to integrate, I usually end up reading it sooner or later.
My only regret is not pushing more changes back upstream
I'm with you on this one. I like to understand how things work and how other people approach certain problems. You can find new tricks to add to your bag. Which is also why I like to reinvent the wheel. Waste of time? Maybe, if you don't want to learn anything.
> ... people expect that you publish code because you want it to be changed, and not simply read.
Browser-interpreted code makes this quite a fuzzy issue. What are the rules with running tools like GreaseMonkey? Is there a legal or moral line that shouldn't be crossed with tools like GM?
As an aside, I wonder if there is any gender bias in the "publish code"-->"you want it changed" conclusion. I've observe that females tend to state problems in order to find empathy, and males tend to state problems in order to find solutions (of course, this is a gross simplification). Mixing these two types when a problem presents itself can sometimes result in conflict. Perhaps the same tendencies in people sometimes conflict over code (i.e., some present code to look at and admire, others see it as an opportunity for improvement).
I would say "publishing" must always be a distinct step, and that there has to have been a conscious effort of some sort on the part of the programmer to put the code up separately from its existence within a program. However, even if some people disagree with that, I don't think it could be argued that obfuscated code was to be considered "published"—which could actually be a good argument for code obfuscators.
I often find that I can't properly "read" code without a mindset of wanting to change something about it. Of course, I sometimes invent a trivial "something" when I really want to understand a piece of code.
And it is surprising how much you can learn from reading code, the most humbling thing I learned from reading other people's code is that I'm not nearly as good a programmer as I thought I was.
I haven't read a program yet that didn't teach me something.
Reading programs is hard work though, it can tire you out pretty quickly, especially in the stage before things start clicking in to place and you can start to predict what's coming next based on the parts that you've already grokked.
I'm definitely not saying it's not a good idea to read code—it's just something that almost nobody does, because, as you've said, it's very hard work; much harder than having the "story of the code" told to you in a book or a blog post.
It's also work no one knows you did; unlike reading a book or a blog post, you can't really reference or quote a codebase to prove you know what you're talking about, because you can't expect the people you're talking to to have read the same exact lines.
It's probably related to the way I learned about tech, I relentlessly pulled stuff apart until I understood how it worked. I never really grew out of that I guess.
Getting good at reading code helps with debugging. I like teams where every commit is reviewed by somebody else -- keeps you honest, you learn new tricks and you reduce bus factor
It's interesting that you mention fan-fiction. I imagine the reason people overlook forking" fiction stems from the fact you're consuming the story, remixing it and spitting out something new. On the other hand, forking code is more like tacking on a paragraph here or there.
Also, while you did touch on the hacker culture I think that's the most important factor. As hackers we're practically born to tinker. When we tinker with hardware ,say a remote controlled car, no one confronts us and asks "Hey, man, why are you tinkering with that car?" More often than not you'll get people saying "Hey, that's really cool!"
Furthmore, it's easier to take a get tangible changes from tinkering with a program than with a piece of literature. You can't miss the impact of gravity on gameplay in a game like HATETRIS but very few people will pick up on the significance of a new piece of text in the middle of a novel.
I really like how jsankey put it when he said "If you put something out there, you should be flattered that people take enough interest to tinker with it."
The authors basically says that it does not always like when people changes his stuff, so he thinks it's fine to do a kind of read only open source with additional unwritten rights (basically i've got the impression that it's okay to send him he likes, but he won't tell you before the rules for him to like things or not...)
He does not take into account at all that you can just modify copies of his stuff. Not his own (unless he planned to do a kind of wikipedia like repository for his code, freely modifiable by anybody without even registration).
And also: copies are naturally free in the digital age.
Also, i'm not fond the whole "i'm a good programmer, you are only allowed to look because you could be a bad one and do a mess in your own copy -- and oh I forgot: I happen to like free software, but not when I write the program" thing.
I would guess the majority of source code available online is explicitly open source. So it's reasonable to assume that this particular bit of source code available online is also (intended to be) open source, if there's no indication otherwise. Fiction is not the same, for various reasons: a work of fiction posted online is probably not "open source" (creative commons or similar), so that's not the default assumption with unlabelled fiction.
This is just culture clash. You're coming from a writer background and publishing things for people coming from a hacker background. If you explicitly state "this is not free software: look but don't touch", people will at least understand what your expectations are. Not everyone will understand or agree with you, but most will respect your wishes.
Similarly, I suspect a hacker-turned-writer would be likely to have a similar attitude to his fiction as to his code, and use a CC license. Or artists in general, actually: two examples I can think of are Randall Munroe and Jonathan Coulton.
I think it's a bit more than a culture clash. The issue is not only that the majority of source code readable online is open source; it's that making code readable is the only thing you need to do to allow people to copy and modify it. It's a bit like a failed Searlian speech act where an actor running lines or a student practicing French is overheard and presumed to be saying something to someone in particular. The OP's readers, having looked at his post and code, quite understandably mis-inferred that he meant the posted material to be beneficial or useful to his readers, when really he only intends it to be useful to himself in some hypothetical future where he wants a job.
To my mind, this is similar to saying "look but don't touch" about a door handle, an elevator, or a platter of hors d'oeuvres in a crowded party. Of course people are bound to be confused; that's not the way to go about bragging to people about your fragile antique doorknob, guerilla marketing for the Otis elevator corporation or demonstrating what a really well made (prototype) bruschetta looks like.
This isn't merely a cultural issue, where we're used to the availability of code being a signal that it's open source. It's a deeper issue of social cognition than that. Other people are seeing the hatetris post, and making the perfectly normal inferences that humans as sophisticated social creatures are bound to do -- namely that if he's putting stuff up publicly and even points to it enthusiastically, and that stuff offers natural interactions to the reader, then it must be because he intends his readers to partake of those natural interactions with that publicly available stuff. Here the stuff is code and the affordances are reading, copying and changing, but I they needn't be for this error to occur. The OP's just failed to consider that his readership might mistake his exhibiting of untouchable code as an invitation to interact with it.
I understand where you're coming from, but the only reason the source is available here is that he wrote in client-side JavaScript. There is no link to the source, no download, no indication that the source is meant to be available, and the explicit invitation to interact with it is to play the game, not monkey with the source. You make it sound like he was exhibiting the code just because he didn't make it impossible to see.
When HATETRIS reached Hacker News, someone posted some
JavaScript which would modify the game to have gravity.
I believe this is in response to the diff I posted. I'm sorry if I infringed upon any stated or implied licence in posting that. I will of course remove it if you feel that is appropriate.
Personally I feel what I posted, given the readership of this website, was directly equivalent to simply saying "Wow, wouldn't that be really hard if it had gravity!" That was the way I'd intended it to be read anyway.
For what its worth, I really enjoyed your programming style, it was clean, concise and built in such a way that extending it to include gravity was trivial. It took me longer to remember the syntax to diff than to figure out the changes.
This is the way I learned to code. I just stole stuff from other people and made it work for what I was trying to accomplish by changing it little by little. So what was his point anyway?
Ah, but as a recipient, the arrangement with your code is the same as with your text: if you put something where I can get it, I'll modify it if I wish.
You may of course prevent me from distributing entire derived works, but not from distributing mere patches like the one that was posted for HATETRIS--- any more than you could prevent me from posting a Perl script that uses a regex to change characters' names in your novel.
Particularly amusing that a rant like this would come in response to someone modifying a game that was itself an unauthorized modification of another game.
The point being made "creations being his babies" seems somewhat odd to me.
"But it's weird to me that other people are so okay with mucking about with other people's work."
That's also called "progress". It's how people learn and grow.
Is it okay to take Shakespeare's characters and modify them here and there, play with the setting a bit, and generally muck about? It's legal, but is it okay? I assume his feelings are hurt that someone has taken his idea/characters and modified them. Because it's not as if he took the _idea_ of tetris and modified it. Imagine how hurt the author of tetris would be! Oh, but is it okay if the auhtor is dead (like Shakespeare)?
Sorry, but I don't buy the argument/complaint. You want people to follow certain rules, put up a license. Hundreds of ideas, words and characters are written, and a lot of them are alike. We're not all that unique.
I like open source software. I'm a big fan of the
objectives that open source software is created to
achieve. I really like not having to pay money for
Notepad++ and TrueCrypt and so on and so forth. I
wish the movement every success.
FSF is against the "open source" moniker for a reason. Some people associate it only with freedoms 0 and 1, and disregard the other two.
It looks like the author falls into the same trap.
I don't really understand the author's aversion to other people adding their own contributions and creativity. How exactly is it harming him? He can retain control of the original -- it's not like anyone is forcing him to accept contributions. And indeed unless he explicitly allows it they can't even distribute an updated version of his project.
If you put something out there, you should be flattered that people take enough interest to tinker with it.
We once had an architect that sued the occupants of a house he designed because the washing they hung out to dry disturbed the beautiful lines of his creation.
I think he views his coded-creations as a form of self expression, or art. This is perhaps why he wants them to be treated with the same hands-off approach as his fiction writings.
However, when it comes to code I think it's best to make known your intentions for it because code generally has a practical function beyond its artistic value as a creation, and as a result people may want to alter it.
More info and updated ports of his code can be found here: http://www.vispo.com/bp/introduction.htm - the notion of translation (either between languages or architectures), and not yet breached by the original thread, should make for some polemical discussion.
It seems to me that the author may be interested in the license Donald Knuth used for the Stanford GraphBase, which looks like this:
The Stanford GraphBase is copyright 1993 by Stanford University
These files may be freely copied and distributed, provided that
no changes whatsoever are made. All users are asked to help keep
the Stanford GraphBase sources consistent and "uncorrupted,"
identical everywhere in the world. Changes are permissible only
if the changed file is given a new name, different from the names of
existing files listed below, and only if the changed file is
clearly identified as not being part of the Stanford GraphBase.
The author has tried his best to produce correct and useful programs,
in order to help promote computer science research, but no warranty
of any kind should be assumed.
That is very similar to the license that Knuth used for TeX as well.
However in both cases Knuth made it clear that he is OK with people reusing the TeX source code as long as they make it clear that it isn't TeX. And again his reason is that he wants people to be able to rely on perfectly consistent behavior from anything that is called TeX.
38 comments
[ 3.0 ms ] story [ 50.5 ms ] threadHere he's asserting his Moral Rights. Alteration is covered in the US by All Rights Reserved as it'd be a derivative work, but you'd have to lean on trademarks and libel/slander to fully enforce your rights regarding attribution.
The way I see it if someone contributes to your codebase you still have the right, and the obligation, to veto that code if you don't feel it matches your philosophies and quality standards. Asserting your preferences is the only way the code is still going to be 'yours'. If your idea of good code matches up with other people's, great! If not, the code will still be 'your baby'.
This makes perfect sense in the art world (and writing is a form of art), as you never really "derive" from a piece of art; instead, you first look at the mechanisms by which it communicated its message to add those techniques to your repitoire of skills, and then re-use those skills on your own works. That makes perfect sense in an artistic medium, where any single stroke or word or note may be chosen from an infinitude of options—but programming requires formal grammar—a finite set of ways of expressing each concept—and thus there is relatively little merit in studying the technique by which a single problem was solved.
On a separate note, for the first few paragraphs he seems to be completely unaware of the medium of fan-fiction—which is about as core to "the culture of online fiction" as you can find.
Seriously? As a programmer, the problem I'm often on a mission to fix in /src is that I haven't learned enough.
My only regret is not pushing more changes back upstream
Browser-interpreted code makes this quite a fuzzy issue. What are the rules with running tools like GreaseMonkey? Is there a legal or moral line that shouldn't be crossed with tools like GM?
As an aside, I wonder if there is any gender bias in the "publish code"-->"you want it changed" conclusion. I've observe that females tend to state problems in order to find empathy, and males tend to state problems in order to find solutions (of course, this is a gross simplification). Mixing these two types when a problem presents itself can sometimes result in conflict. Perhaps the same tendencies in people sometimes conflict over code (i.e., some present code to look at and admire, others see it as an opportunity for improvement).
And it is surprising how much you can learn from reading code, the most humbling thing I learned from reading other people's code is that I'm not nearly as good a programmer as I thought I was.
I haven't read a program yet that didn't teach me something.
Reading programs is hard work though, it can tire you out pretty quickly, especially in the stage before things start clicking in to place and you can start to predict what's coming next based on the parts that you've already grokked.
It's also work no one knows you did; unlike reading a book or a blog post, you can't really reference or quote a codebase to prove you know what you're talking about, because you can't expect the people you're talking to to have read the same exact lines.
Also, while you did touch on the hacker culture I think that's the most important factor. As hackers we're practically born to tinker. When we tinker with hardware ,say a remote controlled car, no one confronts us and asks "Hey, man, why are you tinkering with that car?" More often than not you'll get people saying "Hey, that's really cool!"
Furthmore, it's easier to take a get tangible changes from tinkering with a program than with a piece of literature. You can't miss the impact of gravity on gameplay in a game like HATETRIS but very few people will pick up on the significance of a new piece of text in the middle of a novel.
I really like how jsankey put it when he said "If you put something out there, you should be flattered that people take enough interest to tinker with it."
He does not take into account at all that you can just modify copies of his stuff. Not his own (unless he planned to do a kind of wikipedia like repository for his code, freely modifiable by anybody without even registration).
And also: copies are naturally free in the digital age.
Also, i'm not fond the whole "i'm a good programmer, you are only allowed to look because you could be a bad one and do a mess in your own copy -- and oh I forgot: I happen to like free software, but not when I write the program" thing.
This is just culture clash. You're coming from a writer background and publishing things for people coming from a hacker background. If you explicitly state "this is not free software: look but don't touch", people will at least understand what your expectations are. Not everyone will understand or agree with you, but most will respect your wishes.
Similarly, I suspect a hacker-turned-writer would be likely to have a similar attitude to his fiction as to his code, and use a CC license. Or artists in general, actually: two examples I can think of are Randall Munroe and Jonathan Coulton.
To my mind, this is similar to saying "look but don't touch" about a door handle, an elevator, or a platter of hors d'oeuvres in a crowded party. Of course people are bound to be confused; that's not the way to go about bragging to people about your fragile antique doorknob, guerilla marketing for the Otis elevator corporation or demonstrating what a really well made (prototype) bruschetta looks like.
This isn't merely a cultural issue, where we're used to the availability of code being a signal that it's open source. It's a deeper issue of social cognition than that. Other people are seeing the hatetris post, and making the perfectly normal inferences that humans as sophisticated social creatures are bound to do -- namely that if he's putting stuff up publicly and even points to it enthusiastically, and that stuff offers natural interactions to the reader, then it must be because he intends his readers to partake of those natural interactions with that publicly available stuff. Here the stuff is code and the affordances are reading, copying and changing, but I they needn't be for this error to occur. The OP's just failed to consider that his readership might mistake his exhibiting of untouchable code as an invitation to interact with it.
Personally I feel what I posted, given the readership of this website, was directly equivalent to simply saying "Wow, wouldn't that be really hard if it had gravity!" That was the way I'd intended it to be read anyway.
For what its worth, I really enjoyed your programming style, it was clean, concise and built in such a way that extending it to include gravity was trivial. It took me longer to remember the syntax to diff than to figure out the changes.
You may of course prevent me from distributing entire derived works, but not from distributing mere patches like the one that was posted for HATETRIS--- any more than you could prevent me from posting a Perl script that uses a regex to change characters' names in your novel.
Particularly amusing that a rant like this would come in response to someone modifying a game that was itself an unauthorized modification of another game.
"But it's weird to me that other people are so okay with mucking about with other people's work."
That's also called "progress". It's how people learn and grow.
Is it okay to take Shakespeare's characters and modify them here and there, play with the setting a bit, and generally muck about? It's legal, but is it okay? I assume his feelings are hurt that someone has taken his idea/characters and modified them. Because it's not as if he took the _idea_ of tetris and modified it. Imagine how hurt the author of tetris would be! Oh, but is it okay if the auhtor is dead (like Shakespeare)?
Sorry, but I don't buy the argument/complaint. You want people to follow certain rules, put up a license. Hundreds of ideas, words and characters are written, and a lot of them are alike. We're not all that unique.
It looks like the author falls into the same trap.
If you put something out there, you should be flattered that people take enough interest to tinker with it.
Arrogance comes in all kinds of forms.
However, when it comes to code I think it's best to make known your intentions for it because code generally has a practical function beyond its artistic value as a creation, and as a result people may want to alter it.
The last of which is only visible in the source code as a sort of pun: http://www.vispo.com/bp/download/FirstScreeningBybpNichol.tx... - scroll to the very end (lines 3900 through 4000). The REM command is Apple Basic for "REMark" or a comment line.
More info and updated ports of his code can be found here: http://www.vispo.com/bp/introduction.htm - the notion of translation (either between languages or architectures), and not yet breached by the original thread, should make for some polemical discussion.
The highest form of praise your work can receive is for someone to take the time to contribute to it.
The Stanford GraphBase is copyright 1993 by Stanford University
These files may be freely copied and distributed, provided that no changes whatsoever are made. All users are asked to help keep the Stanford GraphBase sources consistent and "uncorrupted," identical everywhere in the world. Changes are permissible only if the changed file is given a new name, different from the names of existing files listed below, and only if the changed file is clearly identified as not being part of the Stanford GraphBase. The author has tried his best to produce correct and useful programs, in order to help promote computer science research, but no warranty of any kind should be assumed.
However in both cases Knuth made it clear that he is OK with people reusing the TeX source code as long as they make it clear that it isn't TeX. And again his reason is that he wants people to be able to rely on perfectly consistent behavior from anything that is called TeX.