IP Law Makes You an Asshole

I haven't had a very good relationship with IP law. My 2 favorite childhood game franchises - Descent and Freespace, were thrown into IP limbo after Interplay shot itself in the foot too many times and finally fell over. As a result, I have come to utterly despise the common practice of publishers simply taking the IP of the developers for themselves, and in a more broad sense, forcing artists to give up their ownership on everything they make for a company. This becomes especially painful when they aren't just making silly UI art, but creating a universe filled with lore and character and spirit, only to watch corporate meddling turn their idea into a wretched, free-to-play money-grubbing disaster.

What can the artist do? Exactly nothing. Under current IP law, the company usually owns all rights to everything the artist does for them, no matter what. If it doesn't, it's because the company screwed up its legal contracts, which is dangerous for both you and the company. There is essentially no middle ground. That means an artist can't sue the company for screwing up their idea, because it isn't their idea anymore. They can't take it to another studio or even work on their own idea without permission from the company. It makes about as much sense as a company saying they own the rights to your startup idea because you came up with it at work one day and wrote a prototype during break. That isn't just hypothetical, either, it's a disturbingly common problem.

This is not beneficial to companies, either. Artists are increasingly aware of how little control they have over their own work. A paranoid artist who gets a great idea will be unwilling to tell anyone at the company about it until after they've been working on it in secret, distracting them from what they're supposed to be working on and making them uncomfortable and stressed. They'll worry about what will happen if they try to take the idea somewhere else and no one likes it. They could lose their only job. But if they tell anyone about the idea inside their current company, they risk losing all rights to it and then having the company decide it doesn't like the idea and burying it forever, killing the artists brainchild without any hope of resuscitation. What's worse is that an artist is just about as far from a lawyer as you can get - they have absolutely no idea how any of this stuff works and what they can or cannot do, so they tend to either screw up immediately and lose all rights to their idea or tell no one about it, ever. Your company will essentially lose an employee for months as they succumb to stress, and you might never even know about their idea because they're too paranoid about you stealing it.

So what would good handling of IP be? A more fair agreement would give the company nonexclusive rights to use ideas the artist comes up with. The company only maintains nonexclusive rights to partially or completed work the artist created while employed at the company if the artist decides to quit, not the idea itself. It can even attempt to finish partially completed work, but the artist still retains the right to take his idea elsewhere. This is a compromise between ensuring a company can use everything an artist makes for them while employed without restriction, and ensuring that the artist can still walk out with his idea and bring it to life on his own or at another company. For game development companies, there would clearly need to be a clause protecting the companies right to finish a project if the lead designer leaves.

It seems reasonable to approximate this by assigning permanent nonexclusive rights to the company instead of exclusive rights, but things get complicated very quickly. If you don't own all the rights to a copyrighted material, you can get sued if you modify the original even if you have permission to use it. It's possible such situations could also occur with IP assignments, especially when you are specifically allocating certain nonexclusive rights in certain circumstances but not in others, or revoking certain rights upon termination. If an artist leaves a company in the middle of making a game, they shouldn't be able to sue the resulting game because it used their old art, or even created new art based off their old art. Likewise, a company shouldn't be able to sue an artist if they leave and create a game on their own using their idea even if the company had already released a game based on it. How one would achieve this, I have no idea. It gets even murkier when an idea is the collaborative effort of multiple people. Who owns what part? If one person leaves, the company must still retain the right to use his ideas and ideas based off his ideas, and he should only retain the right to use his own ideas, but not everyone else's ideas or ideas based off everyone else's ideas. What happens when they live in another country?

Because of the vast complexity of this issue, most companies say "fuck it" and simply assign all rights to themselves. This is standard advice from lawyers. The mentality is that you don't have time to worry about silly little legal issues with artists. The problem is that it erodes artists' rights, which are already disturbingly emancipated. This is unacceptable.

I'm not a lawyer. I don't know how to fix this. I don't know if it can be fixed. I don't even know how to properly assign IP to my own company or write a contract. All I know is that artists are getting screwed over because IP law makes everyone an asshole.

Obligatory legal crap: The information provided in this blog is not intended as legal advice.

Stop Following The Rules

The fact that math, for most people, is about a set of rules, exemplifies how terrible our attempts at teaching it are. A disturbing amount of programming education is also spent hammering proper coding guidelines into students' heads. Describing someone as a cowboy programmer is often derisive, and wars between standards, rules and languages rage like everlasting fires. It is into these fires we throw the burnt-out husks that were once our imaginations. We have taken our holy texts and turned them into weapons to crush any remnants of creativity that might have survived our childhood's educational incarceration.

Math and programming are not sets of rules to be followed. Math is a language - an incredibly dense, powerful way of conveying ideas about abstraction and generalization taken to truly astonishing levels. Each theorem is another note added to a chord, and as the chords play one after another, they build on each other, across instruments, to form a grand symphony. Math, in the right hands, is the language of problem solving. Most people know enough math to get by. It's like knowing enough French to say hello, order food, and call a taxi. You don't really know the language, you're just repeating phrases to accomplish basic tasks. Only when you have mastered a certain amount of fluency can you construct your own epigraphs, and taste the feeling of putting thoughts into words.

With the proper background, Math becomes a box of legos. Sometimes you use the legos to solve problems. Other times you just start playing around and see what you can come up with. Like any language, Math can do simple things, like talk about the weather. Or, you can write a beautiful novel with words that soar through the reader's imagination. There are many ways to say things in Math. Perhaps you want to derive the formula for the volume of a sphere? You can use geometry, or perhaps calculus, or maybe it would be easier with spherical coordinates. Math even has dialects, there being many ways of writing a derivative, or even a partial derivative (one of my professors once managed to use three in a single lecture). As our mathematical vocabulary grows, we can construct more and more elegant sentences and paragraphs, refining the overall structure of our abstract essay.

Programming too, is just a language, one of concurrency, functions and flow-control. Programming could be considered a lingual descendant of Math. Just as English is Latin-based, so is programming a Math-based language. We can use it to express many arcane designs in an efficient manner. Each problem has many different solutions in many different dialects. There's functional programming and procedural programming and object-oriented programming. But the programming community is obsessed with solving boring problems and writing proper code. Too overly concerned about maintainability, naming conventions and source control. What constitutes "common sense" varies wildly depending on your chosen venue, and then everyone starts arguing about semicolons.

Creativity finds little support in modern programming. Anything not adhering to strict protocols is considered useless at best, and potentially damaging at worst. Programming education is infused with corporate policy, designed to teach students how to behave and not get into trouble. Even then, its terribly inconsistent, with multiple factions warring with each other over whose corporate policies are superior. Programming languages are treated more like religions than tools.

The issue is that solving new problems, by definition, requires creative thinking. Corporate policy designed to stamp out anything not adhering to "best practices" is shooting itself in the foot, because it is incapable of solving new classes of problems that didn't exist 5 years ago. Companies that finally succeed in beating the last drop of creativity out of their employees suddenly need to hire college graduates to solve new problems they don't know how to deal with, and the cycle starts again. We become so obsessed with enforcing proper code etiquette that we forget how to play with the language. We think we're doing ourselves a favor by ruthlessly enforcing strict coding guidelines, only to realize our code has already become irrelevant.

We need to separate our mathematical language from the proof. Just as there is more to English than writing technical specifications, there is more to Math than formal research papers, and more to programming than writing mission-critical production code. Rules and standards are part of a healthy programming diet, but we must remember to take everything in moderation. We can't be so obsessed with writing standardized code that we forget to teach students all the wonderful obscurities of the language. We can't be telling people to never use a feature of a programming language because they'll never use it properly. Of course they won't use it properly if they can't even try! We should not only be teaching programmers the importance of formality, but where it's important, and where it's not. We should encourage less stringent rules on non-critical code and small side projects.

In mathematics, one never writes a proof from beginning to finish. Often you will work backwards, or take shortcuts, until you finally refine it to a point where you can write out the formal specification. When messy code is put into production, it's not the programmer's fault for being creative, it's the idiot who didn't refactor it first. Solving this by removing all creativity from the entire pipeline is like banning cars to lower the accident rate.

Corporate policy is for corporate code, not experimental features. Don't let your creativity die. Stop following the rules.

The Standards Problem

When people leave the software industry citing all the horrors of programming, it confuses me when they blame software development itself as the cause of the problems. Programming is very similar to architecture - both an art and a science. The comparison, however, falls apart when you complain about architecture and buildings having all these well-established best practices. The art of making buildings hasn't really changed all that much in the past 50 years. Programming didn't exist 50 years ago.

The fact is, we've been building buildings for thousands of years. We've been writing programs for around 40, and in that period we have gone from computers the size of rooms to computers the size of watches. The instant we establish any sort of good practice, it's bulldozed by new technology. Many modern functional programming languages had to be updated to elegantly handle concurrency at all, and we've only just barely established the concept of worker threads for efficiently utilizing 4-8 cores as we step into the realm of CPU/GPU collision and the advent of massively parallel processing on a large scale, which once again renders standard concepts of programming obsolete. The fact that software runs at all is, quite simply, astonishing. Windows still has old DOS code dating back to the 1980s having repercussions in Windows 7 (You can't name a folder "con" because it was a reserved device name in DOS). If they were to completely rewrite the operating system now, it'll be completely obsolete in 20 years anyway and we'd be complaining about NT's lingering 32-bit compatibility issues and old functions not being threadsafe on a 128 core processor and problems I can't even predict.

Standards can't exist if we can't agree on the right way to do things, and in software development, we can't agree on the right way to do things because nobody knows (and if someone tells you they know, they're lying). Just as we all begin to start settling down on good practices, new technology changes the rules again. This further complicates things because we often forget exactly which parts of the technology are changing. There's a reason you write a kernel in C and not F#. Our processor architecture is the same fundamental concept it was almost 30 years ago. Ideally we would have moved away from complex instruction sets now that nobody uses them anymore, but we haven't even done that. Language fanboys forget this and insist that everything should be written in whatever their favorite language is, without having any idea what they're talking about. This results in a giant mess, with literally everyone telling everyone else they're doing it wrong.

That's the software industry today. It's where everyone says everyone else is wrong, because we have no goddamn idea what software development should be, because what software development should be keeps changing, and its changing so rapidly we can barely keep up, let alone actually settle on a bunch of standards. Instead, individual groups standardize themselves and you get a bunch of competing ecosystems each insisting they are right, without observing that they are all right at the same time - each standard is built to match the demands of not only where, but when it is being used.

Luckily, I don't program because I want to write programs all day. I program because I want to build something magnificent. If you make a living programming for a bunch of clients that try to tell you what to do and always say it should be faster and cheaper, well, welcome to being an artist.

An evidence-based refutation of the Project Glass parodies

The following was written by Saul Reynolds-Haertle, a close friend of mine who is too busy starting his PhD at Georgia Tech to run his own blog. It is posted here at his request.

---

It seems like half of the internet is complaining about Google's new wearable computers. They say that they're distracting, they say that you can't see through them, and they ask why you would want to be hooked into the internet like that in the first place. However, all of the basic usability complaints are built on critically unsound foundations: none of the complainers have used one of the devices. I've at least tried the technology¹, and I have some facts and some ten-second experiments that I hope will address the more common concerns.

Obstructed Vision

We'll begin with the claim that head-mounted displays would obstruct the wearer's vision. This is the most common argument of the parody videos that spread like wildfire immediately after the announcement. All of them go wrong before they start, mostly because they fail to consider the fundamental differences between the human eye and the recorded video used to make the announcement. Here are a few of the ways in which this difference is important.

First, people are already missing huge chunks of their visual field. To start with, your brain only really pays attention to your foveal region, which is about the size of your thumb at arm's length. On top of that, most adults have floaters, and everybody has the high-school-science "blind spot" where the eye's neurons displace actual sensing elements². Add in your nose, eye socket, hair, and sunglasses, and your brain is continually compensating for large portions of your visual field being useless. Since the icons presented by Project Glass are in the region occluded by hair and eyebrows, you won't even notice them unless you go looking for the interface.

Secondly, and more interestingly, your cell phone makes you go blind every time you look at it.^[pdf] The problem is focal length. It takes nearly half a second for the human eye to change its focus from something on the horizon to something at arm's length, during which time you see just as much (or as little) as you do during a saccade. The trick here is that an HMD can be calibrated to appear as if it's way far away, so your eye can view its image without having to waste time bending lenses around. The effect, when experienced in person, is somewhat striking.

The third fact that this argument misses is more important still. You have two eyes, but Project Glass is only on one of them! In order to convey how critical this omission is, I want you to conduct a short experiment. First, hold up your left hand. Second, cover your left eye using your left hand. Third, continue reading.

Texting While Walking

The next major complaint is that the glasses will present a crippling distraction. I'll agree that the glasses will be distracting, but I'm equally sure that they'll be less of a distraction than people think.

The big thing this argument forgets is that people are actually pretty good at being distracted. Next time you're at the grocery store, count how many times you look down to read your shopping list while you're still moving. While you're walking down the street, pay attention to how often you look at things around you - eye-catching passersby, nice clothing in storefronts, birds flying across the edges of your vision, and so on. Count how many people you see with their noses buried in their book or their phone while they walk. Compared to all this, getting an email really isn't that much of a problem.

I'll even provide some direct evidence that HMDs aren't distracting. The guy in the picture at right is Thad Starner. He's been wearing a head-mounted display continuously since 1993; he's also been deeply involved in Project Glass for a while. Unlike Project Glass, though, his HMD displays a full 1024x768 computer screen with an internet connection, a browser, and Emacs - far more distracting than Google's streamlined interface. I work with some of his students and talk to him occasionally, so I can tell you one thing: he doesn't run into walls very often.

Of course, "doesn't run into walls very often" isn't exactly a scientific measurement, so Dr. Starner has gone ahead and done some research.^[pdf] In particular, he and his colleagues gave some german students a shelf full of bins and a series of orders to place. Some students were given lists of items on paper, others were given pictures of which bin to grab items from, others were given orders over an earphone, and the final group was shown the order on a head-mounted display. Despite having an image floating right in front of them, HMD-equipped users completed their tasks with a third as many errors and about fifteen seconds faster than their competitors. Head-mounted displays aren't distracting; if anything, they're *less* of a problem than the average intrusion.

Too Connected to Think

The final argument, and possibly the most important, is that a permanent internet connection is bad. As you might expect, I believe exactly the opposite.

Put simply, we use computers enough that we've become used to them, not only habitually, but in that our brains have physically shifted around to work with them. Research^[pdf] shows that, if given some information and induced to memorize either the information itself or where it can be found, people are much better at remembering where information can be found. We've all observed this firsthand. We remember the name of the page on Wikipedia rather than its contents, we remember the name of the function or the class rather than its signature and we look it up in the documentation, and so on.

We're well on our way towards Charles Stross's "posthuman genius loci of the net", where a person's computer contains so much information that forced separation results in crippling amnesia. As another experiment, I challenge you to remember more than half of your address book, email or phone number or snail-mail, without using your computer. To recall a definition, a cyborg is "a person who is part machine". Not a human body with robot bits, but a _person_, a self-aware consciousness, which leans on computers to do some of its work. We are all cyborgs. Project Glass simply makes it harder for us to lose our machine halves or drop them in the toilet.

Given that, why is there so much naysaying in the first place? You already have a laptop or a smartphone that organizes your pictures, navigates for you, handles your calendar and your address book, and (by way of Wikipedia) remembers the capital of Albania so you don't have to. Most of you have it with you 24/7. I simply don't understand the objection to making it more powerful and easier to use. I make my computer handle as much of my life as it can; when I'm not doing arithmetic, I can be doing calculus, and when I'm not trying to remember someone's phone number, I can be talking with them about the meaning of life. My computer makes me a better human because it gives me the freedom to exercise my rationality and consciousness. Project Glass is something I welcome. It helps me be human even when I'm not sitting at my desk.


¹ Virtual Retina Display
² Demonstration

comments are disabled
Discuss on Hacker News

Language Wars Are Pointless

Sometimes it really amazes me when anyone actually takes language wars seriously. If I casually mention "pointless language wars" and someone leaves a comment ignoring my entire blog post, informing me that language wars are not pointless, I seriously question their priorities (and possibly their sanity).

As a veteran language warrior, I resent the claim that my efforts are "pointless". There's a lot of terrible software out there, and one of the reasons for this is that inappropriate choices were made on the outset.

Oh, was I not clear enough before? Language wars are pointless. They are pointless for 2 reasons: You are never actually arguing about the language, only design philosophies, and these language wars invariably disregard context, which makes all results of said war completely meaningless.

In this crazy rant Alex Munroe¹ made about PHP being a terrible language, he seems to be confusing "PHP is a bad language" and "PHP adheres to bad design philosophies", and even then its just design philosophies he doesn't agree with. This is all well and good, but that doesn't make PHP a bad language. It's like saying a hammer is bad because you don't like the handle - just because its not good for you doesn't mean its not good for everyone. If you want to prove that PHP is fundamentally a bad language, you have to demonstrate that almost all the philosophies that it follows are bad for everyone. You can't say a philosophy is good in one language and not good in another without accidentally tripping over yet another philosophy. A good example is his complaint about the '@' operator suppressing errors. You can suppress errors in python too, its just harder. The argument is that its too easy to ignore errors, therefore it encourages bad programming, therefore PHP is the devil. This doesn't make sense, because you aren't saying PHP itself is bad, you are saying that you believe a programming language should make writing bad code difficult, which is a philosophy. Consequently, you can't just say that PHP is bad, you have to say that every single language that does this is at least partially bad. Of course, the guy loves writing code in perl, so I suppose he prefers using a language that makes it hard to do anything.²

Let's say you actually prove that something is bad for everyone. Have you proven that its bad for everyone in every possible context? You have to do that too. The problem with language wars is that people go "Yo man whatcha using PHP for we got dis new trunk called Django that's so wicked sick goddamn get with the times homie" without ever actually asking you what you are trying to do and in what context you are doing it in. You cannot critique a language without first specifying what context you are critiquing it in. If you do not specify the context, even if its something vague like "for most non-performance critical applications", everything you say is an over-generalization and therefore invalid. There is quite literally NOTHING that you can absolutely guarantee any piece of code should do - not even the fact that it should work (for example, testing static code analysis). Because of this, unless you are saying X is a bad language for doing Y, and not simply that a given language is bad, forever, no matter what, you are doing a bad job of critiquing. Even brainfuck is useful for illustrating how a Turing Machine works. As the old saying goes, never say never (or always).

With this said, most of the points Alex Munroe makes against PHP are actually quite valid.³ In fact, if he had instead argued that PHP is a poor choice of language for building a modern, professional website, I'd probably agree ...but that doesn't make it a bad language. Maybe its a bad language for that purpose, but that's as far as you can go and still hold a legitimate opinion. There is an endless, endless torrent of people insisting that C++ is a terrible language, and it's not that their reasons are wrong, it's that they are ignoring the context of what I use C++ for. It just follows design philosophies they don't agree with in their line of work. It's fine that they don't agree with them, but uh, that's why we have lots of different programming languages and why we need to stop assuming programmers are all the same. What are you going to do, tell Linus Torvalds to code Linux using Lisp instead of C because Performance Doesn't Matter?

This problem of blindly following idioms like "Performance Doesn't Matter" and "SHARD EVERYTHING" in the database world is that you are separating the advice from the context it was given in. This makes language wars pointless and causes serious issues with the new wave of databases that are pissing off a lot of people (BUT MONDODB IS WEB SCALE) because fanboys who don't understand the context those databases were designed for simply assume you should use them for everything and therefore anyone using MySQL or PostgreSQL is a dinosaur. You can't just forget about Unknown unknowns (things you don't know that you don't know). If someone is using a language and you don't understand why, don't assume its because they're an idiot because the language is bad no matter what, assume that its because there is a variable you forgot to account for.

It's kind of like watching a carpenter yell at a plumber for building a house upside-down, except the plumber actually built a toilet and the carpenter just thinks it looks like an upside-down house.


¹ whose name took me almost 2 minutes of digging around his blog, and then his site, until I finally found it buried in the fine print on the footer.