3 ms·

The current system is broken. I don't think I agree with everything in the post, but I'm excited to see movement in this space given that this is a space I spen

The current system is broken. I don't think I agree with everything in the post, but I'm excited to see movement in this space given that this is a space I spend a lot of time thinking about. (I'll expand on that below) Even if I disagree with parts of this, this is still one of the most interesting things that I've read around OSS licensing in a minute! Having actual VC money behind this movement is awesome. For context: I run an Open Source company that's YC + VC-backed. We use a hybrid of Apache and Business Source License (BSL, a "non-compete" license that converts to Apache in 2-3 years). Our license file[0] has context about my thought process around this, but I still am not totally happy with it. (BSL isn't an "OSI-Compatible" license, but feels like the "best compromise" license out there currently.) To come to that conclusion, I've read both Heather Meeker's book, "Open (Source) for Business"[1], multiple times now and I've also blogged about this topic[2] before. (She helped write the BSL license.) All of that is to say, it's complicated and there are some perverse incentives that can prevent you from always "doing the right thing". Problem #1: You lose control. You may begin with Apache but, as OP states, you eventually end up with the incentive to "rug pull" by switching the license because of market forces/VC influence. (I'm the founder of my company and I would resist it, but eventually our investors might control the board and make that happen anyway by firing me.) Problem #2: The hardest part of building a company is getting traction. Just getting anybody to care about you takes a ton of effort and having a permissive license makes it way easier to get that early adoption. And, by the time you have adoption and you decide to go raise VC money, you now end up with Problem #1. Problem #3: If you start with a copyleft license like GPL/AGPL then you make Problem #2 (adoption) harder. Many companies simply won't use your software if you're using a copyleft license (like Google). (Linux is a notable exception here, while companies like MongoDB switched from AGPL. It's crazy.) We are using BSL because it feels like the best compromise (it becomes Apache 2.0 eventually). I do still think a lot about switching to Apache though. I just really hate the idea of "rug pulling" and I'd rather be honest from the beginning with a license like BSL, even if it is more difficult to get that initial momentum. Does anybody else have thoughts to share about this? 0: https://github.com/lunasec-io/lunasec/blob/master/LICENSE.md https://github.com/lunasec-io/lunasec/blob/master/LICENSE.md 1: Open (Source) for Business: A Practical Guide to Open Source Software Licensing - Third Edition https://a.co/8SLjVZI https://a.co/8SLjVZI 2: https://www.lunasec.io/docs/blog/how-to-build-an-open-source-business-in-2021-part-1/ https://www.lunasec.io/docs/blog/how-to-build-an-open-source...

Nomentatus 4y ago
I had separately come to the conclusion some years ago that what I privately termed a "lag-license" (eventually goes to open source) is probably the right solution. I thought maybe four years. To my mind, the essential problem is that code "copyrights" (copyright is really for artistic value) ought to have been for maybe four years, not more than a century, to begin with. The government hasn't done this (AOC, are you listening?) so business is fumbling toward the optimal solution, slowly. But I had been thinking of a delayed release with a very permissive license such as MIT (duplicating the change in law I'd like to see.) But in that case, I wondered, should one have a clause that insists that derived works also go into the public domain after a lag? I.E. be lagged licensed as well. Only that creates the same situation as a law providing four years of copyright protection. Releasing to Apace 2.0, as you do, addresses that, but might scare off some businesses. Re release to MIT, I can see allowing code to be put in Escrow (Trust in other legal systems) rather than exposed immediately. I do also wonder however if there's a case to allow companies to hold onto code that reveals, or reveals information about, trade secrets. Which likely doesn't apply in your case. But likely such information could be finagled into a data file rather than code.
hodgesrm 4y ago
> Does anybody else have thoughts to share about this? Yes, a couple. 1. Put your software into a foundation before you take VC money. This will force you to adopt a business model that does not depend on establishing what amounts to a proprietary monopoly on the software. It may also reduce your valuation in the eyes of many VCs. 2. Use a different funding model. Revenue-based financing [0] is a good alternative for any business that has ARR. It works well for rapidly growing SaaS businesses. You will pay credit card levels of interest but you keep control of the company which means that you can do what you want. I'm not saying that either of these options is easy. Both oblige you to figure out how to operate profitably or close to it from the start. That's hard to impossible for capital-intensive businesses. But it is far easier to be virtuous with respect to licenses if you are making money. My company currently uses revenue-based financing. [0] https://en.wikipedia.org/wiki/Revenue-based_financing https://en.wikipedia.org/wiki/Revenue-based_financing

Nomentatus 4y ago

I had separately come to the conclusion some years ago that what I privately termed a "lag-license" (eventually goes to open source) is probably the right solution. I thought maybe four years. To my mind, the essential problem is that code "copyrights" (copyright is really for artistic value) ought to have been for maybe four years, not more than a century, to begin with. The government hasn't done this (AOC, are you listening?) so business is fumbling toward the optimal solution, slowly. But I had been thinking of a delayed release with a very permissive license such as MIT (duplicating the change in law I'd like to see.) But in that case, I wondered, should one have a clause that insists that derived works also go into the public domain after a lag? I.E. be lagged licensed as well. Only that creates the same situation as a law providing four years of copyright protection. Releasing to Apace 2.0, as you do, addresses that, but might scare off some businesses. Re release to MIT, I can see allowing code to be put in Escrow (Trust in other legal systems) rather than exposed immediately. I do also wonder however if there's a case to allow companies to hold onto code that reveals, or reveals information about, trade secrets. Which likely doesn't apply in your case. But likely such information could be finagled into a data file rather than code.

hodgesrm 4y ago

> Does anybody else have thoughts to share about this? Yes, a couple. 1. Put your software into a foundation before you take VC money. This will force you to adopt a business model that does not depend on establishing what amounts to a proprietary monopoly on the software. It may also reduce your valuation in the eyes of many VCs. 2. Use a different funding model. Revenue-based financing [0] is a good alternative for any business that has ARR. It works well for rapidly growing SaaS businesses. You will pay credit card levels of interest but you keep control of the company which means that you can do what you want. I'm not saying that either of these options is easy. Both oblige you to figure out how to operate profitably or close to it from the start. That's hard to impossible for capital-intensive businesses. But it is far easier to be virtuous with respect to licenses if you are making money. My company currently uses revenue-based financing. [0] https://en.wikipedia.org/wiki/Revenue-based_financing https://en.wikipedia.org/wiki/Revenue-based_financing