I've thought a lot about this. I believe the future we want is:
1. Open Source.
2. Pricing for larger companies while staying for free for anyone else.
Many believe that trust mode [1] cannot work. But that's not true: Sublime Text's business model is entirely based on trust and they yield in the 7 figures.
Ideally, all Lsos projects would use trust mode only but, if larger companies don't play along, then we'll switch to enforce mode.
I'm not sure I get it. If the project that uses lsos is entirely open-source, then any company that decides they don't want to play nice can just remove the dependency on it, and use the project for free.
If it depends on the compliance of the user, why not just bake it into the license?
Yes you could fork an Lsos project and 1. remove the dependency from the source code, 2. re-build the distribution, 3. re-publish the distribution. You'd have to do this everytime you'd want to use a new release. It's trivial but it's still work and it isn't really worth it; the time spent on circumventing the Lsos library will cost you more than the 10$ / month.
There are easier ways to circumvent the Lsos library but we can prevent these.
Not every company out there is going to agressively wanting to circumvent the Lsos library to save a mere 10$ / month. Only very few actually. Large companies are interested in much higher figures than 10$ / month; it doesn't matter for them to spend a little on open source. They'd rather pay than going through the hassle to save pennies.
Besides the enforce-mode, the trust-mode would generate substantially more income than donations already.
Edit: about licensing: Keeping the MIT license is a strong statement that everything stays open source. It's important to clearly communicate that. Most devS don't understand how copyright works and creating a new license creates confusion about whether the code is still "open source".
You are correct that 10$ a month is not a lot. But many times the real "cost" is the effort it takes to get it through the company's administration department, no matter how cheap it is. For many programmers, writing a script that rebases using git and rebuilds the library (if it even needs compilation) would be much easier.
Hopefully they won't, due to principles, or the fear of getting caught by the public, but I can't help but wonder that maybe having the right license would be much more useful than having an easy-to-pick lock.
Even if we do a poor job with the enforce mode and achieve a rate of only 10%, the Lsos still increases your conversion rate by two orders of magnitude.
That said, we do take measures to strengthen enforce mode:
- Closed-source production build pipeline. The development pipeline is still open-source to allow contributions. If someone wants to fork your project, he'll need to recreate your build production pipeline which makes your project only 99% open source; it's not perfect but it can be a good trade-off.
- Fake anti-Lsos library. A way to cheat the Lsos is to write a script that removes the Lsos library code from your production build. We take measures against this practice (such as inlining the Lsos library, randomizing the structure of the inlined code, etc.) and we anonymously publish an anti-Lsos library that works enough to outperform competing anti-Lsos libraries, while making it not reliable and not trustworthy enough to discourage larger companies from using an anti-Lsos library.
- Add license clause to MIT-license. We actually did developed a license clause that enforces larger companies to pay while preserving open source values. In general, we prefer not using copyright law because many developers don't understand how copyright works and many are afraid of using unknown licensing. That said, for some projects it can make sense to use copyright law.
Does that make your more confident that the Lsos is a tangible alternative to merely hoping companies to donate?
This seems incoherent. Given the decentralized nature of Git and thus the diversity of different repositories a project will live in, what concrete feature of which repository is it keying off of to determine if the repository is public and/or has sufficiently light access to allow free use without an activation key?
6 comments
[ 2.6 ms ] story [ 26.4 ms ] threadI've thought a lot about this. I believe the future we want is:
1. Open Source.
2. Pricing for larger companies while staying for free for anyone else.
Many believe that trust mode [1] cannot work. But that's not true: Sublime Text's business model is entirely based on trust and they yield in the 7 figures.
Ideally, all Lsos projects would use trust mode only but, if larger companies don't play along, then we'll switch to enforce mode.
[1]: https://lsos.org/faq#trust-mode
If it depends on the compliance of the user, why not just bake it into the license?
There are easier ways to circumvent the Lsos library but we can prevent these.
Not every company out there is going to agressively wanting to circumvent the Lsos library to save a mere 10$ / month. Only very few actually. Large companies are interested in much higher figures than 10$ / month; it doesn't matter for them to spend a little on open source. They'd rather pay than going through the hassle to save pennies.
Besides the enforce-mode, the trust-mode would generate substantially more income than donations already.
Edit: about licensing: Keeping the MIT license is a strong statement that everything stays open source. It's important to clearly communicate that. Most devS don't understand how copyright works and creating a new license creates confusion about whether the code is still "open source".
Hopefully they won't, due to principles, or the fear of getting caught by the public, but I can't help but wonder that maybe having the right license would be much more useful than having an easy-to-pick lock.
- Donations: 0.1% (Open Collective / GitHub Sponsors)
- Trust mode: 1%
- Enforce mode: 10%-50%
Even if we do a poor job with the enforce mode and achieve a rate of only 10%, the Lsos still increases your conversion rate by two orders of magnitude.
That said, we do take measures to strengthen enforce mode:
- Closed-source production build pipeline. The development pipeline is still open-source to allow contributions. If someone wants to fork your project, he'll need to recreate your build production pipeline which makes your project only 99% open source; it's not perfect but it can be a good trade-off.
- Fake anti-Lsos library. A way to cheat the Lsos is to write a script that removes the Lsos library code from your production build. We take measures against this practice (such as inlining the Lsos library, randomizing the structure of the inlined code, etc.) and we anonymously publish an anti-Lsos library that works enough to outperform competing anti-Lsos libraries, while making it not reliable and not trustworthy enough to discourage larger companies from using an anti-Lsos library.
- Add license clause to MIT-license. We actually did developed a license clause that enforces larger companies to pay while preserving open source values. In general, we prefer not using copyright law because many developers don't understand how copyright works and many are afraid of using unknown licensing. That said, for some projects it can make sense to use copyright law.
Does that make your more confident that the Lsos is a tangible alternative to merely hoping companies to donate?
Thanks for your feedback, I updated our FAQ.