|
|
|
|
|
by aragilar
1043 days ago
|
|
What would you change then? Practically only the 4th criteria would be one I'd change (but presumably it's there for a reason):
"Integrity of the author's source code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software." As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point. |
|
But this second part of the argument I just don't grok at all. These licenses like BSL provide significantly more of what I want in software I use than proprietary software does. (Namely, the ability to read, modify, and self-host the software of I choose to.)
I think what must be going on is that when you see a license like this you think "there is no point to something like that besides a PR stunt trying to imply proprietary software is open source", and I think "oh this seems like a really useful compromise that allows commercial enterprises to create software with code that I can read, modify, run myself, and contribute to if I want to, without a different company that did none of the work on the software making all the money from it". Just totally different perspectives.