Is this good for bitcoin?

[drewcrawford]

Apologies for flamebait title, but this is a serious proposal.

Background

From my vantage point, open source development has the following desireable properties:

• Revolving door; anyone can contribute (in theory)
• Global; developers can live anywhere
• Global; can be licensed anywhere
• Automatic; no need to make phone calls or credit cards to license more, deal with codes, keys, activations, etc.
• Sourcecode can be read and modified by anyone
• Emergently organized: there's no lawyers or barriers to starting a project
• No single point of failure
• It's forever, you cannot be cut off from existing or even new installs
• It's fair, everyone has the same rights
• No legal impediment to downloading and trying the project right now
• Right to fork

(I don't mean to suggest this is the Final Ultimate List™ of open source benefits, just the ones that I personally appreciate most. Some people (RMS, FSF, etc.) view open source as a kind of social engineering lever, rather than just about creating useful software, and their analysis is very different than mine.)

Meanwhile proprietary software has the following desireable properties:

• People must pay to use it ("teeth")
• People get paid to work on it
• Can afford to pay bug triagers, QA engineers, support personnel, EC2 instances, etc.
• Moreover there exists "infrastructure" to pay for those things, e.g. bank accounts, debit cards, etc.
• If you want to use it in a proprietary program, you can typically come to some equitable arrangement. Whereas doing that with open source is often impossible ([A]GPL) or inequitable (MIT)

It has occurred to me that actually, there is no good reason to have two separate lists. We can have everything we want in only one list.

The result is not exactly "open source" in the way the purists understand it, but it's not exactly proprietary either: it's some Third Thing™ that I call royalties.

Exploring the solution space

Musicians face many of the same problems open-source developers face. They want to get paid for the music they write, but they also want other musicians to be able to build on their work without a lot of hassle. After all,the way to become known as a musician is to get Adele to sing your song. And hopefully, afterwards she cuts you a check.

And musicians have a solution to this problem! The solution is not perfect, and it has grown messy over the years, and I'm not going into all the warty details of it, but basically:

1. You don't generally need the permission of a copyright owner to use their music
2. You do generally need to pay them. The amount and who controls that amount varies, but it is a standard rate for everyone, like "$.25 per copy", that is set by either the law or a rights organization.
3. If you can't figure out who is owed the royalties (e.g. because they have moved, they don't answer your letter, etc.) then you pay a central clearinghouse, and they figure out how to distribute it
4. The end. You now use the song.
5. These days the whole process is automated, and there are entire industries of tooling to distribute the royalties. You can license a song faster than you can read this comment.

And now for software

I think we can use the same solution for software. Most simply: just place the following at the bottom of your commit message:

to license this commit, send .002BTC per device to 1GyPKBt3Tpgqzc8Nbd8tmvRQUQpJPZH41Y

The end.

Looking back at our list of requirements:

• Revolving door, anyone can contribute to a project with this model
• Global, developers can live anywhere
• Global, users can license the software anywhere
• Automatic: we write tooling to parse the commit history and send royalties to the developers. You can license software from the command line, we can write a webapp to take a credit card and do it (although we need lawyers for that part), etc.
• Sourcecode can be read and modified by anyone
• Emergently organized: there's no lawyers or barriers to starting a project. Just place text in your commit message, the end.
• No single point of failure. You pay the bitcoin address, not the author. The author died, disappeared, somebody hacked her account–not your problem. Your responsibility begins and ends with sending a payment to the address, and then you have licensed the software.
• It's forever, nobody can withdraw your right to license new or existing software
• It's fair, everyone has the same rights
• No legal impediment to downloading and trying the software right now (we have some provision for trials in the boilerplate)
• Right to fork
• People must pay to use it ("teeth")
• People get paid to work on it.
• Can afford to pay bug triagers, QA engineers, support personnel, EC2 instances, etc.
• there exists "infrastructure" to pay for those things (bitcoin addresses)
• If you want to use code in a proprietary program, you just build the license fees into your price, and then make royalty payments for your customers. It doesn't matter who specifically pays the royalty, as long as the royalties are paid, the licenses are created.

This is not without its drawbacks

Open source POV:

• Makes Richard Stallman sad (bug or feature? discuss)
• Not "really" open source
• Not GPL(/BSD/MIT) compatible. Although I believe existing MIT/Apache code to be "Royalties"-compatible. So in that sense it is like a "new" copyleft license, you bring code into it, but not back out
• Not DFSG-free/Fedora-free/FSF-free
• "license proliferation" (cower in fear)
• Discriminates against poor people?
• Any change produces angry mailing list posts

Proprietary POV:

• Can't charge rich companies more money than lean startups
• "Competitors will license our code!" (cower in fear)
• Have to actually pay money for more of the software they use
• Don't know who customers are / can't send them company newsletter / etc.

But for me personally, all these "drawbacks" are a small price to pay for the long list of benefits I can enumerate.

Stuff still to work out

• Lawyerification, BOILERPLATE IN ALL CAPS ABOUT LACK OF WARRANTIES
• Marketing, coming up with better names and logos for this scheme and a shorter explanation than the stupidly long explanation I wrote here
• Discussion about per-device vs per-user (what about server software?). Maybe we need a few standard licenses (or a standard royalty table?) that we hide behind simple acronyms, CC-BY-NSA-CIA?
• Software older than [certain age] should be royalty-free? ("To promote the Progress of Science and useful Arts, by securing for limited Times...")
• Deciding I'm totally crazy and there is some obvious problem with the entire premise and it cannot possibly work?

Thank you for reading this far, any opinions or criticism welcome.

[wolftune]

You asked for criticism, so here it is, just meant respectfully:

proprietary software has the following desireable properties… People must pay to use it ("teeth")

That's not a pro, it's only a means to the end of a pro which is funding. Funding is a positive value. Paywalls have no intrinsic positives.

Regarding your music comments, I'm a music professional and I know a lot about these things. There's very little sense in which the system of royalties you're describing is healthy, appropriate, or applicable here. ASCAP mostly makes already-wealthy people wealthier and does nothing for artists who are struggling to get by. The performance royalties you're describing only apply to direct performance of a song and not to derivatives (i.e. "forking") nor to use in video, and it isn't something that a license enables, it's part of the legal framework of copyright itself. But all that aside, pushing this to a license based on Bitcoin does indeed make this whole situation quite different from the music analogy.

You pay the bitcoin address, not the author. The author died…

So, for 70 more years until copyright runs out, people pay anonymous Bitcoin addresses?

to license this commit

That's the biggest failing point here. So, you add up all the commits? Incentivize splitting of work into different commits then? Do people place different prices on commits? If not, I'd go seeking typo fix commits everywhere I can! Does software that no longer uses the code form one commit but where that is in the history need to pay for that commit? Software evolves. I make a commit that tweaks your commit. The whole copyright nature of software is screwy actually, and there's serious argument that it was a mistake for the copyright office to start accepting the idea of software copyrights even. The idea that this can be split up among commits is unworkable. As a developer, I would never want to accept commits from others under this scheme as it would give them a claim to funding of my software and either cut into my funding or raise the price and potentially cut down the royalties by pricing people out. I don't think any commit-centric royalty idea has any chance to go anywhere.

Makes Richard Stallman sad (bug or feature? discuss)

I know you're aiming to be light-hearted, but don't use that rhetoric. It just leads to divisiveness. This is not a personal thing and none of RMS' ideas are help only by him personally.

believe existing MIT/Apache code to be "Royalties"-compatible.

MIT etc. permissive licenses are compatible with anything. You can't write a license that MIT will be incompatible with.

Discriminates against poor people?

Why is that a question? Obviously, all paywalls discriminate against poor people. Unless you added a means-test discount to the license, and that's insanely bureaucratic to mange…

Have to actually pay money for more of the software they use

That would only be true if companies chose to use software licensed this way, which they mostly wouldn't. They'd stick to more traditional proprietary licensed stuff or using actual Open Source.

I won't go into more detail about the nitty-gritty of your idea as I think inherently there are aspects that make it totally infeasible in reality. If those were addressed (which I have no idea how they could be), then I could offer feedback on a future workable variation (which I would still be highly skeptical about).