Archive for the ‘rants’ Category

On the enforceability of laws

There’s much ado today about the pain gun which HN thinks will be turned around and used on civilians. They’re probably right. But in the long run, that doesn’t matter.

You see, pretty much every piece of technology ever invented started out looking pretty evil. Computers were a way to rapidly calculate bomb trajectories. The internet was a secret government network designed to coordinate military attacks. GPS was invented to track ground and air targets.

These things don’t seem quite as evil today, do they? Computers and the internet are probably the most democratically-empowering invention ever, and we’re in the middle of a location-aware GPS renaissance that’s certainly much less hostile than an air strike.

The nature of technology is that it makes things easier to do. The idea in the DoD’s mind is to only make things slightly easier to do, such that only organizations as large as the government can do them. However, progress doesn’t stop because a large government wants it to. Smaller governments develop the technology, and then larger corporations develop technology, until finally, you and I are holding internet-connected computers with GPS in our hands.

This is the reason why the Orwellian nightmare didn’t happen: cameras became cheap enough not only for the government to buy them to spy on us, but for you and I to buy cameras to spy on them. State governments have recently figured this out, but there’s not an awful lot they can do about it.

The first casualty in the widespread availability of technology has been the music and movie industries. Until quite recently, copyright infringement that was good enough to actually pass as the original required complicated equipment–on the order of the cost to make the content in the first place. This complicated equipment was difficult to hide, was easily found when executing a search warrant, and it was expensive. Pirated copies had to be sold (instead of given away) to cover the expense.

Of course, this is no longer the case today. The device you are reading this on is more than powerful enough to copy the very highest-quality audio or video file. How far we have come from military defense networks and rocket trajectory calculators!

Until recently, it was easy to pirate content, but it was difficult to profit from it. Now it is even profitable. In spite of perhaps every country out for its blood, the Pirate Bay sails on, advertisers and all, and seems to be all but unstoppable.

This is the first and the best example, because it is almost fully played out. The pattern is this: technology is birthed to aid the elite. At some point it starts to chip away at the elite’s monopoly. It starts rendering existing laws widely unenforceable. And then it reaches a point where subverting the law is an enormously profitable market.

Let’s look at another example: encryption. Until about the 1970s, if you wanted to send a secret message you needed to employ a small army of mathematicians. If you wanted to keep your message secret from a world power, you were flat out of luck unless you happened to be the US government.

With the rise of formal private key cryptography, it became feasible, technically, to render search warrants unenforceable. Nobody was terribly concerned except the spooks at the NSA, who began feverishly trying to come up with better and cooler ways of cryptanalysis to keep ahead of the curve. They were successful for some time, and still are in a very technical sense. We know today that the NSA actually used some complex math that hadn’t been publicly discovered yet to “fix” DES to be stronger against attacks. However, as strong encryption became easier and easier to implement, it started to work against the NSA’s interests.

More and more politicians began to view strong encryption as a serious problem, and laws were put in place to ban its export outside the US. You actually had to have an export license in order to let your Munich office use your internally-developed DES software. This law remained on the books until 1996, at which point PGP and other open-source encryption software had rendered it totally unenforceable. Even in the PGP era, there were complex legal hoops that had to be jumped through–instead of digital distribution, PGP went through the ridiculous step of printing 6000 pages of source code, exporting them from the US on paper, and scanning and OCRing them, using the “scanned version” for all the international mirrors, where they were downloaded over the internet just like every other piece of software.

Of course, today, you can get military-grade encryption simply by typing an “s” after the “http” in the URL bar, and it would take the NSA a decade and a billion dollars to read your bank password. There is a whole cottage industry dedicated to very complex encryption software, and in an incredibly ironic twist, encryption is still being hailed as the holy grail to fix the failing movie and music industry.

The pattern isn’t quite as clearly marked, particularly because there are a few channels where encryption has not quite taken hold. Many voice communications, for instance, are not regularly encrypted in a secure manner, although new VoIP networks (see Skype) are often fully encrypted. This is why the NSA is so serious about their wiretap program–they know that the window of unencrypted voice communication is rapidly closing.

One potentially serious-sounding loophole is that in many countries (including the US) it is theoretically or actually possible to throw you in jail for refusing to decrypt some kinds of data. In response to this, there are now mathematically rigorous ways of encrypting data in such a way that it is impossible to prove that it is encrypted, and so by extension it is impossible to command you to decrypt it. And there are equally rigorous ways to encrypt several different data blocks in the same cyphertext, meaning you could reveal one of them on command, leaving your adversary no way to prove that there is a second layer. So this has basically rendered the “command decrypt” legislation unenforceable again.

So while this battle is playing out, and with the pattern firmly established, we turn to the future. What will be the next casualty of technology?

It seems to me that the next to go might be controlled money. In almost all civilized country, money serves as a very tightly regulated commodity, one subject to hundreds of thousands of laws, from the IRS code to business regulation to case law. Now some of you are thinking “But banking regulation keeps us safe–surely you are not arguing against it!” Technology did not care if we were morally in favor of copyright law, and it didn’t care if we were morally in favor of wiretapping laws. It simply gave everyday people a viable means to insulate themselves from both. I think the same thing is about to happen with money.

I can envision a future world where the IRS is simply incapable of determining how much money you made (and unable to tax you for it), where the private investigators are unable to investigate your credit card purchases, and where the governments of the world are unable to print more just to get themselves out of trouble. The flipside of deregulation is that consumer protections will also disappear–you cannot enforce bankruptcy protection if there was never a traceable debt to begin with.

Of course, this will cause every civilized government to fail, because governments depend on tax dollars. Do not fool yourself into thinking that this is a reason that it cannot happen–piracy will probably kill the record labels, but that fact hasn’t stopped it.

The easiest way to convince you that this is going to happen is to say “you can watch it happening already”. How many products do you buy from Amazon sales-tax-free? You are supposed to write the state a check for that. Already the entire sales chain that was used for well over a century to get mass produced goods in people’s homes has been virtually undermined. If it is easier to ship your cleaning sponges from a warehouse in New Jersey than it is to walk down to your local Wal-Mart, how long will it be before a warehouse outside of US jurisdiction is cheaper than both?

You also see anonymous banking as a very popular research topic. Right now there are mostly papers about it, and a few silly-looking implementations. It’s like cryptography in the 70s. If back then somebody said that the research was going to lead to subverting a dozen industries and severely curtailing the powers of the US government, you would be laughed at. Today, the cryptography battle is almost won.

But perhaps most convincingly there is a huge need to make money untraceable. Some of this probably comes from the highest levels of the US government as a way to move spies’ funds around without letting on to other governments. China has a huge incentive to prevent the US from trying to print its way out of a depression. But businesses and even normal people also want to reduce their tax liability (and increase their privacy safeguards). So you have the same demand slope for untraceable money as for digital copying and strong cryptography.

And so when I see articles about new government tech like the pain gun, and I see very smart people getting very upset, it strikes me a bit odd. The prevailing wisdom seems to be that we live in an oppressive legal world that desperately needs a reboot, and Orwell is lurking right around the corner. Perhaps this is true, but it is only true on paper. In practice, technology seems to be giving us back our rights even as the law fails to protect them.

And technology bestows rights in a way which is true and real far beyond the law. The law can be changed, but you cannot undiscover AES. The law gives you rights as a fiction, but technology gives you rights as a fact.

The User Experience and App Review

So. It’s fashionable lately to whine about app review. I’ve done it. I’ve blogged about how evil it is.

Being at WWDC though, and hanging around Apple reps 24/7, I’ve started to drink the kool-aid. Now, I still think app review is often terribly unfair (I’ve had some absolutely awful rejections). But. I’m kinda starting to see Apple’s point. If you were looking for another article to enforce the mob mentality and get your juices flowing, you can stop reading now.

The User Experience

The reason app review exists is because it enhances the user experience. Jobs has said this. Apple PR has said this. Apple engineers have said this. Apple legal has said this. But I don’t think, in a very serious way, many developers have actually considered this statement on its face.

You see, from any other company, it would be a joke, or worse. On the level of “We’ve raised our prices to serve you better.” The sort of parroting that happens out of fear that it will be quoted in a class action lawsuit somewhere.

However, I’ve come to the conclusion after speaking with high levels of Apple insiders that Apple is indeed being deadly serious about user experience.

Part of the huge disconnect comes because I think most developers look down on mere users. In today’s world, the number of people who really want to use computers is pretty small. Real people want to browse web sites. They want to get e-mails. They don’t want to use a computer. They don’t want to have to learn the file metaphor. They don’t want to have to learn to use a mouse.

When developers talk about usability, we’re talking about GUI vs. commandline, or mac vs. linux. Nobody cares. The difference in usability is so minuscule for a normal person that it can hardly be measured: that is, everything sucks. It might be just a hair easier to use Apple Mail than Outlook. It’s certainly prettier to look at. But that’s the extent of the difference.

We’ve forgotten what it’s like to be frustrated by a mouse. We’ve forgotten what it’s like to not know what “IMAP” means. We’ve forgotten what it’s like to forget what we named that file or where we placed it. At this level of computer-uneducation, the sort of “prosumer” usability gains from Mac OS just don’t exist.

When developers see these people, we tell them to RTFM or to learn how to subscribe to the mailing list, or even things that (to us) are really trivial like drag this app to your Applications folder or control-click with that icon selected or “type it in spotlight.” All these require the parallel mental understanding of at least:

  1. A conceptual idea of what it is the user is doing (at least if he ever wants to do it again)
  2. Dexterity to perform some potentially challenging keyboard-and-mouse combos
  3. At least one jargon term they’ve never heard before, making them feel stupid
  4. The chance that, due to some weird hardware/software configuration issue, the right thing won’t happen, something bad will happen, or viruses from space will infect their computer.

Contrast this with iPhone OS, where the steps to do just about anything are:

  1. Touch stuff
  2. Nothing bad ever happens

As developers, we underestimate the order of magnitude of this distinction. We learn a new programming language once a week. Pro users learn a new version of Final Cut once a year. Your mom might learn how to send e-mail once, if you’re lucky.

And so, while we’ve laughed at Apple’s claim that Google Voice was rejected for a user experience issue, rather than an anticompetitive issue, consider the assertion on its face: mom installs the GV app. Maybe she even makes calls with it, some of the time. But she wonders why it only works occasionally, having never even entertained the idea of a dialing “program” before, and using GV over the phone’s native dialer is far from her mind. She gets confused–she has these notifications for voicemail, but they’re not in the usual voicemail place? She sends SMSes, but some of them aren’t recorded in GV? Maybe that will get fixed when iOS4 introduces support for “multitasking.”

The real place to have GV support is in the OS itself–perhaps refusing to do so is anticompetitive. But Apple’s statement is certainly true: a GV app is a serious usability issue for normal people.

Developers start with the assumption that the user is wrong. The user needs to be re-educated. Don’t delete your mail, archive it. Don’t power off your computer by pulling the plug. Use “documents” for documents, don’t put your downloads in there. Stop clicking “allow” on all those prompts. Don’t use IE, use <insert-browser>.

Apple is starting with the assumption that the developer is wrong. Developers write software that is way too hard for users to use. Developers need to throw away old metaphors like “save” and “load” and make things Just Work (TM). And if it can’t Just Work then don’t even do it in the first place.

App Review = $$$

I read an article the other day about a person who died because of a third-party dialer on Android.  Can you even imagine if an article like that was written about the iPhone?  I mean it’s obviously not Google’s fault.  But in the mind of your mom who just watched a scary Fox News piece on it… it kinda is.  Now she’s too scared to buy apps anymore.  Good thing she has an iPhone, were nothing bad can ever happen.

A free app market is kinda like terrorism.  Not many people really get hurt, but due to psychology it’s way scarier than the mundane things we really should be worried about.  Especially in the minds of people who don’t really understand technology.

So if there was, say, just a single app in the store that accidentally deleted all your data–how many newspaper articles would be written about it?  How many people would swear off buying apps?  By how much would the app market shrink?  How much would it cost you personally, competent app developer who doesn’t delete anybody’s data?

If one app deletes a customer’s contact list, that anger will be directed at Apple. If one app manages to hit 100% CPU for an hour and drain the user’s battery, that anger will be directed at Apple. If one app gets a kid busted for looking at porn, that anger will be directed at Apple. Developers in theory know better than to direct that anger at Apple–yet in the same breath we blame MS for creating a shoddy architecture that allows malware to thrive.

Already, newspapers don’t need any excuse to blame technology for today’s ills. Any day now, Australia or Jack Thompson or somebody’s ready to ban the Internet. Apple wants to pull itself entirely in the opposite direction–to be totally above reproach. They want those articles to be written about Android.

Fallacies

Due to psychology, consumers are irrationally afraid of bad apps.  But developers can be irrational too.  Here are a few amusing fallacies I’ve heard against the Apple market:

“There’s crap on the market already, so opening it up can’t make it any worse.” Why not?  Seriously, why not?  Just because it’s X bad now doesn’t mean that performing some action A won’t cause it to be 2X bad.

“Android has an open market and it’s doing fine.” If by “fine” you mean people aren’t buying anywhere near as many apps.  You have two things working against you on Android:  1) The people who buy Androids are more often than not developers, who either write their own software or are used to FOSS apps and are conditioned against paying money and 2) Any “real users” who pick up an Android device have the same barriers to buying apps that anyone not on an iPhone has:  (irrational) fear of bad things happening.  Paradoxically, an open market leads to reduced consumer trust and reduced consumer spending.

“Apple could use a community policing policy and that would work out fine.” It would work out fine until the first article about a third-party dialer causing somebody to die.  At that point, sales both of iPhones and of apps would drop off pretty sharply.

“Maybe with some consistent, clear rules, app review would be better.” No, it would be worse.  Right now, there’s (really) only one (secret) rule.  Don’t tell anyone I told you…

The One Rule

There’s only one rule on the app store.  Here it is:

Make your app a magical experience for ordinary people.

Things that are not a magical experience include:

  • Crashing
  • Not doing what the description says it does
  • Using private APIs (a.k.a. crashing on iOS5)
  • Being “slow”
  • Being hard to use
  • Having a sucky cross-platform GUI
  • Running in a VM, a.k.a. killing the user’s battery life
  • Being not roughly worth what you charge for it (“I Am Rich”)

Almost every rejection ever is a violation of The One Rule.

Conversely, if you follow the One Rule, you’ll find you can break a lot of the things in the SDK agreement.  Providing video recording on the iPhone 3G?  Turns out you can use private APIs.  Writing themes for your game?  Turns out you can use Lua.  The SDK agreement is just writing out a lot of things that are somewhat tangential to The One Rule, in a failed attempt to make app review seem objective.  Well, it’s not.  But that’s not necessarily bad.

Other Rejections

“My app got rejected for some other reason!”  Possibly.  The problem here is that Apple gets like 10,000 submissions a week or something ridiculous.  The best QA team in the world would have trouble with that number of submissions.  Mistakes are made.

Personally, I would love to be able to front, say, $99 or so per submission to get a serious app evaluation, maybe even with feedback from an Apple UI designer (currently I have to fly to WWDC to do this, and only once a year).  As a professional app developer, I would have zero problems with fronting some cash to get my app looked at if it meant an “express lane” better-quality review, with actual feedback.  At least I wouldn’t be in the same bin as the crap submissions.  I think Apple’s concern here is that it wouldn’t be “fair” to poor developers.  So keep the same “free” review lane, and add a premium lane.  Problem solved.

Conclusions

Apple might be a little misguided.  They might be treating developers poorly.  But they’re making a hell of a lot of money doing it.  Who are we to say that they’re doing it wrong?

This quote from a developer I think really sums up how a lot of developers feel:

If the end result has and continues to be shoddy then maybe there’s only one way to vote — with your feet.

My rebuttal is simply:

If everybody’s flocking to iPhone, doesn’t that mean the result is better than shoddy?

Backups

I keep trying to find a cloud service that will let me back up all my computers (3TB) for a reasonable price ($<500/yr) and let me manage it (no Backblaze, Mozy, etc.)

It continues to amaze me that nothing comes close to simply colocating a NAS.

And if you think about it, even colocating 3TB is horribly inefficient. Splitting a Backblaze Pod 20 ways would be a huge cost savings.

For the price of S3 (~$5500/yr, not even including bandwidth), I could colocate 7 RAIDed NASes ($700 NAS, 4-year life, $50/month colocation fee).

If me and a couple of friends agree to exchange NASes to save on colocation fees, I could have 31 NASes for the price of S3.

For maybe 50% the price of S3, I could colocate a Backblaze pod and have 67TB of data storage, 22x my need.

This has to be a problem that affects absolutely every computing professional (and even a lot of nonprofessionals–gamers, ad agencies, etc.). How can the only viable solution be roll-your-own?

5 Lessons Learned While Being a Freelance iPhone Developer

I’m doing freelancing full-time this summer.  Here’s a brief summary of what I’ve learned so far.


Lesson 0: Be good.

The key to being a successful freelancer is being good at what you do.  If you are bad, no amount of business wisdom will save you.  In the iPhone business, this means:

  • Write a half a dozen or so apps and get them through App Review.  Kind of obvious, really
  • Troll the official and unofficial developer community hangouts and follow what is going on, especially with regards to new “unwritten” app review guidelines and practices
  • Stay up-to-date with the latest beta SDK documentation so you know what’s coming
  • Spend a lot of time trying out iPhone apps
  • Spend a lot of time learning new SDKs and APIs

Lesson 1: Say “no” a lot

Apple wins by saying “no” to features.  It makes sense that in Apple’s market, you win by saying “no” to clients.  Some examples:

  • Client wants to add lots of really complicated features.  But you can solve 80% of the problem with a simple solution.  Simple solutions are easy to maintain and can always be extended later to recover that last 20%.  If the client can’t understand this, perhaps they shouldn’t be partnering with Apple, the king of simple.
  • Avoid visual overload.  This is a design aesthetic, but it’s key on Apple platforms.  Again, if the client doesn’t get it, what other parts of the HIG is the client going to fight you about?
  • Don’t negotiate on estimates.  I’ve had dozens of people who want me to come down 5%, 15%, or 50%.  If it was going to be less, I would have quoted less.  If the start of the relationship is a spat about $500, what does that say about the rest?

Lesson 2: Filter clients fast

If you are good (see Lesson 0), the amount of work available to you is effectively infinite.  Every person who has held an iPhone has an idea for an app and dreams of riches.  The number of people who can take that idea and convert it to a product, on-time and on-budget, however, is vanishingly small–perhaps 10,000 good developers at most.  So only take the best clients.

This concept is a lot more counterintuitive in real life than it is on paper.  You are looking somebody in the eye who is offering you $5k (for a $6k app), and turning them down, because you know that next week somebody will call you who is willing to pay full price.  It means turning down a stellar multi-app repeat client who pays on time but is extremely picky about the background color of unchangeable Apple UI controls because you know that right behind him is another stellar client who trusts your (and Apple’s) professional design judgment and will be a lot easier to work with.  Turning down a deal in-hand that’s “ok” but less than stellar simply goes against all intuition.

As soon as I have any idea at all what the project will be, I quote new clients a price with a margin of error of a couple of thousand dollars.  I do this before investing any work into writing an estimate or even hearing much about the project.  I need to weed out the “revenue sharing” people instantly, not after even one hour of my time.  There are simply too many of those guys out there.

Lesson 3: Don’t bid

There are a lot of bidding war sites out there like iPhoneAppQuotes.com and GetAppQuotes.com.  Leads from them aren’t worth the time it takes to write an estimate.  Here’s why:

  • Competent developers already have plenty of work.  So the number of competent developers on those sites are pretty small.  So if you’re a developer, you’re bidding against incompetent people.
  • Those incompetent people you’re bidding against?  They will quote a lot less than you.  It doesn’t take much money to not deliver a project.
  • All those clients (speaking from experience here) are either clueless or penny-pinchers.  The reason they’re putting projects up for bid is because they want it done (or not done, as evidenced by the responding developers) as cheaply as possible, even if it sucks.

Fast food is cheap.  It’s the same everywhere.  Any fool can be taught to make it.

I am not in the fast food business.  I am a chef.  I juggle Apple, clients, changing HIG guidelines, changing SDKs, tools, documentation… I design good layouts.  I think through small-screen UI design.  I pay attention to battery life.  I look at what the client wants and I see past the requirements and into the real business problem.  I anticipate what they really want, and I find the right balance between features and complexity.  Those are specialized skills.  They’re not cheap.  They’re not replicable.  They’re not scalable.  And if you give that speech to somebody who’s trying to order a burger at McD, you’re never going to get anywhere.

A lot of people are worried about lowball foreign developers “stealing” all the work.  I’m not concerned, any more than the 5-star chef is concerned when McD opens next door.  It’s not within 100 miles of the same market.  I will solve the problem for you and bill you a price to match.  Fast-food developers will copy and paste something off a forum somewhere and you’ll be stuck in revision hell forever until you give up and hire someone new.

Lesson 4: Revenue sharing is only mostly evil

In the past, I’ve come down pretty hard on revenue sharing:

If you’re going to offer something stupid like “revenue sharing”, just walk away.  Developers are going to laugh at you.  I have a “revenue sharing” deal already–I do development work, and Apple sends me a monthly check.  The only way to compete with that is to pay actual money up front.

I still think this is mostly right.  I have all the revenue sharing agreements I want already: with Apple.  And there’s still no shortage of people offering me a 50/50 split for their “app idea”.

However, I have begun to offer a 5% discount for a 3c per copy royalty for certain projects where the clients are known to be reliable/honest and the product is sound.  This gives me a little bit of residual income and a little bit of risk.  The smart clients realize that it keeps me invested in their projects.

Conclusion

I’m learning more this summer than I’ve ever learned in a classroom.  Being forced to make actual money is perhaps the best teacher of all.  Why don’t we expose students to something like this before they enter the workforce?

On Closed Systems

> We lose nothing by having closed systems.

For good or for bad, for the past 25 years or so, programmers have effectively been subsidized in that the tools to design and create programs are effectively the same as the tools to *run* programs.

So every system, simply by installing a compiler, is ready to write computer programs.

Early computers didn’t even have that step. They had assemblers and basic in the ROM. It was assumed that you were going to be writing programs; how else were you going to get computers to do what you want?

The iPad/iPhone is the latest and greatest step in that huge gap. A little uneasy, for some of us, perhaps, who grew up with QBASIC on-device-coding and can’t imagine any other way.

But that is sort of a straw-man issue. You have to buy a real computer, so what? There’s a closely-related, but way-more-troubling problem.

App review.

App review is painful. I’ve had two apps axed by Apple not for bugs or for security issues, but because, quite simply, Apple didn’t like them (technically I had 3 such rejections; one was “reversed” on “appeal”).

Think this doesn’t affect you? It does. Google Voice found out the hard way. It was easier for them to rewrite their app in HTML5 then to talk Apple into letting it on the app store. Same goes for Google Navigation, that will never see the light of day.

For every app that you hear about, there are hundreds (I suspect more like thousands) of developers who had an app rejected and quietly went away.

That’s the danger in these new devices. Not that you need a computer to develop for them. Not that the apps are sandboxed and you can’t animate your icons or you require some ridiculous API nobody should ever need.

The problem is that Apple can–and, in fact, does–reject well-behaved applications that it simply doesn’t like. Not just the buggy ones. Not just the malicious ones.

That’s a thought that should chill every developer to the bone.

Year of the Linux Desktop

A lot of developers (myself included) have expressed disappointment in the app store on ideological grounds. Can’t install your own software! Apple keeps competitors off the platform! Apple doesn’t let innovative apps through!

But there’s another angle to this that nobody’s covering. The app store keeps piracy off the platform. Not because it makes buying easier than pirating (which it does), but it also makes pirating hard. You can’t be running the latest firmware. You have to forego security updates. Apple’s own development tools often have unexpected behavior on jailbroken devices (not intentional, I think. Just Apple never bothered to test it).

And so developers are pacified because piracy is constrained to those people who wouldn’t have bought anyway (in a way that computer apps aren’t)[1]. This sort of stronghandedness hasn’t worked on other platforms because the users are up in arms. Extra DRM isn’t a feature.

But in this case, the app store acts like an insurance policy. None of the apps are going to wipe out your data. They’re not going to hook into your OS and break Dashboard. They’re not going to forward themselves to everyone on your address book. Users are willing to put up with buying more software if it actually works. And so this is an acceptable trade for them.

And meanwhile, Apple is sitting in the back, pocketing lots of cash[2]. They’ve pacified the developers with more money (less piracy), and they’ve pacified the users with software that works. They’ve solved the two biggest problems in the industry, and they’ve been incredibly successful as a result. The major personal computing platforms of today are no longer desktop and laptop PCs. They’re devices running the iPhone OS.

2012 may very well be the year of the Linux desktop. But only because people using Linux might be the only desktop users left.

Your Wi-Fi Rights FAQ

After having a few run-ins with various over-enterprising institutions, I’ve gotten a pretty good grasp on the state of US Wi-Fi law.  Behold, a FAQ.

First of all, you have a right to run Wi-Fi networks, period.  The landowner can throw a hissy fit all they like, but (more often than not) you can still set up your hotspot.  The rationale is pretty simple.

1.  The 2.4GHz band is owned by the public.  This isn’t a “landowner’s right”, where each landowner “owns” the radio waves traveling over his/her particular land.  It’s like airspace.  American Airlines doesn’t consult with you before they fly planes over your house; they consult with the FAA.  Similarly, you don’t consult with the landowner before broadcasting radio waves, you consult with the FCC.

2.  The FCC has given you permission to broadcast on 2.4GHz (erm, the part that WiFi uses anyway, there are some IRM bands that are still licensed airwaves).  This is like the FAA saying you can fly over above 3500 feet–who you’re flying over has no say in the matter.

3.  Claims of “you can’t use hotspots because they interfere with our network” are not legally sound.  In the eyes of the law, “their network” is no more legitimate than yours, and they have no claim (either through landowner rights or through “first use”) to the airwaves.  If they want their own band, they can pay the FCC for licensed spectrum.  Otherwise, they have to share it with you/everyone.  Period.

4.  This leads to something extremely interesting–it’s perfectly legal to “jam” unlicensed 2.4GHz space (as long as you don’t interfere with licensed space or broadcast louder than the normal WiFi ceiling).  In particular, it’s perfectly legal to use beacon-layer flooding (bringing up lots of imaginary hotspots) or to talk over transmitters (as long as you don’t go above allowed transmit power).

5.  You cannot “sniff” conversations (encrypted or unencrypted) to which you are not a party (47cfr15.9).  There was an incident in the not-distant past in which an organization was sniffing wi-fi packets in order to determine the identity of persons operating “unauthorized” networks.  This is illegal.  Furthermore, if the AP is encrypted, it very likely meets the “access without authorization” test, rendering it a federal trespass crime.  It is also my considered (but untested) opinion that breaking WEP/WPA is additionally DMCA violation in some cases.

Okay, well maybe I can’t ban radio transmission, but as the landowner, surely I can keep hotspots (the physical boxes) off my property?

Actually, no.  Sure, if the Hotspot Bandit runs on your property, you can issue him a trespass warning, and he and his hotspot can go broadcast on the curb.  But if we’re talking about a legal resident / tenant, they can have whatever hotspots they want.  Huh?

It’s simple, really.  There are rules about what landlords can and cannot do.  They can’t not rent to black people or to women or to handicapped people.  They also can’t tell you that you can’t use a hotspot.  The FCC’s reasoning goes like this: since the 2.4ghz spectrum is unlicensed, anyone can broadcast on it.  The only reason to ban hotspots is to prevent people from accessing public airwaves.  Therefore, landowners can’t ban them.

The FCC has ruled like this on case after case–against residential landlords, airports, everybody.  As long as you have “exclusive use” of an area (basically, you can deny random people off the street entry), you can install a WiFi hotspot.  Period.  (You can also install small satellite dishes and many other kinds of antennas, and you can even put things on a mast above the roofline, subject to some safety restrictions.)

But my lease / the rules say X and Y!

I can write a lease that says you can’t have any Asian guests.  That doesn’t make it even remotely legal.  And if anybody tried to enforce it, there would be hell to pay.  Same with WiFi.

But… but…

Sorry.  That’s clearly and unequivocally the law.

Dear Steve Jobs,

Hi Steve,

I’m an iPhone developer. I’ve got four apps live in the store, one in review, and several more I’m working on. Plus the 3-4 apps that I’ve written for clients that they have listed under their own accounts.

TUAW says you pulled GV Mobile. Not only do I use this app every day, but I’m developing something similar (different service; similar functionality). This sort of thing strikes fear into the heart of app developers. Quite frankly I’m not sure about finishing my app anymore. There’s no place I can go to get Apple guidance on whether it will be approved.

TechCrunch thinks it has something to do with the official Google Voice app getting rejected, but I don’t want to speculate.

Anyway, I think that was a really crappy thing to do. And it was especially crappy that you (according to him) wouldn’t give him written confirmation because (according to him), you were “scared he would post it“. I’ve independently been hearing rumours of a secret cabal of app reviewers who call us when your rejections are too “sensitive” for normal means. If that’s true, it’s not very nice, Steve.

App developers are your friends. Thanks for the increased transparency with the software betas, but my word, all anyone really cares about is transparency from the app store.

–Drew

Why the GPL sucks

I have a lot of respect for the work Richard Stallman has done for software. He’s written some really awesome things, like Emacs and GCC. And he was one of the first to get people thinking about open source and free software. He was a pioneer in his field, and an all-around smart guy. And then…

Saint iGNUcious

Saint iGNUcious

Which, hey, cut him some slack, right? The guy wrote Emacs! If he wants to put a disk platter on his head to celebrate, then… that’s cool.

But then… things got weirder and weirder. First, he came for X Windows, which is totally free and open-source. Then, he started rallying against MS’s efforts to turn Office into an open standard. Now, he’s stirring the pot against the free and open-source Mono project with FUD that’s been debunked again and again, prompting even Microsoft to weigh in, and yet Stallman still goes on in his own little “we need a comprehensive patent license” world, completely oblivious to the comprehensive patent license right in front of him.

All that to say, he basically created OSS as we know it today, but that’s no reason to sit back and watch him try to actively destroy it. When Microsoft is the one promoting open standards and open source, and Stallman is the one spreading FUD about pure OSS stacks and pure open standards, that should cause someone to think “Hey wait a minute, this seems a tad bit backwards.” What we are now seeing is, to a large extent, that the two teams have switched ideologies. Stallman, who spent so much of his life opposing big corporations, has forgotten whatever view he used to hold, and is now opposing Microsoft just because, even when it totally contradicts his own former principles.

Which brings us to the GPL. I don’t even want to get into the GPLv3, because that’s been endlessly debated, and as it turns out nobody really important uses it. So I think there’s a certain widespread de facto consensus within the FOSS community that it’s not a very good idea. So when I say “GPL” I really mean v2, because that’s the only one with any sort of widespread use.

For those of you who don’t know, the GPL says (as an extreme oversimplification) that you have to make the source code available to a piece of software when you distribute it. So if you took the popular GCC compiler, and modified it to be faster, and sold it, you would have to distribute the source code of your modification along with every binary copy, and now everybody knows how you made it faster, and you have a hard time making any money, and maybe go out of business. [This is an extreme simplification. I'm not going to get into patent law and trademark law, which are sometimes used (sometimes ineffectively) to make the source code you distribute difficult to actually use.]

Now, you may say “They’re profiting from GCC! People worked hard on that!” And that is very true. It’s rather unfair for other people to profit from your work. But we must be consistent. Red Hat and Novell make loads of money off other people’s work; they simply do it in a way that complies with the licenses (more on this later). And they’re generally rather well-liked in FOSS circles. So profiting off other people’s work can’t be very bad if we let Canonical get away with it and we still like them. It’s got to be an ideological thing. So what can it be?

Releasing FOSS software is like putting a toilet on your lawn with a sign that says “Free”. The first version is probably a pretty shoddy toilet. The author made it to scratch his own itch. 99% of the time, he’s not interested in helping you plunge it. He’s not interested in modifying it to be a wheelbarrow. He made it to solve some particular problem, he decided maybe somebody else could find a use for it, and he put it out on the lawn. His itch has been scratched; his problem has been solved; the thing is done.

Except not. If I come along and want to make the shoddy GPL toilet into a wheelbarrow, if I pour blood and sweat and tears into the wheelbarrow, if I do original research and and custom-mold frictionless ball-bearings and spend millions on case studies and have a team of people… I must also put it out on my lawn for free because somebody else did that with the shoddy toilet I started with. This is called “protecting your freedom.” Wait, what?

Okay, that was a contrived, straw-man example. What actually happens is that very, very rarely does blood and sweat get poured into shoddy GPL projects because everyone knows you’re going to have to give it away. It does happen in cases where somebody (Linksys, I’m looking at you) doesn’t understand how the GPL works, and ends up getting forced to give the software away. It does happen in cases when there’s some other developer looking to scratch a significantly more complicated itch and uses the shoddy toilet as a stepping-stone. It does happen in cases where somebody backs the project as a sort of goodwill/advertising move. But by-and-large, shoddy toilets never make it into polished wheelbarrows.

Now let’s be clear. Neither copyleft nor BSD-style licenses are going to help you much, as the developer. A copyleft license restricts the way in which somebody downstream can use your work, and a BSD-style license basically lets them do whatever they want with it. In some cases maybe you have a cool dual-licensing strategy or negotiate contracts with Red Hat or something. But in the normative case, the only difference is that either cool wheelbarrows exist or they don’t, and neither of these choices have a net positive effect on you. (The fiction, the idea that somebody will make an awesome wheelbarrow, and give it away, is simply that: a fiction. Any game theorist should understand this.)

But there is a net effect on software development. Who makes money off GPL code? We go back to Novell and Red Hat, who test and package this software. And we see a trend–GPL code helps software testers make money. It helps QA people. It helps the people who answer the support phones. It helps everybody except software developers. Oh, maybe Google will pay them a salary as a goodwill gesture. But it’s really, really hard to make money from developing FOSS. You can make money supporting it. You can make money testing it. But no money developing it.

Back to the BSD model. Who makes the money now? Software developers. The people who develop and design the wheelbarrow clean up. Now granted, the shoddy toilet creator gets nothing. But the field as a whole does a lot better. Now the developers are calling the shots, instead of the QA and support people. Now you can get a job designing wheelbarrows, and so on.

That’s the practical argument. Now here are some ideological ones.

First, copyleft licenses like the GPL are widely considered by their proponents to be “freer” than BSD-style licenses. This is the wrong word. The word “free” means this:

not under the control or in the power of another; able to act or be done as one wishes

As we’ve seen, what the GPL actually does is it gives you, the author, more control and power relative to BSD. Maybe this is good; maybe this is bad. But it is certainly not more free. By definition it is less free. And anybody who says otherwise has gotten lost in their own logic.

What copyleft proponents actually mean when they say “free” is they want people to behave well. They want upstream people to be recognized and compensated and they want downstream recipients to release their code so that the whole community can benefit, and they want people to be “fair” to each other, and so on. This is all fine and dandy, but it is not freedom. It’s freedom insofar as downstream recipients are “free” to do what you like, and not free to do things you don’t like. And unlike proprietary licensors, you like some very good things–open source, reusable code, etc. etc. And you dislike some very bad things–people stealing other people’s work, not giving credit where credit is due, etc. But don’t confuse this sort of utopia with freedom, because they are miles apart. Freedom means that somebody has the ability to do things you don’t like. This is what we mean by “free speech”, the ability to say things others don’t like. This is what we mean by “religious freedom”, the ability to practice things that others don’t like. The GPL gives users the “freedom” to do what you like. This is a totally different cup of tea.

Hopefully you’ve seen that horrible bit of bytes that comprises the “You wouldn’t steal a handbag” nonsense. The key difference between stealing a handbag and stealing a film, is, of course, that in one case we’re short one handbag, and in the other case, we’re not short one film. The MPAA and friends like to argue about “lost sales”, and so on, but most reasonable people agree that this is by and large a bunch of nonsense.

This same logic applies to software. When somebody forks a project and makes it proprietary, they haven’t “stolen” the project. All the code you’ve written is still free and open right in front of you. What they’ve done is improved what you’ve built and given people another choice (namely, a proprietary one). You’re not out anything. You’re not short anything. Now granted, it’s not very nice, the same way that downloading a movie off bittorrent isn’t very nice to the movie industry. But the only way you could be “harmed” is if people start switching to the proprietary fork, and your software loses popularity. And if that’s your concern, I’ve got news for you: writing software is a horribly shoddy way to become popular. Take up a different hobby.

Now you may say “But wait, I have some sort of Author’s Right[TM].” And that’s very true. You do have an author’s right. But other people [should] have an author’s right to the code they write. And if somebody makes a serious advance on your shoddy toilet then they should really be able to license it how they see fit. And so if your project is a shoddy toilet project, you really shouldn’t exercise your author’s right by using the GPL, because that prevents other software developers from properly exercising their author’s right [back to that definition of freedom thing again].

At the base of it, I think, the GPL is selfish. When you GPL a project, you’re saying “This is mine, and if somebody else changes it, they’d better give it back to me.” It’s cloaked in better words of course (“This project is the community’s and you’d better give it back to us“). But for me, anyway, saying that would be lying to myself. More often than not, the first release has no community, so there’s just the developer.

This whole time, we’ve been dancing around what constitutes a “modification” and a “work”. Any real software developer knows the distinction between one software package and another is a bit arbitrary. At the end of the day, a microprocessor runs through some statements in order, and it doesn’t know where one package begins and another ends. Packages are purely an arbitrary construction for human minds. And now we get into real trouble.

Say we have two software packages on the same hard disk. Those are clearly separate works. How about two packages as part of a system (like cc and ld)? How about two binaries that communicate via pipes? That communicate via shared memory? How is that different from two libraries that are dynamically linked? And how is the latter any different from being within the same compilation object? How do we deal with “modules” in a dynamic language like Python? Do we treat them like seperate processes, seperate libraries…? How do we deal with “linking” in a JIT-type language? Can we license a DATA assembly section under a software license? If so, can we release text under the GPL? And on and on it goes.

The FSF have acknowledged some of the madness, and so we have a proliferation of licenses like LGPL, GPL, Affero, and on and on it goes. The GPL treats the software “package” as a unit, and any changes to the package must be open. The LGPL uses the “library” as its base unit, and you can link an LGPLed library into a proprietary software program, with some very complex restrictions that basically let people change the version of the LGPLed package you linked to. Affero tries to go the whole nine yards, saying that if you run Affero code on a remote server and let people make queries of that server over the Internet, that counts as “distribution”, and so you must release the source code. (How that is enforceable I have no idea.) As best as I can tell, this stemmed from the sentiment that “How dare Google make gobs of money by making an end-run around the GPL by running software on their own servers,” which is a level of selfishness on the FSF’s part that I hope is self-evident.

But of course there’s no such thing as a library, or a package, or even a web server, except as a legal fiction. There are just x86 instructions. Whether we separate the code by a thread ID number or by an undersea cable, it’s just code.

And here is where we’ve arrived: we have “free” licenses that force developers to construct large and complicated legal and technical barriers between the resources they have available to them and the problem they want to solve. What started out as a shoddy toilet on the front lawn has become a complicated and technical and legal jungle of licenses and compatibility and barriers and linking and languages and words and terms.

And I’m tired of it. This is not the software movement I signed up for. I didn’t sign up to let testers and QA people profit off the work of developers. I didn’t sign up to create a whole series of artificial barriers to prevent people from using my code. I didn’t sign up for misguided and deceptive rhetoric about how “freedom” needs all these complex restrictions.

I signed up to put a shoddy toilet on my lawn, in the hope that some poor soul would find it useful.

C#: Poisoning the well

RMS has just published a position paper against Mono.  FTA:

Debian’s decision to include Mono in the default installation, for the sake of Tomboy which is an application written in C#, leads the community in a risky direction. It is dangerous to depend on C#, so we need to discourage its use.

The problem is not unique to Mono; any free implementation of C# would raise the same issue. The danger is that Microsoft is probably planning to force all free C# implementations underground some day using software patents.

This is the worst sort of fear-mongering.  First of all, in addition to the better-known Mono project, the FSF has their own free C# implementation.  The reason you haven’t heard of it is because it’s unable to compete on merit with Mono; its only (purported) advantage is its GPL licensing (Mono’s licensing is more piecemeal: GPL, LGPL, MIT, depending on the component).

Note that RMS is merely poisoning the well here; Microsoft is “probably planning” this or that, but there’s no halloween document; there’s no evidence of Microsoft every suing anybody over .NET; in fact the only public interaction Mono and Microsoft has had is to announce the (Mono) Moonlight project as the official Linux implementation of Silverlight.  This means that a key part of Mono is the official, Microsoft-supported way to use C# code on Linux.

Oddly, Stallman has no problem with plain old C, which is covered by numerous patents by another convicted monopolist, AT&T.  If his argument was ideologically sound, he would oppose C, C++, and every other popular programming language that FSF software is written in.  In fact, he only opposes languages like Java and C#, which pose a credible threat to C/C++ popularity, which the FSF is heavily invested in, being that they hold copyright on a number of C/C++ tools.  The success of C#, a technologically superior solution for many problems relative to C/C++, which is on equal legal footing with C/C++, which is being used in 100% free software stacks (GPL and MIT all the way down), to advance the cause of Linux on the desktop, is somehow bad and evil.  This is absolutely absurd on its face, even from Stallman’s own purported ideological views.

Jo Shields wrote a fantastic piece a few months ago that is incredibly well-grounded and destroys the entire argument:

Regardless of whether or not any specific patent licenses over ECMA 334 and 335 cover Mono’s implementation of those standards, if indeed such agreements are available (ITWire’s curlish “attempt” to secure such an arrangement aside), the fact that statements have been made in public supporting the idea of royalty-free licensing essentially reduces the financial impact of such infringement to zero. If Foocorp has a license to use patents, under a “non-discriminatory” license, and did not pay for them – then it would be discriminatory to change anyone else for them (breaking the signed terms regarding patent licensing), and as such, those patents lose any financial value. They may, however, still hold non-financial value (such as their use in defending against patent-related attacks), hence not making the patents “free for all” in any understood sense…
The layering of escape routes is extensive in Mono, especially Mono in Debian/Ubuntu. In the first instance, the contentious Microsoft-sourced non-ISO libraries such as System.Windows.Forms are not included by default, and are rarely used in Free applications anyway (because WinForms looks like ass, amongst other things). If a reason is found to remove these non-standardised libraries, then bam, they’re gone – without harming Free apps.

Stallman is using his prominent position in the Free Software world to spread totally unfounded FUD about a free software stack that is absolutely critical to the success of the free software movement.  While Mono isn’t 100% GPL, it is 100% Free Software according to the FSF’s own definition.  The patent claims Stallman makes vague reference to is nothing more than FUD.  ”Discourag[ing] people from writing software in C#”, as RMS advocates, is completely at odds with his own ideological positions on free software.  The only possible downside is that Microsoft might get some good press, and the FSF would have to concede that Microsoft might have a few good ideas.  This sort of Us vs. Them thinking has no place in a rational discussion, and it saddens me to see a once-great software leader now doing so much to destroy his own movement.

Return top