You're confusing two concepts: "different" and "innovative", or in legal terms, "new" and "nonobvious". Something can be new, but obvious - and similarly, something can be different, but not innovative. As I've said and as you admit, both of the features we're discussing are not shown in the prior art reference - they are different, period, full stop. Whether they're innovative is a separate question, and nothing about that is implied by admitting that, yes, the video shows three frames of movement, while the patent claims "continuous" movement.

So, yes, the patent claim is different from the video. The claim has at least those two features that are not shown in the video. But I'm sure you can find them elsewhere in other prior art references, no? If so, you can use the combination of the two references to show that everything recited in the patent claim is known. That's the legal process - you can't simply pound the table and say "clearly obvious", because without using prior art references, at best, all you've done is shown that it's obvious now to someone who has lived with iPhones sliding-to-unlock for years. Show me that it was obvious in 2006. And that requires evidence, not just you saying that it's "clear".

Well, he's using the only sales argument he has from the customer's point of view. From the store's point of view though they won't sell it at the same price you get online because they need to pay for location, staff, deal with shoplifters and books that go stale and unsold that need to be taken off the shelves again. It's better for them not to take your business rather than open up Pandora's box and have people coming in expecting to be price matched, taking up sales rep time and getting angry if they're refused. And if word got around you could get it cheaper just by pointing to a webpage on a smartphone, other people buying it at normal markup could feel cheated and generate a lot of negative publicity about you. As sales pitches go it's a honest one, but it's not the real reason why they won't price match.

Well that's maybe relevant for those coming from another European language or reading old English texts, but to users only interested in contemporary English that's more of a historical curiosity. Their challenge is that the rules aren't consistent, which is often traceable to its historic roots. For example let's take the word steak, it's a loanword from Old Norse steik which is why the "ea" in steak is different from that in peak, leak, beak, weak or freak. Of course every language has a few foreign words that don't follow the normal rules but English has it dialed up to 11.

It's a photo/video camera that might have been on, not even stupid crooks would leave that potential evidence behind.

English keeps the pronunciation of the language they took it from, which means it's a smattering of Britons (~Welsh, -450), Anglo-Saxons ("English", 450-1066), Normans (~French, 1066-), Gaelic (~Scottish, ~Irish) with some Norse from Scandinavia, and through the British Empire it's picked up words from most of the world's languages by now. While "English" has pronunciation rules, unless you're a professor of etymology (the history of words) it's easier to just learn each word than trying to find a pattern.

Or in banking terminology, GNOME is too big to fail. Sorry, ever since Qt went LGPL in 2009 I've wished they'd go away so you can actually build a modular desktop, but as long as there's two competing languages it's almost impossible to build common components without going to awkward workarounds like D-Bus. Not even the kernel would work well with kernel modules written in C++, Java and Python, not that there's anything wrong with them as languages but as modules to a C program. Otherwise I expect the in-fighting will continue until Google pulls an Android and leaves GNOME, KDE, XFCE etc. to be a Nokia N900 niche in the desktop market. Not because it's technically the best solution, but because Google has a certain Steve Jobs effect too - if they tell everyone desktop Android is the next big thing devices, developers/applications and users will follow.

With all due respect, that's not only not slander, and you'd lose any such suit, you'd also make yourself permanently unemployable - no company would ever touch you with a ten foot.

Not if, as you acknowledge, you are unable to complete the services for which you were paid. While you may think that you weren't hired to make bug-free software, the employer - and any jury - would disagree.

Although it would be a good idea, it'll never happen... at least not until get you get Engineer Unions who refuse to work unless a company implements those clauses and prevent any scabs from working. And with the libertarian bent of most Engineers, that will never happen. Otherwise, you'll simply have the engineer refuse to sign the company's boilerplate employment agreement because it doesn't include an indemnity clause; and the company will show him the door and bring in the next candidate who will sign it.

Not necessarily, depending on what was said. Slander requires that the statement be false. Did the engineer screw up? If so, then it's not slander. The only way it would be is if the engineer did nothing other than follow explicit instructions from his superiors, and considering that he apparently made a change without changing a part number, that would seem unlikely.
Also, there's no such things as "intentional negligence" - that's an oxymoron, and would mean that you intended to do something by accident. What you may be thinking of is gross recklessness.

There's a gloss here - these are Professional Engineers, with certifications, licensing, and ethical requirements. PEs are also responsible for the things they sign off on, and may be held professionally accountable for their screw-ups. Now, that said, yes, the company is the one who is civilly liable for any damages from their products and no customer can sue the engineer directly, but that doesn't mean that (a) the company can't sue the engineer if they really were reckless; and (b) the company can't even name the engineer.

Well, first of all since OpenSSL is an open source project, I doubt staying anonymous was an option as you can go back and check git logs and mailing lists.

So the takeaway here is that OpenSSL has a review process that lets "quite trivial" bugs in the input validation of a high security product through, that's comforting

If you were a spy agency trying to get a vulnerability into OpenSSL, do you think it'd be on the first patch? Fix some insignificant bugs, get trusted, introduce seemingly innocent but deeply flawed code and trust that it gets rubber stamped through. He the first of three authors on the Heartbeat extension which for some reason includes an arbitrary size, arbitrary content data block where a simple PING/PONG would confirm the connection is still alive. I'm not saying he is a plant, but I am saying that everything he says is exactly the same as a plant would say to excuse his backdoor as a honest mistake. I mean, could you do it any better if you tried? Create a side channel by passing large chunks of data back and forth between the client and server, then create a flaw to pass the state buffer instead. It smells to high heaven.

If you have a natural owner that's just providing access to it I'd agree, references (or constant references) are great but in this case I'd disagree. If it's for example an application form the form itself is ephemeral, but the information in is not. If you submit it, I want the form to pass the information by value and self-destruct cleaning up after itself. Once it reaches some kind of data owner, it can pass the application by reference through processing steps. For the same reason references are not so good for display, for example you have a function to display an invoice. If some other process on the back-end deletes the invoice, you suddenly have a reference to nowhere and it could crash as you try getting more details or see the next page. In short, don't pass a reference unless you know the source will live longer than the reference.