8 ms·

Preventing the bait and switch by open core software companies

68 points by sytse 4y ago

pessimizer 4y ago
> Only copyleft licenses with a developer certificate of origin (DCO) can protect open source indefinitely
- whoville 4y ago
  I read that and thought: this is ridiculous. First of all, assigning copyright to FSF or SFC is way way better protection. Also DCO has nothing to do with protecting, the protection is from "inbound = outbound" contributions are under the same license as the project, this is the standard. A DCO is just something a few Linux Foundation lawyers dreamed up in order to help give companies faith in using Linux and is basically irrelevant. More info https://www.fsf.org/blogs/licensing/FSF-copyright-handling https://www.fsf.org/blogs/licensing/FSF-copyright-handling .
  - wmf 4y ago
    Inbound = outbound was the standard in the 1990s but CLAs and such have risen since then. I assume most COSS companies are using CLAs or full copyright assignment.
ericb 4y ago
"Our Mission" > 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. 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. 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.
- wmf 4y ago
  You could always say no. In general, copyleft has always prioritized freedom for the users over freedom for the developers and clearly this new initiative is based on that same philosophy.
  - ericb 4y ago
    How much more freedom than a permissive license does anyone need? The term rug-pull is wildly misleading. Let's describe the problem this is setting out to solve better--end users who have gotten something for free are upset that they no longer will continue getting updated somethings for free. The old open source versions are still out there. If they want to use it, they can fork off.
    - kiba 4y ago
      Let's describe the problem this is setting out to solve better--end users who have gotten something for free are upset that they no longer will continue getting updated somethings for free. Something for free? That had never been the point of FOSS. The developers are not obliged to provide free update to users. The old open source versions are still out there. If they want to use it, they can fork off. Of course, if the users have the relevant expertise/money. In reality, there's always limitations.
      - ericb 4y ago
        > Something for free? That had never been the point of FOSS. FOSS = Free Open Source Software
        Caboose8685 4y ago
        Free doesn't mean cost.
- bheadmaster 4y ago
  > 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 I consider this a far better scenario than the current bait-and-switch culture. The Free Software (and Open Source) community has put a lot of effort and volunteering work into constructing its world and gaining its reputation - based on putting the needs of the users first. Now a for-profit organization comes around, and wants to get all the credit for being "open source" without actually being open source? They're poseurs. I'd say good riddance to them. Innovation is not a goal by itself - the purpose of innovation is to benefit people in general.
ianbutler 4y ago
"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." I was with it until this, big oof. How about contact the maintainers and try to interest them in this arrangement? 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. "The operating team" <-- notable lack of the word owner. 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. I'd expect a better, less predatory, model from the CEO of GitLab.
- lbotos 4y ago
  Consider this statement my own, but look at my profile for bias. I think you might be misunderstanding. Look at the companies there now: https://github.com/flowforge/flowforge https://github.com/flowforge/flowforge - The CTO is the creator. https://www.mermaidchart.com/about-us/ https://www.mermaidchart.com/about-us/ - Knut Sveidqvist is the creator of mermaid and involved. https://github.com/koor-tech https://github.com/koor-tech - Rook business, from a Rook Maintainer https://fleetdm.com/ https://fleetdm.com/ - Long time contributor is CTO. "Recruit" meaning see if the creator is interested in being CEO/CTO. And if they are one, find the other co-founder. OCV is trying to throw money at OSS maintainers and help them make a business with his connections, capital and experience. I literally watched him do it with DZ. I don't expect that to change with this new venture. But I am biased.
  - ianbutler 4y ago
    That's good to see. He may want to change the wording then. It comes off much more of recruiting around the maintainers. I'd be curious what happens if they say no. But so far from what you just posted, the actions seem to speak more charitably than I read it. The entire thing read to me like a typical venture studio model that will wind up screwing OSS maintainers out of the value they have created. I'd really consider reworking the marketing copy. I was super disappointed to see it from the CEO of GitLab because generally speaking I love your product and because I think you guys have been THE model for how to properly monetize open core while walking a good line for the open source part.
hardwaresofton 4y ago
Disclaimer: I’ve been paid to write and do experiments/devrel for OCV and portfolio companies in the past 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. Speaking of the disclaimer, we tried to lay out the reasoning and background on how people make money in open source: https://opencoreventures.com/blog/2022-03-someone-has-to-pay-for-the-domino/ https://opencoreventures.com/blog/2022-03-someone-has-to-pay... 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). 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. Open source is 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. 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. 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.
- ianbutler 4y ago
  I agree with the mission and even more so: > Open source is 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. I was actually thinking along exactly these lines this morning. That's why I was disappointed in particular because of who's name was on it, because to me it reads poorly. That's why my reaction was so visceral. I'm glad to hear that in actuality it has really been benefiting those OSS maintainers, but I stand by at least my suggestion that some of the explainer/marketing copy on that site needs to change. It in my honest opinion does not read to the same level of positivity that you or lbotos below put it to.
  - hardwaresofton 4y ago
freeqaz 4y ago
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...
whoville 4y ago
Railsify 4y ago
Shout out to Neo4j.
gregwebs 4y ago
IANAL and would love to be corrected, but the chart in this article may confuse many. 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! 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. Interestingly, there is a CLA that can be used to restrict the ability to relicense a contribution only to other specific open source licenses: http://www.harmonyagreements.org/docs/ha-cla-i.html http://www.harmonyagreements.org/docs/ha-cla-i.html
- Brian_K_White 4y ago
  "Only the copyright holder can relicense the software." The copyright holder who declares an MIT license, has explicitly granted the right to relicense.
  - gregwebs 4y ago
    I don't believe this is true: the MIT license requires maintaining the MIT license disclaimer in the derived work. AFAICT, you cannot actually relicense MIT code (unless you hold the copyright). You can create a new derived work that contains it, and distribute that work as a whole with a new license, but the MIT code portion of that work will always maintain its license and require distributing the MIT license disclaimer. https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html https://softwarefreedom.org/resources/2007/gpl-non-gpl-colla... With that being said, for the purposes of the article we are discussing, this distinction may not be meaningful because one can still take an MIT code base proprietary even if the original code doesn't actually get re-licensed.
1letterunixname 4y ago
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. Docker maybe next given the way they're going. Provide value at a constant rate to things rather than bait to gain users and switch to exploiting them. The same could be said for too-good-to-be-true pricing. 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? OTOH, if you don't want anyone to use your software and if you want to stay poor, use a radioactive license like AGPL.
- jacooper 4y ago
  > OTOH, if you don't want anyone to use your software and if you want to stay poor, use a radioactive license like AGPL Lol, business HN look on the AGPL is truly funny, Because its made to stop people from using the code without contributing, which is exactly what you want to do. Also the biggest on-prem cloud system Nextcloud is under the AGPL, which has its own commercial company Nextcloud GmbH. https://github.com/nextcloud/server https://github.com/nextcloud/server
  - Brian_K_White 4y ago
    I am always amused when people complain about the restriction not to be a d**k. Every time you see someone call something like AGPL something like radioactive, you just saw someone out themselves as a theif. Copyleft: "You can have this for free. You can use it for personal use, you can use it for making mony, you can even redistribute it, you can even sell copies of it itself! The only things you can't do are deny access to that which you were given for free from the next guy, or scrub the existing credits to pretend you wrote it." Theif: "Radioactive!" Me: More radioactive please!
    - Nomentatus 4y ago
      What you wrote matches the MIT license, not the AGPL, say. With AGPL, users have to immediately give away derivative works, and there are many business circumstances when that won't do. Hence dual licensing by the vendor - but alas dual licensing sets up the possibility of bait and switch, or can. I haven't even mentioned implied patent grants.
stevenmih 4y ago
Disclaimer: Cofounder/CEO of Ahana here, which provides a managed service of open source PrestoDB for fast, reliable SQL Lakehouses and analytics. 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. 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!
jacooper 4y ago
> 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. This Authentik? https://goauthentik.io https://goauthentik.io The maintainer works in Yelp(1), so is the company not associated with the actual founder of the project? 1. https://github.com/BeryJu https://github.com/BeryJu

68 points by sytse 4y ago

pessimizer 4y ago

> Only copyleft licenses with a developer certificate of origin (DCO) can protect open source indefinitely

whoville 4y ago
I read that and thought: this is ridiculous. First of all, assigning copyright to FSF or SFC is way way better protection. Also DCO has nothing to do with protecting, the protection is from "inbound = outbound" contributions are under the same license as the project, this is the standard. A DCO is just something a few Linux Foundation lawyers dreamed up in order to help give companies faith in using Linux and is basically irrelevant. More info https://www.fsf.org/blogs/licensing/FSF-copyright-handling https://www.fsf.org/blogs/licensing/FSF-copyright-handling .
- wmf 4y ago
  Inbound = outbound was the standard in the 1990s but CLAs and such have risen since then. I assume most COSS companies are using CLAs or full copyright assignment.

ericb 4y ago

"Our Mission" > 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. 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. 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.

wmf 4y ago
You could always say no. In general, copyleft has always prioritized freedom for the users over freedom for the developers and clearly this new initiative is based on that same philosophy.
- ericb 4y ago
  How much more freedom than a permissive license does anyone need? The term rug-pull is wildly misleading. Let's describe the problem this is setting out to solve better--end users who have gotten something for free are upset that they no longer will continue getting updated somethings for free. The old open source versions are still out there. If they want to use it, they can fork off.
  - kiba 4y ago
    Let's describe the problem this is setting out to solve better--end users who have gotten something for free are upset that they no longer will continue getting updated somethings for free. Something for free? That had never been the point of FOSS. The developers are not obliged to provide free update to users. The old open source versions are still out there. If they want to use it, they can fork off. Of course, if the users have the relevant expertise/money. In reality, there's always limitations.
    - ericb 4y ago
      > Something for free? That had never been the point of FOSS. FOSS = Free Open Source Software
      - Caboose8685 4y ago
        Free doesn't mean cost.
bheadmaster 4y ago
> 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 I consider this a far better scenario than the current bait-and-switch culture. The Free Software (and Open Source) community has put a lot of effort and volunteering work into constructing its world and gaining its reputation - based on putting the needs of the users first. Now a for-profit organization comes around, and wants to get all the credit for being "open source" without actually being open source? They're poseurs. I'd say good riddance to them. Innovation is not a goal by itself - the purpose of innovation is to benefit people in general.

ianbutler 4y ago

"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." I was with it until this, big oof. How about contact the maintainers and try to interest them in this arrangement? 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. "The operating team" <-- notable lack of the word owner. 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. I'd expect a better, less predatory, model from the CEO of GitLab.

lbotos 4y ago
Consider this statement my own, but look at my profile for bias. I think you might be misunderstanding. Look at the companies there now: https://github.com/flowforge/flowforge https://github.com/flowforge/flowforge - The CTO is the creator. https://www.mermaidchart.com/about-us/ https://www.mermaidchart.com/about-us/ - Knut Sveidqvist is the creator of mermaid and involved. https://github.com/koor-tech https://github.com/koor-tech - Rook business, from a Rook Maintainer https://fleetdm.com/ https://fleetdm.com/ - Long time contributor is CTO. "Recruit" meaning see if the creator is interested in being CEO/CTO. And if they are one, find the other co-founder. OCV is trying to throw money at OSS maintainers and help them make a business with his connections, capital and experience. I literally watched him do it with DZ. I don't expect that to change with this new venture. But I am biased.
- ianbutler 4y ago
  That's good to see. He may want to change the wording then. It comes off much more of recruiting around the maintainers. I'd be curious what happens if they say no. But so far from what you just posted, the actions seem to speak more charitably than I read it. The entire thing read to me like a typical venture studio model that will wind up screwing OSS maintainers out of the value they have created. I'd really consider reworking the marketing copy. I was super disappointed to see it from the CEO of GitLab because generally speaking I love your product and because I think you guys have been THE model for how to properly monetize open core while walking a good line for the open source part.

hardwaresofton 4y ago

Disclaimer: I’ve been paid to write and do experiments/devrel for OCV and portfolio companies in the past 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. Speaking of the disclaimer, we tried to lay out the reasoning and background on how people make money in open source: https://opencoreventures.com/blog/2022-03-someone-has-to-pay-for-the-domino/ https://opencoreventures.com/blog/2022-03-someone-has-to-pay... 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). 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. Open source is 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. 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. 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.

ianbutler 4y ago
I agree with the mission and even more so: > Open source is 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. I was actually thinking along exactly these lines this morning. That's why I was disappointed in particular because of who's name was on it, because to me it reads poorly. That's why my reaction was so visceral. I'm glad to hear that in actuality it has really been benefiting those OSS maintainers, but I stand by at least my suggestion that some of the explainer/marketing copy on that site needs to change. It in my honest opinion does not read to the same level of positivity that you or lbotos below put it to.
- hardwaresofton 4y ago

freeqaz 4y ago

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...

whoville 4y ago

Railsify 4y ago

Shout out to Neo4j.

gregwebs 4y ago

IANAL and would love to be corrected, but the chart in this article may confuse many. 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! 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. Interestingly, there is a CLA that can be used to restrict the ability to relicense a contribution only to other specific open source licenses: http://www.harmonyagreements.org/docs/ha-cla-i.html http://www.harmonyagreements.org/docs/ha-cla-i.html

Brian_K_White 4y ago
"Only the copyright holder can relicense the software." The copyright holder who declares an MIT license, has explicitly granted the right to relicense.
- gregwebs 4y ago
  I don't believe this is true: the MIT license requires maintaining the MIT license disclaimer in the derived work. AFAICT, you cannot actually relicense MIT code (unless you hold the copyright). You can create a new derived work that contains it, and distribute that work as a whole with a new license, but the MIT code portion of that work will always maintain its license and require distributing the MIT license disclaimer. https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html https://softwarefreedom.org/resources/2007/gpl-non-gpl-colla... With that being said, for the purposes of the article we are discussing, this distinction may not be meaningful because one can still take an MIT code base proprietary even if the original code doesn't actually get re-licensed.

1letterunixname 4y ago

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. Docker maybe next given the way they're going. Provide value at a constant rate to things rather than bait to gain users and switch to exploiting them. The same could be said for too-good-to-be-true pricing. 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? OTOH, if you don't want anyone to use your software and if you want to stay poor, use a radioactive license like AGPL.

jacooper 4y ago
> OTOH, if you don't want anyone to use your software and if you want to stay poor, use a radioactive license like AGPL Lol, business HN look on the AGPL is truly funny, Because its made to stop people from using the code without contributing, which is exactly what you want to do. Also the biggest on-prem cloud system Nextcloud is under the AGPL, which has its own commercial company Nextcloud GmbH. https://github.com/nextcloud/server https://github.com/nextcloud/server
- Brian_K_White 4y ago
  I am always amused when people complain about the restriction not to be a d**k. Every time you see someone call something like AGPL something like radioactive, you just saw someone out themselves as a theif. Copyleft: "You can have this for free. You can use it for personal use, you can use it for making mony, you can even redistribute it, you can even sell copies of it itself! The only things you can't do are deny access to that which you were given for free from the next guy, or scrub the existing credits to pretend you wrote it." Theif: "Radioactive!" Me: More radioactive please!
  - Nomentatus 4y ago
    What you wrote matches the MIT license, not the AGPL, say. With AGPL, users have to immediately give away derivative works, and there are many business circumstances when that won't do. Hence dual licensing by the vendor - but alas dual licensing sets up the possibility of bait and switch, or can. I haven't even mentioned implied patent grants.

stevenmih 4y ago

Disclaimer: Cofounder/CEO of Ahana here, which provides a managed service of open source PrestoDB for fast, reliable SQL Lakehouses and analytics. 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. 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!

jacooper 4y ago

> 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. This Authentik? https://goauthentik.io https://goauthentik.io The maintainer works in Yelp(1), so is the company not associated with the actual founder of the project? 1. https://github.com/BeryJu https://github.com/BeryJu