Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider changing license type #112

Open
mekhanique opened this issue Apr 21, 2024 · 8 comments
Open

consider changing license type #112

mekhanique opened this issue Apr 21, 2024 · 8 comments
Labels
question Further information is requested

Comments

@mekhanique
Copy link

Hi, awesome tool. I'd love to use it at work for my development team, however, the AGPL license forces any system that connects to it to be open sourced. That forces proprietary business services, both internal and external, to be open sourced. As such it's not useable. Would you consider using a BSL license or similar, which prohibits anyone for making money by providing the software as a service while still enabling internal use cases for businesses. Thanks for your consideration.

@mkatanski
Copy link

Totally agree. Other option would be a paid license for businesses but we need something that is legal that way or another.

@daveshanley
Copy link
Member

I am happy to change the license to make it more accommodating for businesses. My goal is to prevent companies from reselling this tool as it's taken years of work to build out, and I have commercial interest with this tool in the long run.

Would a paid commercial license be an attractive alternative, in addition to a BSL license?

@daveshanley daveshanley added the question Further information is requested label Apr 25, 2024
@mekhanique
Copy link
Author

mekhanique commented Apr 25, 2024

BSL would allow you to prevent anyone from competing from an offering you provide in a software-as-a-service offering while enabling business internal use. I'll be honest, this one would be of great benefit to my organization (and myself as I get to bring the tool in for use, which is a feather in my cap). That said, it doesn't necessarily match what you might want to do here. Here is a BSL that is an example of what I suggest (at least as a base): https://www.hashicorp.com/bsl.

Paid commercial license would, of course, require the ability to accept payment (many times in the form of a PO as credit card charges are frowned upon and frequently block purchases), have some form support contract, and a proper EULA. That said, you'd likely need to add more functionality to make much of a run at it given the development tools market. Otherwise the fees should be low enough that the burden can pass muster as a purchase. Per seat licenses can be seen as costly. Annual service fee is most reasonable IMO, just make sure you map your pricing to the business value the project creates.

Should you want to take this further commercially I'd suggest connecting up with companies such as SonarQube, Sentry, and a few others in this space and see about inclusion in one of their product offerings. That could take many forms, the two that come to mind as examples are a commercial use license providing the project as a OEM, purchase of the software (and possibly an offer to join whichever company). The OEM license would likely need to be for exclusive use as no company wants to buy a feature that others could incorporate in their own projects. This would also require some form of support contract for fixes at a minimum should you head this way. You could also You develop add-ons/plug-ins that are commercial as well as support contracts that ensure fixes for paid customers are prioritized. SonarQube does this, using the GPL for community use and requiring a commercial license for their plugin and more advanced features as value adds. Make sure you get the advice of a lawyer when going towards any commercialization.

Ultimately, the choice really depends upon what you want out of the project. The nice thing is you can change the license when you change versions should you get this to a place where you're ready to pull the trigger on commercialization. As a last push for BSL, I'd point out that more use by businesses breeds exposure and feedback that can make the project better. That helps your longer term goal both in terms of quality and features desired. Lastly, by starting with BSL and getting the project out their in companies, you've created mind-share that could come in handy when you later change or add a commercial offering of any form.

@daveshanley
Copy link
Member

Thank you for your rich and detailed response. I am using a BSL license for another library, so I am happy with the boundaries of the license and how it affects use.

I'll bump the version of wiretap to 0.2 and change from AGPL to BSL, that way your business can use it internally (which is what its intended for) and I am free to persue commercial interests with the codebase. I don't intend to commercialize wiretap it's self, but it will be use in another commercial offering that composes all of my tools together.

If you're interested in learning more, check out https://pb33f.io/doctor/ for a preview of a small subset of the future functionality.

@mekhanique
Copy link
Author

You're welcome. Happy to help. I like where you're going w/ the new tool. I'll definitely keep an eye on it. Best of luck on your commercialization plans! And thank you for making the license change. It's much appreciated!

@mekhanique
Copy link
Author

Just curious when/if you plan to do this or not. Thanks!

@daveshanley
Copy link
Member

I am planning on it yes, nothing has changed.

I have just been super busy working on the next part of the pb33f story and not had a chance to swing back here and change the license

@daveshanley
Copy link
Member

I'll look into it over by next couple of weeks, I have some personal business to attend to that will delay things a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants