is a BSL licensed service acceptable for sysadminy use cases?

[Harald Sitter]

On Wed, May 26, 2021 at 11:52 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> El dimecres, 26 de maig de 2021, a les 16:07:14 (CEST), Harald Sitter va escriure:
> > Ahoy ahoy
> >
> > I do on occasion write behind the scenes micro services for various
> > things we need in KDE and usually more specifically neon. It's always
> > been a big lament of mine that we don't really have a good way to
> > record errors from these services. Gitlab meanwhile has builtin
> > support for a piece of software that would allow us to do this: sentry
> > [1]. The trouble is that sentry is only kind-of open source [2] and
> > consequently there is some concern if we really should use it, even
> > though the use case is pretty much exclusively for sysadmin internal
> > affairs rather than a service we render to the outside or the wider
> > KDE community even. Bhushan and I also looked at similar software but
> > found nothing nearly as hot, and of the serviceable stuff I believe
> > the best option also had ultimately relied on only kind-of open source
> > software (mongodb IIRC).
> >
> > What's your thoughts on the subject? Can sysadmins use not-quite-free
> > software for internal stuff?
>
> Is this about us writing BSL software or us using BSL software? I think using, but want to be sure.

Yes, just using it.

> What's the use case of the software?

e.g. geoip.kde.org encounters an error, instead of abort() it catches
the error and sends a data blob of metadata of the error to sentry
from where gitlab excavates it. I see the error and might decide to do
something about it.

> How locked in are we into it?

Not at all, worst case we can simply live without this particular
software. Or use something else, but so far the stuff Bhushan and I
tried wasn't terribly convincing.

> > c) I do feel for the developers need to turn a profit so most software
> > freedom is better than no freedom in my book
>
> This is a bit of a slippery slope, and makes me a bit sad with it since it agrees with the "you can't make money with Free Software" argument.

I appreciate your point but I would like to hope that my thoughts are
a bit more nuanced than that ;) albeit not really what I would like to
focus on here. If there's interest we can certainly discuss the pros
and cons of the many saas freedom models in general in a thread,
because, personally, I am also not sure our stance vis a vis gitlab's
model is particularly advantageous either. I do feel that is the sort
of topic that is best discussed over a beverage at akademy though.

Never the less here's a gist on this particular case: since what they
offer is saas, I struggle to see options how to monetize their project
outside "hosting" and support. The former of those options would be
undermined if a competitor were to run the same product with different
branding at half the price. So I guess perhaps your literal "you can't
make money with Free Software" is indeed the bottom line here. You
can't with the software itself through sales, at least it can be
exceptionally difficult. Sans goodwill and donations maybe, but if
employee's livelihoods depend on making money I'd not exactly stake my
business on monthly goodwill. You can make money surrounding the
software through: consulting, support, commercial licensing,
additional products built on top, selling ad space, selling out data.
Most of these avenues of income aren't available here because of the
nature of the product and the potential customers.
With all that in mind I find it entirely reasonable to have a license
that says that you can't start a competing commercial offer with the
saas product code, unless that code is at least 4 years old and thus
has been made entirely free (this eventual freedom clause is of course
something we have in our corner of the free software world as well
;)). 4 years is a bit on the long side but in the end it doesn't
prevent competition it just means that if you want to innovate a
product from the code base you'll have to start at a 4 year
disadvantage.

There now I've gone off on a ramble. Why I feel their case makes sense
isn't really important anyway here... unless someone needs swaying in
which case I can do some more musings on request :)

To clarify the terms perhaps the literal license is "don't make a
competing commercial offering with this code + this code automatically
becomes apache licensed in 4 years". A just license to my mind. But
also most definitely not a free license until the code is 4 years old.

HS