The Dieselgate Crisis Management: Played by the Book

The way Volkswagen is handling the Dieselgate is a very good example of proper crisis management and seems coming from a crisis management handbook (such as “Master of disaster“): once discovered, the company neither denied the facts nor tried to hide it, announced an independent review, fired the culprits, called-in a new, serious manager started cooperating with the authorities, saved the money for the inevitable fines and damages.

This way Volkswagen has been able to keep the public outcry under control because no collateral damages – such as deep burying evidences, threatening or bribing involved people, further doctoring information etc. – have been suffered, thus helping the company recover its image – and customer base – faster.

Volkswagen’s Dieselgate and The Danger of Closed Source Intellectual Property

The not uncommon practice in the ICT/Mobile business of “doctoring”products to look good on benchmarks has find its way into the automotive (and God knows into how many others) business.

Volkswagen, though, isn’t the only to blame because, true, they cheated, but no public supervising authority  ever glimpsed at the software ran by its vehicles, only focusing on “hardware” tests. And – I guess – even if the controllers would have thought of examining the software, they would have been prevented to do so by “the need of protecting Intellectual Property” that – as the “National Security Excuse” – is a buzzphrase to stop any further investigation on controversial matters.

Volkswagen’s Dieselgate shows once more that (a certain way to think of) Intellectual Property – as well of Privacy – has neatly changed its role from being a tool to protect legitimate interests into a shield for wrongdoings.

Were the Volkswagen software released under an open source licensing model, the fear of being exposed would have forced the company to play by the book and would have allowed a true and thorough check by the competent authorities, avoiding a major damage for the industry, investors, employees and citizens.


Hacking Team: A Class Action Against Adobe?

After the Hacking Team scandal, everybody and his cousin is calling for a “death sentence” against Adobe Flash, accused of being the “vessel” that allowed Hacking Team’s malware to land on users’ PC and smartphones.

A logical consequence of this  vulnerability and its exploiting by several malwares, including those made by Hacking Team, would be a class-action against Adobe that, as a matter of fact, released a “bugged-by-design” application.

But this is not going to happens against Adobe, as against the other (big or small) fishes of the software pond. We are much too “programmed” to accept a software fault as an act of God instead of either a mistake or a deliberate marketing choice.

Will things change after the Hacking Team scandal? I don’t think so, thus get ready for the next viral infection, information theft or denial of service: is just business as usual.

Giuffrè Editore (Lexis-Nexis partner)’s Update Disturbing Policy

consolleLexis-Nexis Italian partner, Giuffrè Editore, is active in both the editorial and software business. One of its tool is a java application to handle the electronic document filing to the Court’s dock.

As the screenshot shows, the OSX version of this software requires on outdated java version because Giuffrè didn’t update its code. As they write on the website: “last java versions have problem. Download from here the recommended version”.

In other words: we don’t want to fix the software you paid, so stay stick with an older java version.

So  a lawyer wanting to continue using this software faces these alternatives:

  • downgrade the Java version installed on his computer, thus risking incompatibilities with up-to-date application and having his computer possible stability issues,
  • buy a computer (or virtualize one) “just” to use Giuffrè softwares,
  • move to another software and start using it for scratch.

Whatever the option, the customer is the losing part.

Does SHA-7 belong to the US NSA?

As everybody knows, the SHA-n is a series of cryptographic algorithm developed by the NSA and published by the US NIST. The current SHA-n lineup includes SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512.

On the contrary, SHA-7 (see this link – italian only, sorry), a “proprietary, patented encryption algorythm” developed by an Italian company doesn’t belong to the original “family”. And doesn’t have any endorsement by the scientific community.

I wonder why SHA-7 designers have choses this confusing name for their code.



Software-Based Claims Attack Strategies

Under Italian laws, hiring a software-house to produce an industrial application may expose a non-IT savvy company to civil and criminal action filed by the software-house itself and/or by the other software-house that has been called to replace the one the initially did the job. This is the consequence of a lazy attitude towards a properly written agreement and a deep ignorance of the intricacies of the software development’s world.

Here is a fairly usual scenario: a tiles manufacturer needs a software to control the temperature of the ovens used to finally release the products. It asks a software house to write the application, securing in the agreement that “all the intellectual/industrial property belongs to the company”. By doing this the company feels on the safe side and believes to be shielded by no matter what problem.


The agreement didn’t clarify the exact way the IP must be transferred, so the software-house delivers the software on a LICENSING basis and not as a full-ownership transfer. Once the agreement has been signed, the company doesn’t read the following papers at all and thus, de facto, the agreement has been amended (possibly) unbeknownst to the company’s legal department.

Let’s say, now, that the business relationship with the software house breaks and the company finds another partner, giving him access to the source code made by the previous developer. The company sees no problem in doing so since believes to “own” the software so the new developer just start working on the code.


The company failed to identify the code given by the original developer (for instance, by adding disclaimers or comments both in the source and the executable version) thus infringing the moral IP rights that, under Italian Copyright Act belong to the author and cannot be sold or otherwise transferred.

So the software’s author steps in claiming that the company has violated his rights because allowed a third party to access and use a LICENSED code. And when the company tries to blame the new developer he counter the move by accusing the company of infringement of the Criminal Corporate Liability Act (Legislative Decree 231/2001) because of the lack of prior identification of the supplied source code as being authored by a third party.

Lesson learned: under Italian Laws a proper software development agreement should at least contains:

– a precise identification of the source code that has been released, with a duty, on the software-house side, to mark and duly comment the software,

– a clear statement about the IP ownership transfer to the company,

– a clear exclusion of any further change or amendment including the impossibility of turning the agreement from a full-transfer into a license,

– a clear provision that, whatever the legal status of the software, the company is entitled to be given the source-code,

– a clear clause that grants the company, whatever the legal status of the software, the right to allow third parties to access and modify the source code.

Furthermore, since such kind of agreements – once signed – rarely come back on the legal department desks, it is fundamental to train the technical and financial department involved in the further steps, to carefully scrutinize papers and communications so to avoid any “mudding” of the original stipulation.

A final note: when a third party is hired to work on the software, it should be made it clear that the software, while owned by the company, still bears the original author’s moral right, with all the legal consequences.


Aperture’s EOL And The Consequence Of Livining in a Golden Cage

Apple discretely manage software lifecycles to push users into buying new, its new, expensive hardware.

A recent news is that is going to dump Aperture, its photo management pro app, announcing in the meantime the availability of a “photo” application in the next iteration of OSX. True, Apple shall not drop the support for the new OS versions, but for how long? This uncertainty  will force people to either stay stuck to older machines or move to Adobe Lightroom, the (currently only) competitor. In either case this will cause financial and time issues for Aperture’s user-base.

Aperture is nothing but the last Apple-made software to meet this  or a similar fate. Final Cut Pro X latest version, so Pages, Numbers and Keynote, just to name a few, only work with the current OSX version, Maverick.

True, compared to the consequences of Microsoft XP dismissal, the Apple choice looks a trivial issue but on the long term it shouldn’t, since managing the lifecycle of its applications as well as the backward compatibility, Apple is able to force its users into buying new expensive hardware. Furthermore, for those who choose not to upgrade, the software old-versions might not be anymore permanently available through the AppStore and cannot be locally downloaded. So why a professional user should enter into this uncertain – or, on the contrary, safe-but-costly, world?

This is the consequence of living in a Golden Cage: stay comfortable as soon as you can afford it. And when (“when”, not “if”) you don’t anymore, just get lost and give room to the next, wealthy-at-the-moment, occupier of your place in the Golden Cage.

Stop Apple and Google To Take Over Our Cars

Google just announced its “Android Auto” platform, while Apple already did  it with Carplay. Both platforms require an Internet connection and, it is just matter of time, will become more and more deeply interconnected with the car control system.

But software do fail. It fails because there’s no such thing as a bug-free software, it fails because people do mistakes, it fails because the software house’s roadmap not necessarily matches the final users’ safety.

And I don’t care about the usual PR stunts such as “as soon as we discovered the bug we did our best to fix it the fastest way” or “since the xyz library is licensed and proprietary we can’t keep responsibility for the way the software behave” or, finally, “if you just read the EULA you will find that it is clearly stated that we don’t take any responsibility for blah, blah, blah…”

This is a price we cannot afford to pay.

The XP’s EOL. History Will Teach Us Nothing

Windows XP is dead in Redmond, but alive and kicking in a huge quantity of devices such  ATMs. When the news hit the media, waves of “concerns” for the security of our money and safety stormed the public, with no actual effect on the Microsoft’s strategies. And history keeps repeating with domotics, wearable technologies and in-car systems.

This aftermath was easy to foresee when some “clever” IT manager chose to go proprietary when moving its ATM infrastructure “to the next step”, but between this and the open source alternative a third option would have spare us all the current trouble: just put into the agreement a source-code escrow provision, to guarantee the (big) client against the End-of-Life of the software.

Sure, this wouldn’t have been a cheap solutions (we’re not talking about a bunch of PHP code, here) but there are no free beers and easy life can’t last forever. If you go proprietary and enjoy the safety(?) of having somebody else who cares about bugs, patches and updates, you need to have a contingency plan for the moment when your licensor plugs-off the cord that keeps alive the software you’re using.

And now history is re-repeating itself. We’re on the edge of a new invasion of pervasive technology based on Apple’s OSX or – again – Microsoft Windows Whatever, and in a bunch of years we will complain again that because of a copyright issue we can’t enter our home, use the fridge, watch the television, start the car, know what’s the time, have a medical diagnosis and so on…

A final, collateral, question: where do the corporate lawyers were, when those agreement have been signed?