5 ms·
> For an open source user to convert to a paid customer, Wright said, one of three things has to happen: They are in production and there’s a major incident, th
by nirui 3y ago
> For an open source user to convert to a paid customer, Wright said, one of three things has to happen: They are in production and there’s a major incident, the person responsible for operating the software leaves, or there are changes to their enterprise platform requirements.
I have an idea ("question" really), but not sure if it's legally sound.
I'm working on a side project for quite awhile now. My original intent was to write a simple software and then release it under AGPL. But then I got greedy and it has grown to over 20,000 lines of Go code -- too big to just give it out for free IMO.
I still want to release the software under AGPL, but now I also want to compensate for my time and effort. So I renew the plan to the following:
- I'll still release the software under AGPL as originally planed
- I'll maintain full ownership to the software, and will not be accepting code from other people (or doing anything that complicates my rights of ownership)
- Based on the original code (open sourced under AGPL), I'll create another software which adds extra functionalities for users who might want to pay for it. And this software will be for sale and completely propriety, the "all rights reserved" type.
My reasoning is, since I'm still owning the software, legally I can do whatever to it, including "re-licensing" the same code to myself under a set of different conditions. The open sourced version under this context is there to provide a fallback (say, in case my users no longer trusts me) as well as a default that guarantees the minimum functionalities that my software will absolutely offer regardless if you're paying or not.
Although it's not strictly "selling open-source software" any more, it could be a balanced approach to the conversion problem, IF it can legally be done this way of course.
But then, can it be done through? Is there any legal and licensing trap that makes the scheme impossible? Thank you in advance.
- anilgulecha 3y ago> My reasoning is, since I'm still owning the software, legally I can do whatever to it, including "re-licensing" Only if every commit is by you, or has rights assigned to you (typically via CLA). If there's other authors, they continue to have AGPL rights on the repo - and can request your future changes to be provided to anyone the software is distributed to.
- lolinder 3y agoThat was their bullet point number 2: > I'll maintain full ownership to the software, and will not be accepting code from other people (or doing anything that complicates my rights of ownership)
- anilgulecha 3y agoAck, makes sense. I was pointing to the fact of this being a long existent project, which typically would mean external contributions already existing.
- lolinder 3y agoWhat you're describing is called "open core". It's a pretty common business model for open source companies, including GitLab and JetBrains. Usually this is done with a permissive license—GitLab is MIT, IntelliJ core is Apache 2—but iText PDF does something similar with AGPL. My understanding is that if you actually retain full ownership and accept no outside contributions, then you're not obligated to follow the terms of your own license. AGPL is just the terms on which you let other people use your code.
- gizmo 3y agoI understand you want to be compensated for your work, but the world doesn't reward engineering effort by itself. If you want to run a software business, do that. If you want to run an open source project, do that. But it makes no sense to go for some kind of hybrid commercial open core project simply because you've put a lot of effort in and you feel entitled to a monetary reward. Legally, it's fine. But your plan as described is highly unlikely to work. As others have pointed out, open core is harder than closed source, because you can only charge for the difference between the open source version and the commercial version, and that represents only a small amount of the total effort you've put in. On top of that, your main audience consists of people who really prefer not to pay for software.
- nirui 3y agoI do understand that, but currently my open source projects don't bring any monetary benefit at all, and my user base is too small to provide enough donation to support the development. So under this circumstance, any payment is way better than none payment. Plus, I also designed the system in such way that it allows me to vastly extend it's functionality based on the same base code. So in theory I could make a big enough feature-gap between the two. > On top of that, your main audience consists of people who really prefer not to pay for software. I thought about this as well. But doing a pure close sourced product is unlikely to cover these people too. Sure, making the product open source might convert some paying users away to use the open source version, but at least I earned the trust of these users (and hopefully made them happy), still not a bad out come from the open source perspective :)