ONE partner did it, I don't think the others knew his motivation. Hence it being unethical.

You have a lousy legal team. Are they heavily invested in MS btw? I in fact worked for a start up where the partner in charge of tech bought only MS because he had stock in the company. Very unethical.

First off, given the fact that NSA created then cracked RSA type encryption about ten years before it was invented by RSA, all encryption should be considered cracked. I propose we make the next few months a "call a [Muslim | member of WAR | Tea partier | Socialist Workers Party | Wobbly | Other fringe group member] month]. Use a bogus code like:
Alice: The swallows fly over Tehran
Bob: Paris has many sparrows in the sky
Alice: The sky over Paris is glowing in the spring.
Bob: Springfield is a city in America.
Alice: In Springfield Homer prepares his couch.

etc.

Pump so much noise into the system as to make it useless.

Too simple, make it look like a conversation

During the Vietnam war there was an officer once asked, "Why was the village destroyed?" His answer was, "We had to destroy it in order to save it." Please read some history.

It doesn't matter. The principle was violated so PJ's was forced to cough up some crappy pizza.

We had to destroy the Constitution in order to save it. And I don't mean the 2nd amendment. I mean the entire bill of rights as well as the separation of powers.

Yeah I wonder how many budget hawks mindlessly throw money at anything even vaguely associated with National "Security".

Now you are in the position of stripping the victims of their rights. If it hadn't been for the lawyers "blowing the whistle" on the corporations the individual would not get anything and the corporation would get away scott free. You are in fact flying in the face of conventional economics, where the negative consequences of the actions of a corporation is costly. If there were no cost involved then moral hazard would rear it's ugly head. Stop slamming the lawyers, they did not cause the problem. It was the companies who hosed the consumers who caused the problem.

I'm with you on distributed agile. It can be argued that due to the inherent impedance between agile; based on small tight knit teams and constant communications; and the demands of far flung distributed teams that agile does not work at the larger scale.

A standup isn't about excruciating detail. Daily is good as if your meeting is on Monday, which often is a day someone is out, and you are blocked on Wed. the Monday meeting is obsolete. Daily is better as it is closer to real time. If you have nothing to say, say it. But do listen for anything that raises a flag.

From your slashdot id, use of language, and over reliance on the wisdom of others I would say you are new to the game. You need to experience more projects before you can pass judgement.

1) If you are downstream from me you better care what I have done, because eventually it get merged into the build. And just because it builds properly and passes unit tests does not mean it is correct.
2) Ditto for what is happening today. You better know what is going on so you can be agile and adjust.
3) Nothing is more effective than face-to-face communications. There is research supporting this.
4) Ummm... no you fix the problem ASAP. But if you are blocked you bring it up in the next standup so you can get help and anyone affected by your problem can be agile and adjust.

You are a poster child for how crappy software gets developed.

Or perhaps it began in an environment with project types, programmer types, manager types, and problem domains it is good at Now as it goes farther and farther into new areas, where it may be unsuitable, and used by those who are not as well versed in the technique or whose personalities may not mesh well with it limitations are appearing.

False analogy. Designing and creating a car is much easier to manage as a "waterfall" since it is so much harder to change and the problem domain is often in less "flux". The sheer energy and expense to design a car; which consists of market research, basic R&D e.g. engine and tire materials, the design of the car, the design of the factory, the design and construction of the manufacturing equipment, the training of workers, etc., is so huge that upfront design makes sense.

In software the problem domain is often in flux, e.g. financial reporting regulations, and the cost of changes in software are lower. So software must be soft or lose relevance AND the fact that it is soft creates the danger of too many changes. We cannot think of software as no different than a factory, that is the original sin of software development.