
Open Source, SaaS and Monetization - ____Sash---701_
https://lucumr.pocoo.org/2019/11/4/open-source-and-saas/
======
danenania
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
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
"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
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?

~~~
danenania
I'd say the expectation that all software should be free is more similar to
expecting all books to be free, and self-righteously declaring that you will
only read free books, because any author who tries to make money by writing
books is clearly a sell-out who can't be trusted.

Closed source is like saying you aren't allowed to skim the book at the store
before buying or share your favorite passages with a friend. That does
infringe free speech. An author selling a book does not.

But just as with written media, there's plenty of room for both paid and free
options that are both Open in the sense that the code is available. In a
healthy ecosystem we'd have a lot of both, and no widespread bias against paid
options. If anything businesses should have the opposite bias.

~~~
belorn
Depending on what you compare it to you get different answers.

We don't have patents or copyright for math. It is not that we want
mathematicians to not get paid, or that we don't value math, or that there is
no room for both paid and free math. It is that math is such a fundamental
building stone that allowing rent seeking in that space would cause
significant harm to society, including the advancement of science.

Some software is like a book. You buy it and consume it. You don't buy a book
and build a better book. You do have the problem with schools in that children
would be harmed if they had to pay for it, so we have libraries and school
that buy the books for them so they become "free" for the children. Some
nations, like Sweden, also have laws that demands that book publishers send
books to libraries and the money the copyright owner is set by the state.

If we treat software as math then it should be free. If we treat software as
books it should be semi-free for those that needs it and can't afford it.

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

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

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

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

Personally speaking, open sourcing something with no intention of responding
to interested developers doesn't feel right.

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

When you open source though, aren't you making it significantly easier for
people to build a product better than yours?

If it's a paid product that works without hosting, what's to stop someone just
selling it cheaper or releasing it for free?

~~~
capableweb
> Personally speaking, open sourcing something with no intention of responding
> to interested developers doesn't feel right.

Everyone is different :)

> When you open source though, aren't you making it significantly easier for
> people to build a product better than yours?

If the only benefit from you and a competitor is a particular feature or
something else that you gain from proprietary code, you're gonna lose
eventually anyway. You need something stronger if you are to survive. There
needs to be something more between you and your competitors than something
that can be easily copied (like most features in most products).

Some companies focuses on integrations/synergy (like Apple, easier the more
stuff from them you have) while others on other things.

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

------
ensignavenger
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...](https://blog.sentry.io/2019/02/14/sentry-thrives-open-source-
software-company), [https://blog.sentry.io/2016/10/24/building-an-open-source-
se...](https://blog.sentry.io/2016/10/24/building-an-open-source-service),
[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
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)

~~~
ensignavenger
As I said, Sentry doesn't owe new open source code to anyone. Deciding to make
new releases closed is acceptable.

However, they have repeatedly made statements that they are committed to open
source- some only months before this announcement. The 11 year old decision
argument doesn't hold true.

They have a right to change their mind. But they shouldn't be lying to their
customers and the community now that their mind has changed-
[https://sentry.io/_/open-source/](https://sentry.io/_/open-source/) They
continue to advertise that they are open source on their marketing website.
That is a lie, and it marks Sentry as an unethical, dishonest company.

The wider debate on licensing terms and business models can move forward- it
has existed since the beginning of the software industry and likely will
persist for the foreseeable future. I prefer open source licenses. I think
they are the best proposal for software licensing and distribution so far. If
Sentry wants to do something different and use the BSL license, that is fine-
but they shouldn't lie and claim to be open source.

~~~
japhyr
What label would you like them to use? What is the accepted name for a middle
ground license now? Should they be advertising themselves as a "business
source" company rather than an "open source" company?

I don't ask this antagonistically, it's an honest question. I don't think
they've shifted so much that they're just a standard company trying to make
money off of proprietary software at this point.

"You can host your own service, or you can pay us to host the service, but you
can't host the service and charge others for our service" is a business model
I'd like to see continue.

~~~
TAForObvReasons
There's a term for "proprietary projects whose source is available on GitHub",
namely "source available". "Open Source" != "source available", and attempts
to describe one as the other are clearly attempts to deceive

~~~
nicpottier
As I recall "Source Available" is a lot worse than what Sentry is proposing.
It usually required signing an NDA or jumping through some other hoop in order
to get the source. This is much better than that so I don't think it would be
properly descriptive.

------
jamesbiv
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
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
> _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
> Technically, that is incompatible with the AGPL (and the GPL, for that
> matter). Private modifications without distribution are permitted, and if
> you don’t allow them, you are violating the license.

Sorry, I should have been more clear. I meant you make a modification AND
offer a competing SaaS service. At that point under the AGPL that is
considered distribution and would need to be open sourced.

> 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. Also, you can’t then release this code under a
> proprietary license, like you describe.

Yes, so I was thinking about this as well. Basically what I'd like is an AGPL
with a CLA that allows us to incorporate it back into the original service. I
guess what would need to happen is specify in the original licensing of the
product that the proprietary license converts to AGPL + CLA to Plyint.

~~~
teddyh
> _an AGPL with a CLA_

You can’t require a CLA with AGPL. That would be an additional restriction,
which AGPL does not allow. You can require a CLA for contributions to be
accepted into your own distibution of the software (since you are not required
to accept patches), but you can’t require anyone to sign or agree to a CLA if
they recieved the software under AGPL.

It wouldn’t be fair either, I think, for you to sell the contributions of
third parties as part of your software under a proprietary license. You can’t
have your cake and eat it too; either you develop stuff yourself and get to
sell it under whatever license you like, or you accept contributions from
third parties all over the world under a free license, and you then sell the
software to your customers under the AGPL, not a proprietary license.

You might be concerned about your customers then redistributing the AGPL
software you sold them, but firstly, you might be able to fix this by
requiring your customers to sign a contract with you (as part of the sale),
where they agree not to do that, allowing you to sue them for breach of
contract if they do. (I am not sure about the legal status of this scheme,
however, and IIRC, the text of the GPL seems to want to at least discourage
it.) Secondly, Red Hat allows CentOS to exist, and RH still makes a pretty
penny selling RHE licenses. So this might not be a problem in practice.

EDIT: See also this post, linked by jboynyc elswhere in this discussion:

[https://sfconservancy.org/blog/2020/jan/06/copyleft-
equality...](https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/)

~~~
ahnick
> You can’t require a CLA with AGPL. That would be an additional restriction,
> which AGPL does not allow. You can require a CLA for contributions to be
> accepted into your own distibution of the software (since you are not
> required to accept patches), but you can’t require anyone to sign or agree
> to a CLA if they recieved the software under AGPL.

So, the term CLA might be too strong here. What I'm really wanting to do is
add an additional term that allows for "any modification of the source code
that is contributed back to an open source fork to then be reapplied to the
proprietary product." This I don't believe qualifies as a "further
restriction", because I'm just granting an additional right to the company to
reincorporate the code into the original product and I'm not restricting the
rights of the downstream user in anyway. (i.e. they can continue to offer a
competing product and use it however they would like)

Section 7 of the AGPL say this at the end...

"Additional terms, permissive or non-permissive, may be stated in the form of
a separately written license, or stated as exceptions; the above requirements
apply either way.

To me what I'm asking for is a "permissive" additional term that qualifies
under this section. Do you disagree?

From a principle perspective, I think as long as developers know up front
(based on the licensing) that when they contribute code to and open source
project that the code could be incorporated back into the original product,
then they would be okay with that.

As I'm writing this, I had the thought that perhaps a simpler approach is
simply to just open source it as AGPL from the beginning with the additional
restriction to remove the Plyint trademarks from the code. That is fairly
clearly spelled out in section 7 as a valid additional term.

~~~
teddyh
> _allows for "any modification of the source code that is contributed back to
> an open source fork to then be reapplied to the proprietary product."_

That’s not an additional permission. That is granting _yourself_ a right; i.e.
a _requirement_ imposed (on the legal author of the contribution) to give
_you_ this permission.

> _Do you disagree?_

Yes, I disagree. The author of a patch owns the copyright on that patch. You
can’t reasonably believe that requiring this author to give _you_ permission
to do something constitutes an “additional permission” which you are giving to
that author. It is obviously a restriction imposed on that author, since they
would not otherwise be required to give you this permission.

A “permission” can only be something which you grant someone which 1. You are
in a position to grant and 2. They would otherwise be not permitted to do. In
the case of a software license like the AGPL, you the copyright holder have
the sole right to copy the software. The license you give to others to copy
the software under certain conditions is a thing which they would not
otherwise be permitted to do under copyright law. Therefore, this “permission”
that you want to give yourself, regarding copying the code authored by other
people, does not qualify as such, since you are not in a position to give this
permission, since you do not hold the copyright to the patch.

> _From a principle perspective, I think as long as developers know up front
> (based on the licensing) that when they contribute code to and open source
> project that the code could be incorporated back into the original product,
> then they would be okay with that._

Maybe, but you’d have to find some legal way to accomplish this.

> _As I 'm writing this, I had the thought that perhaps a simpler approach is
> simply to just open source it as AGPL from the beginning with the additional
> restriction to remove the Plyint trademarks from the code. That is fairly
> clearly spelled out in section 7 as a valid additional term._

Oh, I agree completely. This would probably be the best for all involved.

~~~
ahnick
Thanks for the cogent explanation. That actually makes a lot of sense to me.

> A “permission” can only be something which you grant someone which 1. You
> are in a position to grant and 2. They would otherwise be not permitted to
> do.

Did you pull this from somewhere? I would like to read more, if so.

~~~
teddyh
> _Thanks for the cogent explanation. That actually makes a lot of sense to
> me._

Thank you! A lot of this licensing stuff actually does make sense if you just
look at it the right way.

> _Did you pull this from somewhere? I would like to read more, if so._

Sorry, no. Just from many years of arguing about licensing on the net. For
further reading, I would suggest this:

[https://www.gnu.org/licenses/gpl-faq.html](https://www.gnu.org/licenses/gpl-
faq.html)

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

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

------
nif2ee
>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?

------
soumyadeb
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
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
Isn't that true for most OSS licenses (not being tested in court)?

------
flurdy
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-cockroach...](https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/)

------
quaffapint
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?

~~~
progval
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...](https://www.mongodb.com/licensing/server-side-public-
license/faq#when-to-use)

