Live data from Hacker News

Open Source, SaaS and Monetization

lucumr.pocoo.org

51–60 of 71 posts

Re: Open Source, SaaS and Monetization

#51
post #22

Earlier quoted context omitted.

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

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

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.

Re: Open Source, SaaS and Monetization

#52

I work on a paid Chrome extension that tests if your website follows SEO, speed and security best practices: 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. re…

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

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

Re: Open Source, SaaS and Monetization

#53

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…

If you want this to change, then you should not use "free" when you mean "gratis" or "freeware". Free software explicitly only cares about freedom and encourages you to charge as much as you want/can: https://www.gnu.org/philosophy/selling.en.html

Re: Open Source, SaaS and Monetization

#54

Earlier quoted context omitted.

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

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

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

Re: Open Source, SaaS and Monetization

#55
post #34
post #15

Earlier quoted context omitted.

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

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

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

Re: Open Source, SaaS and Monetization

#56
post #15

Earlier quoted context omitted.

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

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?

Re: Open Source, SaaS and Monetization

#57

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

Re: Open Source, SaaS and Monetization

#58

Earlier quoted context omitted.

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

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

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

Re: Open Source, SaaS and Monetization

#59
post #55
post #34

Earlier quoted context omitted.

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

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

Re: Open Source, SaaS and Monetization

#60

Earlier quoted context omitted.

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

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

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

Post reply on HN