Earlier quoted context omitted.
> I do also see these kinds of license trends as harmful to open source generally I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from…
I see the open source movement as being about developers sharing their work in order to raise all ships and dramatically accelerate the rate at which participants in that community can build cool software. A lot of that benefit comes from not having to worry about licenses: pick platform components with known open source licenses, build cool things with them. I think the rise in not-quite-open-source licenses (especi…
From where I left
161–170 of 472 posts
Re: From where I left
#162Earlier quoted context omitted.
It is really hard to believe that no one defends antirez&co as protecting themselves from greedy overpriced SaaS businesses who were parasiting others hard work. What about them saases breaking a social contract of giving reasonable prices adequate to the effort put into a product (or a wrapper around the product)?
It's possible to hold both positions at the same time.
Or please explain.
Re: From where I left
#163Earlier quoted context omitted.
The question of what constitutes a "service" seems very murky, and although it's obviously not the intention of all these source-available, BSL style things, in a dark timeline it seems like there's a lot of room for litigious actors to behave very badly. The uncertainty is what makes it scary, I'd also like a lot more clarity.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
Re: From where I left
#164I think people are not afraid of the current change on licensing, but the magic is broken as soon as a company starts wandering around. Yes the current license is not that bad, but while we have valkey on the side now, how can I trust "Redis Inc." will not decide another small change which does not affect me, then the next one, until it makes something which does affect me.
Good point: the key is that, starting from now, Redis Inc. should make small changes that positively affect you.
Re: From where I left
#165Earlier quoted context omitted.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license? It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will no…
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
Re: From where I left
#166For me, the license change upset me mainly for two reasons: 1. Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust. 2. From a purely selfish point…
> I do also see these kinds of license trends as harmful to open source generally I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from…
Yes, because other projects will follow the pattern of successful ones.
> this will dissuade people from using open source components in their products all together,
Yes, because now there is a very real risk that after you have invested in using an open source license, the owner might change the license on you, which makes potential users more wary of open source projects.
> this will dissuade people from contributing to open source
Yes, for similar reasons to the above.
Re: From where I left
#167Earlier quoted context omitted.
> I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer). It is probably more correct to say a bunch of Redis contributors left the Redis GitHub project and moved over to Valkey. You can see there are a bunch of contributors listed on this page who seem to predate the fork and who have continued to…
Nearly all of them work at cloud providers so they literally just followed their income stream.
Re: From where I left
#168Earlier quoted context omitted.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license? It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will no…
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
Re: From where I left
#169Earlier quoted context omitted.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive: > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, manage…
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
[0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
Re: From where I left
#170Earlier quoted context omitted.
I'm embarrassed to admit that I hadn't fully taken into account that those contributions do at least remain under the BSD license and hence stay open under those original terms. Thanks for reminding me of that.
Note though, the code is not Music, it rots quickly without maintenance. The "social contract" of contributing the code is what it will be maintained by collective community, otherwise many companies would just keep it as private forks. It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions