The BTC license hit my radar screen recently. Billed as “sexy” by the author, the permissive BTC license employs blockchain and may signal a new trend going forward that could transform the way many developers work … and how they get their health insurance.
Full name: BTC License
OSI: Not OSI-submitted nor approved
Explanation: Verbatim copy of ISC, with updated copyright line intended to protect individual privacy and facilitate transmission of funds to creators of open source work. Example use within software provided below.
After some open discussion on the list, the team informed the author that given the way licenses are defined in the SPDX License List, this was not a new license. Based on the SPDX guidelines, it matches the ISC license (because the copyright is a variable in the license specification) so we won’t treat it separately. Josh Habdas, the author, understood and appreciated the speedy resolution, and that was that.
But my curiosity was piqued and I set up a call to understand more about his idea. It’s lucky Josh likes to work late, because he lives in Bali (and I don’t). He kindly took my call over FaceTime after dinner while he was out and about town. We quickly reached some common ground chatting about my last blog on permissive licenses and agreed that developers are fundamentally motivated by building stuff that gets used and getting some credit for their contributions.
In essence, Josh has big ideas about how blockchain can help open source developers who build great software get some remuneration to support their efforts. This is an important issue. It came to light big time in the wake of Heartbleed. Jim Zemlin, head of the Linux Foundation, immediately took it on. Realizing that a lot of very important software projects were underfunded (and therefore not secure), Jim went to a bunch of big tech companies asking for help. He showed pictures of the key figures behind these projects and observed that most couldn’t afford health insurance. The risks were clear, and in a couple weeks Jim’s efforts raised millions of dollars to support critical projects like OpenSSL.
But Jim’s efforts alone don’t fix the ongoing problem — how to keep valuable open source projects funded, secure and updated. This isn’t just a problem for the open source community, however. Proprietary apps today include 40%, 60%, or more open source. Imagine companies of the future that understand the value of key components they rely on. What if they were able to easily pass a trickle of remuneration back to the non-employee developers whose code they build on? Many trickles for popular projects might add up to enough of a river to float developers’ health insurance!
That’s Josh’s vision, and the first step to get there is the BTC license (BTC is the abbreviation for Bitcoin). His twist on the ISC license is to use a URL for a blockchain wallet as part of the copyright. It still relies on developers using code to preserve the copyright statement, but allows anyone using software an easy path to get “coin” to the owner(s) of useful open source components. Right now, copyright holder names are often ambiguous, and it takes time and energy to track them down and work out how to pay them. A blockchain wallet is unambiguous and directly addresses the payment issue. Multiple participants in a project could have shares in a wallet and work out a transparent division of spoils. Josh has made a good argument for including wallets URLs in copyright statements.
The bigger vision gets a little crazier. I’m still wrapping my head around blockchain, but the key is to understand that it can track any asset, not just currency, and that includes software. Check out Bitcore I Made This. It lets you use blockchain to timestamp any kind of digital content to “serve as immutable proof that the files existed at a certain point in time, which can be used to demonstrate ownership of original content.” It’s not hard to imagine every commit to an open source project being logged in that manner to create an unambiguous picture of the provenance of every line of code … in every piece of software. Josh tells me all the pieces are already in GitHub today; it’s not so far-fetched.
How this all plays out, we’ll see. But the concept opens eyes to the breadth of ways that blockchain may be leveraged in the future. And it certainly suggests a healthier future for software developers. They may be able to freelance more and still benefit from commercial application of the cool stuff they build.
Join us on September 28 for a discussion of this license with Karen Copenhaver, Partner, Choate Hall & Stewart/Counsel, Linux Foundation; Mark Radcliffe Partner, DLA Piper/Counsel OSI.
Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.