>Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
> Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
For the most part, no, the main direct customer benefit comes from the absence of lock-in with regard to maintenance and services thar results from the absence of usage restrictions.
There's some potential indirect ecosystem benefit for customers from the somewhat lower friction for partners in some source-available-but-use-restricted situations, but otherwise for most customers its the same as any other proprietary license.
Being able to tear through the source code of something to figure out why it's doing what it's doing is valuable even if you never make changes.
I worked for a company a lot of years ago that had BSDi licenses for some of it servers and had paid an extra fee for source access and that -did- actually come in handy to me once or twice.
Later, the same went for the Radiator RADIUS server where you got source access automatically with a license purchase.
White box versus black box debugging is absolutely something that can make a difference, especially when something goes wrong.
> Being able to tear through the source code of something to figure out why it's doing what it's doing is valuable even if you never make changes.
Yep. I've definitely noticed this at work with some proprietary ('open-core') software that we use, and it's made me inclined to prefer source-available proprietary products over more restrictive proprietary ones as well. It's not as favorable as actual F/OSS, but it definitely makes a bit difference nonetheless.
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?