Introducing the BTC Crypto License

Bringing sexy back to software licenses

The licensing luncheon. Photo: Courtesy Jez Timms

I’ve been developing free (as in freedom) software for several years and have always enjoyed opening my source code.

Until recently learning how to apply the GPL to my software I was unaware of just how unsexy open source licenses can be.

But it doesn’t have to be that way.

Unlike MIT and ISC licenses the GPL is the size of a book and reads like stereo instructions — you know, the kind you don’t read unless you purchased from IKEA or are building an ultrasonic robot. Simply trying to interpret GPL can make one feel a lot like a robot too.

Not only is the GPL the size of a novella, it comes with its own FAQ the size of an international airport runway — ensuring when (not if, but when) you botch it there’ll be no one left to blame but yourself.

But you’re not a robot. No problem, you think. Just don’t use GPL, right? Oh if only life were so simple…

If you’re planning to submit a theme to WP.org, for example, using GPL is mandatory — you have to use it. I won’t get into the details as to why. Because that story is even less sexy than the GPL itself.

After thinking I’d done GPL right I looked on GitHub to see how others applied GPL to their works, and, much to my surprise, discovered a metric ton of licensing issues — both in my own work as well as in others. And not just with the GPL: with all open source software licenses.

You see, software licenses just aren’t that sexy. And it shows. Even a quick peek under the covers of the most popular Version Control System on the planet, GitHub, draws the narrative.

Common Licensing Issues

By and far the most prevalent licensing issue I saw while reviewing code on GitHub where works which didn’t include a license whatsoever. Take it from Jeff Atwood, who once made the mistake of not including licenses with his FOSS work: you may regret not including a license later.

Another common licensing snafu I noticed were when works would use a manifest such as package.json and assumed simply setting the license object in the manifest was indicative of licensure. This may seem logical, but it is most certainly not the case.

No problem. Just slap on a license… That’s what I saw a few individuals do — even library and toolkit authors — just pick something and plop it in there. Problem solved. To hell with license proliferation!

Yet another issue seen on GitHub was for more complex FOSS licenses like the GPL, against recommendation from the Free Software Foundation, to not add boilerplate license headers to project source files.

What’s the big deal with license headers anyway?

For starters, license headers are a great way to distract one during development. Using them feels like sleeping with the enemy. Their omnipresence in source files serve as a constant reminder of the complexities legal issues bring to FOSS development, and they’re a surefire way to frighten off would-be contributors.

But license headers pose a bigger problem. If kept in source code license headers can cause programs to fail. True story. Just try applying the GPL license headers to a Hugo theme and you’ll quickly see what I mean.

Simple licenses to the rescue?

Want to keep your software simple and permissive, and skip license headers altogether? Well then you just apply the MIT or ISC licenses and call it a day, right? Everyone understands those.

Wrong.

ISC and MIT licenses are so simple some just ignore them altogether.

For example, I recently had substantial portion of source code I spent hundreds of hours creating copied verbatim, including a majority of my README, and the author of the derivative work didn’t even carry the license through or mention my name.

ISC and MIT licenses are so simple some just ignore them altogether.

Should we be so vein as to challenge others to fix their licensing issues when their works could carry our names? What is there to be gained by vanity in libre software?

In my case I decided to switch to WTFPL and call it a day. But that didn’t address the actual problem—and I’m still irked.

Switching to an ambiguous license with expletives may draw attention and entertainment value, but it does little to fix the larger problem with FOSS licenses: enabling individuals to receive recognition for their work.

A better way forward

What are we to do when the licenses we have today either require the likes of a six-year degree to understand, or are so completely dumbed down they lead others to believe it’s okay to ignore them?

Solution: Make FOSS licenses sexy again.

Not sexy for attorneys. Not sexy for business stakeholders. Or profiteers. Or profit centers. But sexy for the common man, the creators of these great, not to mention free, creative works.

Make FOSS licenses sexy again.

Let’s make licenses sexy favor the individuals doing the hard stuff. The ones on the ground floor. Those putting their true passion into their work for the benefit of others. Let’s make FOSS licenses favor the authors of these creative works.

Because, if you ask me, a license which is actually useful is a lot more attractive than one which is easily misused: *cough* GPL *cough*.

Introducing the BTC License

In my frustration with existing FOSS licenses and eagerness to understand what the future holds for open source when tied to blockchain I’ve created the BTC License and applied it to the Fetch Inject module.

The BTC license itself is a verbatim copy of ISC and was chosen for its existing ubiquity, terseness, permissiveness and functional equivalence with BSD-2-Clause and MIT licenses.

In fact, the only difference between BTC and ISC is the copyright line, which, for all intents and purposes, isn’t even considered part of the license.

So why a create new license then if nothing changed?

Ah, so glad you asked… Without a new license it’s unlikely something so similar to ISC would ever see widespread adoption and use—and no one likes license proliferation whether they realize it or not.

We need a canonical example with which to begin building sexier FOSS licensees.

Benefits of the BTC License

I expect the subtle change of the addition of a wallet address to the copyright line of software licenses to have the following benefits:

• Identification. Instead of listing the names of the 17 authors, the BTC License lists the address of a single bitcoin wallet. No more wondering which John Doe created the work, no more hand-wavy “and contributors” nonsense. Just a single wallet address provides individual authors and groups with wallet access the ability to receive recognition.
• Monetization. Because the BTC License uses a wallet address, software may be cast into the wild and potentially monetized programmatically. No more payment gateways, gatekeepers or Gratipay; no more advertisements hidden inside documentation, begware. Just a license and a wallet address with the capability to enable trickle-down for libraries used as a part of a larger works or to remove individual doubt bout how to give back to a software author.
• Privacy. Because the BTC License uses a wallet address the need for moral rights protections are lessened as it’s less likely anyone is going to take personal offense to a wallet address getting defamed. This small change brings with it another benefit. Those wishing to remain anonymous may do so without requiring use of a pseudonym.
• Awareness. Finally, adding a wallet addresses will do something powerful. Something FOSS has never seen before. It will make people actually want to look at licenses. No more leaving before the credit roll folks, because, such as things are, everyone still needs to eat. After all, you don’t really think those starving artist are really buying beer and coffee with the money you donated for your work, did you? You did donate, didn’t you? Right after you read their license?

To help formalize the BTC License I submitted it to the SPDX Legal Team in accordance with their instructions to Request New License and received feedback on how to move it forward.

I’ve also spoken with GitHub support to request an allowance of the BIP-0021 URI scheme in markdown files — which would allow individuals to link directly to their wallets from within their READMEs on the most popular FOSS hub on the planet, which is necessary at least until user agents auto-detect wallets like mobile devices link mobile numbers today.

We’ll see where things go from here. But no matter what happens, I will continue to push on crypto licenses. Because your hard work, well, it deserves a little recognition. And so do you for being so giving. Let’s bring sexy back to FOSS licenses — not that they were ever sexy to begin with.