181–190 of 197 posts
Earlier quoted context omitted.
Steam gog And archive.org some of the games are abandonware and free.
For anyone who cares about legality, do not touch Internet Archive (archive.org) with a 10 foot pole. That place is one of the biggest collections of warez known to man today.
Earlier quoted context omitted.
shagie@Mac-Pro ~ % bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin23) Copyright (C) 2007 Free Software Foundation, Inc. I will note that is an interesting date as version 3 of the GPL was released on 29 June 2007 -- https://www.gnu.org/licenses/gpl-3.0.html https://ftp.gnu.org/gnu/bash/ has version 3.2.57. Opening up the 'COPYING' file from that distribution: GNU GENERAL PUBLIC LICENSE Version…
Apple’s violation of GPL has nothing to do with which version they’re using and everything to do with failing to provide source code promptly that matches the OS they’re shipping.
Earlier quoted context omitted.
VLC’s doing fine. It’s how our kids watch movies on road trips (download to iPad from Jellyfin’s web interface, play in VLC). Almost every book I’ve read in Books is from libgen. Download, open-in, and it’s on all my devices. Reading progress syncs and everything. The best electronic comic book experience I’ve seen is from a free app (optional one-off IAP that does nothing—I wish it had higher tiers, the author is do…
Does VLC have any extra codec support (read: software decoding) compared to what Apple makes available via APIs? I think the only thing I've noticed is webm files being playable in VLC and not when opening via the `files` app, but the vp9 codec is hardware accelerated and has been available for playback in apps for years (the YouTube app shows it in use a lot).
How’d this get past app review? Apple has allowed zero emulators of any type on the App Store. I bet this gets crushed.
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is…
> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area
This refers to the storage container each app gets, once a user loads up a script into the app, it’ll be stored within its container. So there’s no reading or writing outside its container area.
One could argue that the app itself isn’t self-contained in its bundle, but that depends on how you draw the lines. If your definition is that the app is an emulator then it’s self-contained within its bundle, if however you contend that the games you load in are to be considered part of the app and that those games are to be deemed apps then it’s not self-contained.
> nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps
There is no downloading or installing code, but there is executing code. Again, does executing this code change the features or functionality of the app? If your definition is that the app is an emulator, then no, if your definition is that when it runs these games it changes the app then yes the execution clause applies.
At face value the app, the emulator, is not changed and is self-contained, but reasonable minds can differ.
Nevertheless I don’t think the app it at risk for its functionality, rather it’s at risk for being under GPL license as per the App Store listing.
This is because Apple doesn’t allow GPL licensed apps on their App Store courtesy of the FSF[0] who tried to force Apple to change their App Store terms with a gambit by submitting an app licensed under GPL, to then turn around and complain that Apple’s App Store doesn’t comply with the GPL license by virtue of not distributing the app without DRM and other restrictions.
Apple’s response of course was to simply remove the app in question and adopt a silent policy of not allowing GPL apps (and other apps with a license that collides with the App Store ToS and license).
0: https://www.fsf.org/blogs/licensing/more-about-the-app-store...
hmmm I suspect this is because it is GPLv2 which doesn't require the freedom to RUN the program (which apple doesn't give you) apple seems to ship software with gplv2 (old bash, etc) but no GPLv3 software. ...even though they are technically in violation of the GPL by modifying and shipping bash binaries without full source - it is missing rootless.h (not the X11 file)
They're not.
They've covered this in two main ways:
1) By listing all their source code on https://opensource.apple.com/ (which links to their GitHub with all the source code)
2) By offering a complete machine-readable copy of the source code upon request as per GPLv2 (3)(b). This offer is made both in the license agreement[0] you agree to when booting up your Mac for the first time, updating it, etc., as well as in an Acknowledgements.rtf[1] file that is located on your drive at multiple locations (e.g., /Library/Documentation) and linked to from within certain apps (e.g., about section, acknowledgment section under Help, EULA agreement prompt, etc.).
That covers the bash part. rootless.h isn't part of bash and is part of libSystem.dylib, so that would fall under the OS exception in GPLv2[2]:
> However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
That said, it probably won't be long before they stop shipping bash altogether, they've already switched to Zsh a while ago and seem to have moved to a "bring your own tool" philosophy for anything they don't support by default (see Python removal and future Ruby and Perl removal notice).
0: https://www.apple.com/legal/sla/docs/macOSSonoma.pdf (see §15)
1: https://opensource.apple.com/source/files/files-553/Library/...
2: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
Interesting. My 5 year old sons favourite app on his Android tablet is ScummVM. I bought all the Putt Putt, Freddy Fish, and Spy Fox games on Steam, and after copying the data files over to ScummVM on Android, my son has been enjoying them a lot. I'd much prefer him spending his time with these rather than these toxic mobile games that target young kids with repetitive loops locked behind countdown timers and in app…
This doesn't meet the 2.5.2 prohibition for reasons explained elsewhere[0], and it shows a misunderstanding about which guidelines prevent commonly desired emulators.
Emulators are generally barred mainly under the intellectual property guidelines[1] in §5.2 because most emulators require copyrighted bios files to run. Some other emulators were yanked after a DMCA request, and again, others were yanked because they were disguised as other apps.
ScummVM doesn't suffer from these issues at face value, but their more significant problem is that they're licensed under GPLv3, and Apple has an unofficial policy of not allowing GPL(v3) on the App Store thanks to a gambit the FSF[2] tried to pull that blew up in their face.
They tried to force Apple to change their App Store terms by submitting an app licensed under GPL, then turned around and complained that Apple’s App Store doesn’t comply with the GPL license because it does not distribute the app without DRM and other restrictions.
Apple’s response was to remove the app and adopt a silent policy of not allowing GPL apps (and other apps with a license that collides with the App Store ToS and license).
0: https://news.ycombinator.com/item?id=38826426
1: https://developer.apple.com/app-store/review/guidelines/#int...
2: https://www.fsf.org/blogs/licensing/more-about-the-app-store...
Earlier quoted context omitted.
Not sure if you linked the wrong video, but the one you linked to barely supports your comment. Setting aside that abandoning OpenDoc turned out to be the right call, I see a dude trying to get a rise out of Jobs and Jobs handling it in a very respectful way, going as far as admitting they make mistakes and that he is flawed, but that ultimately the decisions are made with the end user (and sales) in mind and less wi…
> just recompile it bro This assumes you have all the source code for everything available, the person to do it ready, and that no compiler errors anywhere have crept in through the many revisions of the SDK. None of these assumptions hold for iOS ports that sold poorly (as most did), that were done by some team (likely defunct) as a one-off, that probably used a bunch of middleware they didn't own. It's just not wor…
The transition to 64-bit started in 2013 with iOS 7, 5 years after the App Store launched and included a 64-bit compiler in Xcode 5 that year.
Not long after, 64-bit was set to default for new projects in Xcode.
That was the point developers should have made the transition.
Instead, we saw that most developers didn’t bother, and by the time 2015 rolled around, and 64-bit became mandatory, many had still published 32-bit apps in the two preceding years.
In other words, most of the abandonware was made in the two years leading up to the 64-bit requirement despite ample warnings.
Now, you have me believe that they didn’t have their source code lying around somewhere? I’m sorry, but that’s just not believable.
So, the source code was available. How about the people who could do it? Many makers of abandoned apps and games happily continued publishing new 64-bit apps and games after the transition (e.g., Capcom), so I think it’s safe to say that the people were available.
Now, what about the difficulty of porting it to 64-bit? I can’t find an authoritative source that describes it objectively, so I’ll just have to throw in my own anecdotes.
I’ve done about 15 ports for various people with apps varying from your garden variety app to some games.
As I stated above, in most cases, it was as easy as recompiling it. In a few instances, Xcode would throw up some warnings and errors, but those were all of the “you need to do this” variety, and working through them didn’t take me (a solo dev) more than a day.
Games were a little more involved in some cases because I needed to audit pointer usage and optimize memory usage, but even so, in all cases, I had a build up and running within a week.
Would all of this been harder had this been abandonware from two decades ago that nobody had touched since? Probably.
But specifically, in the case of the iOS transition to 64-bit, it mostly boiled down to “just recompile it, bro,” as you so aptly stated in part because they were, by definition, relatively recent projects.
So to me, the ones that didn’t do it didn’t bother because it wasn’t opportune to them, rather than out of a lack of ability to do it.
Earlier quoted context omitted.
Apple’s violation of GPL has nothing to do with which version they’re using and everything to do with failing to provide source code promptly that matches the OS they’re shipping.
That one? https://opensource.apple.com/source/bash/bash-123.40.1/versi...
Earlier quoted context omitted.
Apple’s violation of GPL has nothing to do with which version they’re using and everything to do with failing to provide source code promptly that matches the OS they’re shipping.
The source for the version that Apple ships is at https://opensource.apple.com/source/bash/bash-123.40.1/