Which humanities? Music? Languages? History? Writing? Theology? Politics? Economics? Business? Given the amount of material that is being taught by rote and memorization in many humanities courses, it's not clear that "doubt" is a fundamental aspect of humanities. But doubt, and _testing_ are certainly core to good science courses. So is measurement and checking your work for engineering. And part of the very core of modern physics is the Heisenberg Indeterminacy principle: the fact that doing the measurement _itself_ changes the state of what you're measure. How much more doubt could you desire?
There are many reasons to study many fields in college: Too small a focus means you're vulnerable to tremendous errors from lack of knowledge of the other fields:, or even awareness of when consultation is needed. For example, learning to write well helps tremendously with _publishing_ your science or engineering work, and it's visibly lacking for many less skilled engineers I know.
> It's simple. Having your own website allows you maximum control. And it's not complicated.
It is complicated if you want backup, high availability, security audits, account management, protection from Distributed Denial of Service attacks, a stable deployment environment, etc. "Shared hosting" is not what I would refer to as "setting up your own website". I'd refer to "setting up your own website" as doing so from scratch, as so many of my developer acquaintances insist is so trivial to do.
The post you responded to directly said, and I'm quoting:
> For the last round of hiring my company did, it was strongly suggested that any applicants open a Github account so they can use it to save the code they wrote for our evaluation. Having a Github account can give software-oriented people a chance to publish any projects they've written, akin to a portfolio for graphics design artists.
What seems to have confused you is that it is not a visual portfolio: it's for source code. If your raw source code does not look good on review, and you hide this with a pretty and cleverly designed web site, then you should apply for jobs as a web designer, not a systems person or a software developer.
Some of us can can our own vegetables, brew our own beer, and weave our own cloth. Some of us can even build our own computers from chips, or write in various assembler languages. That doesn't mean we should spend our professional or social time doing so and shouldn't use well-built shortcuts.
> 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.
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.
Swartz was an entirely different case. If Aaron merely wanted to publish JSTOR material publicly, he should have done it from his own office at Harvard, where he had legal access. Aaron's death is not the problem of a "police state", it's the problem of a mentally fragile person pulling tricks that interfere with thousands of other people's studies, research, and livelihood, and being unable to tolerate the stress of facing a felony trial.
I don't suggest that our modern security groups are not willing to abuse their power. I'm suggesting they're not as abusive, pervasive, or powerful, _yet_. While the modern US security groups have asked for neighbors to report on each other, they've not gotten the cooperation that the Stasi got nor become as widespread, and they don't have a watchdog in every apartment building (as the Stasi had at one point). And the US press has not been as vigilant as I'd like, but some of them _have_ been publishing abuses.
Preventing such abuse is important. Write: expose real power abuses: write software tools that protect people's privacy and personnel documents. (Phil Zimmerman, author of PGP, deserved a Nobel Prize.) Whistleblow if you have to. I'm glad I've not had to: the abuses I've seen and and had to protest were much smaller scale, and I was able to work around them.
> Back on topic, is there really that much difference between 21st Century DHS/ICE/TSA, FBI, CIA, NSA, Border Patrol, and the Gestapo/Stasi/Abwehr
In this case, I think you've managed to avoid invoking "Godwin's Law" about all converations eventually turning into labeling people as Nazis. You've raised a relevant question. We have the equivalent of concentration camps (in Guantanamo Bay, and the kind of abusive prison exposed at Abu Ghraib). The secret police are operating without oversight against an ill-defined political threat with no one nation or base, a threat that may live among native citizens ("terrorists" now versus "the Jews"). And they're collecting extraordinary amounts of personal information without court approval or informing those monitored.
The primary differences are of scale, and of use of the information. So far, we've seen little sign that the NSA or CIA are directly involving themselves in day to day politics. And they've simply not been as pervasive in getting neighbors to report on each other, or blackmailing people to do so. It's not even reached the levels of the McCarthy era anti-Communist scare, though not for lack of trying on the part of people who believe their nation, or organization, is the important thing to defend rather than the citizens of that nation or the ideals of that nation. Nor has it reached the Hoover era corruption at the top, or at least it's not been exposed as being so corrupt.
I and my colleagues prefer to do this, especially because we prefer open source code. It's often not feasible: on my current project the company wants all its code kept in-house, and even with a GPL copyright on the original work there is no obligation to publish it.
Simply putting up a copyright, and a name of the current maintainer, _corporate employee_ who is responsible for maintaining the software, is not a large offense where I work. If you did not sign it at all, it could even be unsurprising that a newer developer would do so, to provide a contact point for users of the software, especially if hte copyright is a corporate copyright and not a personal one. They may even think they modified it enough to deserve a new copyright (which can be very easy to do), even if some of the best core components are essentially unchanged.
So there seems no need to start out heavy handed. Also, you're showing off in your interview that was done as a work for hire? Did you get permission from your former employer to display or share that work? Then you may be violating _their_ copyrights. So be safe: contact them, especially your old manager if you can find them, and ask for permission to show your old work, and see if you can cite them as a reference for doing that work.
If the new developer is actually plagiarizing your work and re-copyrighting it for themselves personally, your old employer is the one being hurt by this. Then you may need to show some traceable source control or software backups to enforce the claim. And you may be able to get cooperation from supervisors or HR at your old workplace. It could be awfully hard to sue for damages in a situation like this,, especially if you don't have good evidence. But someone who is plagiarizing your work will probably plagiarize other work, and a good manager will appreciate a heads up from the original author. This has happened to me and my colleagues before, and will again. It may be too late for you to follow good source code control practices, but those can be invaluable not only to locate who write the code, but who _broke_ the code later.
If you've got your evidence lined up, you might even be able to contact this developer directly and give them the opportunity to fix the situation. If they can provide a letter that says "this work was originally developed for Company A by _fill in your name_, and we're delighted with its performance.", I think you'd be in very good shape for the questions you w4ere asked.
Have you ever tried to buy one _voting_ share? Those tend to be far more expensive, and far m ore tightly held than non-voting stock. That's why being "paid in shares" is so rarely paid in voting shares, except for senior management.
There is nothing archaic about the regulations. The employee and stockholder meetings often have newsworthy information which the attendees are prohibited, by contract or by regulation, from announcing before an actual company purchase occurs or before the planned announcement. A few minutes of advance notice about a company like Google purchasing another company, or about a critical staff member resigning, can allow very profitable stock sales and purchases.
Of course, I'm normally on call for several critical corporate functions. So unless they want to take the risk of any major problem leaving them offline, I need my contact tools. But I'm discreet enough to have a simple pager for such situations, because I've encountered other security situations where transmitters are forbidden but they've permitted me a receiver for professional use.
Graybar has some nice external wiring boxes, very suitable for locking down external connections. I've often recommended similar boxes, the outdoor electrical outlet boxes with covers, for use in small data centers. It helps protect electrical outlets of critical equipment plugged into the wall from being accidentally tripped over or casually unplugged.
Slashdot Mirror
Which humanities? Music? Languages? History? Writing? Theology? Politics? Economics? Business? Given the amount of material that is being taught by rote and memorization in many humanities courses, it's not clear that "doubt" is a fundamental aspect of humanities. But doubt, and _testing_ are certainly core to good science courses. So is measurement and checking your work for engineering. And part of the very core of modern physics is the Heisenberg Indeterminacy principle: the fact that doing the measurement _itself_ changes the state of what you're measure. How much more doubt could you desire?
There are many reasons to study many fields in college: Too small a focus means you're vulnerable to tremendous errors from lack of knowledge of the other fields:, or even awareness of when consultation is needed. For example, learning to write well helps tremendously with _publishing_ your science or engineering work, and it's visibly lacking for many less skilled engineers I know.
> It's simple. Having your own website allows you maximum control. And it's not complicated.
It is complicated if you want backup, high availability, security audits, account management, protection from Distributed Denial of Service attacks, a stable deployment environment, etc. "Shared hosting" is not what I would refer to as "setting up your own website". I'd refer to "setting up your own website" as doing so from scratch, as so many of my developer acquaintances insist is so trivial to do.
The post you responded to directly said, and I'm quoting:
> For the last round of hiring my company did, it was strongly suggested that any applicants open a Github account so they can use it to save the code they wrote for our evaluation. Having a Github account can give software-oriented people a chance to publish any projects they've written, akin to a portfolio for graphics design artists.
What seems to have confused you is that it is not a visual portfolio: it's for source code. If your raw source code does not look good on review, and you hide this with a pretty and cleverly designed web site, then you should apply for jobs as a web designer, not a systems person or a software developer.
Some of us can can our own vegetables, brew our own beer, and weave our own cloth. Some of us can even build our own computers from chips, or write in various assembler languages. That doesn't mean we should spend our professional or social time doing so and shouldn't use well-built shortcuts.
> 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.
Swartz was an entirely different case. If Aaron merely wanted to publish JSTOR material publicly, he should have done it from his own office at Harvard, where he had legal access. Aaron's death is not the problem of a "police state", it's the problem of a mentally fragile person pulling tricks that interfere with thousands of other people's studies, research, and livelihood, and being unable to tolerate the stress of facing a felony trial.
I don't suggest that our modern security groups are not willing to abuse their power. I'm suggesting they're not as abusive, pervasive, or powerful, _yet_. While the modern US security groups have asked for neighbors to report on each other, they've not gotten the cooperation that the Stasi got nor become as widespread, and they don't have a watchdog in every apartment building (as the Stasi had at one point). And the US press has not been as vigilant as I'd like, but some of them _have_ been publishing abuses.
Preventing such abuse is important. Write: expose real power abuses: write software tools that protect people's privacy and personnel documents. (Phil Zimmerman, author of PGP, deserved a Nobel Prize.) Whistleblow if you have to. I'm glad I've not had to: the abuses I've seen and and had to protest were much smaller scale, and I was able to work around them.
> Back on topic, is there really that much difference between 21st Century DHS/ICE/TSA, FBI, CIA, NSA, Border Patrol, and the Gestapo/Stasi/Abwehr
In this case, I think you've managed to avoid invoking "Godwin's Law" about all converations eventually turning into labeling people as Nazis. You've raised a relevant question. We have the equivalent of concentration camps (in Guantanamo Bay, and the kind of abusive prison exposed at Abu Ghraib). The secret police are operating without oversight against an ill-defined political threat with no one nation or base, a threat that may live among native citizens ("terrorists" now versus "the Jews"). And they're collecting extraordinary amounts of personal information without court approval or informing those monitored.
The primary differences are of scale, and of use of the information. So far, we've seen little sign that the NSA or CIA are directly involving themselves in day to day politics. And they've simply not been as pervasive in getting neighbors to report on each other, or blackmailing people to do so. It's not even reached the levels of the McCarthy era anti-Communist scare, though not for lack of trying on the part of people who believe their nation, or organization, is the important thing to defend rather than the citizens of that nation or the ideals of that nation. Nor has it reached the Hoover era corruption at the top, or at least it's not been exposed as being so corrupt.
I and my colleagues prefer to do this, especially because we prefer open source code. It's often not feasible: on my current project the company wants all its code kept in-house, and even with a GPL copyright on the original work there is no obligation to publish it.
Simply putting up a copyright, and a name of the current maintainer, _corporate employee_ who is responsible for maintaining the software, is not a large offense where I work. If you did not sign it at all, it could even be unsurprising that a newer developer would do so, to provide a contact point for users of the software, especially if hte copyright is a corporate copyright and not a personal one. They may even think they modified it enough to deserve a new copyright (which can be very easy to do), even if some of the best core components are essentially unchanged.
So there seems no need to start out heavy handed. Also, you're showing off in your interview that was done as a work for hire? Did you get permission from your former employer to display or share that work? Then you may be violating _their_ copyrights. So be safe: contact them, especially your old manager if you can find them, and ask for permission to show your old work, and see if you can cite them as a reference for doing that work.
If the new developer is actually plagiarizing your work and re-copyrighting it for themselves personally, your old employer is the one being hurt by this. Then you may need to show some traceable source control or software backups to enforce the claim. And you may be able to get cooperation from supervisors or HR at your old workplace. It could be awfully hard to sue for damages in a situation like this,, especially if you don't have good evidence. But someone who is plagiarizing your work will probably plagiarize other work, and a good manager will appreciate a heads up from the original author. This has happened to me and my colleagues before, and will again. It may be too late for you to follow good source code control practices, but those can be invaluable not only to locate who write the code, but who _broke_ the code later.
If you've got your evidence lined up, you might even be able to contact this developer directly and give them the opportunity to fix the situation. If they can provide a letter that says "this work was originally developed for Company A by _fill in your name_, and we're delighted with its performance.", I think you'd be in very good shape for the questions you w4ere asked.
Have you ever tried to buy one _voting_ share? Those tend to be far more expensive, and far m ore tightly held than non-voting stock. That's why being "paid in shares" is so rarely paid in voting shares, except for senior management.
There is nothing archaic about the regulations. The employee and stockholder meetings often have newsworthy information which the attendees are prohibited, by contract or by regulation, from announcing before an actual company purchase occurs or before the planned announcement. A few minutes of advance notice about a company like Google purchasing another company, or about a critical staff member resigning, can allow very profitable stock sales and purchases.
Of course, I'm normally on call for several critical corporate functions. So unless they want to take the risk of any major problem leaving them offline, I need my contact tools. But I'm discreet enough to have a simple pager for such situations, because I've encountered other security situations where transmitters are forbidden but they've permitted me a receiver for professional use.
Graybar has some nice external wiring boxes, very suitable for locking down external connections. I've often recommended similar boxes, the outdoor electrical outlet boxes with covers, for use in small data centers. It helps protect electrical outlets of critical equipment plugged into the wall from being accidentally tripped over or casually unplugged.