10 ms·

Open Source, SaaS and Monetization

seanwilson 7y ago
I work on a paid Chrome extension that tests if your website follows SEO, speed and security best practices: https://www.checkbot.io/ https://www.checkbot.io/ I considered making it open source but couldn't see a way I could monetise it if I tried to charge for it mainly because someone could just upload a free version to the Chrome Web Store. Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful. Helping users with support requests is already enough work when you're a solo developer too. Generally, I guess you have to weigh up: 1) time investment from open sourcing and maintaining a community vs 2) benefits you'll get from having open source contributors vs 3) increased competition from the open source version With some app ideas, it's very hard to reduce the impact of factor 3 which is a shame.
- kemitchell 7y ago
  I lead a project to develop a strong-copyleft license that makes development tools "free for open source": https://paritylicense.com https://paritylicense.com The idea was that developers like you could make your tools available under Parity and charge folks who want to use their code to develop closed, rather than open, software. However, several projects and companies have also used the license simply to make sure their work stays open, without selling any permission to build closed projects.
  - seanwilson 7y ago
    I like the idea. How would it stop someone releasing a free version of a paid development tool though? It relies on people downloading the free tool to be honest enough not to use it on commercial projects?
    - kemitchell 7y ago
      No license can guarantee compliance with its own rules. That's true of all copyleft licenses, including GPL, EPL, and MPL. Whether and how to enforce the license is up to the developer.
      - seanwilson 7y ago
        So for tools like https://www.checkbot.io/ https://www.checkbot.io/ specifically, where the tool gives you a list of problems to go and fix, it would be easy to use the tool on a commercial project and conceal that you did so. I can see a license like yours working for a library you had to integrate though as I can't imagine any serious company would risk integrating a library in a way that violates the license.
- capableweb 7y ago
  > Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful I agree with the rest of what you said, but not this quoted parts. Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means. Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project.
  - seanwilson 7y ago
    > Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means. I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs. If you don't do this, aren't you missing out on a lot of big reasons to make it open source? > Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project. Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests. Going back to my list, if you aren't doing item 1, you're not going to get much of benefit 2, and item 3 is going to be a risk for little gain.
    - capableweb 7y ago
      > I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs. I see. I don't want to be pedantic (but I guess I am anyway) but building a community and open sourcing code are two very different things. If you're running a business, in no way should we force them to do what we can call "community open source". The idea is that you can modify the code to your needs, and neither of the community things are absolutely needed for this. Of course it helps, but I feel like we miss out on a lot of companies open sourcing their code if we only care if they build a open source community too. > If you don't do this, aren't you missing out on a lot of big reasons to make it open source? Everyone have their own reasons for open sourcing something. I'm sure everyone could handle their incoming open source contributions better, but in the end it's up to the companies/organizations/projects/people themselves. > Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests. That sounds great to me, maybe I'm missing something. If someone makes something that is better than your thing, wouldn't the best thing (for the users) be to use that then? Or if it makes different tradeoffs, that maybe makes sense in more scenarios? You still have to make sure you're a better product for someone to purchase, if you now so persistently want to run a company based on your open source code. You can still run a better product than your competitors. Also, if you don't want to open source your code, that's fine too. Probably in the future (if not already), having open source code is a advantage against your competitors.
ensignavenger 7y ago
I have a tremendous amount of and appreciation for Armin Ronacher and many of their fabulous Python libraries which I use regularly. However, this blog post is odd. It says that the open source sass model "has worked out very well for us", but then goes on to say "at one point someone has to make money somewhere.." in order to justify abandoning open source licensing of Sentry. Maybe "worked out great" means that they got a ton of publicity and traction because they were open source, and now they are ready to abandon open source so they can monetize the traction they gained from being open source in the first place? Sentry certainly doesn't have any obligation to continue being open source- the old code is still open source- but these events make me question any companies commitment when they claim to be open source. It seems that you can't take any company at their word, even when they publish multiple blog posts about how "committed" they are to open source- because in the end, many companies will do what Sentry did and will dump open source the minute they have gotten what they want from it. [https://blog.sentry.io/2019/02/14/sentry-thrives-open-source-software-company https://blog.sentry.io/2019/02/14/sentry-thrives-open-source..., https://blog.sentry.io/2016/10/24/building-an-open-source-service https://blog.sentry.io/2016/10/24/building-an-open-source-se..., https://blog.sentry.io/2015/06/30/driven-by-open-source https://blog.sentry.io/2015/06/30/driven-by-open-source] And if there was any doubt about Sentry's willingness to use and abuse open source- months after this announcement, they continue to advertise being open source on their site, lying to the community and their customers. https://sentry.io/_/open-source/ https://sentry.io/_/open-source/ Sentry doesn't have any obligation to continue to releasing new code as Open Source, but they should stop lying about being open source.
- japhyr 7y ago
  I have been aware of Sentry for years, but I've never used it and haven't followed the company closely. Reading Armin's post, and the official Sentry announcement [0], this strikes me as pretty reasonable. Sentry is about 11 years old. The industry has changed a lot in 11 years. There are people and companies around now that can build direct competitors more quickly than they could 11 years ago. The question raised in the Sentry post is completely valid: Was the license chosen 11 years ago the best one to base a company off of? A company relicensing its software after 11 years is a lot different than a company waving the open source flag for a year and then closing off access. I appreciate the work people are doing to find a middle ground in the open source world. Purist approaches are important in many areas, but can't work for everyone and for every project. People who are suggesting that Sentry is no longer open source have a point, but there is also a world of difference to me between a company using a BSL, and a company whose entire codebase is a black box to the outside world. One of the key questions I ask about companies built around open source, is "Are you being honest about your business structure?" I'm fine with middle-ground open source licenses as long as the terms are clear and transparent. I have no respect for hidden small-text clauses that put legal limits in place which contradicts what a company's PR copy says. I say all of this from the perspective of a programmer who wants to be able to sustain my own work, as a user of open source who wants to have some libraries that are fully open, and as a customer who wants to pay people for reliable software-related services. [0] https://blog.sentry.io/2019/11/06/relicensing-sentry https://blog.sentry.io/2019/11/06/relicensing-sentry
karterk 7y ago
This is a topic that I have been thinking a lot on recently. I've been working on a typo-tolerant instant search engine for a couple of years now called Typesense (https://github.com/typesense/typesense https://github.com/typesense/typesense). It has not been wildly popular (mostly because I've not really started marketing it) but it's loved by those who use it. While exploring how to support its development, there were only 2 options: either to offer a hosted version or premium features which will take some features away from the open source version (essentially open core). A hosted version is essentially ruled out since it's a lot of work and will eventually be bettered by AWS :) Open core will mean crippling the main product in some ways. Tricky choice. Eventually I ended up with a middle-ground. Offer a premium version but price it so reasonable (in my case 500 USD / year) that it becomes a no-brainer decision. The only downside to this approach is of course you can't probably run a company off it but it certainly can support 2-3 people comfortably IF it succeeds.
nif2ee 7y ago
It is kinda ironic that most people zealously arguing for the "pure" open source definition and harrassing authors here on HN or even on Github issues are the ones who work for FAANG-tier companies and making 6 figures contributing little to nothing to open source projects or getting paid for their contributions. There must be a way to protect authors and small startups from simply being ripped-off by any lazy for-profit entity. I don't think that 99.99999% of users would mind to use an application that is identical with MIT, Apache, GPL plus a clause that protects the author or company that created it.
- zozbot234 7y ago
  The author has chosen an approach which makes the software available under the Apache 2.0 license after an embargo period. This is quite okay under the "pure" open source definition (at least for those "liberated" releases, if obviously not in the broadest sense), and nobody is harassing him for that. Many crowdfunding models come with this sort of time-limited "exclusivity".
  - nif2ee 7y ago
    but that's exactly what they do, many people here posted SHOW HN threads for github for-profit projects that use clauses in licenses or licenses like BSL, SSPL and the posts turned into harassment party because of the "hijacking" of pure open source according to them.
    - eitland 7y ago
      A little bit of nuance might help. I can like the idea of the BSL. I have no problems seing the justification for that. What certain people does, that makes me and others react is when they insist on their commons clause licensed applications or libraries being open source.
    - zerkten 7y ago
      The problem here is programmers having a fixation on licences as some sort of template that must be followed exactly without having any real experience with how the law actually works. This is convenient for something like an OSS license used extensively because you have some common reference. However, many contracts don't follow a template and it's normal in other contracts for items to be customized to any extent required. Template licenses are often used to intimidate people who aren't aware of their rights and what is possible. For example, employers may say that they can't modify an employment agreement because it's a standard template to make the potential employee feel like there is some legal rather than policy issue at play. Similar things happen in other places and you have to decide how much you want to fight policy, but parties almost always have the option of agreeing on custom terms. This is hard today in the OSS ecosystem, but it'll have to evolve to support additional terms.
danShumway 7y ago
> Open Source is pretty clear cut: it does not discriminate. If you get the source, you can do with it what you want (within the terms of the license) and no matter who you are (within the terms of the license). However as Open Source is defined — and also how I see it — Open Source comes with no strings attached. The moment we restrict what you can do with it — like not compete — it becomes something else. I appreciate this distinction. I don't have anything against a company updating its licenses to remain profitable, as long as they're up-front about what they're doing. My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit, or that the restrictions are just technicalities that everyone should ignore, or that Open Source is doomed and they're here to save everyone. Not everything needs to be Open Source, but Open Source should mean something.
- jboynyc 7y ago
  You might also be interested in this essay on "proprietary relicensing" from the Software Freedom Conservancy: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/ https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
  - danShumway 7y ago
    I am! This was an interesting read, thanks. In particular, I fee like the comment on copyright assignment is an insightful way of explaining why these approaches to licensing often feel inconsistent with company claims to support 'Openness': > If an entity does not gladly bind itself by its own copyleft license (for example, by accepting third-party contributions to its codebases under that license), we should not treat that entity as a legitimate license steward, nor treat that license as a legitimate FOSS license.
- anderspitman 7y ago
  > My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit If a project is still usable in 99.9% of the ways most developers would care about (ie everything except AWS hosting their own paid version), are you saying you don't like it when projects communicate that fact by saying things like, "we're almost open source, except X"?
jamesbiv 7y ago
I had a very similar dilemma myself when putting together a project of mine a few months ago. However, at the end of the day, I felt that keeping the license of the solution (or core solution) as MIT was the best option irrespective, and my thoughts came from the following areas in which monetisation can be substantiated. - Labor costs for staff, which include developers, network administrators, and support officers. - Costs incurred for resources, server infrastructure, office resources and so fourth. - And of course marketing and sales of the solution. The key is to communicate this substation, therefore asking customers for donations, i feel, becomes irrelevant if you can do that effectively. So really the gist is "it's great that the software is free but someone has to run it and even more so someone has to keep supporting it". Ideally, my opinion on monetisating comes from the business model which encapsulates the solution, therefore licensing the end product can just be focused around the tangibles that inherently make up the business side of a SaaS company. I think the most murky part of this dilemma comes from professional services and enterprise grade solutions because this is where custom and closed treatment maybe needed for the client. Plus other issues come more from a security standpoint and trade secret standpoint than anywhere else. For instance customisation on top of a SaaS platform via APIs or integration work may require the asset (or code) to be closed source from the perspective to satisfy the clients' needs, but this has always been an issue and is not a SaaS centric problem as the argument only comes during the purchase cycle of a company and the IT manager asks the question "can our business trust open source?".
ahnick 7y ago
The model we are planning to use for the products at Plyint(https://plyint.com https://plyint.com) is basically the "Free Software Product" model in a SaaS format. How this will work is we will release the code with a proprietary license, but then if you want to use it in a product or pure open source fork, then you need to go to the trouble of removing the company name and product references. Once, that is done then the license will become an AGPL license that can be used as one would normally expect and any modifications to that code would need to be released again publicly. (This way any fork is required to contribute their code back to the public domain) I think this will introduce enough time delay that the SaaS service will establish itself. Plus, the product has to become popular enough for anyone to want to go through that level of effort. Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.
- teddyh 7y ago
  > any modifications to that code would need to be released again publicly. Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted by the GPL/AGPL, and if you don’t allow them, you are violating the GPL/AGPL license by adding this additional restriction. Of course, this might not be a problem, for two reasons: Firstly, you might be the sole copyright holder, in which case you don’t need a license (it is instead you who give licenses to others), and secondly, for a SaaS product, any public use by a third party will make the AGPL kick in and require, from the third party, a release of the modified source. > Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well. Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications (except when the AGPL requires it; i.e. when the software is available publicly). Also, you can’t then release this code under a proprietary license, which you say is your plan. Note: If you’re OK with the release of modifications which AGPL requires, then everything is fine. It’s only if you insist on the release of all private modifications that you could run into trouble.
  - ahnick 7y ago
nif2ee 7y ago
>I remember too many cases of people that tried to do dual licensing with code and ended up regretting it after ownership was transferred or they had a fall out with other partners. Can somebody here elaborate on this?
deleted 7y ago
[deleted]
quaffapint 7y ago
For my upcoming saas I wanted to do something similar... -Paid hosted saas solution -Freely downloadable to use and install for your own projects ...I want people to be allowed to make money with it even if they freely download it, but I just don't want them to be able to compete with my hosted saas. I'm not quite sure that this is what the BSL is saying, so is there a license for something like that?
- thebigshane 7y ago
  I think that is what Armin was looking for as well, but couldn't find anything that quite did that so settled on the BSL instead (probably because determining what fork qualifies as competing or not seems hard). BSL seems close, but seems to disallow any commercial usage (IANAL!)?
- progval 7y ago
  This is mostly the goal of MongoDB's license, the Service-Side Public License: > A company that offers a publicly available MongoDB as a service must release the software it uses to offer such service under the terms of the SSPL, including the management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the source code made available. https://www.mongodb.com/licensing/server-side-public-license/faq#when-to-use https://www.mongodb.com/licensing/server-side-public-license...
- candiddevmike 7y ago
  I've looked into this in the past and couldn't find any non commercial licenses. Creative Commons has one, but it isn't suitable for software as it lacks a warranty clause. Curious if there is anything out there too.
soumyadeb 7y ago
We have been thinking about this a lot for our open-source Segment project (https://github.com/rudderlabs/rudder-server/ https://github.com/rudderlabs/rudder-server/). We launched things under mongo-SSPL (which is not a OSS approved license) but we now think AGPL is probably good enough for a product like ours. AGPL should kick in for anything (e.g. mobile app) that sends events to the our AGPL-backend so needs to be open-sourced too - that should be a strong enough deterrent for anyone to offer this as a service. Is this statement true? If yes, why did Mongo with with SSPL instead of AGPL? At the same time, we still want businesses who don't care about OSS to use Rudder without having to open-source their code. To address that we are thinking of releasing our binary (and AMI images etc) under MIT license. Sure, someone can spin up a SaaS service on the binary but that's hard. Any feedback on this would be highly appreciated.
- matchy 7y ago
  AGPL hasn’t really been tested in court so it’s not clear whether it would be enough to stop someone from running your software as a service.
  - soumyadeb 7y ago
    Isn't that true for most OSS licenses (not being tested in court)?
danenania 7y ago
I don't believe we've been served well by defining the term "Open Source" to also necessarily mean "Free". This definition and the accompanying zealotry mainly serves big tech and the cloud providers. Everyone else would be better off if we as an industry also make room for software that is Open (in the sense that the code is freely available), but not Free (you must pay or obtain permission to run it yourself, re-distribute it, or run it for others). Open is almost universally good. Open means self-hosting, auditability, ability to patch/submit patches for problems yourself, and not being up shit creek if the provider folds. But Free? Free might not always be bad, but it has a lot of problems. Free = a race to the bottom. Free = ads. Free = selling user data. Free = no one cares enough to maintain it. Free = no one cares enough to promote it. Free = no one can afford to hire a UX designer. Free = ripped off by AWS. Free = bait and switch when the VC gets impatient. For all these reasons, you should demand access to the code, yes, but you should also be willing to pay the people who write the crucial software you rely on. It's far more sustainable and healthier for our industry.
- soumyadeb 7y ago
  Stallman keeps saying Free of OSS is "Freedom of Speech" not "Free Beer". However, the "Free Beer" part is also important - there won't be any startup if every software (open-code or not) required big license fees. Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today.
  - danenania 7y ago
    "Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today." Yes, I agree wholeheartedly. My problem is with the many folks who automatically discount anything that is not "Free Beer". This attitude seems to be quite pervasive, unfortunately.
    - soumyadeb 7y ago
      Fair enough. Having a "OSS-compliant" license which supports "payment to run the sofrware" would help open-source startups like us but I guess "requiring payment" will hurt the "Freedom of Speech" part of OSS. An analogy would be - you have "Freedom of Speech" in a democracy but it requires a 100$ payment. Maybe?
nicpottier 7y ago
We are in a similar position and probably survive mostly through luck despite having vendors that sell our Open Source SaaS without contributing anything meaningful back. In our particular case I don't think the BSL would work for us, but I definitely understand and support Sentry going this route. FWIW, we have been using Sentry for almost a decade and while we started off hosting our own server we quickly saw the advantage in paying for it instead (and we were happy to do so). It's a tough thing to balance for sure, they have been one of the players we watch to see how Open Source SaaS can work and I wish them luck.
flurdy 7y ago
CockroachDB also changed to BSL[1] last summer. I think it is what a lot of my projects would aim to be. Free to use, tweak, contribute. Free to launch products using it. But not free to launch a service as SAAS or API that does more or less the same? * [1] https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...

I work on a paid Chrome extension that tests if your website follows SEO, speed and security best practices: https://www.checkbot.io/ https://www.checkbot.io/ I considered making it open source but couldn't see a way I could monetise it if I tried to charge for it mainly because someone could just upload a free version to the Chrome Web Store. Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful. Helping users with support requests is already enough work when you're a solo developer too. Generally, I guess you have to weigh up: 1) time investment from open sourcing and maintaining a community vs 2) benefits you'll get from having open source contributors vs 3) increased competition from the open source version With some app ideas, it's very hard to reduce the impact of factor 3 which is a shame.

kemitchell 7y ago
I lead a project to develop a strong-copyleft license that makes development tools "free for open source": https://paritylicense.com https://paritylicense.com The idea was that developers like you could make your tools available under Parity and charge folks who want to use their code to develop closed, rather than open, software. However, several projects and companies have also used the license simply to make sure their work stays open, without selling any permission to build closed projects.
- seanwilson 7y ago
  I like the idea. How would it stop someone releasing a free version of a paid development tool though? It relies on people downloading the free tool to be honest enough not to use it on commercial projects?
  - kemitchell 7y ago
    No license can guarantee compliance with its own rules. That's true of all copyleft licenses, including GPL, EPL, and MPL. Whether and how to enforce the license is up to the developer.
    - seanwilson 7y ago
      So for tools like https://www.checkbot.io/ https://www.checkbot.io/ specifically, where the tool gives you a list of problems to go and fix, it would be easy to use the tool on a commercial project and conceal that you did so. I can see a license like yours working for a library you had to integrate though as I can't imagine any serious company would risk integrating a library in a way that violates the license.
capableweb 7y ago
> Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful I agree with the rest of what you said, but not this quoted parts. Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means. Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project.
- seanwilson 7y ago
  > Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means. I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs. If you don't do this, aren't you missing out on a lot of big reasons to make it open source? > Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project. Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests. Going back to my list, if you aren't doing item 1, you're not going to get much of benefit 2, and item 3 is going to be a risk for little gain.
  - capableweb 7y ago
    > I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs. I see. I don't want to be pedantic (but I guess I am anyway) but building a community and open sourcing code are two very different things. If you're running a business, in no way should we force them to do what we can call "community open source". The idea is that you can modify the code to your needs, and neither of the community things are absolutely needed for this. Of course it helps, but I feel like we miss out on a lot of companies open sourcing their code if we only care if they build a open source community too. > If you don't do this, aren't you missing out on a lot of big reasons to make it open source? Everyone have their own reasons for open sourcing something. I'm sure everyone could handle their incoming open source contributions better, but in the end it's up to the companies/organizations/projects/people themselves. > Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests. That sounds great to me, maybe I'm missing something. If someone makes something that is better than your thing, wouldn't the best thing (for the users) be to use that then? Or if it makes different tradeoffs, that maybe makes sense in more scenarios? You still have to make sure you're a better product for someone to purchase, if you now so persistently want to run a company based on your open source code. You can still run a better product than your competitors. Also, if you don't want to open source your code, that's fine too. Probably in the future (if not already), having open source code is a advantage against your competitors.

ensignavenger 7y ago

I have a tremendous amount of and appreciation for Armin Ronacher and many of their fabulous Python libraries which I use regularly. However, this blog post is odd. It says that the open source sass model "has worked out very well for us", but then goes on to say "at one point someone has to make money somewhere.." in order to justify abandoning open source licensing of Sentry. Maybe "worked out great" means that they got a ton of publicity and traction because they were open source, and now they are ready to abandon open source so they can monetize the traction they gained from being open source in the first place? Sentry certainly doesn't have any obligation to continue being open source- the old code is still open source- but these events make me question any companies commitment when they claim to be open source. It seems that you can't take any company at their word, even when they publish multiple blog posts about how "committed" they are to open source- because in the end, many companies will do what Sentry did and will dump open source the minute they have gotten what they want from it. [https://blog.sentry.io/2019/02/14/sentry-thrives-open-source-software-company https://blog.sentry.io/2019/02/14/sentry-thrives-open-source..., https://blog.sentry.io/2016/10/24/building-an-open-source-service https://blog.sentry.io/2016/10/24/building-an-open-source-se..., https://blog.sentry.io/2015/06/30/driven-by-open-source https://blog.sentry.io/2015/06/30/driven-by-open-source] And if there was any doubt about Sentry's willingness to use and abuse open source- months after this announcement, they continue to advertise being open source on their site, lying to the community and their customers. https://sentry.io/_/open-source/ https://sentry.io/_/open-source/ Sentry doesn't have any obligation to continue to releasing new code as Open Source, but they should stop lying about being open source.

japhyr 7y ago
I have been aware of Sentry for years, but I've never used it and haven't followed the company closely. Reading Armin's post, and the official Sentry announcement [0], this strikes me as pretty reasonable. Sentry is about 11 years old. The industry has changed a lot in 11 years. There are people and companies around now that can build direct competitors more quickly than they could 11 years ago. The question raised in the Sentry post is completely valid: Was the license chosen 11 years ago the best one to base a company off of? A company relicensing its software after 11 years is a lot different than a company waving the open source flag for a year and then closing off access. I appreciate the work people are doing to find a middle ground in the open source world. Purist approaches are important in many areas, but can't work for everyone and for every project. People who are suggesting that Sentry is no longer open source have a point, but there is also a world of difference to me between a company using a BSL, and a company whose entire codebase is a black box to the outside world. One of the key questions I ask about companies built around open source, is "Are you being honest about your business structure?" I'm fine with middle-ground open source licenses as long as the terms are clear and transparent. I have no respect for hidden small-text clauses that put legal limits in place which contradicts what a company's PR copy says. I say all of this from the perspective of a programmer who wants to be able to sustain my own work, as a user of open source who wants to have some libraries that are fully open, and as a customer who wants to pay people for reliable software-related services. [0] https://blog.sentry.io/2019/11/06/relicensing-sentry https://blog.sentry.io/2019/11/06/relicensing-sentry

karterk 7y ago

This is a topic that I have been thinking a lot on recently. I've been working on a typo-tolerant instant search engine for a couple of years now called Typesense (https://github.com/typesense/typesense https://github.com/typesense/typesense). It has not been wildly popular (mostly because I've not really started marketing it) but it's loved by those who use it. While exploring how to support its development, there were only 2 options: either to offer a hosted version or premium features which will take some features away from the open source version (essentially open core). A hosted version is essentially ruled out since it's a lot of work and will eventually be bettered by AWS :) Open core will mean crippling the main product in some ways. Tricky choice. Eventually I ended up with a middle-ground. Offer a premium version but price it so reasonable (in my case 500 USD / year) that it becomes a no-brainer decision. The only downside to this approach is of course you can't probably run a company off it but it certainly can support 2-3 people comfortably IF it succeeds.

nif2ee 7y ago

It is kinda ironic that most people zealously arguing for the "pure" open source definition and harrassing authors here on HN or even on Github issues are the ones who work for FAANG-tier companies and making 6 figures contributing little to nothing to open source projects or getting paid for their contributions. There must be a way to protect authors and small startups from simply being ripped-off by any lazy for-profit entity. I don't think that 99.99999% of users would mind to use an application that is identical with MIT, Apache, GPL plus a clause that protects the author or company that created it.

zozbot234 7y ago
The author has chosen an approach which makes the software available under the Apache 2.0 license after an embargo period. This is quite okay under the "pure" open source definition (at least for those "liberated" releases, if obviously not in the broadest sense), and nobody is harassing him for that. Many crowdfunding models come with this sort of time-limited "exclusivity".
- nif2ee 7y ago
  but that's exactly what they do, many people here posted SHOW HN threads for github for-profit projects that use clauses in licenses or licenses like BSL, SSPL and the posts turned into harassment party because of the "hijacking" of pure open source according to them.
  - eitland 7y ago
    A little bit of nuance might help. I can like the idea of the BSL. I have no problems seing the justification for that. What certain people does, that makes me and others react is when they insist on their commons clause licensed applications or libraries being open source.
  - zerkten 7y ago
    The problem here is programmers having a fixation on licences as some sort of template that must be followed exactly without having any real experience with how the law actually works. This is convenient for something like an OSS license used extensively because you have some common reference. However, many contracts don't follow a template and it's normal in other contracts for items to be customized to any extent required. Template licenses are often used to intimidate people who aren't aware of their rights and what is possible. For example, employers may say that they can't modify an employment agreement because it's a standard template to make the potential employee feel like there is some legal rather than policy issue at play. Similar things happen in other places and you have to decide how much you want to fight policy, but parties almost always have the option of agreeing on custom terms. This is hard today in the OSS ecosystem, but it'll have to evolve to support additional terms.

danShumway 7y ago

> Open Source is pretty clear cut: it does not discriminate. If you get the source, you can do with it what you want (within the terms of the license) and no matter who you are (within the terms of the license). However as Open Source is defined — and also how I see it — Open Source comes with no strings attached. The moment we restrict what you can do with it — like not compete — it becomes something else. I appreciate this distinction. I don't have anything against a company updating its licenses to remain profitable, as long as they're up-front about what they're doing. My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit, or that the restrictions are just technicalities that everyone should ignore, or that Open Source is doomed and they're here to save everyone. Not everything needs to be Open Source, but Open Source should mean something.

jboynyc 7y ago
You might also be interested in this essay on "proprietary relicensing" from the Software Freedom Conservancy: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/ https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
- danShumway 7y ago
  I am! This was an interesting read, thanks. In particular, I fee like the comment on copyright assignment is an insightful way of explaining why these approaches to licensing often feel inconsistent with company claims to support 'Openness': > If an entity does not gladly bind itself by its own copyleft license (for example, by accepting third-party contributions to its codebases under that license), we should not treat that entity as a legitimate license steward, nor treat that license as a legitimate FOSS license.
anderspitman 7y ago
> My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit If a project is still usable in 99.9% of the ways most developers would care about (ie everything except AWS hosting their own paid version), are you saying you don't like it when projects communicate that fact by saying things like, "we're almost open source, except X"?

jamesbiv 7y ago

I had a very similar dilemma myself when putting together a project of mine a few months ago. However, at the end of the day, I felt that keeping the license of the solution (or core solution) as MIT was the best option irrespective, and my thoughts came from the following areas in which monetisation can be substantiated. - Labor costs for staff, which include developers, network administrators, and support officers. - Costs incurred for resources, server infrastructure, office resources and so fourth. - And of course marketing and sales of the solution. The key is to communicate this substation, therefore asking customers for donations, i feel, becomes irrelevant if you can do that effectively. So really the gist is "it's great that the software is free but someone has to run it and even more so someone has to keep supporting it". Ideally, my opinion on monetisating comes from the business model which encapsulates the solution, therefore licensing the end product can just be focused around the tangibles that inherently make up the business side of a SaaS company. I think the most murky part of this dilemma comes from professional services and enterprise grade solutions because this is where custom and closed treatment maybe needed for the client. Plus other issues come more from a security standpoint and trade secret standpoint than anywhere else. For instance customisation on top of a SaaS platform via APIs or integration work may require the asset (or code) to be closed source from the perspective to satisfy the clients' needs, but this has always been an issue and is not a SaaS centric problem as the argument only comes during the purchase cycle of a company and the IT manager asks the question "can our business trust open source?".

ahnick 7y ago

The model we are planning to use for the products at Plyint(https://plyint.com https://plyint.com) is basically the "Free Software Product" model in a SaaS format. How this will work is we will release the code with a proprietary license, but then if you want to use it in a product or pure open source fork, then you need to go to the trouble of removing the company name and product references. Once, that is done then the license will become an AGPL license that can be used as one would normally expect and any modifications to that code would need to be released again publicly. (This way any fork is required to contribute their code back to the public domain) I think this will introduce enough time delay that the SaaS service will establish itself. Plus, the product has to become popular enough for anyone to want to go through that level of effort. Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.

teddyh 7y ago
> any modifications to that code would need to be released again publicly. Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted by the GPL/AGPL, and if you don’t allow them, you are violating the GPL/AGPL license by adding this additional restriction. Of course, this might not be a problem, for two reasons: Firstly, you might be the sole copyright holder, in which case you don’t need a license (it is instead you who give licenses to others), and secondly, for a SaaS product, any public use by a third party will make the AGPL kick in and require, from the third party, a release of the modified source. > Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well. Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications (except when the AGPL requires it; i.e. when the software is available publicly). Also, you can’t then release this code under a proprietary license, which you say is your plan. Note: If you’re OK with the release of modifications which AGPL requires, then everything is fine. It’s only if you insist on the release of all private modifications that you could run into trouble.
- ahnick 7y ago

nif2ee 7y ago

>I remember too many cases of people that tried to do dual licensing with code and ended up regretting it after ownership was transferred or they had a fall out with other partners. Can somebody here elaborate on this?

deleted 7y ago

[deleted]

quaffapint 7y ago

For my upcoming saas I wanted to do something similar... -Paid hosted saas solution -Freely downloadable to use and install for your own projects ...I want people to be allowed to make money with it even if they freely download it, but I just don't want them to be able to compete with my hosted saas. I'm not quite sure that this is what the BSL is saying, so is there a license for something like that?

thebigshane 7y ago
I think that is what Armin was looking for as well, but couldn't find anything that quite did that so settled on the BSL instead (probably because determining what fork qualifies as competing or not seems hard). BSL seems close, but seems to disallow any commercial usage (IANAL!)?
progval 7y ago
This is mostly the goal of MongoDB's license, the Service-Side Public License: > A company that offers a publicly available MongoDB as a service must release the software it uses to offer such service under the terms of the SSPL, including the management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the source code made available. https://www.mongodb.com/licensing/server-side-public-license/faq#when-to-use https://www.mongodb.com/licensing/server-side-public-license...
candiddevmike 7y ago
I've looked into this in the past and couldn't find any non commercial licenses. Creative Commons has one, but it isn't suitable for software as it lacks a warranty clause. Curious if there is anything out there too.

soumyadeb 7y ago

We have been thinking about this a lot for our open-source Segment project (https://github.com/rudderlabs/rudder-server/ https://github.com/rudderlabs/rudder-server/). We launched things under mongo-SSPL (which is not a OSS approved license) but we now think AGPL is probably good enough for a product like ours. AGPL should kick in for anything (e.g. mobile app) that sends events to the our AGPL-backend so needs to be open-sourced too - that should be a strong enough deterrent for anyone to offer this as a service. Is this statement true? If yes, why did Mongo with with SSPL instead of AGPL? At the same time, we still want businesses who don't care about OSS to use Rudder without having to open-source their code. To address that we are thinking of releasing our binary (and AMI images etc) under MIT license. Sure, someone can spin up a SaaS service on the binary but that's hard. Any feedback on this would be highly appreciated.

matchy 7y ago
AGPL hasn’t really been tested in court so it’s not clear whether it would be enough to stop someone from running your software as a service.
- soumyadeb 7y ago
  Isn't that true for most OSS licenses (not being tested in court)?

danenania 7y ago

I don't believe we've been served well by defining the term "Open Source" to also necessarily mean "Free". This definition and the accompanying zealotry mainly serves big tech and the cloud providers. Everyone else would be better off if we as an industry also make room for software that is Open (in the sense that the code is freely available), but not Free (you must pay or obtain permission to run it yourself, re-distribute it, or run it for others). Open is almost universally good. Open means self-hosting, auditability, ability to patch/submit patches for problems yourself, and not being up shit creek if the provider folds. But Free? Free might not always be bad, but it has a lot of problems. Free = a race to the bottom. Free = ads. Free = selling user data. Free = no one cares enough to maintain it. Free = no one cares enough to promote it. Free = no one can afford to hire a UX designer. Free = ripped off by AWS. Free = bait and switch when the VC gets impatient. For all these reasons, you should demand access to the code, yes, but you should also be willing to pay the people who write the crucial software you rely on. It's far more sustainable and healthier for our industry.

soumyadeb 7y ago
Stallman keeps saying Free of OSS is "Freedom of Speech" not "Free Beer". However, the "Free Beer" part is also important - there won't be any startup if every software (open-code or not) required big license fees. Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today.
- danenania 7y ago
  "Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today." Yes, I agree wholeheartedly. My problem is with the many folks who automatically discount anything that is not "Free Beer". This attitude seems to be quite pervasive, unfortunately.
  - soumyadeb 7y ago
    Fair enough. Having a "OSS-compliant" license which supports "payment to run the sofrware" would help open-source startups like us but I guess "requiring payment" will hurt the "Freedom of Speech" part of OSS. An analogy would be - you have "Freedom of Speech" in a democracy but it requires a 100$ payment. Maybe?

nicpottier 7y ago

We are in a similar position and probably survive mostly through luck despite having vendors that sell our Open Source SaaS without contributing anything meaningful back. In our particular case I don't think the BSL would work for us, but I definitely understand and support Sentry going this route. FWIW, we have been using Sentry for almost a decade and while we started off hosting our own server we quickly saw the advantage in paying for it instead (and we were happy to do so). It's a tough thing to balance for sure, they have been one of the players we watch to see how Open Source SaaS can work and I wish them luck.

flurdy 7y ago

CockroachDB also changed to BSL[1] last summer. I think it is what a lot of my projects would aim to be. Free to use, tweak, contribute. Free to launch products using it. But not free to launch a service as SAAS or API that does more or less the same? * [1] https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...