"Our Mission"<p>> We form companies centered around open source software projects with commercial applications. Rather than founders pitching us for investments, OCV identifies open source projects with traction and potential and seeks out builders and technologists to launch our ideas. OCV Fund I invests the personal capital of Sid Sijbrandij who serves as the General Partner of the firm.<p>So, this company takes the hard work of creator(s) who have been generous with their licensing terms, and in the name of "preventing them from using a more restrictive license" tries curtails their business opportunities by offering a legal structure with more favorable terms to end-users, thereby destroying the innovator's chance to make money off their invention.<p>To me, it seems like, if it offers no business opportunities, then people just won't offer innovations using permissive licenses for open core in the first place? If I'm going to give money to someone, I'd prefer it to be the innovator.
Disclaimer: I’ve been paid to write and do experiments/devrel for OCV and portfolio companies in the past<p>People seem to be complaining about the business model here, but that can be tweaked or changed literally at will (and by negotiation for maintainers). As for intent, at this point I don’t think it makes sense to consider Sid’s intent nefarious —- look at how Gitlab is run.<p>Speaking of the disclaimer, we tried to lay out the reasoning and background on how people make money in open source:<p><a href="https://opencoreventures.com/blog/2022-03-someone-has-to-pay-for-the-domino/" rel="nofollow">https://opencoreventures.com/blog/2022-03-someone-has-to-pay...</a><p>On the spectrum of how people make money with open source, open core with investment has been proven to work and produce large sustainable companies that can compete with VC backed closed source (I say this as someone who has benefitted from Gitlab’s free tier massively).<p>There’s a trade off here. What number should the investor get, and what number should the maintainers get? How we get to an equitable number (pun intended) is discourse and negotiation.<p>Open source <i>is</i> unsustainable right now —- Github Sponsors will not save the maintainers with software used by Fortune 500s expecting business level support. That shouldn’t be the situation, but it is.<p>At the very least, the open core model encourages maintainers of F/OSS software to do enough business to help themselves, while spending some of Sid’s money.<p>We need F/OSS maintainers that know how to business, just like the beautiful conception of F/OSS by nerds that knew how to lawyer.
"At OCV, we start and invest in open core companies. We identify open source projects with traction and recruit CTO/CEOs to build a commercial application and company around it. Our vision is that open core will eventually replace proprietary software as the default. Preventing a “bait and switch” from open source to proprietary is central to our model. It is for this reason we think open source is more than a license—it’s the base of all software companies."<p>I was with it until this, big oof. How about contact the maintainers and try to interest them in this arrangement?<p>Also looking at their operating model, fuck that. There are more favorable arrangements to be had. YC is one of them. If you're going to build a company you should definitely capture more of the upside.<p>"The operating team" <-- notable lack of the word owner.<p>This makes me even more unlikely to open source ANY of my work now, especially with this type of predatory bs running around. I'd rather make the money from my work thanks.<p>I'd expect a better, less predatory, model from the CEO of GitLab.
Disclaimer: Cofounder/CEO of Ahana here, which provides a managed service of open source PrestoDB for fast, reliable SQL Lakehouses and analytics.<p>I wanted to add nuance to the conversation: While most open source projects these days are licensed with Apache 2.0, there are two categories that projects fall into: community-controlled and vendor-controlled. The difference is the control. If a project is governed by a gold-standard hosting organization like the Linux Foundation and have organizationally diverse committers, then it's community controlled and open forever. However if the project is mostly owned by one company then it's easy to move to a non-compete license. For example, Linux Foundation hosts Presto and the license cannot be changed to a non-compete. This is guaranteed by the Linux Foundation charter. The fork of Presto (named Trino) however, turned into a company controlled open source project. In my experience, the distinctions between open forever vs. possibly more closed with a non-competitive license tends to be overlooked in choosing which to use.<p>I commend Sid on his efforts to keep open source, open forever. Donating your project to Linux Foundation like Facebook/Meta did with Presto is one path to achieving that, this new approach is another. Bravo!
SugarCRM, CFEngine2/3, Chef, Heroku, grsec, Tripwire, ... there are countless examples in the dustbin of history who ceased giving back, rested on their laurels, and became FOSS-washed commercial ventures who faded into the past.<p>Docker maybe next given the way they're going.<p>Provide value at a constant rate to things rather than bait to gain users and switch to exploiting them.<p>The same could be said for too-good-to-be-true pricing.<p>If a project needs to lock-up code and service to survive OR large companies use it widely without supporting it monetarily or with fixes, then maybe it shouldn't be open source to begin with?<p>OTOH, if you don't want anyone to use your software and if you want to stay poor, use a radioactive license like AGPL.
IANAL and would love to be corrected, but the chart in this article may confuse many.<p>Permissive licenses cannot be relicensed any easier than non-permissive licenses. Permissive licenses can be incorporated into larger works with minimal consequences, whereas with AGPL, the consequence is that the rest of the software must be AGPL. Arguably incorporating permissive licensed code into a closed source work is a form of open core, which is what this site is advocating for!<p>Only the copyright holder can relicense the software. A CLA is often used to assign the copyright of any contribution to the company operating the open source project. This ensures the company can relicense the project, regardless of the current license of the code. A DCO is an extra acknowledgement by the developer about their contribution, but does not change the copyright assignment, and thus has no effect on relicensing.<p>Interestingly, there is a CLA that can be used to restrict the ability to relicense a contribution only to other specific open source licenses: <a href="http://www.harmonyagreements.org/docs/ha-cla-i.html" rel="nofollow">http://www.harmonyagreements.org/docs/ha-cla-i.html</a>
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)<p>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.<p>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.)<p>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.)<p>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".<p>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.)<p>Problem #2: The hardest part of building a company is getting traction. Just getting <i>anybody to care about you</i> 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.<p>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.)<p>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.<p>Does anybody else have thoughts to share about this?<p>0: <a href="https://github.com/lunasec-io/lunasec/blob/master/LICENSE.md" rel="nofollow">https://github.com/lunasec-io/lunasec/blob/master/LICENSE.md</a><p>1: Open (Source) for Business: A Practical Guide to Open Source Software Licensing - Third Edition <a href="https://a.co/8SLjVZI" rel="nofollow">https://a.co/8SLjVZI</a><p>2: <a href="https://www.lunasec.io/docs/blog/how-to-build-an-open-source-business-in-2021-part-1/" rel="nofollow">https://www.lunasec.io/docs/blog/how-to-build-an-open-source...</a>
> We’re launching our first OPBC company, Authentik Security, in November. Authentik Security is a cyber security company that provides identity management solutions around single-sign-on, user enrollment, and other access control features.<p>This Authentik?
<a href="https://goauthentik.io" rel="nofollow">https://goauthentik.io</a><p>The maintainer works in Yelp(1), so is the company not associated with the actual founder of the project?<p>1. <a href="https://github.com/BeryJu" rel="nofollow">https://github.com/BeryJu</a>