> But for someone in the field for a decade or more, they very likely only do programming at work.

Not if you work extensively with open source or free software. Many of us have long term relationships with several projects, and profoundly enjoy helping the new users out of difficult messes. Teaching is an invaluable skill in senior technical people. If you _don't_ have a few projects you are involved with for historical or personal interest, I'm personally much less interested in hiring or working with you.

If the first position is a "temp->perm" or other contract situation, then it's a much more understandable switch. But for a permanent position, it's awkward if it shows up on your resume. Like divorcing someone on your honeymoon, it can happen especially when a partner is abusive. But if the first employer invested the time, money, and resources to hire you, you've actually _wasted_ a lot of their resources pulling this kind of trick. And it will hurt your reputation, and anger that company against Google. And for larger software companies, they may actually have contracts to prevent "poaching" of employees, so this trick should only be pulled with serous thought and legal review.

> The GPL can easily be abused in this way, as can all the alternatives.

Please do re-read the licenses yourself. The GPL has been much more careful about the consequences of its claims, and more recently about patents, than the other licenses. GPL learned the lessons about casually written, or "vendor friendly" software licenses that allow encumbering of commercial or patent licenses _on top of_ the the originally free or open source software. Such encumbering occurs today: take a deep look at the various firewall appliances and storage appliances that are BSD based, and just try to get source code for their components. GPL has been very helpful to get access to that software, and has been much more robust for work I do.

I have colleagues and friends who've gone through Google hiring in the last 2 years. I've seen excellent personnel whom I've recommended not get the interview for 3 months, finally be interviewed because it turned out they were still looking to upgrade their position, and finally given job offers _over one month_ after the interview. Every single one of them found another role in the meantime, including promotions in their old company as new budgets were made to include a new position for them. The people who are still available after such a lengthy process are those who've effectively paid aa quite large Google hiring tax, of either weeks unemployed or of months at a lower salary.. While Google pays well, they don't pay well enough for people to pay such a task on the mere _hope_ of getting the Google role.

I've also seen some excellent personnel rejected because they applied for a specific role, which had requirements not in the job description and for which they were not made an offer. They were then unable to apply their existing interview results for roles which better suited their skills and which were not published as available when they applied to Google. They had to start over from the beginning. Coupled with the long hiring time for Google, and these personnel were long gone by the time they were made an offer or even interviewed for the second role.

Because your build environment may be subtly different than mine., or the build environment on which the software was first generated and tested. And this can seriously break the software.

The presence, or absence, of optional compilation components makes a large change in software features. A very small change in one system library, or compiler environment, added to allow one component to build, may break other live components in ways the original author of either component never envisioned. And if I patch that source for my local build environment, how can I publish those patches for others with similar environments? The complexity of building this, and maintaining this, is one of the serious failures of "just build everything from scratch" approaches. It's exacerbated by carelessly written installers that simply overwrite, or dynamically modify, critical system files such as cron or inittab.

This is also an old discussion: developers who can build tools locally, and quickly, often want to use them instead of packaged or managed tools that are more likely to be correctly and securely installed, and less likely to save people's passwords in plain text.

This is debatable. Booting from a CD is really booting from a floppy image written on the CD, so the feature is still in use worldwide for installers and for livd CD or live DVD environments.

Few modern kernels and boot environments fit on a single 1.44 Megabyte floppy image anymore.

Please go and review the actual licenses. "Ideas" is a very vague standard for what can, or cannot, be copied, and the history of copyright has many competing decisions on what copying is of "ideas", which are not copyrightable, and what is of "content", which is copyrightable. The idea that the GPL somehow locks down ideas where Apache or the variety of BSD licenses do not is not well founded, because copyright does not cover "ideas". To lock down "ideas", you need something much more comprehensive like an End User License Agreement or an actual contract.

A key difference between GPL and BSD licenses are the _patent_ rules. GPLv3 covers _patents_ very carefully, and for sound historical reasons. The "TIVO" set topo bax used GPL code, but locked it down with patents so customers could duplicate the very "ideas" you mention, even if they were allowed to read the modified code under the GPL. Patents were used to lock down the box and make it difficult, even dangerous, to duplicate or modify.

The various BSD rules _do not cover patents_. Thus, you are far more in danger of being in intellectual property violation, and at the risk of patent troll lawsuits, by using BSD licenses. The Apache license is even worse, by the way. If you sue anyone over their patent abuse, _even if you're suing them for fraudulently claimin gyour patent is theirs_, you lose your license to use all patents in that particular code. It's a dangerous license.

Find the person who wrote the code. Make sure that educating you or your colleagues is part of their paid responsibilities, and make sure that you respect their work when reviewing it: this helps them share the ir work and take it well if you need to revise things. My colleagues and I often bring new features or help stabilize old projects, and a working relationship with the original author is invaluable.

And ff the author says "just read the code, I don't do documentation because documentation can lie", or if they say "don't bother checking the data for correctness, just don't make mistakes", be ready to throw out _everything_ they ever wrote. It may work at the moment, but it's likely to be as broken and unsustainable as their attitudes.

> if he wanted all those restrictions, he'd have specified them.

Or may not have known better. It certainly happens that people forget to do that extra step, so making that protection set by default could be very helpful to people new to open source or free software.

Only if you can see the code. Why do you assume that they've published their code as open source when they copied it and violated the GPLv3 or other patent licenses?

The problem is that if you, as a programmer, sue anyone for patent infringement for your licensed work, even if they're in clear violation of _your_ and the Apache patent licensing, you are now in violation of the upstream Apache patent licenses and lose the right to use those patents. This eliminates your ability, as an Apache v2.0 user, to see a big corporation for violating your patents, _even if they are repackaging your patented material as theirs and fraudulently suing others_, without losing patent licenses for the upstream Apache patents.

While I've not seen anyone actually encounter this, this is the consequence of a poorly thought out license agreement. It's the kind of subtle risk the GPLv3 does _not_ create.

The GPLv3 includes effective patent protection for developers and users of free software. I've reviewed other open source and free licenses, and GPLv3 has the best patent protection.

The Apache 2.0 patent license has some very odd patent consequences. If you sue anyone for patent violations on the basis of Apache 2.0 licensed work, you lose your patent license from the day you file the lawsuit. This is apparently true even if your lawsuit is to force them to honor the Apache 2.0 copyright for the patented materials.

_This_ is an excellent idea. I'd prefer GPLv3, myself, for maximum programmer protection.

From personal experience: patent law is international, as is a great deal of copyright law, and by ignoring licenses you leave yourself and any compuany you work for open to patent trolls for expensive lawsuits. I've had to defend my work against copyright trolls, and was very glad I'd left a clean paper trail of the licenses I worked with. It's why I strongly prefer open source software: because the source is open, so are the changes and usually the records of who contributed what.

There's plenty of good material at Wikipedia about international copyright and patent law. Start there to investigate how your reuse of other people's software, without permission or in violation of upstream licenses and patents which you never bothered to examine, can put your finances and your work at serious legal risk. It will also get your software blocked from any significant Linux or open source software distribution.

You've my complete sympathy: my colleagues and I have been in just that situation

Find the incompetent manager a new job somewhere else, where _they_ will be happier, and look for personnel who will improve the department's and company's effectiveness. That's often someone in-house, or a different team than is currently there. And unless you've established really well that the manager is not only ineffective due to outside reasons, but incompetent in general, don't bother calling them incompetent. If you can, be open with them. If not, be prepared to leave at high speed when your task is complete, because you won't want to be responsible for the political mess when a new manager costs more for jobs that used to be estimated as costing much less.

Letting the old manager out with some of their pride intact lets them clean up documentation and political messes on their way out, rather than jolting everyone with a complete turnover in dead rush. And the manager may be much more competent in a more detailed, more procedural, or even in a less detailed and more goal oriented environment. Mismatches happen all the time: my colleagues and I often get to clean up after things break down, so it can be educational to be part of the clean up.