3 ms·

part of this issue is that it's difficult for maintainers to capture value for their work even when they're successful i've written a "paid use" license that a

by nqzero 8y ago

part of this issue is that it's difficult for maintainers to capture value for their work even when they're successful i've written a "paid use" license that attempts to capture many of the freedoms of FOSS while allowing a revenue stream if a package is successful. would love any feedback https://github.com/db4j/pupl https://github.com/db4j/pupl

syrrim 8y ago
The problem is that people want open source software to be like their own software. That is, it is written like they would have written it, and in such a way that they can go through the source code and understand it and modify it, but without them having written it themself. Necessary for this, I think, is that the software is legally indistinguishable from software they wrote themself. Many people license their code under a "public domain license". What's interesting is that such a license has no requirements of placing a copyright notice anywhere, and allows someone to freely relicense without modification. This is precisely as it would be if you had written the software yourself. Your license recognizes the value of freeware as a marketing tool - the more people with their hands on the software, the more likely some of them will stand up and pay for it. But I think the personal ownership aspect is more foundational. In advancing that, the license I would write would be one that places the software under a free license after some fixed date. You might state, for software released in 2019, that starting in 2024 it will be licensed under the GNU GPL. Until then, it would be licensed under some proprietary license, perhaps the one you propose. This forces people who use the software to pay for it's development, under whichever terms the proprietary license requires. Simultaneously, it ensures that those paying for it ultimately own the software, and therefore any improvements they make to it.
- nqzero 8y ago
  mariadb's Business Source License (https://mariadb.com/bsl11 https://mariadb.com/bsl11) is consistent with what you describe, though without any assurances during the proprietary phase possible that combining the two as you suggest would be the best of both worlds. i need to think about the business implications for the author

by nqzero 8y ago

syrrim 8y ago

The problem is that people want open source software to be like their own software. That is, it is written like they would have written it, and in such a way that they can go through the source code and understand it and modify it, but without them having written it themself. Necessary for this, I think, is that the software is legally indistinguishable from software they wrote themself. Many people license their code under a "public domain license". What's interesting is that such a license has no requirements of placing a copyright notice anywhere, and allows someone to freely relicense without modification. This is precisely as it would be if you had written the software yourself. Your license recognizes the value of freeware as a marketing tool - the more people with their hands on the software, the more likely some of them will stand up and pay for it. But I think the personal ownership aspect is more foundational. In advancing that, the license I would write would be one that places the software under a free license after some fixed date. You might state, for software released in 2019, that starting in 2024 it will be licensed under the GNU GPL. Until then, it would be licensed under some proprietary license, perhaps the one you propose. This forces people who use the software to pay for it's development, under whichever terms the proprietary license requires. Simultaneously, it ensures that those paying for it ultimately own the software, and therefore any improvements they make to it.

nqzero 8y ago
mariadb's Business Source License (https://mariadb.com/bsl11 https://mariadb.com/bsl11) is consistent with what you describe, though without any assurances during the proprietary phase possible that combining the two as you suggest would be the best of both worlds. i need to think about the business implications for the author