>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?
Open Source, SaaS and Monetization
11–20 of 71 posts
Re: Open Source, SaaS and Monetization
#12[deleted]
Re: Open Source, SaaS and Monetization
#13The model we are planning to use for the products at Plyint( 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…
> 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.
Re: Open Source, SaaS and Monetization
#14For 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?
Re: Open Source, SaaS and Monetization
#15The model we are planning to use for the products at Plyint( 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…
> 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 s…
> 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.
Re: Open Source, SaaS and Monetization
#16Earlier quoted context omitted.
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".
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.
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.
Re: Open Source, SaaS and Monetization
#17Earlier quoted context omitted.
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".
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.
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.
Re: Open Source, SaaS and Monetization
#18I 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 the…
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.
Re: Open Source, SaaS and Monetization
#19For 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?
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.
Re: Open Source, SaaS and Monetization
#20I 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 the…
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 i…
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/ 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.