DEV Community

Discussion on: Introducing LibVLCSharp Commercial Licensing

Collapse
 
jayjeckel profile image
Jay Jeckel

I strongly disagree with this decision on principle, but more importantly as a user of the package I have to consider any change to less permissive licensing to be a red flag. When this happens, as it seems to be happening more and more lately, I have to ask:

If no companies were using your software in commercial products, would you instead be relicensing to charge a subscription from all of the individual developers?

If the answer is, yes, then us individual developers should start looking for alternatives now, in case you don't see enough profit from the business users and decide later to restrict the license even more.

If the answer is, no, then I have to question the claim of unsustainability. What extra work is being caused by these users due to them being for-profit and how can I be certain that the criteria wont be expanded in the future and require a broadening of the subscription base?

This is not to make any claims on your actual motivation, but the current project where we're using your package has been in development for almost two years and being a FOSS application suite we can't risk any dependency that could eat into the nearly non-existent budget.

What concerns me, personally, even more is things like, "priority bug fixes, feature requests and documentation improvements".

I wince every time I read it. Development of the software, especially the priority and fixing of bugs, should not be decided based on who gives you money. When you start making technical decisions based on who pays what, that is when for-profit starts slipping toward the dark side.

I'm sure there is no talking you out of this licensing decision, but this perk should be scrapped immediately. Improve documentation because it makes the software better; add features based on the needs of the software and the community as a whole; and for the love of all that is holy, fix all the bugs you can, no matter who reports them, and prioritize them based on how they affect the codebase, not how they affect the bottom line.

This perk does nothing but reward the corporate world, letting them come in, throw around money, and treat the open source community as yet another pool of cheap outsourcing. Instead of offering to directly increase your workload in exchange for pennies an hour, offer consultancy services for them implementing bug fixes and new features, with the obvious understanding that all those improvement could be ported upstream to the project. This would help you, it could improve the software, and it educates the corporations on how to be good contributing members of the community. It's a win for everyone.

Collapse
 
mfkl profile image
mfkl

Thank you for sharing your thoughts on this!

I have to consider any change to less permissive licensing to be a red flag

To be exact, this is not a license change, but license addition.

If no companies were using your software in commercial products, would you instead be relicensing to charge a subscription from all of the individual developers?

Probably not? I don't know. This is not very realistic.

If the answer is, yes, then us individual developers should start looking for alternatives now

People have to stop taking free things for granted. Someone, down the line, always pays the price.

If the answer is, no, then I have to question the claim of unsustainability. What extra work is being caused by these users due to them being for-profit and how can I be certain that the criteria wont be expanded in the future and require a broadening of the subscription base?

This isn't about business users causing more work. This is about asking (and not demanding) business users to contribute financially so that the project's long term viability is not in danger, and that casual hackers can keep enjoy using it (for free).

This is not to make any claims on your actual motivation, but the current project where we're using your package has been in development for almost two years and being a FOSS application suite we can't risk any dependency that could eat into the nearly non-existent budget.

You are free to keep doing as before. This license addition changes nothing for you.

Development of the software, especially the priority and fixing of bugs, should not be decided based on who gives you money.

Priority support is provided in good faith. There is no SLA and it is still subject to my limited time.

Improve documentation because it makes the software better; add features based on the needs of the software and the community as a whole; and for the love of all that is holy, fix all the bugs you can, no matter who reports them, and prioritize them based on how they affect the codebase, not how they affect the bottom line.

That wasn't gonna change.

offer consultancy services for them implementing bug fixes and new features, with the obvious understanding that all those improvement could be ported upstream to the project.

There is no 'upstream'. There is one repo and one branch, two licenses. Now, consultancy services have been advertised in the past of course, and there have been little to no takers. It's right there on the readme.

So I'm trying something new. If you have better alternatives, then by all means, I'm all ears :)