Expurple

9 ms·

61.
by Expurple 1y ago
That's true. But at the same time, the risk is kinda overblown. You can still use the last open version of Redis. There's even an open, community-maintained fork that you don't have to maintain yourself. Even GPL can't f
62.
by Expurple 1y ago
Rewriting "any software" is an extremely high bar to begin with. I think, we can agree that smaller utilities and libraries can be rewritten by anyone. Another comment [1] even references the "Bram's Law". It basica
63.
by Expurple 1y ago
It's true that we don't have any definitive data on this. But I buy the article's argument that upstreaming a patch once is simply cheaper than maintaining your own proprietary fork forever. It externalizes the efforts of mai
64.
by Expurple 1y ago
Compared to permissive licences (from the user's POV), GPL is merery a guarantee that a proprietary fork won't left you behind in the dust overnight. That's a rather strong guarantee that most people (including myself) don&#x
65.
by Expurple 1y ago
> I don't see why a company that refuses to add to a GPL project has a "decent change" of releasing their code under a more permissive license. Because upstreaming a patch once is cheaper than maintaining your own propriet
66.
by Expurple 1y ago
The article makes the point that, in practice , permissively-licenced projects see more contributions back. Copyleft projects are being rewritten as proprietary instead (with a few exceptions like Linux, which are too big to fail). The e
67.
by Expurple 1y ago
Redis has an open fork. Seems "free" enough to me. Companies are not obligated to keep developing the open version forever, anyway. If Redis was GPL, they could've just abandon it and write a compatible clone from scratch. No
68.
by Expurple 1y ago
But a proprietary fork doesn't change anything for permissively-licenced projects either! The open original is still available, you can still use it and fork it. If it's a popular project, a community-maintained fork will always h
69.
by Expurple 1y ago
The point of the article is that BSD & Co have better survival characteristics, eventually attracting more developers, producing higher-quality software, and making the users switch to that. In the long run, even from the user's pe
70.
by Expurple 1y ago
Are you seriously trying to imply that the GPL isn't largely about granting you the freedom to fork? Sure, it's also about forcing the copyleft responsibility on you. But come on... That's not even relevant if you don'
71.
by Expurple 1y ago
Indeed, that's a very important thing to foster! In fact, I published a post about this just two days ago: https://home.expurple.me/posts/non-profit-foss-solves-the-co...
72.
by Expurple 1y ago
Your argument is in terms of "fairness". But most users don't care about fairness. They care about better software. I'll use a permissively-licensed project if it's better. Most people will use a proprietary project
73.
by Expurple 1y ago
> The fact that very large corporations are willing to spend tens and hundreds of millions of dollars to replicate software is exactly why the GPL is not irrelevant. No, it's the opposite. The premise of copyleft is forcing the depe
74.
by Expurple 1y ago
Most other "flagships" of the Rust ecosystem (including rustc itself and ripgrep) are permissively-licensed, and still haven't been "hijacked" by a proprietary fork. Or by a copyleft fork, for that matter. Permissiv
75.
by Expurple 1y ago
> you're doomed You're making a big stretch here. Sure, you can be left in the dust behind their proprietary fork, that's true: https://hypercritical.co/2013/04/12/code-hard-or-go-home But y
76.
by Expurple 1y ago
Yes, but what's the better alternative? The article makes the point that you're not even getting table scraps back into your GPL project. In most cases, the companies prefer a proprietary rewrite. Now you're just stuck with a
77.
by Expurple 1y ago
The same could be said about non-corporate contributions. "People only contribute as long as they have a personal itch to scratch. The moment they get what they want, you're on your own again". That's always been the dea
78.
by Expurple 1y ago
From a developer/business point of view, there's no reason to use a more restrictive GPL dependency if it's not clearly "superior" to a permissively-licensed one. The article makes a case that this will eventually p
79.
by Expurple 1y ago
Yeah, copyleft has always been just a hack to cope with the current legal framework
80.
by Expurple 1y ago
True, but the article makes a point that it's very hard and unlikely to maintain technological superiority over a coproration that's determined enough. A corporation simply has much more resources. See also: https://hyp
81.
by Expurple 1y ago
The point of the article is that: 1. In most areas, they eventually will! 2. If there is a permissively-licensed project in that area, at least there's a decent chance that the "reimplementation" will be a fork of that projec
82.
In the long run, GPL code becomes irrelevant (2015)(josephg.com)
44 points by Expurple 1y ago|176 comments
83.
by Expurple 1y ago
> one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part. You have gotten it across just fine. We're trying to get across that no one is ever going
84.
by Expurple 1y ago
> The idea that one needs Rust to write reliable software is not only ridiculous at a logical level I never said that. I said that it's more appropriate and productive. > If it were really “preferable for writing such production
85.
by Expurple 1y ago
Yeah, the historical reason for standardizing C is the reason to "reconcile" a bunch of already existing compiler implementations
86.
by Expurple 1y ago
The machine code will always be generated from "something". A one-line informal prompt isn't enough. There will always be people who write specs. Even the current languages are already far from "machine code" and co
87.
by Expurple 1y ago
Editions will look like band-aids that don't fully solve the cruft accumulated over the 50 years. That's not hard to predict. It's still a very useful mechanism that slows down the accumulation of said cruft. I'm yet to
88.
by Expurple 1y ago
I don't have any negative experience with that one, but I remember having to manually install various versions of the Windows C++ runtimes to get an app working
89.
by Expurple 1y ago
As the other commenter responded there, your example isn't about editions at all. It's about mixing ABIs and mixing multiple versions of the language runtime. Those are entirely separate issues. You're correct that the possib
90.
by Expurple 1y ago
> the Golang/Python/Java teams have already released to customers. ...have already released a broken prototype that appears to be working for now. I'm yet to see a case where manually "hardening" your software

More ›