8 ms·

Sentry is now Fair Source

39 points by the_mitsuhiko 2y ago

ramon156 2y ago
Fair enough
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
cratermoon 2y ago
I'm not sure what's special here. The company makes the source available, but doesn't accept changes from the community. If the community really hates what the company does with the product, it can fork it. If the company goes out of business, the license reverts to a standard OSI-approved one. Unless I'm missing something – entirely possible – this doesn't sound like anything new and different.
- 0_gravitas 2y ago
  From how I read the Fair Souce manifesto on their site, the company is allowed to accept and benefit patches made by dogooder developers, but those developers are not allowed to make any changes that impede on the "producer's business model", which implies that hard forks would actually be prohibited. So it's actually worse. You're allowed to do free labor for the company, and nothing/no one else.
  - whit537 2y ago
    > You're allowed to do free labor for the company Allowed? Sure. Expected to? Nope. I put it this way in the FAQ: > Developers can propose modifications back to the producer if they wish, or simply benefit from the company's continual investment in maintenance and improvement. https://fair.io/faq/ https://fair.io/faq/ That said, for me personally (taking my Sentry hat off for a second), I think the most interesting future is one in which companies use Fair Source licensing _and_ open hiring/twyw compensation: https://opensource.com/open-organization/16/5/employees-let-them-hire-themselves https://opensource.com/open-organization/16/5/employees-let-... https://gratipay.news/sharing-our-take-what-you-want-story-911dad62ac32 https://gratipay.news/sharing-our-take-what-you-want-story-9... Fair Source is a small step towards that as a possible future.
    - cratermoon 2y ago
      > open hiring/twyw compensation I'll be honest, that doesn't sound nice. It sounds like a way for corporations to skirt employment law, similar to other gig economy companies. Do not want.
      - whit537 2y ago
        That's not the way it felt when we did it: https://opensource.com/open-organization/16/7/compensating-employees-letting-them-take-what-they-want https://opensource.com/open-organization/16/7/compensating-e... Super-experimental, though. Not ready for prime time yet. :D
    - SkyPuncher 2y ago
      I would do this if it benefited my company. It’s almost always easier in the long run to fix something upstream than to have to maintain a downstream fork.
      - maccard 2y ago
        Any patch that I make to a third party dependency increases the risk of upgrading the dependency. Any change they take from us benefits us in the long term, and benefits the industry as a whole.
woodruffw 2y ago
Branded website is here[1]. Maybe it's because it's new, but the website doesn't offer a ton of insight into how "Fair Source" is different from other attempts to re-brand proprietary software as pseudo-open-source. For example, the FSS definition on the home page mentions "minimal restrictions," but I can't find a clear list of what those restrictions are in the FAQ[2]. (And to be clear: I'm not an ideologue around FOSS/OSS; I think source availability also benefits the commons. But I would not be surprised if FOSS/OSS people chafe at these kinds of implied-value-judgment labelings ("fair source," "commons clause") for what is fundamentally not OSS.) [1]: https://fair.io/about/ https://fair.io/about/ [2]: https://fair.io/faq/ https://fair.io/faq/
- ezekg 2y ago
  The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. That's why we needed a new term that does have a concrete definition and does convey user freedoms. Fair Source is meant to sit on the gradient between Open Source and source-available. It's not meant to replace Open Source, diminish Open Source, or claim to be Open Source. It isn't Open Source, and never has been. It's definitely not trying to be a "pseudo-open-source." It's a new term to clearly communicate something that's close to Open Source, if we envision that gradient between Open Source and source-available, and something that eventually contributes to Open Source via delayed Open Source publication (DOSP).
  - woodruffw 2y ago
    > The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. I don't particularly disagree; I'll just observe that calling your particular flavor of source availability the "fair" flavor is a leading characterization that people who do OSS (either for fun or professionally) aren't necessarily going to agree with. Concretely: I found the terms of the FCL[1], and one of the restraining terms of "competing use" against the "business interests" of the author. Any half-competent attorney could use this to argue that virtually any change, including basic security fixes, would harm the original author's business interests by reducing the relative competitiveness of their version. That doesn't strike me as very fair: as a security person in OSS, I don't want to be punished with lawsuits for trying to remove security problems from the projects I rely on. > It's definitely not trying to be a "pseudo-open-source." [...] It's a new term to clearly communicate something that's close to Open Source Can you explain why these sentences aren't contradictory? Please understand that I'm not using "pseudo" to mean something negative; I meant that it's clear you're attempting to adapt some of the features of OSS licensing into something that isn't itself OSS. That isn't a bad thing in my book, but I do think the "fair" labeling and repeated reference to the specific properties of OSS that FSS finds desirable is essentially obfuscatory. [1]: https://fcl.dev/ https://fcl.dev/
PreInternet01 2y ago
So, since I'm an unrepentant cynic, I guess it's now, like 1.5 months until the inevitable "Sentry: it has been an interesting journey" blog post? Anyway, so, I tried Sentry at some point, like, five years ago. Signed up for the 'team' plan, even though it's just lonely me, and had bugs coming in for about... a week, maybe less? Then, my subscription suddenly became inactive, because I had exceeded the 10K (or so, at the time) bugs that they were willing to track for me. Not, unique bugs, mind you, just the same bug that the same automated process was hitting every second or so. But still, I now had to either negotiate an "Enterprise" price plan, or go away elsewhere. And I did actually ping them about the former, but never got a response. So, well, back to manually reading logs like an animal it is, then, I guess? TL;DR: If your vision is to solve a certain problem, aren't the oh-we-didn't-see-that-coming corner cases the most interesting?
- LewisJEllis 2y ago
  Sentry's been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change? Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.
  - PreInternet01 2y ago
    > Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal" OK, maybe not, but, on the current version of https://sentry.io/pricing/ https://sentry.io/pricing/: Developer (free): 5K errors Team (US$312/user/year): 50K errors Business (US$960/user/year): 50K errors Enterprise (who knows): who knows So, they now go from 50K (which sounds close enough to '10K 5-or-so years ago', right?) errors to "negotiated enterprise deal", and I have no idea whether that's worth it? Do they coalesce errors these days? Again: I would love to use services like these, and I even don't mind getting a customized pricing plan, except that nobody like, ever, seems to want to talk about even the most basic details? "Just give us your credit card number, and we'll see what happens, we'll make it work"... Right! But, but by any means, go and complain on HN that's it impossible to get paying customers...
vetrom 2y ago
Per previous discussions: - https://news.ycombinator.com/item?id=38877059 https://news.ycombinator.com/item?id=38877059 (sentry FSL relicense) - in particular: https://news.ycombinator.com/item?id=38312686 (rugpull licensing still possible on future versions/contributions) - https://news.ycombinator.com/item?id=38046537 https://news.ycombinator.com/item?id=38046537 (an aside about AGPL vs BUSL vs similar license schemes) - Sentry's first relicense: https://news.ycombinator.com/item?id=21466967 https://news.ycombinator.com/item?id=21466967 Looking back to the first relicense in particular, the company effectively doing a rugpull on third party users/contributors, and the trend of companies trying to pretend they aren't doing exactly that sours me on basically any 'opencore'/required CLA project. I make rare exceptions for non-profits, but only those that are mature, well established, and not the sort of non-profit that puts most of their operation under a for-profit entity. As woodruffw mentions, these implied-value-judgement labelings are really marketing terms designed to muddle the value and importance of what it means to be an open source product. If it doesn't work for your business, fine, don't use an OSS license. But don't expect us to slurp up your peddling when you want to pretend its an OSS license, and don't act sad when you alienate swathes of your contributors. *EDIT*: I misspoke, my brain had thought that old Sentry licenses were GPL, they were more MITish as seen in the LICENSE file in older releases of Sentry. My mistake :\ FWIW, if Sentry had stayed MIT or even moved to AGPL, I think they would have stopped much of their newer competition from even coming to market (I'm thinking of signoz, glitchtip, vs OTEL and its million integrations here.) My position in 2019 was that much these decisions are being driven by the VC money, and I believe that is still true today. If it weren't, they could have chosen options that served the wider community better. (I also think that wider community and the accessibility of such is what got sentry much of its initial draw, but TBH im not sure how much that bears out in reality. I haven't studied deeply enough to have a good idea of the numbers there.)
- whit537 2y ago
  [disclaimer: Sentry employee] > don't act sad when you alienate swathes of your contributors This is ill-informed, for what it's worth. Our relicensing had essentially no effect on the ratio of commits from outside the company: it went from 3.5% to 3.4%. I wrote about this when OSI published the DOSP paper that we underwrote. https://blog.sentry.io/nows-the-time-for-delayed-open-source/ https://blog.sentry.io/nows-the-time-for-delayed-open-source... > the company effectively doing a rugpull on third party users/contributors Since Sentry has always been built by Sentry, our relicensing wasn't a rugpull. I wrote about this when Redis relicensed most recently: https://openpath.chadwhitacre.com/2024/relicensing-and-rug-pulls/ https://openpath.chadwhitacre.com/2024/relicensing-and-rug-p...
deleted 2y ago
[deleted]
paxys 2y ago
Another one in the long line of victims of the "popular open source product -> VC funding -> demand for profits -> closed source -> enshittification" pipeline.
PeterZaitsev 2y ago
I think it is great Sentry folks do not pretend it is Open Source. It is great to see innovation and we will see if it becomes popular. What I see is a lot of "single vendor" projects which carry most of development burden want their business protected while having, often minimal, contributions from community. The "Real Open Source" though is multi-vendor - think PostgreSQL, Linux, Kubernetes among others, in which case many parties share the burden of development and maintenance but also have even playing field monetizing product.
- whit537 2y ago
  I referenced Dirk's original "single-vendor" paper in the FAQ, "Why should I adopt Fair Source at my company?" fair.io/faq I engaged heavily with a lot of Dirk's work in my historical deep-dive: https://openpath.chadwhitacre.com/2024/the-historical-case-for-fair-source/ https://openpath.chadwhitacre.com/2024/the-historical-case-f... > Dirk asked in 2021, “What’s next after ‘source-available’?” Our answer is Fair Source. I’ve made the case that it is a good way to resolve tensions that have been present in Open Source since the beginning. The net effect can be more closed-source code released to the world, and less pressure to change the Open Source Definition one way or another. > we will see if it becomes popular Agreed, time will tell. A major test is whether we ever see a viable fork under DOSP, seems likely years away if ever.
janober 2y ago
Honestly generally love it. Not surprising, after all, are we at n8n Fair Code licensed ourselves(not to be confused with Fair Source). I would, however, really love it if it ended up being more inclusive and so in a joint effort rather than a divided one. More information about why we did not join here: https://medium.com/@faircode/n8n-commits-to-fair-code-6b892343fc68 https://medium.com/@faircode/n8n-commits-to-fair-code-6b8923...
- ezekg 2y ago
  I wish you would have been more involved in the discussions [0] [1] leading up to this. I know you were invited to participate, since Chad shared your thoughts a few times via proxy. Regarding your main points: 1. I'm on the governance 'board' for Fair Source, and I am not associated with Sentry. All it took was involvement and deeply caring about the subject (which I know you do). 2a. The requirement for delayed Open Source publication (DOSP) could have been discussed further if there was more involvement from other non-DOSP companies other than me (before I relicensed from ELv2 to FCL). I advocated for ELv2 to be considered Fair Source, but nobody else advocated with me, and I ended up abandoning it for the FCL. I was looking forward to you discussing SUL and how it was a good fit for Fair Source, but you never did. 2b. The lack of options for self-hosted monetization (e.g. EE/CE offerings) is no longer a problem for Fair Source under the Fair Core License [0], which I drafted alongside Heather Meeker (who helped draft FSL and ELv2) to solve the problem of self-hosted monetization under the FSL or BUSL. With that said, I think where we landed i.r.t. requiring DOSP makes sense as a differentiation vs open core and "source-available." I was originally vocally against Fair Source requiring DOSP, but the lack of involvement from other companies using ELv2, SSPL, and SUL, made the decision a little bit easier. [0]: https://github.com/fairsource/fair.io/issues/14 https://github.com/fairsource/fair.io/issues/14 [1]: https://github.com/fairsource/fair.io/issues/21 https://github.com/fairsource/fair.io/issues/21
  - janober 2y ago
    Yes, I totally agree that I should have been more involved in hindsight, and that is definitely on me! In the first conversation with Chad, we actually agreed on chatting again after a few weeks regarding the next steps, but that never happened. The next time I heard about it was a few weeks before the launch (and yes, for sure, also partly on me!). When I heard from Chad, DOSP was also still optional. The only issue I had was about governance. That sadly changed around one week later, and it became a hard requirement, even though I made very clear that it would be a deal breaker. So, I would say I was at least involved there, but it did not really matter. Worrying about something like that was interestingly also why governance was so important to me. I expected it to become a problem sometime later but was surprised that it was already a problem before it really started. Our original conversation was also more about what to move forward with, fair code or source, and should be more like a joint effort (at least how it sounded to me). I was, however, very honest about it, saying that my time was limited at that time, and so I am happy he takes the lead. Maybe that is where it partly broke down, and we understood something very different. Regarding differentiation: Honestly, I do not think the difference between "fair source" vs "open core" vs "source available" is what matters. What matters is the differentiation vs open source.
rubinlinux 2y ago
Nobody wants to 'read' your source code! The entire point of choosing to use open source projects is that if you, the author, begin to enshitify the product (Or simply start to move in a direction different from users) users can fork the project and carry on an un-enshitified version. If you can't compete with the author, you can't do that. So what is the point of picking software using this license over traditional closed source?
- maccard 2y ago
  It's not _just_ read, it's read and modify but not redistribute in a way that competes with the original product, > So what is the point of picking software using this license over traditional closed source? I don't want to compete with Sentry (or a variety of other open-like applications), but I _do_ want to support my employers identity provider, fix bugs (and push them back), and maybe even add features that I/my team use. As an example, I've personally contributed multiple bug fixes, performance improvements and documentation changes to sentry's libraries. I don't want to compete with sentry, I want them to maintain my improvements and for other developers to benefit from my work.

39 points by the_mitsuhiko 2y ago

ramon156 2y ago

Fair enough

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

cratermoon 2y ago

I'm not sure what's special here. The company makes the source available, but doesn't accept changes from the community. If the community really hates what the company does with the product, it can fork it. If the company goes out of business, the license reverts to a standard OSI-approved one. Unless I'm missing something – entirely possible – this doesn't sound like anything new and different.

0_gravitas 2y ago
From how I read the Fair Souce manifesto on their site, the company is allowed to accept and benefit patches made by dogooder developers, but those developers are not allowed to make any changes that impede on the "producer's business model", which implies that hard forks would actually be prohibited. So it's actually worse. You're allowed to do free labor for the company, and nothing/no one else.
- whit537 2y ago
  > You're allowed to do free labor for the company Allowed? Sure. Expected to? Nope. I put it this way in the FAQ: > Developers can propose modifications back to the producer if they wish, or simply benefit from the company's continual investment in maintenance and improvement. https://fair.io/faq/ https://fair.io/faq/ That said, for me personally (taking my Sentry hat off for a second), I think the most interesting future is one in which companies use Fair Source licensing _and_ open hiring/twyw compensation: https://opensource.com/open-organization/16/5/employees-let-them-hire-themselves https://opensource.com/open-organization/16/5/employees-let-... https://gratipay.news/sharing-our-take-what-you-want-story-911dad62ac32 https://gratipay.news/sharing-our-take-what-you-want-story-9... Fair Source is a small step towards that as a possible future.
  - cratermoon 2y ago
    > open hiring/twyw compensation I'll be honest, that doesn't sound nice. It sounds like a way for corporations to skirt employment law, similar to other gig economy companies. Do not want.
    - whit537 2y ago
      That's not the way it felt when we did it: https://opensource.com/open-organization/16/7/compensating-employees-letting-them-take-what-they-want https://opensource.com/open-organization/16/7/compensating-e... Super-experimental, though. Not ready for prime time yet. :D
  - SkyPuncher 2y ago
    I would do this if it benefited my company. It’s almost always easier in the long run to fix something upstream than to have to maintain a downstream fork.
    - maccard 2y ago
      Any patch that I make to a third party dependency increases the risk of upgrading the dependency. Any change they take from us benefits us in the long term, and benefits the industry as a whole.

woodruffw 2y ago

Branded website is here[1]. Maybe it's because it's new, but the website doesn't offer a ton of insight into how "Fair Source" is different from other attempts to re-brand proprietary software as pseudo-open-source. For example, the FSS definition on the home page mentions "minimal restrictions," but I can't find a clear list of what those restrictions are in the FAQ[2]. (And to be clear: I'm not an ideologue around FOSS/OSS; I think source availability also benefits the commons. But I would not be surprised if FOSS/OSS people chafe at these kinds of implied-value-judgment labelings ("fair source," "commons clause") for what is fundamentally not OSS.) [1]: https://fair.io/about/ https://fair.io/about/ [2]: https://fair.io/faq/ https://fair.io/faq/

ezekg 2y ago
The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. That's why we needed a new term that does have a concrete definition and does convey user freedoms. Fair Source is meant to sit on the gradient between Open Source and source-available. It's not meant to replace Open Source, diminish Open Source, or claim to be Open Source. It isn't Open Source, and never has been. It's definitely not trying to be a "pseudo-open-source." It's a new term to clearly communicate something that's close to Open Source, if we envision that gradient between Open Source and source-available, and something that eventually contributes to Open Source via delayed Open Source publication (DOSP).
- woodruffw 2y ago
  > The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. I don't particularly disagree; I'll just observe that calling your particular flavor of source availability the "fair" flavor is a leading characterization that people who do OSS (either for fun or professionally) aren't necessarily going to agree with. Concretely: I found the terms of the FCL[1], and one of the restraining terms of "competing use" against the "business interests" of the author. Any half-competent attorney could use this to argue that virtually any change, including basic security fixes, would harm the original author's business interests by reducing the relative competitiveness of their version. That doesn't strike me as very fair: as a security person in OSS, I don't want to be punished with lawsuits for trying to remove security problems from the projects I rely on. > It's definitely not trying to be a "pseudo-open-source." [...] It's a new term to clearly communicate something that's close to Open Source Can you explain why these sentences aren't contradictory? Please understand that I'm not using "pseudo" to mean something negative; I meant that it's clear you're attempting to adapt some of the features of OSS licensing into something that isn't itself OSS. That isn't a bad thing in my book, but I do think the "fair" labeling and repeated reference to the specific properties of OSS that FSS finds desirable is essentially obfuscatory. [1]: https://fcl.dev/ https://fcl.dev/

PreInternet01 2y ago

So, since I'm an unrepentant cynic, I guess it's now, like 1.5 months until the inevitable "Sentry: it has been an interesting journey" blog post? Anyway, so, I tried Sentry at some point, like, five years ago. Signed up for the 'team' plan, even though it's just lonely me, and had bugs coming in for about... a week, maybe less? Then, my subscription suddenly became inactive, because I had exceeded the 10K (or so, at the time) bugs that they were willing to track for me. Not, unique bugs, mind you, just the same bug that the same automated process was hitting every second or so. But still, I now had to either negotiate an "Enterprise" price plan, or go away elsewhere. And I did actually ping them about the former, but never got a response. So, well, back to manually reading logs like an animal it is, then, I guess? TL;DR: If your vision is to solve a certain problem, aren't the oh-we-didn't-see-that-coming corner cases the most interesting?

LewisJEllis 2y ago
Sentry's been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change? Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.
- PreInternet01 2y ago
  > Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal" OK, maybe not, but, on the current version of https://sentry.io/pricing/ https://sentry.io/pricing/: Developer (free): 5K errors Team (US$312/user/year): 50K errors Business (US$960/user/year): 50K errors Enterprise (who knows): who knows So, they now go from 50K (which sounds close enough to '10K 5-or-so years ago', right?) errors to "negotiated enterprise deal", and I have no idea whether that's worth it? Do they coalesce errors these days? Again: I would love to use services like these, and I even don't mind getting a customized pricing plan, except that nobody like, ever, seems to want to talk about even the most basic details? "Just give us your credit card number, and we'll see what happens, we'll make it work"... Right! But, but by any means, go and complain on HN that's it impossible to get paying customers...

vetrom 2y ago

Per previous discussions: - https://news.ycombinator.com/item?id=38877059 https://news.ycombinator.com/item?id=38877059 (sentry FSL relicense) - in particular: https://news.ycombinator.com/item?id=38312686 (rugpull licensing still possible on future versions/contributions) - https://news.ycombinator.com/item?id=38046537 https://news.ycombinator.com/item?id=38046537 (an aside about AGPL vs BUSL vs similar license schemes) - Sentry's first relicense: https://news.ycombinator.com/item?id=21466967 https://news.ycombinator.com/item?id=21466967 Looking back to the first relicense in particular, the company effectively doing a rugpull on third party users/contributors, and the trend of companies trying to pretend they aren't doing exactly that sours me on basically any 'opencore'/required CLA project. I make rare exceptions for non-profits, but only those that are mature, well established, and not the sort of non-profit that puts most of their operation under a for-profit entity. As woodruffw mentions, these implied-value-judgement labelings are really marketing terms designed to muddle the value and importance of what it means to be an open source product. If it doesn't work for your business, fine, don't use an OSS license. But don't expect us to slurp up your peddling when you want to pretend its an OSS license, and don't act sad when you alienate swathes of your contributors. *EDIT*: I misspoke, my brain had thought that old Sentry licenses were GPL, they were more MITish as seen in the LICENSE file in older releases of Sentry. My mistake :\ FWIW, if Sentry had stayed MIT or even moved to AGPL, I think they would have stopped much of their newer competition from even coming to market (I'm thinking of signoz, glitchtip, vs OTEL and its million integrations here.) My position in 2019 was that much these decisions are being driven by the VC money, and I believe that is still true today. If it weren't, they could have chosen options that served the wider community better. (I also think that wider community and the accessibility of such is what got sentry much of its initial draw, but TBH im not sure how much that bears out in reality. I haven't studied deeply enough to have a good idea of the numbers there.)

whit537 2y ago
[disclaimer: Sentry employee] > don't act sad when you alienate swathes of your contributors This is ill-informed, for what it's worth. Our relicensing had essentially no effect on the ratio of commits from outside the company: it went from 3.5% to 3.4%. I wrote about this when OSI published the DOSP paper that we underwrote. https://blog.sentry.io/nows-the-time-for-delayed-open-source/ https://blog.sentry.io/nows-the-time-for-delayed-open-source... > the company effectively doing a rugpull on third party users/contributors Since Sentry has always been built by Sentry, our relicensing wasn't a rugpull. I wrote about this when Redis relicensed most recently: https://openpath.chadwhitacre.com/2024/relicensing-and-rug-pulls/ https://openpath.chadwhitacre.com/2024/relicensing-and-rug-p...

deleted 2y ago

[deleted]

paxys 2y ago

Another one in the long line of victims of the "popular open source product -> VC funding -> demand for profits -> closed source -> enshittification" pipeline.

PeterZaitsev 2y ago

I think it is great Sentry folks do not pretend it is Open Source. It is great to see innovation and we will see if it becomes popular. What I see is a lot of "single vendor" projects which carry most of development burden want their business protected while having, often minimal, contributions from community. The "Real Open Source" though is multi-vendor - think PostgreSQL, Linux, Kubernetes among others, in which case many parties share the burden of development and maintenance but also have even playing field monetizing product.

whit537 2y ago
I referenced Dirk's original "single-vendor" paper in the FAQ, "Why should I adopt Fair Source at my company?" fair.io/faq I engaged heavily with a lot of Dirk's work in my historical deep-dive: https://openpath.chadwhitacre.com/2024/the-historical-case-for-fair-source/ https://openpath.chadwhitacre.com/2024/the-historical-case-f... > Dirk asked in 2021, “What’s next after ‘source-available’?” Our answer is Fair Source. I’ve made the case that it is a good way to resolve tensions that have been present in Open Source since the beginning. The net effect can be more closed-source code released to the world, and less pressure to change the Open Source Definition one way or another. > we will see if it becomes popular Agreed, time will tell. A major test is whether we ever see a viable fork under DOSP, seems likely years away if ever.

janober 2y ago

Honestly generally love it. Not surprising, after all, are we at n8n Fair Code licensed ourselves(not to be confused with Fair Source). I would, however, really love it if it ended up being more inclusive and so in a joint effort rather than a divided one. More information about why we did not join here: https://medium.com/@faircode/n8n-commits-to-fair-code-6b892343fc68 https://medium.com/@faircode/n8n-commits-to-fair-code-6b8923...

ezekg 2y ago
I wish you would have been more involved in the discussions [0] [1] leading up to this. I know you were invited to participate, since Chad shared your thoughts a few times via proxy. Regarding your main points: 1. I'm on the governance 'board' for Fair Source, and I am not associated with Sentry. All it took was involvement and deeply caring about the subject (which I know you do). 2a. The requirement for delayed Open Source publication (DOSP) could have been discussed further if there was more involvement from other non-DOSP companies other than me (before I relicensed from ELv2 to FCL). I advocated for ELv2 to be considered Fair Source, but nobody else advocated with me, and I ended up abandoning it for the FCL. I was looking forward to you discussing SUL and how it was a good fit for Fair Source, but you never did. 2b. The lack of options for self-hosted monetization (e.g. EE/CE offerings) is no longer a problem for Fair Source under the Fair Core License [0], which I drafted alongside Heather Meeker (who helped draft FSL and ELv2) to solve the problem of self-hosted monetization under the FSL or BUSL. With that said, I think where we landed i.r.t. requiring DOSP makes sense as a differentiation vs open core and "source-available." I was originally vocally against Fair Source requiring DOSP, but the lack of involvement from other companies using ELv2, SSPL, and SUL, made the decision a little bit easier. [0]: https://github.com/fairsource/fair.io/issues/14 https://github.com/fairsource/fair.io/issues/14 [1]: https://github.com/fairsource/fair.io/issues/21 https://github.com/fairsource/fair.io/issues/21
- janober 2y ago
  Yes, I totally agree that I should have been more involved in hindsight, and that is definitely on me! In the first conversation with Chad, we actually agreed on chatting again after a few weeks regarding the next steps, but that never happened. The next time I heard about it was a few weeks before the launch (and yes, for sure, also partly on me!). When I heard from Chad, DOSP was also still optional. The only issue I had was about governance. That sadly changed around one week later, and it became a hard requirement, even though I made very clear that it would be a deal breaker. So, I would say I was at least involved there, but it did not really matter. Worrying about something like that was interestingly also why governance was so important to me. I expected it to become a problem sometime later but was surprised that it was already a problem before it really started. Our original conversation was also more about what to move forward with, fair code or source, and should be more like a joint effort (at least how it sounded to me). I was, however, very honest about it, saying that my time was limited at that time, and so I am happy he takes the lead. Maybe that is where it partly broke down, and we understood something very different. Regarding differentiation: Honestly, I do not think the difference between "fair source" vs "open core" vs "source available" is what matters. What matters is the differentiation vs open source.

rubinlinux 2y ago

Nobody wants to 'read' your source code! The entire point of choosing to use open source projects is that if you, the author, begin to enshitify the product (Or simply start to move in a direction different from users) users can fork the project and carry on an un-enshitified version. If you can't compete with the author, you can't do that. So what is the point of picking software using this license over traditional closed source?

maccard 2y ago
It's not _just_ read, it's read and modify but not redistribute in a way that competes with the original product, > So what is the point of picking software using this license over traditional closed source? I don't want to compete with Sentry (or a variety of other open-like applications), but I _do_ want to support my employers identity provider, fix bugs (and push them back), and maybe even add features that I/my team use. As an example, I've personally contributed multiple bug fixes, performance improvements and documentation changes to sentry's libraries. I don't want to compete with sentry, I want them to maintain my improvements and for other developers to benefit from my work.