Looked at that. I do not really think implementing something like artichoke or rutie would be a good idea. I do not want my project to become overly bloated and to achieve my real goal of a declarative system management thing I think sticking to bottles (that cover almost all formulae thanks to the amazing homebrew community) and casks, getting those to work 100% is the better approach. Thank you for the suggestion though!
(A)GPLv3 does not prevent their projects from being used.
That's the point!
GPL family of licenses would've made a difference in this aspect for libraries (because afair if you link to GPL code, you must be GPL). But for an app? You can use it, fork it, modify it...
Just make sure you make your changes available under the same license. Seems very fair to me.
> (A)GPLv3 does not prevent their projects from being used.
In practice, it does in many cases. Many companies have a blanket policy of avoiding these licences. But I agree that they make more sense for apps than libraries.
Not in their products. Internal use is fine, but where it gets dicey from a legal point of view is when you distribute GPLv3 binaries as an integrated part of your product.
Linux in Android is GPLv2 not GPLv3. The v2-v3 difference is a big deal to some.
Linux developers made an intentional decision to stick with GPLv2 and to remove the "or later version" option, so you can't include it into GPLv3 projects as you can with most other GPLv2 software.
GPLv3 avoidance is why Apple ships ancient versions of Rsync, Bash and Make on its current OSes instead of the current versions, and replaced Samba with its own inferior SMB service.
This is a huge difference. The GPL and its flavor are explicitly not about use. They place zero restrictions on use. Unlike, say, just about all proprietary software.
It only governs distribution and especially prevents distributors from locking their users in, and from placing restrictions on their users' use of the software.
Depends on your definition of "user"/"use" and "distribution" really.
If the service provider is the "user," and performing actions with it on behalf of the ultimate user is "use," and not "distribution," then you are technically correct. It restricts the service provider from forcing their customers to be dependent on the them and/or restricting the end users' use of the service, like the GPL does for proprietary software the user runs on their machine.
I personally disagree that running something on behalf of a user makes you the end user, but there's always the GPL if you think that.
From my past experience, it goes something like this.
If software is GPLv2, it's penalized relative to more permissive options when it comes to picking one. In practice it means that it's avoided unless it's "too big to avoid", or because the very nature of what you're doing requires it - this is the case for e.g. Linux and R.
If software is GPLv3, it's considered radioactive and is avoided at all costs, even if it means rewriting large amounts of code from scratch.
Notably, macOS ships mainly BSD-derived userland utils and for the rare GNU software, it's GPLv2 stuff (hence zsh as the default shell, while shipping bash 3.whatever for compatibility).
And guess what application developers install immediately after getting their MacBooks?
The GPL licensed git.
If I'm forced to use MacOS, I'm fine installing git, GNU make or whatever I want for myself. But I don't see any downsides in Apple being unable to distribute those applications together with their OS.
> And guess what application developers install immediately after getting their MacBooks? The GPL licensed git.
Why would they do that? I didn't, because macOS ships with version 2.39.5 as /usr/bin/git. You're free to upgrade to a newer version, of course, but the included one is recent enough for most uses.
Does macOS include git? Oh. My bad. I concluded from the previous comment that Apple doesn't ship bash because it's GPL and hence doesn't ship anything GPL.
And my point was: this is fine. Even if it was true.
But as this is not the case, I see even fewer arguments against GPL licenses.
Apple shies away from GPLv3 code. They ship a ton of GPLv2 code, though. And as you mentioned, even if they didn't, it just takes a moment to install Homebrew and get whatever else you want. Apple doesn't stop me from installing a new Emacs.
Sure, Apple won't stop you. But the defaults matter. If you're writing a shell script and you want it to run on MacOS, you need to target the ancient version it's actually shipping, or you have to tell your whole team to install a later version. If your servers are running Linux then you'll be dealing with platform inconsistencies all day long. Ask me how I know.
This is even more damning because it means the maintainers want their MIT-licensed projects to be used by for-profit companies, but bellyache when certain big-tech companies fulfill the maintainer's vision.
GPLv3 with interpreted code is a legal nightmare you do not want. Compiled is manageable.
Then again I've seen companies publishing stuff on GitHub, when asked about the license; slapping GPLv3 on it but also forcing you to take a license with them for commercial use. Yea no, thanks. You just made a poison pill somehow even more lethal.
> (A)GPLv3 does not prevent their projects from being used.
It really does. It stops it being used by people who need or want to use other licences. I believe it stops it being used on iOS and (probably) Android apps. The GPL world and the permissive licence worlds are walled off from each other in significant ways for lots of reasons.
Source: I maintain an app where I didn't choose and can't change the licence. And I come across code I can't touch almost every week.
> I believe it stops it being used on iOS and (probably) Android apps. The GPL world and the permissive licence worlds are walled off from each other in significant ways for lots of reasons.
I fully agree that (A)GPLv3 code effectively stops code from being used by many large companies (every place I’ve worked in the last decade has a near blanket policy on refusing to use code licensed that way except in very specific and exigent circumstances), but it isn’t necessarily true that app developers can’t use (or can’t choose to license) (A)GPL code in their iOS apps, provided they abide by the terms of the license.
Most developers won’t — or can’t — but the advent of dynamic linking of libraries in iOS, as well as the EU-mandated third-party app stores (which aren’t available outside the EU, but still), make the situation a lot more grey from the black and white stands the FSF attempted to take in the early 2010s. And to my knowledge there have been no legal challenges about the use of GPL code in iOS apps, so the issue is essentially unsettled.
That said, in most of the cases where I have seen iOS apps use GPL code, the full app source was available (and that may or may not fulfill the redistribution requirements but I’m not a lawyer and I’m not going to cosplay as one).
On Android, where full Google Play alternatives like F-Droid are available, plenty of GPLv3 apps exist, even if they aren’t available on Google Play.
But yes, when it comes to incorporating GPL code into a non-GPL app, that is much more difficult in the realm of mobile than it is for other types of applications.
> but the advent of dynamic linking of libraries in iOS
I'm not sure you can dynamically link to GPL in this case (LGPL maybe )? And I recall that there's also issues around signed bundles used on the various stores.
But the fact that we're not sure and the fact that we're having this conversation rather proves my point. People who aren't fully in the GPL world usually have to steer clear of GPL code entirely. This goes double for hobbyists and small orgs who can't afford a legal team.
> even if they aren’t available on Google Play.
As much as it's regretful this is a huge issue for most people who want to make apps that other people can use.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
This is a "some companies might not want to have to litigate that". Whether or not there would be a problem is an open question. Legal likely advised not touching GPL version 3 out of an abundance of caution.
Eben Moglen speaking at the GPLv3 launch, January 16th 2006
...
We recognise that for parties who have extensive portfolios that are extensively cross-licensed, what we are saying here for the first time creates questions concerning their cross-licenses in relation to their distribution.
We recognise also that to say that you must "act to shield" is not explicit enough. We recognise that this is a very hard problem and though we have worked long at it we have no unique solution to offer you, even as a beginning for conversation.
...
I am not a lawyer, but what I understand from that is, if Apple authorizes use of bash under GPLv3, and then Apple decides it has a patent on something and bash is infringing on that patent, Apple can't go sue their customers for patent infringement because they are using bash. I'm 99% sure that's the intent of the clause. Lawyers are famously pessimistic and so I can see why they wouldn't want to test that, but seriously, what. are. the. chances.
Like seriously, maybe Oracle comes and sues Apple for patent infringement, and Apples only defense is to counter sue Oracle for using bash on their Macbooks?? They lost that defense when they stopped distributing bash, why not just distribute it under GPLv3 anyway?
As I understand it, it's more difficult than that... though I'm not a lawyer.
Let's say {some company} and Apple have a cross patent licensing for some set of patents.
Apple releases some softer under GPLv3. {Some company} sues someone else for a patent in bash. Since Apple licenses that patent and distributes bash, Apple is now obligated ("must act to shield") the distribution of bash that includes that patent.
If you distribute a covered work knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you.
That wording of "knowingly relying on a patient license" and "must act to shield downstream users" are things that lawyers don't want to touch with a 10 foot pole. Would it mean that Apple would be required to defend the company that its patent partner is suing? Not a spot that lawyers want to be in. Furthermore, if you distribute GPLv3 software, it may mean that doing the cross patent licensing is more perilous... again, not a situation that lawyers or large companies want to be in.
There's Apple's bash distribution. If this was the GPLv3 version of bash and apple distributed a version that {some company} decided was infringing, and {some company} sued you - "I got it from Apple. Apple Legal, help me."
That's a helpful explanation, thank you. As a consumer of free software, that sounds great! I agree that it sounds pretty messy for big companies and all their patent deals. Sucks to be them, I guess
All the replies to this spreading anti-GPL FUD are doing Microsoft's work for them. The idea that the GPL is "viral" and will latch onto any code it gets near is an Orwellian turn of phrase invented by Microsoft from what, 30 years ago? And it has worked because people are scared of the GPL! It's gonna get you! Don't even get close to it!
Nevermind that Red Hat built a billion dollar business on top of GPL licensed code. Never mind the millions of embedded systems being sold with GPL code in them. Nevermind Google, Facebook, Netflix, etc., etc. all eating Microsoft's lunch a thousand times over using GPL code. Businesses better stay away! It's dangerous!
I won't use GPL libraries in my code. I'm quite confident I'm not the only one.
If there was no other choice, I may consider something LGPL or with the linking exception, but not until I had exhausted a search for something more permissive. To this day, I've never used GPL in any of my code, open source or closed. I've been writing code for 35 years daily.
Strange comment given the obvious differences in GPL vs. non-GPL regardless your personal opinion. GPL code means if I decide to distribute my project in the future, I will have to distribute my source code. That isn't a risk I'm willing to take. Some of my projects are open source, but I want to retain the option of doing what I want with my code, so I don't use GPL licensed code.
> The two main factors for this are: two-person income households up-bidding, making it less affordable for single people/mums/dads, and an unsustainable level of immigration.
I feel like you have at least missed two other very significant factors: low interest rates and increased borrowing limits for mortgages driving up the amount people are able to afford and the fact that councils almost completely stopped building houses since the 70s/80s.
I agree with you, but I don't think they're absolute fundamental drivers.
Low interest rates will drive prices up, but not to the point we have now where nice-sized family houses are divided into multiple small residences and it's still not enough. I haven't tried it, but I suspect if you game-theoried it out with a stable population and low interest rates there would be up-bidding, but everyone would still end up with a house.
With a relatively stable population you don't particularly need many new houses to be built (and not by councils in particular).
Also increased longevity. Where we once had three generations alive now it is four. Where I live is full of aging single people clinging on to their family homes.
Shouldn't parsed XML be smaller than the raw uncompressed text? (as you could deduplicate strings). I'd expect that to be a significant saving for something like wikipedia in XML
> I think what would be better is an LTS release. Historically, you get a new Mac and you usually only get 5-6 years before they drop your model from the latest release
In fairness, Apple to do tend to continue to release critical security patches for older versions.
I suspect that it will be AI features that push Apple into deprecating older hardware. But I also hope that the M series hardware will be supported a bit longer than the intel hardware was. Time will tell.
The real benefit here is the increased density of the neighbourhood. That's conducive to community even if it's strangers that move in. Combine this with mixed zoning that allows for commercial property (things like cafes and grocery stores) and suddenly you have a pathway for gradually turning faceless modern suburbs into walkable neighbourhoods with amenities.
Why use Java when you can use Rust? In all seriousness, Rust is a joy to work with for these kind of tools which typically don't have complex lifetimes or ownership semantics.
On top of that you get better performance and probably smaller binaries. But I would pick Rust over Java for CLI tools just on the strengths of the language itself.
> They forget why we moved on. Modern systems are built with constraints like memory protection, isolation, and stability in mind. You can’t just “flatten address spaces” and ignore the consequences.
Is there any reason why GPU-style parallelism couldn't have memory protection?
do you mean accessing data outside of your app's framebuffer? or just accessing neighboring pixels during a shader pass, because those are _very_ different things. GPU MMUs mean that you cant access a buffer that doesn't belong to your app that's it, its not about restricting pixel access within your own buffers
reply