The Danger of Remotely Managed (i.e. cloud-based) Software

Today you can buy a lot of software on a subscription, cloud basis scheme.

Of course, from the software-house point of view there are no issues.  But from the users’ perspective the fact that cloud, subscription-based business models are widely enforced by the market, and that its supporters claim this to be an advantage for the users doesn’t turn a bad management choice into a good one.

In the last months I had to handle  cases of companies literally “ransomized” by the software houses who first developed specific application with the help of the company itself, and then claimed a full-ownership on the result, sold back on a “as-a-service, cloud based” business model.

The element common to those cases was that when a controversy arose, the first thing the software house did was to block the access to the “service” thus forcing the company to negotiate from a very weak position. As you may guess, another (typical) element of these cases is that no lawyer has been involved in the early stages of the software development negotiation, thus leaving the companies in an uncomfortable position.

This is actually nothing new in the grand scheme of  things. The history of software litigation is full of  logic bombs hidden everywhere, from industrial machinery to simple applications, to be exploited in case of (alleged) licensee’s misbehaviour. But what makes me uncomfortable with the “cloud variable” is that in this case a company doesn’t have an actual possibility to carry on its business while handling the litigation.

Ideally, a properly-managed software license agreement would include provisions regulating the source code access and/or escrow, the clear attribution of software authorship, a safeguard mechanism to avoid that the original developer becomes – de facto – a stakeholder of the company by being the sole and only authorized to provide services based on his (alleged) software ownership or, furthermore, the ban of every behaviour that might block or limit the company operation. These are just a few things that might help to de-escalate a controversy and find an amicable settlement instead of take the issue in court or suffering other kind of damages.

You can’t always get such kind of safeguards, especially when negotiating with the US giants, but there are a lot of cases where the software house is not part of the Big League and thus amendments to its standard, Cloud-EULA addressing the specifics of granting the access to service even in case of controversy  could and ought be obtained.


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.