3 ms·

Open Source is what allows developers to make their choices without having to ask for permissions. You can apt/pip/npm etc install and integrate pieces written

Open Source is what allows developers to make their choices without having to ask for permissions. You can apt/pip/npm etc install and integrate pieces written by others in your own solution stack without having to call a lawyer. These non-open source licenses force you to stop and think, ask your lawyer before you build on top of them. What's the advantage of these "semi" almost but not all the way open licenses?

reedciccio 3y ago
I mentioned apt, pip etc because Sentry, Elastic and everything is built by integrating hundreds of packages. Nobody builds 100% of the code they ship to users and customers. These non-open source licenses make things like pip impossible to exist. This is why people and organizations familiar with Open Source react so vehemently against them. Re: GPL, the license is 30 years old, it (used to be) well understood and has an extensive FAQ. It has 2 main flaws: it's unappealing to SilVal VCs and ostracized by big tech. And it's promoted with one single-minded organization. Both things made it unpopular in the past 10 years and it became suddenly obscure. Re: shareware/shared source code owned by a single corporation. History shows that the possibility to fix bugs locally is only a theory. None of the projects using that license scheme still does or exists. Think Eucalyptus, read their conflict with NASA and how that led to OpenStack. At best, you will have to maintain your fork. The proper place to find ways leading to a sustainable business is not creating new licenses but iteration on business practices.
arp242 3y ago
These things aren't in apt (other than non-free repos), so that's not really a problem. I'm not sure about the pip and npm policy on these types of things, but Sentry isn't a library you would add, so it's not really a problem. But it's fine to keep Sentry out of pip as far as I'm concerned. > You can apt/pip/npm etc install and integrate pieces written by others in your own solution stack without having to call a lawyer. These non-open source licenses force you to stop and think, ask your lawyer before you build on top of them. Try doing that with AGPL, or even just the GPL, or CDDL, or any number of licenses. There's tons of OSD/Four Freedoms compliant licenses that come with conditions; you really do need to look at them and can't "just" do whatever and already need to think about it. And personally I really have trouble especially with the GPL licenses; try reading them and determining what exactly they mandate in various edge cases. We have tons of people clarifying all this (which may or may not be applicable to your situation/jurisdiction), but going on just the license is often very non-obvious. > What's the advantage of these "semi" almost but not all the way open licenses? I can fix bugs for starters. From a purely pragmatic point of view this kind of "I can fix my own problems" is >95% of the value for me. I can easily self-host (including some hacked-up version which addresses some specific needs). I can see what the code does if something is unclear. There's tons of advantages. The only limitation is "don't compete with us". There's probably a few edge-cases, but practically speaking almost everyone is unaffected and they can treat Sentry as "just MIT" (or Apache) for almost all practical intents and purposes. People talk as if there are all sorts of caveats and booby traps here, but there aren't.

reedciccio 3y ago

I mentioned apt, pip etc because Sentry, Elastic and everything is built by integrating hundreds of packages. Nobody builds 100% of the code they ship to users and customers. These non-open source licenses make things like pip impossible to exist. This is why people and organizations familiar with Open Source react so vehemently against them. Re: GPL, the license is 30 years old, it (used to be) well understood and has an extensive FAQ. It has 2 main flaws: it's unappealing to SilVal VCs and ostracized by big tech. And it's promoted with one single-minded organization. Both things made it unpopular in the past 10 years and it became suddenly obscure. Re: shareware/shared source code owned by a single corporation. History shows that the possibility to fix bugs locally is only a theory. None of the projects using that license scheme still does or exists. Think Eucalyptus, read their conflict with NASA and how that led to OpenStack. At best, you will have to maintain your fork. The proper place to find ways leading to a sustainable business is not creating new licenses but iteration on business practices.

arp242 3y ago

These things aren't in apt (other than non-free repos), so that's not really a problem. I'm not sure about the pip and npm policy on these types of things, but Sentry isn't a library you would add, so it's not really a problem. But it's fine to keep Sentry out of pip as far as I'm concerned. > You can apt/pip/npm etc install and integrate pieces written by others in your own solution stack without having to call a lawyer. These non-open source licenses force you to stop and think, ask your lawyer before you build on top of them. Try doing that with AGPL, or even just the GPL, or CDDL, or any number of licenses. There's tons of OSD/Four Freedoms compliant licenses that come with conditions; you really do need to look at them and can't "just" do whatever and already need to think about it. And personally I really have trouble especially with the GPL licenses; try reading them and determining what exactly they mandate in various edge cases. We have tons of people clarifying all this (which may or may not be applicable to your situation/jurisdiction), but going on just the license is often very non-obvious. > What's the advantage of these "semi" almost but not all the way open licenses? I can fix bugs for starters. From a purely pragmatic point of view this kind of "I can fix my own problems" is >95% of the value for me. I can easily self-host (including some hacked-up version which addresses some specific needs). I can see what the code does if something is unclear. There's tons of advantages. The only limitation is "don't compete with us". There's probably a few edge-cases, but practically speaking almost everyone is unaffected and they can treat Sentry as "just MIT" (or Apache) for almost all practical intents and purposes. People talk as if there are all sorts of caveats and booby traps here, but there aren't.