Open-Source, and the MIT Licence

How often do I have to remind people to read the goddamn licence before copy-pasting code (and reselling it as their own, obviously)? Too damn often.

For those of you who are curious about what the most permissive open-source license out there actually entails, read this great /dev/lawyer post.

TL;DR: yes you can resell it, no you can't say it's yours, no you can't sue or ask anything of the authors.

Some choice bits:

Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license, United States law doesn’t recognize any such rule.  Strong copyright protection, not permissive licensing, is the default.

This is true almost everywhere. Without a licence or a written word granting rights, you cannot use someone else's work. Yup, taking some code on Stack Overflow, and not giving credit is actually illegal. By default, everything posted there without any licence is under the CC BY-SA 3 license, and you have to state where you got it, who wrote it and what you changed. You are also not allowed to change the licence, which means that you cannot stop anyone from taking your modifications and running with them.

Frankly, compliance with this condition is breaking down.  Nearly every open-source license has such an “attribution” condition.  Makers of system and installed software often understand they’ll need to compile a notices file or “license information” screen, with copies of license texts for libraries and components, for each release of their own. The project-steward foundations have been instrumental in teaching those practices.  But web developers, as a whole, haven’t got the memo.  It can’t be explained away by a lack of tooling—there is plenty—or the highly modular nature of packages from npm and other repositories—which uniformly standardize metadata formats for license information.  All the good JavaScript minifiers have command-line flags for preserving license header comments.  Other tools will concatenate LICENSE files from package trees.  There’s really no excuse.

This is where I gnash my teeth and rend my garnments, and all those things. Of course you don't have to give proper attribution, even if the tools let you do that in 5s flat, because it's free, amirite?

Someone worked for that. Someone took some time off of stuff that could give them pleasure, closure, money, or all of the above, to give you a solution to something you couldn't fathom on your own. Someone who isn't asking you to pay them, enter a contract with them (agreeing on a sum of exactly zero spacedollars, with your signature and theirs), or even contacting them to ask for permission. All they want is that you say you couldn't do it on your own, and that you used their work instead. Your poor ego can survive that, I promise you.

If you're huffing and puffing at that, or are in any way offended or even unsure, please send me a link where you post your pictures or some words. I'll make sure of publishing them as my own, and we'll see how you feel about that. Hell, if you're really dismissive, I might go ahead and try to sell your works, see if that finally triggers some empathy.

The MIT License works.  It is by no means a panacea for all software IP ills, in particular the software patent scourge, which it predates by decades. But MIT-style licenses have served admirably, fulfilling a narrow purpose—reversing troublesome default rules of copyright, sales, and contract law—with a minimal combination of discreet legal tools. In the greater context of computing, its longevity is astounding. The MIT License has outlasted and will outlast the vast majority of software licensed under it.

Yes, the MIT licence is imperfect, because courts (especially anglo-saxon courts where the letter of the law matter as much as, if not more than, the spirit of the law) will always be about rethoric and who can convince better. But the MIT licence works. It allows people to give away rights that are theirs by default ("what I make is mine") to foster some ideal of going towards perfect code through a multitude of eyeballs, while retaining a quaint obligation of gratitude ("what's the magic word?").

And yes, younger developers very seldom read, and even less often understand, the licence of the code they so happily pillage on their way to riches.

A little anecdote to let you know why this matters to me:

In 2000, I was a young (and frankly pretty bad) developer, but I had made a nifty little tool that caught the attention of some people in the Macintosh world. I was also fascinated and rapidly becoming an expert in two fields that were foretold as extinct on multiple occasions, and yet retained a decent demand for experts: IrDA, and QuickTime. I was invited to the WWDC that year. At the time, Apple struggled to fill the theatre, so that doesn't make me anyone special, but it was a nice show of recognition anyways.

Lunches were taken at round tables of maybe 12-14 people, you grabbed your lunch tray (which was pretty good) and you sat where there was some room. I happened to sit down at a table where people were hotly debating some random specific detail of an obscure API, and the whole table got talking about their idiosyncratic solutions. Everyone around the table was treated equally. We were all under the tacit agreement that no one would use the contents of the discussion for ill, or for profit, it was just a honest discussion about the ways we went about solving some issues in some random bit of image treatment that bothered us all, in one way or another.

Late in the conversation, I realized I was speaking to (and with) the guy who wrote the JVM for the Mac, two guys from SETI working on Seti@Home, a woman who was working on the in-flight computer of jet fighters from a military contractor, and a woman from Bell Labs. They were treating my questions and my inputs as relevant.

How can that kind of conversation happen (or meetups, or public git repos, ...) without the implicit trust that your work will either be a source of inspiration (i.e. rewritten from scratch, taking the lessons to heart), or will be used carefully (either by sharing proceeds if there's a huge payday on the horizon, or at least mentionning to your boss/client that they should contact you if they have another problem in that field), or maybe that you will get help from them for free in the future?

Trust is the most valuable thing we have. If you can't be bothered to respect that trust when someone shares a piece of code with you, you run the risk of hurting that person and preventing them from helping anyone else in the future. Not to mention the illegal stuff, of course.