> 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?