From personal experience, that's a proper reading of the rule. You can do things for "personal education" but you can't release anything that's code (open or closed source, doesn't matter, including things already released...you can't maintain them) or code-related (e.g., blog posts, books, etc.) without a ridiculous number of approvals (some from people at like the VP or SVP level).

How do they stop you from just ignoring their rules and doing it anyway?

Author here. I've heard from current and former employees that they believe that Apple doesn't actively police it. However, telling people not to makes it easier to shut down later if they want.

Thanks for writing such a fantastic tool. It's recently become for me a must-have when writing shell in any codebase.

One thing I've really appreciated is the Github wiki pages for individual shellcheck errors. Without those pages I wouldn't have learnt so much more about shell and the shellcheck tool would be more difficult for people to use :)

It is possible to get an exception approved by SVPs -- legal/general counsel merely advises management after all. But Shellcheck's GPLv3 license is a virtual dealbreaker.

Really, really expensive lawyers I would guess. I look to Apple's behaviour towards the Right to Repair movement for proof of past behaviour/culture as an organisation.

They can terminate your employment if caught?

Yup, exactly. I can’t say I heard of that happening but it was pretty understood that there would definitely be severe consequences.

I can speak from personal experience that it's happened, though it's unclear if the violation of this rule was the real reason for the termination or just the scapegoat.

Hello, author here. Yes, it was very surprising. The rationale given to me was this:

You can't compete with Apple, which is fair. However, you're also not privy to what Apple is or isn't working on at any given time.

If Apple gave you permission to work on something, you could infer that they're not working on it, so it's not allowed.

Wow, are they so insecure about quality of their software, that they squash any possible and impossible chance of competition so paranoidly?

I'm unclear how you arrived at this being about their quality.

The statement reads simply as: apple works on many things, and doesn't want you working on things outside of apple that may compete with current r&d or future r&d.

We can disagree with them on if it seems appropriate, but it doesn't seem to be about their software quality at all.

> apple works on many things, and doesn't want you working on things outside of apple that may compete with current r&d or future r&d.

And yet Apple is totally fine with benefiting from the open source work of others...

> And yet Apple is totally fine with benefiting from the open source work of others...

And? Every other person benefits the same with the code contributed under the licenses in play. I fail to see the issue. With llvm for example they seem to be upstreaming a lot of their xcode backend stuff as they get time. So that statement of many copyleft proponents that only copyleft encourages upstreaming rings hollow to me.

Hell go talk to people from Redhat about custom gcc forks that target chips that aren't upstreamed to gcc. Just because you're using gcc and modifying it doesn't mean you'll actually be contributing the code if its all internal.

To answer you, the key part of your reply is: "...that may compete with current r&d or future r&d".

It seems to me that they are afraid (or at least unwilling) to compete on even grounds, despite likely having more budget than a single random employee competing in their free time.

Or their lawyers are extremely good at getting employment contracts drawn up. Never attribute to malice that which can be explained by paranoid lawyers that got the c levels ears.

Who would sign something like that in the current market?

For enough TC I would contractually agree to stop touching a computer between the hours of 6pm and 8am.

More realistically... most engineers don't code as a hobby. HN, /r/programming, and other software dev hangouts are small echo chambers.

> More realistically... most engineers don't code as a hobby. HN, /r/programming, and other software dev hangouts are small echo chambers.

This sounds unnecessarily dismissive to me and also unsubstantiated. It removes the focus from the more important fact that this is a foul encroachment of personal freedom regardless of how many professional coders like coding as a hobby.

> This sounds unnecessarily dismissive to me and also unsubstantiated.

Anecdotally, the programmers I work with don't seem to read anything outside of StackOverflow or contribute to any OSS projects. Albeit, what OSS projects we contribute to or what communities we participate in isn't usually a topic of conversation among my coworkers.

> It removes the focus from the more important fact that this is a foul encroachment

I agree that this is an encroachment on personal freedom and I doubt this clause is legally sound (in California at least). I am quite surprised that Apple has such a policy. But I am even more surprised that they are able to find programmers who agree to it.

Someone who wants to work at Apple despite that.

The vast majority of Software Engineers I’ve come across don’t write OSS code, don’t write blogs, maybe read Hacker News. For most of them this is sort of a non issue.

I would not say non-issue.

It might be a non-issue as in "I probably wouldn't have exercised that right anyway", but that doesn't mean that one feel the restriction is acceptable, fair, or justified.

I would not. Regardless of whether I had any intention to do it or not.

I suspect that that would be unenforceable in the EU, UK, and Scandinavia.

Is there a lawyer with experience in the field reading this?

Not a lawyer, but I have previously contracted one to evaluate and discuss something closely related, which are the Swedish laws about non-compete clauses in employment or contractor contracts.

In summary. They are allowed to some extent, but if a court would consider a non competition paragraph as being too broad, the paragraph becomes void in its entirety, as if it was never entered into the contract at all.

For non management employees the exclusivity must be quite specific, and unless the law has changed recently without my knowledge, and entire industry, or a broadly specified skill would fail the test in any case I can think of.

Applying the most basic levels of those principles, I would assume that attempting to limit a programmers ability to engage in programming in general would lead to nothing but a complete dismissal of any claims related to the non-compete clause if someone brought it to court.

Effectively, if you try to prevent someone to apply their trades and/or talents to broadly, they could essentially moonlight for your worst competition without much of a risk as long as they don't convey what is clearly trade secrets as they are differently protected.

Suffice to say that companies with decent legal departments tend to write specific non competition clauses especially outside of the realm of management positions, as they get no value at all from too broad non competition clauses.

Of course it's enforceable. If you gain certain areas of knowledge working at a company where IP is restricted, then that restricted IP may be reflected in your personal code. This kind of practice is pretty common on a lesser scale, i.e. if you work on say a libc at work, then arguably you couldn't work on a libc or something very similar at home without risking a breach of IP. It just so happens that in Apple's case, they have fingers in such a large number of pies that it must take a great deal of work to verify that something /doesn't/ infringe on their IP.

Of course, they can still sue you for a long time.