As the platform owner, they explicitly reserve the right to do this - see also Meta, Google, Amazon, etc.
Apple collects data, but they usually keep it for their own use, that's the difference.
Third parties trying to do the same level of collection and also share it with partners is the issue. As such, the platform owner putting constraints on them by applying rules related to privacy shouldn't surprise anyone.
I've had the preferences "close windows when quitting an application" and "ask to keep changes when closing documents" checked since the day they appeared in System Preferences.
With these two, most applications behave as they did in the pre-Lion document model.
IMAP "defeated" POP long ago if you wanted to use a third-party client but still access mail from anywhere.
By definition, this doesn't work in a POP environment, but that's increasingly an outdated mindset.
For historical reasons (intertia, and being early enough that I was able to acquire a "firstname.lastname" address), I don't plan to leave Gmail unless things really go south. My personal domain (Fastmail) is used for other things and I've never anything other than Mail.app and their own web interface.
This is about importing email from your non-gmail account INTO your gmail account. POP is simply the easiest way to do this, and just from GMail's own IMAP interface, it's pretty clear that IMAP is NOT reliable for this task...
The details in TFA are that you can add an external IMAP account to the gmail client app in Android. This does nothing for the gmail web ui, meaning you need something else for your external email.
Wouldn't mind exploring something akin to a web-based, self-hosted Thunderbird mail client giving a server hosted web UI for multiple email and nntp services. If if synced to desktop/mobile apps and/or had a decent mobile web UX, that would be gravy.
I see the appeal of using Gmail to manage all of your mail, including the fact that you can still send through external SMTP servers, but it's just not for me.
Native clients continue to improve, and the mismatch between how I handle Gmail on iOS vs (for example) Fastmail shows that they're so wedded to this particular mindset that it's unlikely to ever be fully solved.
I look at people like my Dad -- early 70's, who spent most of his career as the "desktop infrastructure" manager at a midsize insurer -- who still wants to have Outlook available because he likes how Outlook does mail. It's just how his mind works. IMAP exists, but it's an implementation detail that's separate from the specific client features they add.
Wouldn't mind exploring something akin to a web-based, self-hosted Thunderbird mail client giving a server hosted web UI for multiple email and nntp services.
Self hosting your own mailserver is almost always a bad idea unless you're really a dyed-in-the-wool mail nerd - I worked for one at a small startup one summer during college, but they're a rare breed.
Sourcing .zshrc works reasonably well. I have the following at the end of setup.sh -- which creates symlinks and sets up other configurations.
makeLinks does most of the work, then sets Homebrew's zsh as the default shell -- this currently runs in bash, so it probably will need to be updated at some point -- and everything gets reloaded.
makeLinks && chsh -s /usr/local/bin/zsh
exec $SHELL && brew doctor
There's a reason why the CSS ["reset"][1] is still with us - the lower level user-agent stylesheet never really adopted any of this stuff. Presumably, this was to reduce the delta between browser engines (vendor prefixes, etc, etc.) but it would be nice to see some movement in this area.
There is in other areas of copyright law, like romhacks and action replay codes. Romhacks seem like a very grey area but generally don't get DMCAed when they distribute large binary patch files of the original roms. And "Lewis Galoob Toys, Inc. v. Nintendo of America, Inc." would imply that the dead simple 16 byte[0] "patch files" in the form of game genie codes are legal.
To take a more practical example. Is there no meaningful difference between the dwm multimon patch files[1] and the full forked repo[2]? For context, lots of suckless software keeps extra features/addons in semi-offical out of tree patches files. The philosophy of suckless is generally to hardcode config options in source code and recompile instead of editing .rc files. This reduces the complexity of the code, so you end up with some very minimalistic easy to patch recompile and code. So it's a natural (if very esoteric) way of implementing plugins.
Obviously this is a bit contrived because all the suckless code is actually open source, so none of this matters to them. But I think it's fair to say that distributing the 7 .patch files at [1] wouldn't count as distributing a forked version of dwm. The patch files contain some context lines ripped straight from the main codebase, but not the main repo. Hell I'd even wonder if there's some kind of fair use argument for patch files. After all, often they boil down to a criticism of the codebase, saying that it's bad because it contains all the lines of code starting with '-' signs and really would be better if it had these extra lines of code after the '+' signs.
The license doesn't seem contradictory to me. Counter-intuitive, unclear, and paradoxical (in the most general sense of the word), yes. But not contradictory.
Before the ambiguity of language can get in the way, there has to be a coherent idea that you want to express in the first place.
This license explicitly contradicts itself. It says you are encouraged to contribute changes to the source, and you may not share changes to the source with anyone ever.
It seems like the intent is to encourage giving changes to exclusively the maintainer, and that forking in this context refers to distribution beyond a private communication between the change proposer and the maintainer.
Which, this being a git repo, makes perfect sense, as despite the impression GitHub gave to a whole generation of developers, Git was designed with a different contribution workflow in mind: one of sending patches by e-mail. Cloning the repo locally, making changes, formatting a patch, and sending it to the maintainer, seems to be perfectly withing bounds of both intent and text of the license.
Not really. Legalese is vague on purpose because not every situation can be rigidly defined.
As for English, because of its plain nature, I have little trouble understanding someone who isn't proficient or who has a heavy accent, whereas languages with specific infections or tones might not have that kind of liberty.
Didn't lame do that for years? It was distributed as a patch you could apply to the patent-encumbered MPEG "dist10" reference source code (which as far as I can see, did not even have an explicit license, the distribution only includes disclaimers of warranty)
Related: The installer for iTunes 12.2.1 included a bug which might recursively delete a volume if the path given as input included incorrectly escaped spaces.
Apple collects data, but they usually keep it for their own use, that's the difference.
Third parties trying to do the same level of collection and also share it with partners is the issue. As such, the platform owner putting constraints on them by applying rules related to privacy shouldn't surprise anyone.
If it does, you're not paying enough attention.