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

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.