Live data from Hacker News

From where I left

antirez.com

161–170 of 472 posts

Re: From where I left

#161
post #151
post #127

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…

[deleted]

Re: From where I left

#162
post #147
post #144

Earlier 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.

In the world of legal consequences it is not.

Or please explain.

Re: From where I left

#163
post #84

Earlier 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).

For the companies who "are copyright holders of the code" the uncertainty and litigation potential is not a bug, it's a feature.

Re: From where I left

#164
post #160

I 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.

> how can I trust "Redis Inc." will not decide another small change which does not 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

#165
post #142
post #84

Earlier 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…

> Redis, Inc. could some day be acquired by Oracle

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

#166
post #127
post #68

For 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…

> this will dissuade people from using OSI licenses

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

#167

Earlier 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.

I know this doesn't mean much, but I spent a lot of time outside of work helping to maintain the Redis codebase. I attended our meetings and responded to issues on vacation because I cared about the community, it was more than just a paycheck for me. I don't regret doing any of that.

Re: From where I left

#168
post #142
post #84

Earlier 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…

A cynical view is that it's not just 2-3 providers, its any competition to their cloud-hosting business. See for example the recent wordpress drama, which concerns a small competitor.

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

#169
post #106
post #84

Earlier 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 for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere.

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

#170
post #101

Earlier 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

That may be true of node.js codebases, but last time I checked Redis was written in C and only depends on ISO and POSIX standardized stuff. I doubt there's been any leftpads that have broken the old versions by now.
Post reply on HN