Cykod Blog

Some thoughts on property and the direction we're moving in the twenty-tens. It's not completely insane that sometime in the not to distant future a parent will hear their progeny ask a question like:

"Dad, what does it mean to buy something?"

and the following conversation might ensue:

Dad: "Well Billy, it's like licensing something, but you can do whatever you want with it"
Child: "But that's crazy, no company would ever let someone do WHATEVER they want with their product"
Dad: "Actually it used to happen all the time, you would buy something, and then you could do what you wanted - use it, disassemble it, loan it, even sell it again"
Child: "But isn't that completely anti-capitalist? It you could sell stuff you didn't need anymore then how would companies make money. Why would be people keep buying new stuff if the old stuff worked just as well?"
Dad: "I don't know it used to just work itself out...You know free market and all that"
Child: "Dad are you a Commie? Do I need to call the thought police?"

Ok, that last piece was a little over the top, but the rest isn't all that far from where we are now.

Anything that's delivered in a digital form is already licensed and not sold. Music, Movies, Video Games, Books.

Physical goods are moving in that direction too, helped by embedded microcontrollers and software. You can't take ownership of a computer without accepting a whole bunch of restrictions on what you can do, but it gets worse. Want to sell ink cartridges for someone elses printer? Get slapped with a DMCA lawsuit for reverse engineering their faux-DRM. Want to sell an unlicensed game on console? Same thing.

Intellectual Property rights are slowly encroching into all walks of life. Want to post a video of yourself dancing like an idiot to a pop song? Good luck.

Pretty soon baseball bats will come shrink-wrapped with End User License Agreements allowing them to sue you if you use their bat in an unauthorized manner.

Combine the licensing phenomen with the credit phenomenon, and suddenly we don't actually own anything. That house you bought? Technically the bank owns it, and you owe them more than it's worth. That car? Actually, you traded in your last car for less than it was worth to upgrade to this years model, so technically you own less than 0% of that too.

Ownership just isn't for the little people anymore. It's so 2009.

This never quite made it out of the backlog back in October, but I thought the implications of a case discussed on Volokh a couple of months ago were pretty staggering. To highlight the article's quote of the ruling (significantly chopped down):

The Fourth Amendment protects our homes from unreasonable searches and seizures, requiring that, absent special circumstances, the government obtain a search warrant based on probable cause before entering. This is strong privacy protection for homes and the items within them in the physical world.

When a person uses the Internet, however, the user’s actions are no longer in his or her physical home; in fact he or she is not truly acting in private space at all. The user is generally accessing the Internet with a network account and computer storage owned by an ISP like Comcast or NetZero. All materials stored online, whether they are e-mails or remotely stored documents, are physically stored on servers owned by an ISP. When we send an e-mail or instant message from the comfort of our own homes to a friend across town the message travels from our computer to computers owned by a third party, the ISP, before being delivered to the intended recipient. Thus, “private” information is actually being held by third-party private companies.

...[snip]...

Thus subscribers are, or should be, aware that their personal information and the contents of their online communications are accessible to the ISP and its employees and can be shared with the government under the appropriate circumstances. Much of the reluctance to apply traditional notions of third party disclosure to the e-mail context seems to stem from a fundamental misunderstanding of the lack of privacy we all have in our e-mails. Some people seem to think that they are as private as letters, phone calls, or journal entries. The blunt fact is, they are not.

This is a pretty significant statement - what it means is that if you transmit over a public line (read: the internet) anything that could be read by a third party, you shouldn't have an expectation of privacy about it. In essence, this is what the tinfoil-hats have been saying all along,  and the only solution is to encrypt-encrypt-encrypt. Why? Because if you encrypt your transmissions and storage then suddenly you do have an expectation of privacy.

If the government wanted to read an encrypted email that was encrypted against your own private key, then following the above logic - even if it was stored on a third party server - they would need to get a warrant and they couldn't just read what they wanted.

Now one of the problems here is that the data would need to be encrypted in a way only accessible to you along each step of it's journey: sending, transmission, reception, storage and retrieval, otherwise since the ISP could have logs of any of those steps, your expectation of privacy would fly back out the window. 

The good news - the securing transmission part is getting easier. While very few people outside of the enterprise use certificates to encode and sign their emails (unless they like wearing the aforementioned metal-headpieces), a good portion of the email being sent is starting to be transported via SSL.  What this means is that if you only leave the ISP the transmission part, and host your own email servers, then your expectation of privacy would hopefully return since you're not relying on a third-party for reception, storage and retrieval.

The bad news - until Google releases a GMail appliance, there's no way to use an ISP for other services and be protected. Now while the 4th amendment only applies to governmental search and seizure, this has further implications for private enterprise moving to SaaS models. If the court has stated that you never should have had any legal expectation of privacy about any of your data in the first place then you need to be very dilligent in reading your terms of service. Could you sue a SaaS provider if they released some valuable statistics about your data to a competitor? Most likely their ToS doesn't explicitly mention all meta-data and derived data, so I don't know, but until it gets decided in court, I wouldn't throw out all those servers and cloudify all your business needs just yet. 

The saga surrounding oracle's acquisition of sun and the MySql debacle has grown to send tiny self-rightous reverberations through the blogosphere - with people alternatively decrying , and decrying the decrying of the GPL.

Of the former, none more so than mysql founder Monty Widenius, whose rhetoric sounds slightly self-serving:

Monty: I'm shocked, just shocked at how Oracle could use the GPL to limit freedoms!
Accountant: Here are your monthly returns on the money you made on your sale of Mysql, whose value was dramatically boosted by the dual-licensing method you guys were a major pioneer of.
Monty: Oh, thanks.

The GPL is a restrictive license. Everyone knows it. Eveyone has known it for a long time. It's the reason why people who don't have strong idealogical or commercial interest and want to release free-er as in beer-er software don't release under the GPL. They release under the MIT or the BSD. The GPL and it's even more restrictive variant the AGPL is really only for two groups that at first glance should have nothing in common: open-source zealots (I use that terms in a positive sense) and commercial enterprises.

The reason for this odd coupling is that both groups actually have exactly the same unified goal: neither wants anyone else to be able to gain a competitive commercial advantage using their software over anyone else. For the former group the story ends there. For the later group - commercial enterprises - there's an additional part of the story: except if people pay us for that privelege and we can control it.

The freedom that the GPL provides isn't for you when you are using, modifying and distributing a piece of someone else's software - it's for everyone else, and most importantly for whoever birthed the piece of software in question into the world and retains the copyright on the existing code. It's a guarantee that you can't take their software, make a bunch of enhancements and then sit on those enhancements while the money pours in - you'll need to share those enhancements with everyone else and lose any competitive edge you have gained - or talk to the creators of the software and come to an agreement as to how to divide the pot.

So is this commercial use of the GPL somehow wrong or anti-ethical? I don't think so. I think it provides the opportunity for companies to release software that is part of their core business strategy which otherwise wouldn't have been released because of the danger of someone taking what they've done and privately monetizing additions to a free release.

Now, given that that we're releasing a AGPL'd CMS take that obviously self-interested opinion with a grain of salt, just remember that free (as in beer) != free (as in speech). You can take your free beer and sell it to anyone else you like but that impassioned speech you just heard on the evils of capitalism is technically a piece of intellectual property that you can - to a fairly liberal extent - copy and reuse but you will never actually own.  Now now license that is associated with as software product doesn't necessarily tell you the whole story - Linux under the GPL is very different then MySQL under the GPL - so free (as in speech) doesn't even always = free (as in speech). Just like everything else in the real world, free comes in shades of gray.

One of the first lessons that you learn as a programmer is failure: the program you just wrote doesn't compile or it doesn't work.

We're not talking nuances here, it's not that your program "mostly" works - this is a black and white failure - it just won't compile or run for whatever reason. This is sort of unusual, as in many other diciplines you don't get any instant feedback of rejection.

Compare the english student writing a paper. There's no "publish button" that you click when you think you're done. In this case failure is in the eye of the beholder (or whoever's grading it) - but a gaggle of typos, full-page sentances or a sprinkling of emoticons doesn't give any instant feedback of the fact that there's going to be a big red "F" on the top of the page when you get it back (although it probably should)

As CS Students, most of the time if the computer doesn't reject what you're trying to do then you're usually most of the way there. Sure, your professors will mark some style points and want to see some comments, but if it runs and full-fills the techinical requirement, you're probably going to pass.

This give developers in the real world a strange failure dichotomy. We accept constant failure as a fact of life - as long as it's coming from a machine. But we have a tougher time dealing with failure if it's coming from a living, breathing individual.

Developer: "What do you mean it's wrong? It has 100% test coverage and fullfills the specifications to a T?"
Client: "But no one here can figure out how to use it"

Failure in the real world doesn't always give a black and white compile-time error - it sometimes comes at you in shades of gray. This means that sometimes, like our developer above, you might disagree with other's definition of failure as for developer's there's really only 1 type of project failure we implicitly accept:

#1  500 - Internal Server Error

But on consulting gigs there are plenty of other types of failure out there:

#2  Users can't use your software.
#3  You didn't explain to the client what you were building and it's not what they wanted.
#4  You didn't force the client to figure out what they wanted and instead built what they thought they wanted.

#2  is a development failure - it's pretty clear that you need to be able to build something that's usuable by whoever the end user is. Now doing so and doing so well is a skill that takes learning and experience. It's a failure you can really only avoid by experiencing it a few times and eventually come out richer for the experience. Accept that unless you are your own demographic (e.g. programming stack overflow must have been kinda fun) you're going to have to put some legwork in to develop something that works at the level of your audience, but that's a long discussion for another time.

Compared to #2, #3 and #4 are project managment failures caused by not putting in the time upfront to figure out the requirements.

#3  happen much more often than they should because as everyone knows - programmers are lazy, tiny gods. They are lazy in that stuff that's not fun - a.k.a. anything that doesn't involve programming - is going to be skipped:

"Programmers will not keep themselves honest. If left to their own devices, they will skimp on anything that is necessary but not fun." (Phillip Greenspun / Design Review)

They are tiny gods because they reign supreme over their tiny project-specific domains like entitled, angry tyrants, refusing to accept that what they are doing might not really be what's best for the project.

This means that developers are happy to spend hours and hours of time developing the wrong product and will take umbrage upon being told of this failure - when a hour-long meeting early in the process would have put everyone on the same page.

Unfortunately clients are people too - and they suffer from the same desire to skimp on the un-fun. Once they've hired someone they'd like to believe that their work is done and the developer will take it from here. But since the only true metric of success in consuling is a satisified client, and since clients often don't know what they actually want until they've seen what they thought they wanted, there's a chicken-and-the-egg loop that makes it difficult to succeed right at the start.

These two issues can sometimes lead to first-iteration-failure, where the first iteration of a project is a complete throw away because it doesn't match the client needs.

Sometimes there's no way to get around it. Creating the first iteration gives you and the client a domain specific language to actually discuss the project that no amount of specifications or poking and prodding of the client would work. But oftentimes a few hours of the unfun work on both the client and developers part can lead to a quicker happier project conclusion. Time spent on user stories and blocking out pages in design usually pays for itself many-fold down the line.

Failure is a fact of a life as a developer, but sometimes we need to accept that failure as not just coming in black and white but in shades of gray as well.  And clients, your need to remember: programmers are people too.