Hacker News Reader

Comment by tytso | Hacker News Reader

Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time". The problem is it's extremely difficult to say, figure out when someone might have invented some super clever idea which can be pantented "on their own time". This was true when I worked for MIT, VA Linux, IBM, and Google. At VA Linux it was the VC's which insisted on that clause in the employee's contracts. So anyone who think this is some evidence of Google being, or becoming, evil is either seriously misinformed, or just engaging in unthinking hate of Google, or both.

In fact, Google has one of the most permissive IP policies that I've seen at any company except for VA Linux Systems. The default is that the vast majority of work done by an employee can be released under an open source license. Sure, there's a process that you have to go through, and unless what you want to do intersects with work that you are doing for your team that isn't intended to be released publically, or competes with a critical company initiative, the default answer is that it will be allowed to be released.

This is not true for many, if not most companies, and as a responsible open source maintainer, I make sure that people understand they have permission from their company before I accept their open source contributions. Otherwise, I would be putting them, and the project, at risk. (Note that because of this, there are many employees which are not allowed to participate in open source development, because their employers will not give them permission to release code written by an employee under an open source license, whether written "on their own time" or not.)

At Google, once you get this (mostly pro forma) permission, you can work on open source projects on your own time, or on 20% time, using company laptops, or using GCE resources, etc. When I was hired at Google, my manager and I cut a deal such that I could work on Linux Kernel and community projects for 50% of my time, instead of the normal 20%. Sure, the overlap between what was good for Google and what was good for ext4/Linux was pretty broad, but Google also paid for me to travel to various conferences in Asia, Australia, Europe, etc.

Also unique to Google is there is a process by which you can get permission for you to out-and-out own the work done on your own time, as opposed to Google owning it and releasing it under an open source license. If you take that option then it really has to be done on your own time, and must not use any company resources, meaning not on a company laptop, or on a company network, etc. This is rare, and I'm not aware of many other companies that give employees that option.

View on HN

It's absurd for any company to say they're going to attract passionate programmers, and then expect them to just roll over and give up projects that were started before they even joined at the company.

If you're Google, you can get away with this because you just throw so much money at people that they're willing to temporarily put their life on hold for 3-4 years.

But for any other company, people who are genuinely passionate about something are not going to let you dictate their entire involvement or own everything they produce. My current employer doesn't own "everything" that I produce, only projects that would present a clear conflict of interest. I don't have to be secretive, they know what I'm working on outside of my job -- not even just Open Source stuff, but even closed-source projects that I'm looking to monetize.

I would never, ever join a company that didn't (in writing) allow me to retain ownership of my side projects.

That's the tradeoff. You want your programmers to take initiative, stay up to date in the field, stay creative? You want them to be able to propose novel solutions to your problems, and think outside of the box? You have to let them go outside of the box, and do the things outside of work that keep them in that frame of mind.

If your programmers are scared to experiment outside of work, because they have to run a calculus of whether or not an idea is worth putting on hold until they can actually own it -- well then, surprise, they're not going to experiment outside of work, and your software quality will suffer for it.

People like tytso, who are effectively being sponsored by Google to work on their side projects, might be an exception. Most of your programmers will not be an exception.

> I would never, ever join a company that didn't (in writing) allow me to retain ownership of my side projects.

OK that's fine, but doesn't everyone have this choice? Apparently google attracts thousands of top engineers with this clause. Lots of people agree to it, just because you won't doesn't mean it's absurd. Maybe you are absurd for calling google and their ideas absurd.

Companies like Google are an exception; they pay their engineers so ridiculously much that people are willing to ignore the clause under the assumption that they'll work 2-3 years and quit. Google is also broad enough that they can basically hire passion project employees -- people like tytso who are being paid to spend upwards of 50% of their time working on a side project like the Linux kernel.

If you're a startup or a small company, you do not have enough money to do what Google is doing. You'll attract talent, but you won't attract industry veterans or people who have very wide skill sets, because what your company is doing is not interesting or broad enough to hold their entire attention -- and you're demanding their entire attention, both in and out of work. You're also not in a position to offer anyone like tytso their dream job, because you have a minimum viable product to build with specific requirements. So the industry talent you do have will leave quickly, because in order to do interesting things they'll have to.

I regularly see articles about how to hire good people and keep them, and a lot of them waste time talking about stuff like snacks in the office, or the company culture, or whatever. Very few of them acknowledge that good programmers are good because they like programming, and if you put them in an environment where they can't program without your permission, they'll leave because regardless of how many free sodas you're giving them, they'll still feel smothered. Similarly, the employees that stay will progressively have a harder and harder time keeping up with the industry, because there's no reason at all to explore new technologies when you can't do anything with them.

Take whatever position on the ethics you want, it's absurd to assume that you're going to hire someone who's genuinely passionate, and keep that person around for 10 (or even just 5) years if your company has policies like this. You have to give those people the ability to breathe, or they'll go somewhere else where they feel less strangled.

People look at Google and say, "it's fine, because it works for them." 99% of companies in the world aren't Google, and will not be able to pull this off without suppressing their hire quality and retention.

> People look at Google and say, "it's fine, because it works for them." 99% of companies in the world aren't Google, and will not be able to pull this off without suppressing their hire quality and retention.

Do they really? Who cares? If some startup adopts the policies of one of the largest most successful companies in the world, then that is stupid and on them, they deserve to fail. At this point it doesn't even have anything to do with Google.

You said you won't apply to Google because of their policy, I said fine they don't need you they have plenty of qualified applicants. Now you're saying the problem is all these copycats. OK, whatever. Let them do what they want, and let people sign agreements they want. You just keep saying that it's absurd, but that doesn't make it so. That is entirely your opinion and the fact that thousands of engineers CHOOSE to work there is supporting that it's not absurd. If this is all about Google and you don't care and would never work there then why do you care so much about the people that do? Are you concerned they're being oppressed in some way? Have they been mislead? Isn't it possible they just disagree with you?

I never said anything about trying this policy out at your local startup or anything about what's best for you as a programmer in general. No kidding people like freedom? People lash out at Google and then turn it into something completely different halfway through the conversation.

I think your reaction here is similar to how people reacted to the headline that a woman sued her 5 year old nephew for accidentally breaking her arm. She was actually suing the parent's home owners insurance policy because the policy is supposed to cover these kinds of accidents. The insurance company didn't want to pay out though, so they spun the story to a news broadcaster in an effort to shame her into dropping the claim.

Most cases where an employer claims ownership of something an engineer did on their own time, it's because the engineer decided to create a competing product and used information or other ip they only had access to as an employee. The guy trying to sell his competing product doesn't want to acknowledge that they've violated a non-compete or NDA they signed, so they publicly claim their employer is just being a bunch of greedy bastards. When you dig into known cases of employers claiming ownership of an employees outside work there are cases where they worked on it before they joined, but those are outliers, and having initial work from before joining doesn't mean that later work hasn't infringed on the employers existing IP.

This topic is often complicated, but the realistic answer is that you should always tell your employer that you've started working on something and have it acknowledged as yours way before any valuable IP is created. Not doing so isn't just irresponsible, it's a known business pattern that results in failure. You should ideally tell them before you've even answered the question of how you intend to do it. Nobody is going to steal a vague idea, so this just eliminates the possible argument later. A lack of ability to trust is a strong indicator of eventual failure of the project anyway, so there simply isn't a reason to avoid doing it.

The cases that make it to court are often the ones where the employee was in the wrong, but cases that make it to court aren't the only thing to judge these policies by. If the policies cause a chilling effect where people who join give up on contributing to outside projects (as the OP twitter thread and multiple others from the author talk about), then it's valid to criticize the policy for that. The cases that make it to court are more likely to have the employee be in the wrong because they're selected from the subgroup of cases where the employee went against the policy instead of quitting outside contributions.

This isn't a bad argument, but it doesn't match up with the experience that OP had in the Twitter thread.

I don't see the point in arguing about what most theoretical cases are when we can instead talk about the actual case that actually happened here. It's difficult to argue that OP stole anything, and they weren't competing with Google, and OP is saying that they didn't use company resources to build anything.

Unless your claim is that OP actually did something wrong, the rest of it a little too theoretical for me.

I've written this elsewhere, but if obvious abuses were all that companies cared about, the terms wouldn't be written so broadly as to cover everything. A contract is not the place to put an egregious term and then say, "don't worry, we won't enforce it." Treat contracts like they will be enforced.

In particular, we've seen this pattern with arbitration agreements. How many women signed Google's arbitration agreements when they joined under the (false) assumption that, "of course for something serious like sexual abuse, Google wouldn't enforce that"?

> you should always tell your employer that you've started working on something and have it acknowledged as yours way before any valuable IP is created

I do heavily agree with you on this.

Don't do what OP did and just ignore the terms, be up front about what you're doing. It just removes doubt. And don't be afraid to walk away from a company if they won't negotiate on this kind of stuff. You want to be in a trusting relationship with your employer.

I get your point, and if the parent's argument was "but the situation is not that they do it on their own time, but that they violate NDAs etc." then it'd be a solid argument. But the parent argues that it's completely normal for a company to claim ownership on 100% of employee's life and intellectual output, regardless of NDAs and IPs, and that Google has to be praised for permitting you to keep your intellectual output to yourself, if you ask extra nice.

> so there simply isn't a reason to avoid doing it.

Well, one of the reasons would be what I do outside of work is not my employer's effing business. Of course, if I am taking stuff from work, it makes sense to tell my employer - e.g., if I use company's car to move my furniture, I'd better clear it with my boss, same goes for IP. But if I use my own car to move my own furniture, why would I need to tell my boss about it, even if I use the company car when they are paying me? I mean, I might get a paper just to cover my ass, but that's rather a testament to the state of litigiousness and ridiculousness of our society, not a proper way to do things.

> It's absurd for any company to say they're going to attract passionate programmers, and then expect them to just roll over and give up projects that were started before they even joined at the company.

What I find more absurd are companies that want to hire employees that are passionate and work on side projects but also require employees to sign extremely broad “we own your IP” contracts. It’s like they are saying, “We want to hire the most passionate! But we also want to own all the work they do outside of work. Free labor!”

It seems like the industry as a whole is moving towards standardizing around such a double requirement in hiring, and I do not like that trend.

The industry isn't moving towards this. The IP agreements I signed at start-ups in 1994, 1998, 1999, and so on all had functionally identical terms. And more, like the duty to in good faith pursue patents whenever merited and assist IP attorneys with the creation of filings and sign over patent rights for nominal sums. [Edit formatting and typos.]

I wasn’t referring to the IP clauses when I said moving towards. I meant it in the context of employers glorifying passion and moving the baseline job requirements towards having projects outside of work.

First time I heard that companies hire employees for free.

This is not necessarily "give up". You still own the code that was written before you joined the company. If it is an open source project, your code contributions after you start work will still be open source. They will just be owned by the company, so the resulting code will have some code owned by you, and some code owned by the company. If this is a healthy open source project (such as, say, e2fsprogs), it already has some code owned by Red Hat, some code owned by SuSE, some code by IBM, etc. So the fact that there will be some code written by you, but actually owned by Google, is (everyone repeat after me) No Big Deal.

Now, it's different if your "side project" is under a proprietary license, and you hope to make $$$ some day. In that case, companies like IBM, Google, VA Linux Systems, which have a "all your IP belong to us" will be problematic for you. You can choose not to work for such a company, or you can choose to try to negotiate with the company.

But for a side project which is an open source project, in general there won't be a problem. Now, if said open source project directly competes with a proprietary product sold by that company --- you had better disclose it up front during the hiring negotiations, and have a negotiation about how it should be handled. The fact of the matter is, the company doesn't have a right to your services, and you don't have a right to a job at that company. You negotiate it, just like you negotiate cash salary and equity compensation. And if you can't come to a negotiated outcome that both sides are happy with, neither side is evil; they just couldn't come to an agreement.

> This is not necessarily "give up".

"Giving up" is an ambiguous term here and I should have tried to be more specific. But I wasn't just referring to ownership. If I'm working on a project, and joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant.

I'm unlikely to go back to a 3-4 year old project and pick it up again later. Most of those projects are dead.

> So the fact that there will be some code written by you, but actually owned by Google, is (everyone repeat after me) No Big Deal.

Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing."

People are so ready to say that terms like this are no big deal. If it really doesn't matter who owns the code that gets contributed to an Open Source project, then why is it important that Google own it? If Google isn't going to exploit that code in any way, then they shouldn't have a problem with their employees retaining ownership, right?

> Now, it's different if your "side project" is under a proprietary license

I think it's unrealistic and unreasonable to assume that every time an employee enriches themselves outside of work, they'll be doing it in relation to an Open Source project.

It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms. We can say this stuff is standard and it all comes down to individual choice, but we have pretty decent data that universally getting rid of noncompetes was good for the software industry. We have reasonably decent data that allowing employees to work on commercial side projects outside of work would similarly be good for the industry.

Labor laws just haven't caught up yet to that point.

> Neither side is evil; they just couldn't come to an agreement.

I do think that these policies are unethical, that they amount to a kind of attempted takeover of employee autonomy on a level that a business owner shouldn't even be trying to restrict.

However, that wasn't the argument I was making when I said this was absurd. I was just making the observation that most businesses don't have as much money as Google to throw at people or to offer them dream jobs. So most businesses who attempt this are giving up any chance of hiring the best developers, because on average the best developers won't tolerate those terms unless they come attached to Google money and a dream job.

Obviously, direct competition or conflicts of interest are another story, but nobody is debating them. It's a mistake to start from, "direct conflicts of interest should be avoided", and then immediately extrapolate from there to "a business should own everything that comes out of an employee, anywhere."

> "Giving up" is an ambiguous term here and I should have tried to be more specific. But I wasn't just referring to ownership. If I'm working on a project, and joining Google means I need to stop working on it for 3-4 years, then I've effectively given up that project, in the sense that it's no longer going to be maintained or stay relevant.

And what I'm saying is that for an open source project, in general that doesn't happen. And if you're not sure, you negotiate that up front. I did that when I started work for IBM, for example. And it was more than just copyright issues; it included stuff like, "look, I'm one of the chairs of the ipsec working group, and I'd like you to pay for me to travel to IETF meetings so I can finish out my commitment to IETF, even though that doesn't have that much to do with the IBM Linux Technology Center". Everything is negotiable; they might say no, but you'll never know until you ask.

More generally, I'm having trouble thinking of situations where you (a) can't take a side project and release it as open source, and (b) you're wanting to keep it proprietary except for "wanting to earn $$$ on a side project" while also drawing from a big company.

> Sure, unless your company is Oracle and they decide X years later to say, "actually we own the code and we didn't authorize it to be Open Sourced, and that means the entire project is infringing."

Nope, it doesn't work that way. Once code is released under an open source license, that can't do a "I take it back!" thing. So long as there is an explicit open source releasing policy, and you followed it, then you are an authorized agent of the company when you released changes (including git commits) whose copyright is owned by the company. I can use fancy legal terms like "latches" and "equitable defenses", but the principle is quite simple: "No backsies."

Oracle can say that no new code will be released for Open Solaris, but they can't change their mind on the Open Solaris code already released under an open source license. Again, programmers really should understand basic IP law. It's not that complicated....

> It's also ignores the fact that a nontrivial portion of Silicon Valley was built on top of people who didn't accept those terms.

Um, if it's in an employment contract, and you signed it without reading it --- sorry, but I have very little sympathy for you. If you signed it, you agreed to it.

> if it's in an employment contract, and you signed it without reading it --- sorry, but I have zero sympathy for you.

Arguing that employees should read their contracts, and arguing that the terms in those contracts aren't problematic, are two entirely separate things.

I agree with you on the first point, I disagree with you on the second.

> So long as there is an explicit open source releasing policy, and you followed it, then you are an authorized agent of the company when you release changes

This is the key part. If Oracle has a policy like Google's, and if Oracle decides to let you release that code, and if you follow the process correctly, then you're fine. In practice, this assumes a great deal. You're arguing that as long as a company

a) has an official Open Source release policy, and

b) agrees to let you use that policy,

then there's no problem. And, sure. As long as Oracle explicitly gives you permission to contribute code to Open Source projects, nothing bad will or can happen[0]. But that's a very different thing than arguing that it's fine for employers to retain complete control over

a) what that policy is, and

b) what projects are allowed under it.

It's like claiming that if no abuse happens, there's no problem. It's true, but doesn't mean anything. The issue is that under the terms Google proposes, there is nothing preventing abuse. You're entirely at Google's mercy over whether or not you can contribute to any project, proprietary or Open Source.

The issue is that when you sign those terms, you no longer have a guarantee that you can contribute to anything. And if you operate outside of whatever policy exists, you are opening yourself up to exactly the kind of abuse I describe. That's what I was trying to argue with Oracle: not that you'll have future problems if you follow an official policy, but that Open Source licenses are not enough to save you in the absence of an official policy, and that Open Source licenses are not enough to save you if you get rejected from that official policy.

> I'm saying is that for an open source project, in general that doesn't happen.

Except in the case of OP, where they were forced to find a separate maintainer for their project. You're not the only person to suggest here that this never happens, but... it did. You can argue that OP should have negotiated that up front before they took the job. I would tend to agree with you on that.

But outside of OP's own responsibility, is it good for anyone else, anywhere, that they were forced to abandon that project? Not, "what could they have done differently", not "do they bear any responsibility" -- is it good for the software industry as a whole that Google was able to do what it did?

I would argue no. I would argue the entire history of Silicon Valley says that allowing these kinds of terms is counterproductive to maintaining a healthy software industry, and that ideally labor laws in California would treat "we own everything" clauses the same way they treat noncompete agreements.

----

[0]: Except that you won't be able to re-license later, and you won't be able to contribute to projects that force you to assign copyright, and in the case of GPL software you write you'll be bound to the same GPL terms as every other user. But those are admittedly probably minor concerns for most projects.

It is worth re-asking the question though -- if code ownership doesn't matter for Open Source projects, why does Google want it? Why is it important for Google to own code contributions their employees make to Open Source projects?

My argument is that employees are responsible for reading the contract, and if the contract have terms that might be problematic for open source contribution, the employee is responsible for finding out ahead of time what the policy is. (For Google, the policy is publically available[1], so it can be read by people who aren't yet employees.) If the policy is not acceptable to you, then you shouldn't work for that company.

[1] https://opensource.google/docs/

And if the policy changes --- such as for example, when Oracle suddenly changed the rules about Open Solaris, the solution is simple. You quit. Large portions of the core Solaris team left, soon after Oracle changed the rules.

Bryan Cantrill left Oracle, and he's done fine for himself. He's even made talks explaining what happened when Oracle screwed over Open Solaris:

"As you know people, as you learn about things, you realize that these generalizations we have are, virtually to a generalization, false. Well, except for this one, as it turns out. What you think of Oracle, is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle. And I gotta say, as someone who has seen that complexity for my entire life, it's very hard to get used to that idea. It's like, 'surely this is more complicated!' but it's like: Wow, this is really simple! This company is very straightforward, in its defense. This company is about one man, his alter-ego, and what he wants to inflict upon humanity -- that's it! ...Ship mediocrity, inflict misery, lie our asses off, screw our customers, and make a whole shitload of money. Yeah... you talk to Oracle, it's like, 'no, we don't fucking make dreams happen -- we make money!' ...You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle." -- Bryan Cantrill https://www.youtube.com/watch?v=-zRN7XLCRhc

> It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time"

No, it's standard industry practice to claim ownership of everything a software engineer comes up to that relates to the company's business. It's certainly not standard practice to claim ownership of, like, a young-adult fiction novel you write on weekends.

The unusual thing here is that Google's business and potential business is approximately everything to do with computers.

> Also unique to Google is there is a process by which you can get permission for you to out-and-out own the work done on your own time, as opposed to Google owning it and releasing it under an open source license. If you take that option then it really has to be done on your own time, and must not use any company resources, meaning not on a company laptop, or on a company network, etc. This is rare, and I'm not aware of many other companies that give employees that option.

I think this is perfectly normal. I've never worked somewhere where it isn't true. (Also, isn't this basically required for the common Silicon Valley practice of "working on your side hustle while employed at your FAANG, and then getting investors later" to not be fraught with IP dangers?)

Thank you. "We own everything you do" is absolutely not standard practice, even in the US, and we shouldn't do Google's work for them by pretending it is. The linked Twitter thread says Google "tries to appropriate" everything you do, which is a very different claim.

I've seen "we own everything" asserted exactly once, in a laughably bad "Whartonite seeks code monkey" contract. Meanwhile, "you own unrelated work done on your own time, without company resources" is not at all unique to Google; it's been in every other IP ownership clause I've ever read. Many of them don't even require "a process by which you can get permission". They might require disclosure, or encourage you to talk to Legal if there's an appearance of overlap, but if you write thermostat software at work you can go make Flappy Bird at home without asking anyone for permission.

What's actually common, and what Google does, is claiming ownership of anything touching not only resources but the company's business. In the narrowest cases this is completely understandable: Mongo/10gen doesn't want employees to notice a Mongo pain point at work, then instead of mentioning it go home and build a product they know will have eager customers. And a bit more broadly, companies don't want their staff punching the clock, then going home and building a competitor with the experience they gained at work. But of course, companies have no real incentive to stop at what's reasonable: they'd like to own what you make, or capture all of your creative energy, so they commonly say "you can't make anything in our same industry". Amazon is infamous for attempting to claim "a connection with a cofounder" as a company resource and so claim anything made by ex-Amazon teams. (Which is only infamous because "we own everything" isn't common - if it were then Amazon's policy would look lenient.)

As you say, Google is doing the same thing, it's just that they do everything and they're just limiting ownership to the employee's scope of business. Maybe you work on Gmail, but Google owns Nest, so they can claim your smart home project. It's not a standard level of restriction, it's aggressive and probably unenforceable.

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

Is your argument really "it's no big deal cause everyone's doing it"?

He said it a bit different "it's no big deal not only because everyone else is doing it but also because the referred company is one that does it the less."

The added fluff at the end doesn't legitimize his stance for me. This seems to be a common belief in the US: "that because this is the way it is, this is the way it should be".

I can't wait for US citizens to fight back and get some real labor and pro consumer laws in place. It would only take a cursory look at what Europeans and Canadians have to realize that the US is setup for corporations to thrive, not people.

You can call it industry standard but it is blatant exploitation of workers and their rights. It is also breaking one of basic human rights, right to work, putting them into situation where they are slaves to the company.

Someone in EU should bring this to the EU court for human rights, I am sure they would win the case and stop this practice, at least for EU.

For my country this is completely unenforcable and every judge would just drop the case.

IT workers should form union. Seriously. We have huge power, a week of strike can bring a company down, or even internet. And based on such contracts, I wouldnt be surprised if joining union is also forbiden in states (can someone at google please check his contract?)

Maybe just a detail for USA workers, a brief explanation how some things work in some EU states, as an alternative to union, much softer one, but it has teeth (as an extreme, it can get CEO to a jail).

I am 8 years (elected, 2 mandates, around 1200 workers) in workers council (Germans might be well aware of this). This is a "political body" which as its basic description, has to work in favor of workers AND company (distinction between union - union will defend the worker even if company goes down - workers council tries to do what is best for company and worker, sometimes annoying but beneficial at most times for both - and there is always a baseball bat that it can transform to a union. The definition can make a lot of decisions hard, but at least it does take the company into account). And as most important, it can break owners decisions that are harmfull to the company.

The company has obligation to get a conformation from the workers council for important decisions, like selling the company. And we can break a deal (the CEO goes to jail case).

The confirmation also needs to be given for any larger lay off of employees. No we wont allow that for short boost of cash to satisfy management bonus conditions (HP).

It can also effect the decisions where it can affect workers contract changes. It can veto them.

Monthly reports about company financials. We are still bound to NDA, but we hava enough informations to decide.

Selling a company. We can veto.

There is hell of a lot more legislation behind this, buf I think it can solve a lot of issues that USA has.

(I have a hell of a lot to say to this, but I dont want to translate hunderds of pages of legaslation for nothing. Please DO ask.)

I'm afraid this doesn't have enough corporatocracy or dystopia, but thank you.

Actually in the NGINX case, the former company claims (or is trying to find proofs, such as timings of git commits) that Nginx has been developed on company's paid time. Even if the sysadmin was "on call" and coding Nginx on the side. I guess the Nginx lesson should be a wake up call for all of us who are developing FLOSS on the side.

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

Bullshit. I've never had to do that in 17 years as a software engineer (in the United States). Don't normalize this crap and make excuses for it.

Not only that, the bit about letting you "out-and-out own the work done on your own time... not [using] any company resources" is standard.

Most ownership clauses allow it, and many of them don't even require permission. They might require notice, or encourage you to check in with legal up front to preempt issues, but they don't require you to get approval for a project totally unrelated to your job. I'm not sure why people are claiming the situation is already so bad there's no point in caring.

I'm a googler, I've got side projects, most of them are open-source.

While I'd prefer not to think about all this and just code, I appreciate that there is an existing policy instead of a bad surprise in a few years.

The current policy, which is 100% public (https://opensource.google/docs/iarc/), is basically "let's assume that we own everything except what we don't, and let's figure things out before it's too late".

If you contribute to an existing open-source project on github, this is basically a non-issue and the answer to who owns the copyright has practically no effect. There are pre-approved licenses and a few banned licenses (agpl, wtfpl, public domain, etc), as well as pre-approved CLAs with major entities (Python, Mozilla, etc).

I think this matters in two cases:

1/ you want to start a new open-source project, you don't want google to have copyright because you think that a good open-source license will not protect you/your work from being stolen (!).

2/ you want to start a side project and maybe one day you'll turn that into a business, and you don't want to be Pied Piper vs Hooli.

Also a googler.

> because you think that a good open-source license will not protect you/your work from being stolen (!).

My reason for wanting to keep copyright is that I want to be allowed to work on my code under the same name after I leave the company. I'd happily trade away that option if I were being paid to work on it, but if it's my hobby, and if (in my view, if not IARC's) it isn't related to my work or Google's business, I won't.

I agree, but I think it's (mostly) not an issue. IIRC we're asked to use our corp email for contributions, unless we already have contributions under your own name/email address on the project.

I read this as:

* if you interacted with people on mailing list with your personal email address, it's OK to use your personal email address in the patches.

* if you are the maintainer of a project, use your own address (unless this is a google project, of course).

edit: don't get me wrong though, I don't like this clause, I just think it only matters in rare cases.

There's some open source projects Google won't let me contribute to because they don't like the project's CLA.

Is there a public list of these and do these projects know?

Their argument seems to be that "California law allows us to do it", and "it's protecting us from employees creating competing products".

The problem I see with that is

1) They don't have to do everything they're legally allowed to in a contract as long as they aren't breaking the law.

2) It's disingenuous to spin this as somehow protecting employees. They just want people to make use of their process so that they get to arbitrarily decide whether they own something or not. If employees were really interested in exercising their legal rights, they could ignore the IARC and work on it on their own time anyway, and if Google wanted to, they could try suing the employee to get the copyright transferred. In practice, that makes them look bad, so they have the IARC process instead, which makes it easier for them to pressure employees into assigning things to Google, even if it wouldn't stand up in court.

Pretty much every company I know does this:

> If you take that option then it really has to be done on your own time, and must not use any company resources, meaning not on a company laptop, or on a company network, etc. This is rare, and I'm not aware of many other companies that give employees that option.

It’s actually a California law that the company can’t own what you do on your own time with your own equipment.

Further, I’ve gone through this process with two employers. All I did was disclose what I was doing and they set limitations on MY EMPLOYMENT at their company. So they wouldn’t take the IP, just they may not continue to employ me. The limitation was simply that “I couldn’t willfully help competitors to the company” then they listed a few industries. This was true for two fortune 100 companies I worked for.

> It’s actually a California law that the company can’t own what you do on your own time with your own equipment.

This comes up a lot here and is only half true. California law does not protect IP that is similar to what the company does or may do: https://news.ycombinator.com/item?id=21754139

Others have already commented on how this isn't "standard" in places outside the US, so I'll focus on something else.

Ted, you're a Big Deal. You maintain ext4, you're a major kernel contributor. Of course Google is going to keep you happy, give you plenty of time to work on FOSS, and provide you with resources for it. They are paying you to work on FOSS to a large extent. The deal is they give you all this time and resources, and you slap a Google copyright on it and don't care because it's all GPLed anyway, and since you're working on this stuff at work anyway, you throw everything into the same bucket and Google owns whatever commits you make at home too.

This is entirely different from the average Google SWE/SRE, who may have a number of personal projects, and may contribute to random things, but nothing Google cares about much. Google doesn't give a damn if I stop contributing to FOSS. As an SRE, none of my work product at Google had anything to do with FOSS directly (except, like, one 20% project where I ported Linux to some vendor hardware). Google doesn't care if they force me to stop maintaining usbmuxd, which they effectively did by rejecting my IARC application (without answering my questions after it; e.g. they could've proposed going through releasing and Google copyright from then on, but they also didn't do that).

For someone like me, going through all those processes, especially in the form they existed in back when I worked there >5 years ago, was all red tape for zero benefit. Google wasn't sponsoring any of my work. Google doesn't care if I have a commit in ALSA to fix 5.1 audio on a specific Acer laptop. Google doesn't care that I made FireWire not blow up on JMicron controllers on systems with an enabled IOMMU. Google doesn't care that Pulseaudio network discovery now works properly with link-local addresses. Google wasn't paying me to do any of those things. They are just things I did in my own time, as a FOSS user, not as a Google employee. And so, it is not reasonable for Google to own that work, that I do on my own time, that has nothing to do with my job, and to then require me to go through getting permission, and to then slap a Google copyright on all my code. Copyright assignment isn't free. I had to relicense a project from GPL to LGPL recently. It was a simple matter of asking the other 2 one-off contributors and changing the license. It would not have been a simple matter if Google had owned part of the code, which they would've had they not messed up my employment contract in my favor.

Yes, other companies are worse (Apple). That doesn't mean Google gets a pass for being less-bad. It's still broken.

marcan_42, I will have been at Google for 10 years in January, and even back then the Open Source policies were part of the Noogler training, and the fact that Google would own everything you did, even on your own time, was clearly in the stated in the employement document, as well as a place for you list everything that you had worked on before you started work at Google and so was your Intellectual Property (IP).

Google's open source policies is now fully public (as of a few years ago), and I can affirm that they haven't changed substantially in the last ten years. It's all here[1], including the statement releasing code as open source under the Google copyright was very clearly documented in the IARC process[2]:

[1] https://opensource.google/docs/

[2] https://opensource.google/docs/iarc/

So I have trouble taking your complaint that "Google didn't tell me that I had an alternative" seriously. Also, from your description, a huge portion of your contributions that you listed were in the Linux and associated projects (such as Pulse Audio). So all of this would have required one, or perhaps two, requests to release OSS patches; once you have done that for one or two contributions, it's no longer necessary to ask permission for subsequent patches to a OSS project. (This is true for all Googlers.) Asking for permission to release those under GPL is trivial, and is granted as a matter of course. Lots of other Googlers have done it, without problem, and most have not complained the OSS releasing process is heavyweight. IARC is more heavyweight, yes, but it's right there in the IARC process documentation that the OSS releasing process is the preferred option, and that it is lightweight.

Before I started working at VA Linux Systems or at IBM, I had taken the class, "Law for an I/T Manager" at the MIT Sloan School. So I was very well aware of IP law issues (patents, copyright, and trade secrets), and how to read contracts, including employment contracts. So none of this took my surprise (either at VA Linux Systems or at IBM, both of which had similar provisions in the employment contract); perhaps you didn't bother to take the time to read the employment contract and perhaps you didn't bother to read the very clear web pages at Google's Open Source Program Office. I can't speak to what you experienced at your Noogler training, so it's unclear whether you weren't paying attention, or it's since been streamlined. But if you found the IARC documentation so you could submitted the IARC request, you should have found rest, and this shouldn't have been a surprise to you.

> most have not complained the OSS releasing process is heavyweight

Citation needed. I have been at Google for 6 years and I have seen many people either 1. quit in frustration at our OSS policy; 2. stop contributing to OSS projects on their free time because of frustration with our policy; 3. just ignore the OSS policy at the risk of getting fired because the precedent is that most people ignore the policy. Most people I talk with do (3), nobody will admit to it publicly though.

I'm right now waiting for an IARC approval for a small HTML+Typescript that took me 6h to build on a weekend and that I want to MIT-license. This has now been pending for 2 weeks. This is completely ridiculous and it means there is just no reasonable way for someone to follow the policy while doing small side projects on the weekend. Going through the releasing process would have taken roughly the same time, except that Google would also probably not be interested in owning that code for multiple reasons.

> I'm right now waiting for an IARC approval for a small HTML+Typescript that took me 6h

Why do you want IARC and not patching approval for that? Unless your intent is to make money from it in the future, there's really no need to engage in the IARC process.

Patching approval is painless, and the easiest process for something that you want to be considered to exist outside of Google (its owned by you in your personal capacity, but google maintains copyright to your while-employed-by-google contributions), and doesn't require IARC or any approval other than a quick self-approval process for the first few commits. Then it requires nothing.

For example, because I don't want people to have to sign a CLA to contribute patches to my weekend side projects? That's incredibly dev hostile.

Unless it's changed recently, projects released under patching (again, not releasing) don't require a signed cla (edit: just checked and they don't). They're not Google owned, Google just maintains ownership of your contributions.

And if you look at the releasing guidelines, they only make sense for code developed in google3 and later released. You can't actually follow the releasing process for code developed on non-google hardware, your only option is to follow the patching or iarc methods, and patching is trivially easy and doesn't require anyone to sign a cla.

It's not that Google didn't tell me I had an alternative (I knew about the patching process), it's that they ignored my email asking for further info entirely. I wanted clarification on what it means to be a maintainer of an open source project, to then join Google, and to be rejected for IARC.

There was no place for me to list prior projects I had worked on before joining Google. I've heard about this from one other person. It must vary depending on where you joined Google, because I never heard about any such process through my contract/onboarding in Ireland. All I had was the IARC and patching documentation. I was told to go through IARC for existing projects.

In fact, most of my OSS contributions are to random projects. I only listed the PA one because it was the one that got me in trouble, and the two kernel ones because you'd be familiar with that area (in fact those two didn't even happen during my employment with Google). My OSS contributions are completely random. It's rare that I contribute to the same project more than once or twice, with a few exceptions, outside of personal projects and a few things I may be more invested in, or stuff so fundamental and large like the kernel where over the years I end up finding reasons to send a patch multiple times (and even then to completely unrelated subsystems).

What ends up happening 99% of the time is that I use some open source software as a user, I find a bug, I fix it and send a patch. Chances are small I'll ever contribute to that project again. I just happen to enjoy making small contributions. Often those contributions involve high effort but small amounts of code - both inside and outside of Google, I'm somewhat notorious for figuring out issues that nobody else can, even if the resulting patch is one line of code. I've fixed a problem in the Golang runtime that was breaking Google prod even after leaving Google; that bug had been open for half a year. I've fixed an Inkscape bug that was open for many years. This is what I do - little things in random projects that may not be much code, but I'm sure are very appreciated by people affected by the bugs.

And so, with this kind of development, the old process of "get an approval for every project" was completely unsustainable. I work in bursts. I'll spend an evening finding and fixing a bug that has eluded the project developers for months, then I'll move on to the next thing. The last thing I need is to have to go through a multi day approval request after that to be able to send the patch. It completely kills any motivation to do this kind of stuff. And so this is how you wind up with Googlers ceasing to contribute to open source when they join Google.

That's very US industry centered practice. As such, it spread worldwide.

In France at least, negotiation is always open in your employment contract for specific permissions for personal work and open source contributions. I always mentionned that in interviews that went far enough, it also works as a good test.

> It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time"

I've seen this a lot. I've also seen a lot of people saying that it's fair to use github commits as a means of selecting software engineers to employ. What I've not seen is how these two are supposed to co-exist.

Because it's standard industry practice, that's OK then ? Argumentum ad populum.

You struck a good deal because of your ext4 maintainership and unique resume ? That's survivorship bias.

There's old, sarcastic, saying in my language for that: we should all eat shit, after all billions of flies can't be wrong!

French?

Polish

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

Not in my big tech company. You have to disclose any side work you do only if it is similar to the work you do. Not if it is similar to anything the company does. And they're not overly broad (so my doing SW doesn't mean I have to report all SW side work).

As someone else said, let's not normalize this crap.

> It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

That doesn't make it acceptable. I've never signed a contract with such clause nor will I.

When I was freelancing one of my clients tried to get me to sign a contract with a clause like this. It would have killed my business since I worked on multiple projects at once. In their case it was an oversight in using a form contract and they changed it.

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

I have not yet worked at a job where this was the case, and I would decline an offer to do so. It is unusual here, but I know of a friend who signed such a contract for a video game studio, but then only for games specifically and not IT in general.

Mostly thanks to unions there are plenty of options not to work for these leeches.

> The problem is it's extremely difficult to say, figure out when someone might have invented some super clever idea which can be pantented "on their own time".

On the other hand it's extremely difficult to say that the innovations I contribute to my employer are conceived exclusively during paid hours.

> So anyone who think this is some evidence of Google being, or becoming, evil is either seriously misinformed, or just engaging in unthinking hate of Google, or both.

Without even addressing the conclusion you can surely see how this reasoning is faulty. If all evil things that were ever considered common practice were excused for only that reason, we'd probably live in a pretty shitty world.

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

If you make a kid (on your own time, with your own equipment, and not in their office), should it also by their property?

Since pregnancy is part of "making" a baby and the uterus works 24/7, Google actually has a stronger case for ownership of its female employees' children than for their intellectual creations.

This type of commentary only serves to move the progressive goalpost closer towards the conservative (imho also the regressive side) of the debate.

Yes everyone does it. But is that ok? To suggest so, is to suggest there is no better alternative. This thinking ultimate leads to it's predicted outcome, not because of any sort of prescience, but out of the lack of will to use the available light to find a better way out.

As others have said, this is nowhere near the standard outside of the US. Personally, I consider this "industry standard" pretty gross and touching on some very uncomfortable topics like wage slavery. Your employer should not own your ideas and it should not matter where you got them.

A no-compete clause is the much more reasonable solution a company can use to protect itself from flagrant violations of trust.

> A no-compete clause is the much more reasonable solution a company can use to protect itself from flagrant violations of trust.

Non-competes are illegal in California

I'm astonished that I came to this thread and the top comment was a lengthy defense of Google. This behavior is absolutely unacceptable. "Standard industry practice" my ass. This is literally the "if your friends all jumped off of a bridge" argument. It's not okay for Google, and it's not okay for everyone else. Many wrongs don't make a right. I shouldn't need your permission to be creative on my own time. Employees do not exist to give their lives in service of your giant capitalist machine. Employers have zero claim to any IP generated in the employee's own time using the employee's own resources - end of story.

Im sorry but this is an absolutely terrible argument, no company should be allowed to do this, period.

If anything this shows google continuing to move to "evil" by moving towards an already established terrible practice. It is absolutely absurd its allowed in the first place, and its absurd you take it. I don't mean to be a dick, but your position on this kind of makes you look entitled. No way my employer is ever getting any of my work done on my time, and just because you have allowed this to happen to yourself for so long does not mean it should happen to others, or that is an acceptable business practice.

>It's standard industry practice for companies to claim ownership of everything a software engineer comes up with

Well, because it's standard industry practice, I guess you're not allowed to complain about it.

Your whole argument is that it's the norm, while this article advocates for changing the norm.

> This is rare, and I'm not aware of many other companies that give employees that option.

I’ve never worked for a tech company who doesn’t allow that and my list of former employers includes many household names that virtually anyone would immediately recognize.

It's common for large corporations, but I've been able to negotiate it being removed in all cases but one (it was an acquihire by large corpo and I quit over that after golden handcuffs expired).

Don't accept it as standard or it will really become it.

are you google pr? because this post is full of misinformation. shopify, microsoft, and a myriad of other tech companies ive worked for have no such clause. google's policy in this regard is terrible. im upset about it because its a pretty basic and valuable thing to be able to participate in your own activities, code or otherwise.

disclaimer: this post reflects my own personal views and not those of my employer.

He's not exactly Google PR, he's a high-ranking Linux maintainer. But, as OP responded in a sibling comment, it's in Google's interest to make him able to keep doing that work - that's essentially why they hired him. He's okay with Google owning the copyright to the OSS he works on, as long as it gets contributed, and that's aligned with Google's interests. He's also been at Google for almost a decade, and if Google is in any way competent, he has no incentive to be looking for other jobs (and reading their employment agreements).

I agree with you that in fact most other tech companies make it pretty easy to own the copyright on work you do on your own time.

I think it makes sense that Google wants to control what employees do in the time they pay them for. "Using company laptops" is kinda stretching it (I mean, I could buy a separate laptop just for open-source patches, especially if I'm paid Google salary, but isn't that really a ridiculous pettiness? Marginal cost of it to Google is exactly zero). But claiming you own somebody's free time and everything they do in their free time, just because they pay the person a salary is beyond ridiculous. I can get why people put up with it - those sweet Google salaries again - but it doesn't stop being beyond ridiculous. It's like I'd claim if I hire a lawyer now I get to be a beneficiary of every lawsuit they ever file, or if I buy a book the writer now owes me royalties on every book they write from now on. It just mind-boggling that one has to get some kind of "permission" to own the products of one's own brain and hands because they get salary from Google, and that people expect Google to be praised for letting some people to use their own brain.

It did not use to be standard industry practice.

Now even every bodyshop and IT Contracting outfit has language in their agreements that claim ownership.

It is a claim that they own the information contained in one’s brain

There are many things that are "standard industry practice" that will be illegal some day, and using some other company as a defense for anything is supremely lazy.

I recently joined Google and have a general purpose Apache-licensed Java library which I submitted and was rejected for overlap. This seemed fair since they also have similar projects (e.g. Guava) even though I don't work on them (or even write Java there). I can still contribute to the project and will be able to use that code forever since it is also Apache, I just won't hold copyright and therefore wouldn't be able to relicense it without their permission, but that's not a concern of mine so I've been happily hacking away on it.

I also submitted a new side project, which obtained copyright release quickly (couple days) and without any additional qualifications, which was nice as I could then proceed freely with it.

Overall I'm pretty happy with the process and thought it and the rules around it were fair.

I have either gotten that clause struck from my contract, ensured it is limited to direct competition or turned down the position. People really not need to take it for granted, we are in a hot hot hot tech market we have options and that affords leverage. Use it.

This is not standard practice in Seattle. Not unheard of, but not standard.

There are places you can work outside of the Valley.

This is a disgusting policy - basically the company OWNS you if you do anything meaningful. Complete defeats the idea of "freedom" and takes away the already pitiful chances of normal people "making it". Ib4 people pretend not having a job is a valid option. This isn't Google specific, but it's one of the few things that genuinely upsets me. Hell, more than the death of net neutrality.

It's not standard practice and I would never agree to it. It's standard practice to claim ownership of things done at work or for the job itself.

> The problem is it's extremely difficult to say, figure out when someone might have invented some super clever idea which can be pantented "on their own time".

That depends. If the employee's project is in an area that is completely different from what Google is doing, then it should be clear that there is no conflict. At least the wording in the contract should reflect that possibility.

If that is the case, Google has a process for explicitly relinquishing their claim on copyright to the creator.

The intent of this policy is to make it clear that creators have to go through that process if they want to use something they fabricated as a side project independently.

That seems backwards. If you think something I have is yours, it's up to you to prove it.

That's the purpose of the blanket ownership claim.

I tried going through that process, and they rejected one of my projects (with no followup or explanation, and without replying to my questions). That's the story I told in the OP Twitter thread. That's when I realized the process was broken.

That's highly unusual. I believe you, but it's definitely a weird breakdown in the process.

It'd have been easier, given you were working on it before you joined the company, to claim it on the carve-out document that described the blanket copyright policy. That's what I did for my projects and it was never contested.

(And to be clear, I find the experience you had completely unacceptable. If I'd had the experience you had when I was working there, it would have made me significantly reevaluate whether I wanted to keep working there).

>So anyone who think this is some evidence of Google being, or becoming, evil is either seriously misinformed, or just engaging in unthinking hate of Google, or both.

Just because an evil practice was already well adopted does not change that increased adoption of that practice by an entity can reasonably be taken as a sign of that entity's evil quotient increasing.

>Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time".

Whatever something is "standard industry practice" and whatever its outrageous and should be stopped and called for what it is, is orthogonal.

This does seem to be an industry standard practice when it comes to employment contracts. However, you are well within your rights to scrub this out before you commit to signing the contract. I've scrubbed this clause out of every contract. My intellectual thoughts that are outside and unrelated to this project are mine and mine alone. No employer in my mind has the right to that.

Why do software developers accept this? It's the only profession i've heard of things like this happening. I've never had an employer even think that anything I make or do in my own time is their business, even when i've used materials or equipment from work. The idea that an employer has any rights to anything I do they aren't paying me for is mind boggling.

> Oh, please. It's standard industry practice for companies to claim ownership of everything a software engineer comes up with, even "on their own time". ... So anyone who think this is some evidence of Google being, or becoming, evil is either seriously misinformed, or just engaging in unthinking hate of Google, or both.

The fact that every other US company is as evil does not make Google any better. The practice is evil, thus Google is evil.

The US got some economic leeway from California and a few other states banishing that exact practice. If they start to backtrack on that, you can expect the entire country to suffer on a couple of decades.

Has Google or any other company actually used this for "evil" though? It sounds like it's just a necessary part of doing business in the US. Don't hate the player. Hate the game. I'm not a lawyer, but I'm sure rules like these make it easier to sue someone if they steal your source code like with Levandowski.

At their size, Google get to dictate the rules of the game. And it's very convenient for them if employees can't have portfolios that make them easier to poach, and can't start side businesses and so on.

Don't expect the public to support IP protection if their only experience is having it used against them.

> Has Google or any other company actually used this for "evil" though?

From the original Twitter thread:

> usbmuxd was rejected without an explanation. My follow-up email asking for clarification was ignored.

> I ended up having to hand over maintainership of usbmuxd.

Different people have different thresholds for evil, but I consider that to be at least unethical. OP was working on usbmuxd before they joined Google. If Google wanted ownership, that should have been discussed during the hiring process. To hire someone, require them to submit a 'request' to retain ownership, and then pull the rug out from under their feet -- I think that's unethical, even if usbmuxd was a conflict of interest.

But of course, OP wasn't working on anything that would make usbmuxd a conflict of interest. Google's policy was, "because someone somewhere in our company is working on something similar, we own it." I think that's also an unethical overreach. If I'm hired to work on A, I don't think I should need to care that someone else at the company is working on B. My conflicts of interest and related software should be determined based on the parts of the software I'm involved in.

I would posit that this stuff isn't a theoretical concern, that OP demonstrated its an unethical policy that is actively being used for unethical reasons.

I mean. You can just always ignore what lawyers say, and just work on open source projects under a pseudonym while you're employed there, which is what the OP did anyways. The worst thing that happened to the OP is that he pissed off some lawyers, and got into an argument with a guy. Also, Google can't own any of your code you did before you're employed there, just any new code from when you're employed by them.

> The worst thing that happened to the OP is that he pissed off some lawyers, and got into an argument with a guy

The worst thing that happened to OP was that he lost control of his project.

> I ended up having to hand over maintainership of usbmuxd.

----

> You can just always ignore what lawyers say, and just work on open source projects under a pseudonym while you're employed there

I am not a lawyer, but this seems like very bad advice. Even ignoring the potential legal risks, many Open Source maintainers like to be able to talk openly about their projects using their real names, especially at conferences, to friends, and to future potential employers.

Even ignoring that, some side projects aren't Open Source. I'm working on commercial, proprietary software outside of work. My company knows it. Even if I wanted to keep it a secret from them, there's no real good way I could do so -- at a certain point, most commercial software gets linked to real people. You're taking on a lot of extra risk that could potentially turn into a nightmare during a discovery process later.

> I am not a lawyer, but this seems like very bad advice.

That's kind of my point. Millions of people have been employed by companies with similar policies, and undoubtably many of them chose to ignore the "correct" legal moves because it's just easier. If Google really wanted to screw people over, they could, but that doesn't seem to be happening.

> If Google really wanted to screw people over, they could, but that doesn't seem to be happening.

But again

> I ended up having to hand over maintainership of usbmuxd.

What's your personal criteria for getting screwed over? From my perspective, it already happened with OP.

I mean like take ownership of a project or start up based on a technicality. Taking someone's app money would be another one. I don't think that making someone else maintain your project is unreasonable, especially if that someone can be a mysterious anon that comes in at the right time.

The "maintainerr" is the "owner" in this context.

I actually didn't piss off the lawyers; the lawyer working under cdibona was a nice guy, and his contributions to the email thread reasonable. cdibona alone flamed me, and then personally banned me from the process.

I hear he's not in charge of that department any more. Maybe that's why the policy is less onerous now.

I see. I appreciate the clarification!

In the original Twitter thread, Google stole ownership of a pre-existing side project when the maintainer filed for approval. That's evil. It may not have been a personal evil, but bureaucratic evil is very real.

Do you have the text of where he says this? It sounds like it's just the work that you do while you're employed there. Even then, it seems like it's just a formality that they don't really bother enforcing.

Why is it a necessary part of doing business in the US? What is different about the US compared to countries where this practice is unheard of?

Right, every company in an entire country is evil. You don't sound horribly biased at all

I thought California had explicit laws about employee rights in this matter?

"standard industry practice" is a gross cop-out for a lot of really, really vile behavior.

California law gives everyone that second option as I understand it.

Depends on where you live - it's not normal.

Reply on news.ycombinator.com