You can get new post notifications through RSS, email, Twitter or Facebook
Open sources licenses still not understood (by Hiscox, at least)
Insurance company Hiscox has posted a misleading article on “the advantages and risks of open source software” in its “small business knowledge centre”. It is not clear who the article is aimed at, the explanations of legal issues are unclear, and the discussion of security issues irrelevant. They could have saved themselves from looking foolish if they had asked some with some technical knowledge and familiarity with the licences to review the article.The first problem is that it appears to be aimed at people making the decision about whether or not to write proprietary software on an open source platform, or creating a proprietary fork (separately developed version) of existing open source software. However it explains:
Source code is the text commands that tell a software program what to do. Whereas software from the likes of Microsoft contains secret source code that is developed and maintained by the company’s own programmers, in open source code software the lines of code are open for every programmer to view, use, modify and improve.
All perfectly correct, but if a developer, or even a manager, of a small software business does not know what source code it, they have a serious problem.
It then goes on, quite correctly, to explain that open source software is covered by copyright, and license terms must be followed, but its explanation of the terms and the legal consequences is rather poor:
They stipulate that any software created from, or even containing, lines of their open source code must be made publicly available to all other developers.
This, in practice, means one of the GPL licences. This misleading as the criterion is not that the software “contains” lines of code. The commonest version of it is that:
any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof
This can included works that link to GPL libraries (although not if the library uses the LGPL variant), or that is for some reason a derived work (as defined by copyright law). That said, proprietary equivalents also have licences, that can be even more complex.
There are, at a conservative estimate, around 70 licences governing the use of open source code
True, but only a handful are widely used: versions two and three of the GPL license and its LGPL variant, the Apache license, the MIT and BSD licenses (which are very similar), and, perhaps, the Mozilla Public License.
It is also misleading about the legal consequences of a breach:
you may be forced to make freely available the software that you’ve slaved over. Although the licences may not actually preclude you from trying to sell that software also, if users know they can get it for free then they have much less incentive to buy it from you.
Not true, because you have other options. You have to stop distributing the software or open the source code or get a license for use in a proprietary application. You may have to pay damages for breach of copyright, but this rarely happens. If you can sell your software as web app (installed on your own servers) the GPL does not restrict your sales at all (because you are not distributing it outside your own organisation) unless it uses the fairly rare Affero GPL variant. You may be able to negotiate a commercial license from the copyright holder to use the open source code in your proprietary app (some open source developers base their business model on this).
The article then goes on to cover “virus problems”, but the author does not seem to know what a virus is. He refer to ” the recent Shellshock and Heartbleed viruses”. Neither Heartbleed nor Shellshock were viruses: they were vulnerabilities (holes that could be used to infect a system with a virus, among other ways of attacking a system).
If a bug in your software introduces a virus into your client’s systems then you’ll not only face acute professional embarrassment, but also a potential negligence lawsuit.
The first problem with this, is that it could happen with a proprietary library or platform as well. Unless you write everything from scratch, using no external libraries (which is usually impossible) whatever third part software may have security issues. Going by track records, using open source will reduce this risk.
The other problem is that the risk of a negligence lawsuit is tiny. Heart-bleed affected most of the world’s secure web servers (i.e. any page with an address starting “https” and showing that lock icon in web browser). It affected banking sites, and other things people depend on. There were similar bugs found in other major encryption libraries, both proprietary and open source (Apple’s, Microsoft’s, and Mozilla’s). How many lawsuits resulted? The only one I am aware of was against the NSA who knew about the problem but failed to warn people, not against any software developer.
If there was a significant risk of being held responsible for security vulnerabilities, the software business would be very different, and several (if not most!) of the big software companies would have been sued into oblivion years ago. I am not suggesting that this would be a good thing, as strict security review for everything would make software development too expensive.
Similarly with Shell Shock, except that it is a less widespread thread. The ways I can think of it happening are an insecure server configuration (which can happen with proprietary software) together with user data passed to a newly started process (probably a CGI script started with Bash), or through failure to sanitize user input, or writing a CGI script in Bash (why would anyone do that?).
The useful information in this article can be summarised as “if you use open source libraries or code, check the licences, and, in particular, make sure you comply with GPL terms on distribution and Apache terms on patents”. That, and a link to the GPL FAQ would tell most people what they need to know.
Comments disabled
Sorry, comments are closed
Feed