Live data from Hacker News

Open Source, SaaS and Monetization

lucumr.pocoo.org

61–70 of 71 posts

Re: Open Source, SaaS and Monetization

#61
post #56

Earlier quoted context omitted.

Instead of CLA you may consider on requiring the contributions to be dual licensed MIT + AGPL. MIT allows you to use the code in your SAAS version. Your code, the constributions and the entire repo can be kept AGPL only (because MIT doesn't impose a condition on you to release the entire code as MIT).

If someone contributes back to the repo is that contribution governed by both the MIT and AGPL licenses in a dual license scenario?

Not necessarily, but that is always true, even for, e.g., GPL-only projects. I.e. a GPL-only project might recieve a patch, but if the patched code does not contain a license covering that patch, the project does not have a licence to the patch and cannot use it. The usual way this is fixed is by having clear descriptions in your developer’s documentation on how to contribute patches and what licenses must be given to recipients in order for you, the software maintainers, to accept the patch into the project.

See further this post:

https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

Re: Open Source, SaaS and Monetization

#62
post #59
post #55

Earlier quoted context omitted.

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

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

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.

Re: Open Source, SaaS and Monetization

#63

Earlier quoted context omitted.

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…

I think you are wording that a bit strongly. They are still sharing the source just saying you can't load it up on a server and start selling that service. (you can load it internally for your own use though) Yes, Open Source has had a very specific meaning historically and maybe we need a new term but this still feels like they are following the spirit to me.

Part of the "spirit" of open source is the freedom to use the software- including to use it to sell a service. This protects the freedom to fork the software, and pay for support or charge others for the support I provide for my forked version.

Re: Open Source, SaaS and Monetization

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

Re: Open Source, SaaS and Monetization

#65

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-di…

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.

I have trouble with startups leaching off "free as in beer" code. The least they could do is pay an open source license with the same level of equity they pay to their employees.

Startups pop up to make money they shouldn't shy away from disruption just because there head start on product launch might cost some money.

Re: Open Source, SaaS and Monetization

#66

Earlier quoted context omitted.

> I don't believe we've been served well by defining the term "Open Source" to also necessarily mean "Free". I don't think we've done that. On the contrary, Stallman and many other free software advocates specifically distinguish between open source software and free software. To add to the confusion, I think you're talking about free as in beer (gratis) rather than free as in freedom (libre). The latter is what most…

While this may be technically true, in practice these two types of "freedom" are almost always conflated. Anyone who posts something that is "libre" but not "gratis" will be met with lots of "why isn't it FOSS?" and "here's a FOSS alternative" comments. This is the (imo) self-defeating attitude I'm referring to.

Well, if something is libre it's hard for it not to also be gratis, because someone can just take your code and run it elsewhere. So there's understandable skepticism when something is libre but not gratis, because the suspicion is that the creator will retract the libre-ness of their code.

I see the trend you're talking about, but I also see an inverse trend: people think that if software isn't funded it won't happen. Particularly on Hacker News: there's a segment of Hacker News who either can't comprehend or refuse to acknowledge that there might exist motivations besides money. I'm not accusing you of this, at least not to that extreme, but I'm saying that some people have that attitude, and it's certainly informing what you're saying to some extent.

My perspective as someone who has written some open source software, is that I did it for fun, to solve my own problems, or out of some idealistic drive to push humanity forward. Money was a foregone conclusion, but I wrote the software anyway. I might feel differently if I had written anything significant enough that it had a wide user base of profitable companies, but it's my impression that people don't write software and make it free because they want money.

I'm not saying we shouldn't support our free software contributors. We should, it's a nice thing to do. All I'm saying is that fear about the incentive structure of open source software isn't really warranted. Free (libre) and free (gratis) software will continue to be built regardless of whether they are ever funded, by people who are well-aware that they may never receive any money for it.

Re: Open Source, SaaS and Monetization

#67

> 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 appreci…

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

A better way of stating that would be, "we're Source Available with permissive licenses." Aesprite handles this particularly well; it's very up-front with what its license allows.

I don't inherently have a problem with people saying, "we're almost X, but not quite." However, I disagree that licenses like SSPL are "almost" Open Source, and I disagree that paid hosting is a particularly minor restriction.

To again quote Sentry's post:

> The moment we restrict what you can do with it — like not compete — it becomes something else.

Blocking companies from offering paid hosting has implications, not just on an ideological level but also on a purely practical level. Part of the reason I trust technologies like Matrix or Postgresql is because I'm hopeful that their hosting will be somewhat commoditized. I know that when hosts compete there, they're competing purely on hosting quality, not on software licenses.

If the official hosting services go sour for a truly Open Source project I have the option of self hosting -- but I also know that other companies will likely step up and provide alternative hosting solutions as well. When you restrict the ability to compete with your service, you make that less likely. So Open Source isn't just about the code I can run on my computer, it's also about my ability to delegate to other people. If you restrict my right to delegate hosting to an open market, that's not an insignificant restriction.

And again, not everything has to be Open Source. I use proprietary SaaS services, I even use open-core services like Gitlab. But I recognize that products like Gitlab's enterprise offering comes with substantial limitations.

Re: Open Source, SaaS and Monetization

#68
post #62
post #59

Earlier quoted context omitted.

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

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.

> 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

Re: Open Source, SaaS and Monetization

#69

Earlier quoted context omitted.

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

A better way of stating that would be, "we're Source Available with permissive licenses." Aesprite handles this particularly well; it's very up-front with what its license allows. I don't inherently have a problem with people saying, "we're almost X, but not quite." However, I disagree that licenses like SSPL are "almost" Open Source, and I disagree that paid hosting is a particularly minor restriction. To again quot…

> I disagree that licenses like SSPL are "almost" Open Source

Again, my definition of "almost" is what 99.9% of developers are actually likely to use it for. Most aren't interested in starting a competitor.

> Blocking companies from offering paid hosting has implications, not just on an ideological level but also on a purely practical level. Part of the reason I trust technologies like Matrix or Postgresql is because I'm hopeful that their hosting will be somewhat commoditized. I know that when hosts compete there, they're competing purely on hosting quality, not on software licenses.

There's nothing stopping companies from competing; they just can't use your code/binaries directly. They're free to implement your protocols themselves, which is very commonly done when people implement OSS implementations of Google or AWS APIs. Matrix isn't code; it's a protocol. If they had released their reference server as commons clause, you would be at exactly the same level of vendor lock-in you are now, because there are already multiple independent OSS server implementations.

> I also know that other companies will likely step up and provide alternative hosting solutions as well. When you restrict the ability to compete with your service, you make that less likely

Can you name a single example of this happening? From what I've seen, even moderately successful services (like Parse) simply die (aka self-hosting only). On the flipside, we have examples like AWS offering best-in-class hosted MongoDB that the mongo guys could never compete with, no matter how hard they try.

Sorry if my response seems combative. I'm mostly trying to improve my own understanding of what I see as a tricky problem. I've released a couple services lately that I would love to open source in some fashion, but there don't seem to be any great solutions.

Re: Open Source, SaaS and Monetization

#70

Earlier quoted context omitted.

A better way of stating that would be, "we're Source Available with permissive licenses." Aesprite handles this particularly well; it's very up-front with what its license allows. I don't inherently have a problem with people saying, "we're almost X, but not quite." However, I disagree that licenses like SSPL are "almost" Open Source, and I disagree that paid hosting is a particularly minor restriction. To again quot…

> I disagree that licenses like SSPL are "almost" Open Source Again, my definition of "almost" is what 99.9% of developers are actually likely to use it for. Most aren't interested in starting a competitor. > Blocking companies from offering paid hosting has implications, not just on an ideological level but also on a purely practical level. Part of the reason I trust technologies like Matrix or Postgresql is because…

No worries, I don't take it as combative. To be clear, I'm not trying to shame anyone who decides that they can't Open Source something they make. There are positives and negatives to these approaches. I'm also not trying to say that there aren't reasonably ethical, proprietary, Source Available licenses out there.

I still use Aseprite, in part because its license terms are very good, even for a Source Available application. In the art world, some of the Creative Commons licenses are far more restrictive than any Open Source code license could ever be. I don't think the Creative Commons licenses are unethical.

That out of the way:

> Can you name a single example of this happening?

Your own example is quite good.

> we have examples like AWS offering best-in-class hosted MongoDB that the mongo guys could never compete with, no matter how hard they try.

There are two ways of looking at this. One of them is that by outcompeting Mongo, AWS is making it harder to maintain the core software. That's a negative. However, it doesn't mean that the alternative wouldn't also have drawbacks.

The other way of looking at it is that in a world where AWS couldn't Freely build hosting services on top of Mongo, we would be losing out on a best-in-class Mongo hosting solution that the Mongo maintainers could never provide at the same level of quality and reliability. The entire Mongo ecosystem would be worse, because (frankly) the Mongo team is not as good at SaaS as Amazon is.

Sure, Amazon could license the software under separate terms. They can license Oracle Database too. But in both cases, the core license isn't Free (Libre). We're now in a situation where companies are competing on contracts, not just on on hosting, and we're now in a situation where the Mongo maintainers can leverage prices or exclusivity to change how the market looks.

Jumping back the the example of Matrix: yes, Matrix is a protocol. But it's also an Open server implementation (Synapse) that anyone can host for commercial purposes. Having Open server implementations means that what hosts are competing on isn't "who can implement the protocol best", or "who can secure the best licensing agreement". It's just "who can provide good hosting and customer service". The organization behind Matrix does provide their own Synapse hosting, but their explicit goal is that eventually their service will be outcompeted and die.

I would contend that supporting that kind of ecosystem matters for a heck of a lot more than 0.1% of developers. 99.9% of developers are not hosting their own Mongo instance. They're taking advantage of the market. Unless you're planning on rolling your own cloud for every SaaS product you ever launch, the market matters. Every developer who uses a 3rd-party cloud to host their stuff (ie most of them) benefits from companies like Amazon being able to freely offer hosting.

This might sound like a technicality, but it's the same reason why a lot of other things matter in Open Source. I have never read the Linux kernel source code, but the fact that other people have makes me trust it more. I've never compiled a custom kernel, but the fact that other people have means I can get custom kernels for obscure hardware. I have never started a commercial Postgresql hosting service, but the fact that other people have gives me confidence that I will always be able to find a quality Postgresql service when I need hosting for my own projects.

Of course, that Open market has downsides in that there are fewer people funding the software. But those are the same downsides we see in many other core attributes of Open Source. Being able to freely compile and distribute programs has the obvious downside that in practical terms, it is very hard to sell your stuff, regardless of what Richard Stallman would claim.

My goal is not to demonize people who say, "giving up an Open competitive market is a fair tradeoff for supporting core software." My goal is not to demonize people who say, "if I release my game/tool/library as Free (Libre), I won't be able to support myself." I think those are reasonable concerns.

But at the same time, I would challenge you -- if Amazon's ability to host Mongo doesn't matter to 99.9% of developers, why is Amazon making so much money from this? Why are developers choosing AWS over Mongo's SaaS offerings? I would argue that the answer is that AWS is genuinely providing a tangible value to a huge number of programmers, and that those programmers really do care about being able to access 3rd-party hosts offering that kind of value.

Post reply on HN