Tech Disputes Webinar - Software Disputes transcript

DW: Well good morning and welcome to our webinar on Software Disputes. My name is David Wilkinson, I head the IP practice at Ashurst London and I am going to be chairing this morning's session.

We know that almost all industries are effected by digitalisation in one way or another and the Covid pandemic has only accelerated that trend. The thing which underlies and enables digitalisation is computer software, without that there would be no artificial intelligence, there would be no machine learning and there would be no logging on from home to join a webinar.

So software is now business critical, that's no exaggeration and the IT budgets of many companies have increased exponentially as a result. Inevitably that means the disputes around software are also likely to increase. So today we are going to be focussing on four issues relevant to software disputes.

First of all how does the law of copyright protect software and how is copyright infringed. Secondly, what contractual protections can be built into software licences to try and help avoid disputes. Thirdly, what's involved in a software licence audit from both the licensor and the licensee's perspective and finally what are the risks around open source software and how can those risks be managed.

Helping us to answer those questions today we have a number of panellists who are all extremely familiar with the legal and commercial issues surrounding software.

From the Ashurst Digital Economy Team we have partner David Futter. David specialises in tech transactions, especially in the field of FinTech and he has led deals from banks, processors, card schemes, tax vendors, merchants and retailers and many others.

Then from Ashurst IP Team we have Counsel Don McCombie. Don handles all aspects of IP both contentious and transactional and he's got a great deal of experience of disputes involving copyright infringement and misuse of confidential information relating to software and then we are delighted to be joined by Akshay Bajag from FTI Consulting. Akshay is a senior director at FTI and he is responsible for software licence forensics and software asset management in both Europe and the U.S. He specialises in the software licence compliance, software asset management, IP infringement and IT transformation and security engagements. Over the last 15 years Akshay has managed and led several thousand software licence compliance engagements globally for several major software publishers.

So welcome to our panellist and thanks for taking the time to participate. Before we kick off I would just like to mention that we do welcome questions from the audience so please feel free to send these in using the chat function and we will deal with as many of the questions as time permits.

So, Don, starting with you, we have all heard of copyright but some of us may not be absolutely sure what it is and how it works so my first question is how do you go about obtaining copyright protection for your software?

DM: Thanks David. Well the short answer is you obtain it very easily. So just by writing a line of code and saving it, unless it's completely trivial you have created a copyright work. There are a lot of myths around copyright ownership so one is that you need to put your work in a sealed envelope and post it to yourself in order to obtain copyright. That old chestnut has been doing the rounds for decades but it simply isn't true. There is no requirement to register your copyright either, in fact in most countries in the world it's impossible to register copyright, the only exception being in the U.S. where you can register copyright but even then you still get copyright automatically upon creating a work and fixing it in permanent or semi-permanent points. So just by writing and saving you automatically get copyright protection.

DW: If copyright's not registered Don as you have just explained how do you go about proving that you own the copyright and the given program?

DM: Well so rules regarding ownership are relatively simple. So the ownership is determined by reference to the author, so the default position is that the person that writes the code is the first owner. So it’s the author of the code, you know the first owner. If the programmer creates the program in the course of their employment then it will typically belong to the employer. With modern integrated development and environmental control systems it can be pretty easy to determine who wrote what and when and then once you determine who wrote the code, when they wrote it and the capacity in which they wrote it, that can be quite easy to prove who the owner is and good record keeping can make your life very easy.

If the records are not great then you need to look for other types of evidence about ownership. Depending on just how murky the chain of title is, so looking at who created what and when and whether there are disputes about whether one person wrote the basic code or whether they wrote it in their private capacity outside the work. If you need to look into all this that could be quite a lot of fun for a litigator but it would be less fun for the companies that are involved in that type of dispute. So, keeping records is really quite important.

You can also assign copyright in a program, both before and after it has been created where you commission someone else to write a program for you it would typically be assigned even before its written as long as you have got your contracts in place properly.

However, if the contract is silent as the IP ownership just because you pay someone for it to create a program for you that doesn't mean you own it, you actually need a specific assignment and that's for getting your contracts correct in the first place really is important. More software disputes really aren't about copyright per se, more often than not they are about contracts and I think that is where really it is so important to get all your documentation in place at the outset because it's typically far cheaper to put in place a good agreement at the start of an arrangement than have to argue about it further down the line. You will save yourself an awful lot of costs in the long run.

DW: Thanks Don. David I would just like bring you in on that point. So following on from Don's comments on ownership of copyright I know that clients who've sometimes paid a great deal of money to develop a suite of software programs, the starting position is they want to own copyright in it but equally from the point of view of the developer they wouldn't want to sign away copyright in, for example, standard routines that they may well wish to use on other projects for other clients so, how can that sort of conundrum be resolved through the agreement that regulates who owns what?

DF: Morning David. You are right this is something that does crop up from time to time. I mean, the first thing I would say is really to understand what the underlying commercial deal is right, because is it a software development arrangement or is it a licencing agreement because the two of them will have very different economics. So if the customer wants to own the copyright and the software that's being developed then naturally the developer is going to be expecting a much higher price for that, so it's going to effect that dynamic.

I would also look to test for the customer whether they actually really need ownership of the software, so often when you are asked the question that what comes back is the idea that it's a principle based thing that they are paying for the software to be developed and so therefore they feel they should be owning it and that may or may not be right but the difference between ownership of the software and a really robust non-exclusive licence is the extent to which you can prevent others from using the software so unless there is something really unique in the software which the customer wants to retain for a competitive advantage say, then an appropriate non-exclusive licence can often be enough for the customer and by appropriate I mean it's one that is perpetual and irrevocable so you've got those lasting rights and it's also one that gives you access to develop and manage the source code so you can maintain and enhance the product that you are buying over time.

If you get all of that then often ownership isn't such a big issue. There are times when ownership is something the customer still wants and that's fine and the way you see that working is sometimes the front end functionality, so the funky stuff is sort of assigned over to the customer and the developer retains ownership of some of the back end generic IP that's created and that's fine you can deal with that in the contract as long as it's clearly set out.

The one thing I would say and I'm sure you would agree with me is that don't be tempted to think that joint ownership of the IP is the answer, you know joint ownership can get really messy and so that's not the easy fix that some people sometimes think it is, that's the thing I would avoid.

DW: Yeah I completely agree with you on the joint ownership point David, I have dealt with quite a few disputes myself where the clients have thought well it will all be fine because we will just own in jointly and you do end up in a very sticky situation legally if the issue is not grappled with at the outset as to who owns what.

So moving on from the question around ownership from your perspective as a transactional lawyer what are the most common provisions and licence agreements that tend to give rise to disputes?

DF: It's an interesting question this one because there is that perception that software licences are highly technical documents and while part of them can be pretty technical, and we have just spoken about how copyright can play into them as well, it's not in my experience the technical areas so much that are most likely to give rise to the disputes it's more of the commercial areas that often get revisited, so it’s the things around the description of the software, the functionality of it especially if bespoke software is involved, it’s the scope of the licence that's being licensed and also the way the licence fees are calculated, these are the ones that really trip people up more often than not.

I think out of all those commercial areas the one that I would probably call out the most is the scope of the rights that’s being granted and that's because licensors will generally look to limit the scope of the rights that’s being granted in quite a number of different ways across the document so making sure that these are lying with how you intend to use the software is pretty critical.

For example, there will typically be a restriction around who can use the software and that can be framed around individual named users, it would be perhaps a number of users that are licensed to you it or indeed the number of computers that can process the software. But if these authorised users are not clearly defined in the contract then trouble can crop up. I think you also need to look very carefully at how the software could be used to distinct of who can use it and again it’s the clarity around these permitted use provisions that can often avoid or create a disagreement later.

So, unfortunately I do still see quite a lot of permitted use provisions lacking the necessary detail so for example a right to use software for internal business use only is pretty vague. You know while that clearly restricts some uses like directly on selling the software there are question marks about where the boundary lies. So if you want to use the software to perhaps form part of your end customer platform of if you want to use it to interface with your end customers what about if you want to process data or perform other tasks with that software on behalf of your customers as part of the managed service.

In these circumstances if that internal business use or not, so I think, but I always say that it's really important to test the language that is used in the contract around permitted use against how the software is going to be actually used in practice and make sure it really clearly and precisely covers your expectations.

One final point is if you are also looking at the third party access to the software, now this is an extension of the authorised user point but you need to be very careful about whether the licence includes just your employees or personnel or whether it also extends to cover your contractors and affiliates.

But if the licence is silent and ambiguous around that then you will come as stirring up trouble especially if you end, perhaps later you want to outsource the business unit or the product in which the software licence is going to be integrated or support and with the extent of collaboration and partnerships you've mentioned before that is coming up more and more in terms of how businesses are looking to develop their digital offerings then that's a real key restriction to look out for as well.

DW: We are obviously focussing on primarily on disputes today but just briefly from your perspective as a transactional lawyer drafting software licences on an extremely regular basis what are the most common mistakes you come across when negotiating licences?

DF: Yeah, I think probably the most common mistake that I see certainly on the customers side is not accommodating for potential shifts in how the business might want to use or indeed how much they want to use the software in the future. I think building in pricing and other terms up-front for your future expansion plans it is really sensible, whether that's looking at new territories, perhaps increasing the number of users that I mentioned or maybe even giving different business use the right to use that software in the future can be really effective to do that up-front when you have got that additional leverage over your suppliers before you get tied into them.

I guess one of the big mistakes, maybe not the most common, but still a really big mistake that I see is the business not getting legal involved early enough. Obviously as a lawyer I'm kind of bound to say that but it does make a huge difference. Thankfully the days when I get asked to cast my eye over a licence the day before signing are far and few between nowadays but it does still happen and there are two real major problems with that, I think first you are unlikely to have had the time to build in that flexibility that I mentioned just a minute ago and secondly, those sort of late stage reviews inevitable end up really where you have to unpick some pretty unpalatable positions from a very weak negotiating position and under tight time pressure and all of that taking together is just the wrong environment to the get the best outcomes in these types of arrangement so really get legal into the technical discussions early on and you will get some real benefits from that.

DW: And just following on from that David, we are seeing a rise of you know, a lot of emerging technologies at the moment … think artificial intelligence … think BLT or distributed ledger technology, are there any particular points should be borne in mind when dealing with that, you and emerging tech as opposed to good old fashioned software that has been around for 30 years or whatever?

DF: Yeah. I think there are two things that you really want to do here in relation to the merging tech. The first thing is to understand how the technology works, you know you can't identify risks and issues if you don't understand the tech. We spend a lot of time in my team sort of getting under the hood of how some of the new technologies you mentioned function, we have looked at Blockchain, AI we have recently looked at IoT as well and so I'd say go and speak to your technical teams about the technology you know, in my experience techies love talking about the technology they are implementing and the new stuff and so go and talk to them and understand what's involved.

The second thing that can really help is to understand how your business wants to use it and in particular thinking carefully about how the new technology you're implementing may interact with your existing IT estate and in particular how that might affect the existing licencing that you've already got. So, for example, if for a risk the way that your new technology is being implemented with your existing software is there a risk of that interaction will be a chargeable event under your existing software licences.

David, you'll be familiar with the case of SAP and Diageo where this is exactly the case but for those of you who are not familiar with it this is where Diageo integrated some new software within the RP system that they were already licencing from SAP and this new software enabled Diageo's end customers to pull data directly from SAP's system without having to go through their existing call centre. Now that was great and it drove some real efficiencies for Diageo but when SAP got wind of it they successfully argued that those interactions between the end customer and SAP's ERP system which is enabled by this new software but that was effectively users within the scope of SAP's licence and that resulted in a damages claim of tens of millions, I think it was knocking fifty odd in the end.

Now why that didn't relate to new and emerging tech, I think the underlying point still stands which is it is important to understand what's going on within the estate as a whole because particularly with the rise of systems that are now being designed specifically with straight through processing and automation in mind, you know whether that’s robotic processing automation, IoT connections, AI call outs whatever it is, all of that interacting with each other automatically without human intervention that's fantastic but you need to understand what your existing licences say about that and what positions you might be getting into.

DW: Thanks David. Don just bringing you in again. What aspects of a computer program does copyright actually protect and are there things that copyright doesn't protect and that you can't rely on copyright for?

DM: Sure, so I think somewhat surprisingly there's a starting point, copyright protects computer programs as literally works, now that might be a bit surprising to hear because traditionally literally works, now everyone knows what a literally work is in terms of literature and a book, but literally copyright protects writing in any form so that an email that you write, most emails that you write will have copyright existing in them and will be literally works. But, in the late 70's early 1980's it was decided that this is how we would protect computer programs and so the way its protected as a literally work is in the code as written and by protecting the code rather than other aspects of software that affects the scope of protection because you are protecting the code itself but not the effects of the code, so copying the functionality of the program without copying the underlying code, the functionality is typical and not protected by copyright and there is quite a famous case about this which is called Saturn Institute and Wild Programming.

In my view the effect of that case are a bit misunderstood and are often exaggerated and I will come on to that later but in addition to copyright in the code there may also be additional copyright works within a piece of software so, for example, the music and sound effects in a video game they will be copyrights works in their own right if they will be within your software and there will be separate copyright works within your software but they are themselves protected works in their own right.

Similarly, photos, graphics, graphical user interfaces and icons – these can also be set works separate from the code as well but typically in terms of the software itself and the core aspects of software which copyright will protect, it’s the code as written and not the functionality.

DW: So if the functionality is not protected Don what effect will that have on liability for infringement in an infringement claim?

DM: In the simplest case of copying so that would be piracy so that is people who just make a straight copy of a piece of software and in the olden days when it was much easier to do piracy you would just get another program on a floppy disk and you would make a direct copy of the software on that disk and the form of the software on that disk would have been executable which would be in kind of object code form and maybe it's worth explaining that before going any further.

So, a lot of people will be familiar with the distinction in object code and source codes, most people probably not. Generally these days the way that software is written is in a higher level programming language, there are lots and lots of high level languages the commons ones would be C++ or Python or Java and that's written, the source code is comprehensible to a human programmer, not every man on the street would be able comprehend a program but for someone who is skilled as a Python programmer they are able to read the source code when it gets compiled into a runtime and these days not every language does get compiled but traditionally it always used to be the case that it would be compiled into what's called the object code form and the executable loaded onto a disk and distributed and it would be the executable form that customers would obtain and that's what you would run on your computer, and just copying that executable that in itself is a clear act of copying the code and that would be an act of infringement unless it's licensed. That's the easiest type of case but in terms of source code, the copying of source code itself so just literal verbatim copying of source code that's an infringement of copyright, that's quite a clear case but then there cases where the code itself is not being copied verbatim and those are harder cases but it's just worth mentioning one defining feature of the SAP's Institute and Wild Programming case that I have already mentioned, which effects the kind of import of that case so, in that case the alleged infringers what they had done was they had taken a copy of SAP's Institute suite of software, the very expensive technical software but they had never had access to the underlying source code so they had never been able to see how it was written but never been able to see how the various features were implemented in code, all they had done was get a copy of the program and they tested it, they had seen how it behaved with certain inputs and output and they've made a functionally almost identical copy which did exactly the same thing to the point where the instruction manuals for the original software could be used to run the copy software. So the functionality was that similar it was a functional copy but because they hadn't had access at all to any of the source codes and because it was found in that case that functionality of software is not protected as a copyright work there was no infringement there. But, the big issue there, which is different from a lot of cases about copying is that there wasn't really any question of the alleged infringers having access to the source code.

Now, often in the cases we tend to see, the circumstances are really quite different. You will have current or former programmers or technical team members to from of company who perhaps leave to join a new company or they write competing software while they are still employed by a current employer and then go off and start their own business, but at the time they wrote the software they had access to the original and in that case the points about copying functionality or not copying functionality, they kind of fall away because when you had access to the original source code then you can make a copying case or copyright case just along ordinary traditional copyright principals, and those traditional principles or at least under English law if someone has taken a substantial part then that's the key trade of the copyright law.

If they have taken a substantial part of the original and incorporated it into the allegedly infringing product then that can be sufficient for copyright infringement.

There's no hard and fast rule for what will be a substantial part but it doesn't have to be 10% or 5% of a code base anything like that and there are also a lot of myths around what is a substantial part and some of these things come from rules in the past about licencing and permitted copies, so maybe when you're a student you saw that you get … you are permitted to copy 10 per cent of a book. Those were kind of big licensing schemes and things like that don't affect substantial part. You must just be copying a particularly useful feature of the code and that can be sufficient for copyright infringement and there are various different ways of proving that the copy has taken place.

One final point to mention on this as well is that it's not just a case of cutting and pasting lines of code and just copying elements of the code verbatim, it's specifically recognised in the UK copyright statute in particular that making a translation of a program from one language into another language is itself an infringement. So, there may be will that there isn't a single line of code that’s absolutely identical to programs but if you have, say, taken a program written in Java and convert that into C++, that act of translation from one language to another is itself an act of infringement which is recognised in the statute.

DW: Thanks Don. Akshay I'd like to bring you in now. You have a great deal of experience of software audit programs, perhaps you could explain to us for those who are not familiar with that concept what is an audit program and what are software publishers trying to achieve by engaging in audits?

AB: Thank you David, good morning everyone.

It is a very interesting question and before I get into that I'll just spend a minute talking about software. Now, software by its very nature is intangible, it's expensive, it's extremely expensive and then after that you have a variety of licencing metrics. David Futter previously talked about a user in the SAP case, a user defined by one publisher is different from a user defined by another publisher so there are all these different types of complexities which make it very hard to actually manage.

Now, for the vendor when the sell the software ultimately their direct objective of what they like to obtain from an audit program is to protect their IP – what that means in controlling piracy, controlling illegal use of software and minimise counterfeiting and from a vendor perspective there are significant risks associated with say pirate software such a malware, financial exposure, reputation damage and ultimately the software publisher wants to eliminate all of that as much as possible.

The other reason that they want to … or they have very active audit programs is actually they want to recover any fees or payments that are due to them as a result of their IP being used. These are very much direct straightforward objectives that a vendor wants to get out of this but some of the other indirect objectives that they would like to get from this is by knowing what their customers are using, it gives them an opportunity to upsell, try new products, put it out on the market to increase the footprint with their clients, it also helps to understand how their products are better being used so if one of their clients comes up with an innovative way of using a product in an industry they like to see that being implemented and being used by other parts by their other clients in the same industry.

I think one final point is publishers with the audit programme they do like to level the playing field, what I mean is software like I said is quite expensive and companies that use unlicensed software or pirated software would not be spending as much on these and therefore those law operating costs translate into law margins for their clients and so, yeah, the vendors definitely want to protect that aspect.

DW: Okay. The typical software publisher will no doubt have many client whom it could potentially audit when it's looking at that client list how does it work out who to target, who to pick on in your experience?

AB: Again, that's a very interesting question because you are very right they have tens and thousands depending on the publisher, it varies but they would have anything between a few hundred clients to a few thousand or million clients as such.

Now, there is a lot of work that happens in the background by the vendors to identify the potential candidates for an audit, some vendors have the approach that have ongoing active audit programs in which the objective is that they like to audit each one of their main customers once every three years or once every four years and therefore they will potentially tell you that you are not specifically targeted or selected as, you know to perform an audit.

But, bear in mind vendors do their homework the will look at a lot of data points that would have them identify candidates, to select their customers to perform an audit. I just want to say that it doesn't actually mean that the vendor suspects non-compliance or you are being accused on non-compliance that there is a problem but it's just the way the vendor goes to identify their audits as such.

Coming to the point on what is it that the vendor will look at, so how is it that they actually get to that list, some of the things they would look at are purchasing patterns, so if you have a lot of sporadic purchases done across different points in the year or if you stop support for say part of the estate then that sort of raises a few red flags in the vendors heads to say maybe they are not so much in control of the environment.

I mean, you would be a much higher target for an audit as opposed to someone who does their annual or regular purchases in bulk with the reseller. In some other cases vendors have access to dial back data so if somebody has registered the software and installed the software in things like their IP address or the user name goes back and the vendors can very quickly do a check to see how many registrations have you got for an entity versus how many licences they actually have. Those are the sort of things again they would consider whilst selecting candidates.

Mergers and acquisitions, divestitures, some of the other things such as past audit history, these are various different points that the vendor will definitely put into consideration as part of their selection criteria.

DW: Once that audit has taken place, let's say you are a corporate and you have been subject of an audit, typically what are the kind of issues that cause disputes, what sort of problems arise from an audit again in your experience of them?

AB: Sure, I mean … in my experience of a few thousand audit what I can see is before the actual audit reaches the law firms and before it actually becomes a dispute or before they have an arbitration there is a lot of back and forth between the software publisher and their client and the reason is their client, the software publishers client would have got an audit report which says they owe them X amount for software that's been made use of or that software is deployed and therefore they need to pay that.

There are a lot of technical discussions that happen around on this point some of the common points that we see as part of these licence audits are whether the software is actually deployed or installed versus whether it's actually being used or any benefit has been derived out of that software. So, for instance, some licences and it comes down to the contract, some vendors would actually want you to pay for every instance of software that is actually installed or prevalent in your environment irrespective of whether it's being used or not. An analogy for that is when you go to the bookshop to by a book whether you actually read the book is a whole different thing but if you want to buy the book or the intention is to read the book then you buy it then you've paid for it.

When some software vendors actually would not be licencing or you don’t incur a licence fee if you actually are not using the software. In a similar vein environments such as test environment, developing environment, back-up environment, disaster recovery what sort of standby is present. I appreciate some of these are a little technical but depending on whether the software has been made use of or is active or is actually switched off and is cold somewhere not being made use of.

Those are the sort of things that definitely are discussed and give rise to quite a lot of disagreements between the vendor and its client.

DW: And we are seeing a bit of structural change in the industry with more in the way of on demand and cloud based solutions as a more traditional way of doings things. Do you think that will have an effect on audits, will there be fewer audits, more audits, how do you think that will play out?

AB: So, David Futter talked about on the changes and technology and IoT and the impact of the artificial intelligence and David you also mentioned there are shifting trends in IT where there is a shift from the customers wanting to have the software on premise within their own environment versus actually wanting it within the cloud and there has been a gradual shift, I would say in the last three or four years and especially in the last few months it has been accelerated because of Covid where people are wanting to go … when they want to prevent something they are moving and shifting things into the cloud.

I would say that software vendors are definitely still performing audits but the nature of the audits is changing slightly. They are definitely more collaborative because they would like to work with their customers, with their clients, understand what their requirements and then have them moved to the cloud and the advantage for the vendors from this perspective is that it changes then from an annual purchase to effectively getting some regular income, regular revenue from their clients in this way and of course from the licensor's perspective the end user, they don't have to worry about provisioning or worry about licensing aspects per se because they would have … that risk sort of … is shifted a little bit to the cloud service provider.

Nevertheless, I mean with the mix of on-prem and on-cloud infrastructures software licence audits become more complicated if anything else and so I don't see them going away at any point in time but I see them becoming a little more collaborative. I do see vendors being collaborative in their approach for this.

DW: Thanks for that Akshay. Don coming back to you again, we just have time for a brief chat around open source software. Now, that's a term that's very widely used, many people if not most people have heard of it but perhaps an understanding of what it actually means is less common so maybe you could elaborate for us on what open source software is and what that term means.

DM: Sure, just to note I'm experiencing a band width issue here so I'm not going to turn on my camera here and at its broadest, open source software is software made available in a form where the source code is accessible, so it's an open source code and when the phrase was first used back in, I think probably the 90's all software at that point was distributed in the form of an executable file on a physical disk and I've mentioned before the different between executables and the source code and that’s where the source code is like comprehensible or understandable to a human programmer. But by having access to the source code it allows you to modify, fix bugs, make changes, really do what you want with the software as long as you know what you're doing but under the older model where software was distributed on physical media in executable form you were reliant, consumers of software were reliant on the developer to fix bugs and if the system was closed because you couldn't modify the software yourself.

But with open source the idea was that when you distribute a copy of a program you also distribute it in source code form and that allows the user of the software to make changes and fix bugs and to over time improve the software and so that's what the open source movement was. It was led by engineers rather than lawyers and partly for that reason IP law was not a big focus it really was a kind of engineering focus and for open access to source code.

Now, just because the open source software was typically available for free, so at no cost, that doesn't mean it's copyright free. It's quite the opposite actually because copyright subsists in open source software in the same way as it does for any other piece of software. The difference is that a licence terms that apply and so some open source licences are known as permissive licences and these tend not to cause too many problems when incorporated into other commercial software. But you have other types source licences which are known as restrictive licences or copyleft licences and these can cause big problems when incorporated into commercial software. So, for example, one licence known as the GPL requires that an open source code licensed under its GPL terms if that is incorporated into another program that new program was also being made available on GPL terms and so this means it must be made available for free and that you need to publish it in open sourced form.

So that could potentially undermine a software developers business policy where they make their money by selling copies of their software to customers and part of their strategy variety protection is keeping the source code confidential because we have seen about the limits of software protection for functionality and one way of protecting your IP in your software is not only the copyright in the underlying code but if you keep that code confidential, don't expose that to the wider world that is a way of protecting your IP in software whereas copyright … and in these days it's one of the most effective ways of maintaining your IP protection. But, if because you have used codes subject to the GPL open source items you are obliged to make that code available in open source form, that can be a problem.

DW: So Don, my understanding is that in reality it's virtually impossible to avoid using at least some open source if you are engaged in the business of developing software it's just everywhere, it's out there.

So in your view how can you manage the risks associated with it given that the reality is that it is going to feature to at least some extent in almost any program.

DM: I wouldn't say that it's to be avoided at all, it's open source in my view is definitely to be embraced and if you are not using it it's almost a red flag when you're doing a due diligence on its software acquisition because of efficiency advantages that you get from using open source software. There is a lot of great stuff out there but what you can do to manage the risk is you can give developers simple guidance on the points to check before using codes that they may find online. So quite commonly you'll find or get access to open source codes via a codes reportedly such as GitHub that's probably the biggest one, there are so many, there's a huge amount of stuff on GitHub.

What you can make sure or ask your developers to do is when they do get a code from GitHub they will look at the licence file which is with the software and check which specific licence covers that code and if there is no licence the default position should be don't use it, but if the licence is one of the permissive licences and you can get guidance as to which of the licences are generally acceptable for your used case then you can say that's probably going to be okay and then if the licence software is subject to one of the restrictive licences you would need more specific guidance as to how the code should and shouldn't be used and whether by default you should try and find an alternative which is subject to a permissive licence or if it's going to be used in certain aspects of your code, so it's not actually going to be distributed then there is a lower risk there and you can build that into your policy.

Pro forma guidance can cover most scenarios, it won't cover every scenario but starts from some very simple usable rules of thumb without a huge amount of difficulty.

DW: Thanks Don. Turning to all of the panellist now that there have been a few questions that have come through in the court of procession. The first one David Futter I think its arising from your aspect of the present station and the question is, if you have a perpetual irrevocable and exclusive licence is it equivalent to ownership?

DF: I've got to say I've never seen a perpetual irrevocable exclusive licence myself, or at least I don't remember seeing one and I suspect that might be because there may well be some anti competition issues around that to trade.

In essence in going back to the question as to whether it's equivalent ownership, no its not they are separate rights so even if you were to have a perpetual irrevocable exclusive licence that would be something quite separate to ownership and so, for example, the reason why you might have the ownership separately is because they may be licence fees and royalties that are payable to the owner for that licence being granted even though its perpetual and irrevocable and exclusive and so the owner could then deal with that as an asset separately, you could look to, you know, assign this or sell that revenue stream. So the two are compatible together it's just I wouldn't say you would necessarily see them very often.

DW: The second part to the question actually is how would the courts interpret it but I'll just briefly comment on that.

I did do a very large case about 20 years ago called Ocular Sciences against Aspects and one of the very many issues in that case was what does perpetual and irrevocable mean and that case in the context of a patent licence and after an 8 week trial the court decided that perpetual and irrevocable means perpetual and irrevocable so it didn't shed a great deal of light on things but the words meant what you think that they mean at first blush.

Akshay a question for you. We have recently received an audit request from an IT supplier how do you think we should responsd?

So that's a very specific question but perhaps you could give a more general answer to the approach you would recommend.

AB: Absolutely. I mean it's no secret that every company would be audited at least 3 or 4 times depending on your size in a year by different vendors so, yes if something lands on your doorstep how do you respond?

These days the vendors actually also send the letter to finance department so apart from IT the finance teams also get it so there is just no swirling back. The image of response some companies like to do is to get an effective licence position which is to send the IT teams to find out how much is it that we actually have installed and get someone in procurement to say what have we actually got in terms of our licences so that we can merge the two together and see if we have got a problem or not.

Now, whilst that is something one should do I think it makes sense to involve procurement as well as involve legal as soon as you get the letter because the legal teams can definitely advise you on an appropriate response that could be sent to the publisher.

Most publishers give you some time period to respond to this and to agree with this. I would suggest its best to make use of that sort of timeframe. If you have very critical IT projects ongoing at the time you receive the letter I think it then requires you to work with procurement because you have a relationship with the vendor. To sort of manage that and see how this can be addressed or what sort of timeframes could be agreed with the publisher itself.

It's always good practice to assign a single representative on an interface from your side to interface with the vendor or to interface with the auditors so that you can be sure of the information of the data that's actually going through you can be sure of there are no ad hoc requests and project the audit can be managed effectively essentially yeah.

I think that definitely is the approach but some of the things like having an NDA in place, finding a team with specific responsibilities, making sure your contracts are in order and you have all your licence entitlements in one single place, I think those are some very good things to have as soon as you get a letter.

DW: Okay thank you. Don there is a question directed at what you have been saying. Limiting copyright and software so that it doesn't protect functionality that's an EU based development and do you think that's likely to change following Brexit, so it's perhaps inevitable Brexit question?

I think we appear to have lost Don. He's gone.

DM: I'm having connection difficulties sorry, I'm back in the room.

So, yes I would be surprised if anything did change after Brexit. I think that like certainly among the judges, the judges in the UK tend to be more kind of pro re-use of things, they tend to more often than not if they have got the opportunity limit the scope of IP protection rather than expand it and if its left to legislature I think it's probably something a little bit too complicated for the legislature to get round at the moment. I think they have probably got bigger fish to fry right now but I would be surprised if the position changed.

DW: Okay, thanks Don.

That's all we've got time for today I hope you found the session interesting and informative, thanks again very much to our panellist for participating. If you have got any other questions which we didn't have time to deal with today please feel free to email any or all of the panellists and we would be happy to deal with those offline.

Finally, I would like to plug the next webinar in this series, the date hasn't been fixed yet but it's going to be at some point in early December and it's going to cover the thorny subject of trade secrets and confidential information. So, please do look out for that and just let us know if you would like to register.

So again, thanks very much and enjoy the rest of your morning – thank you.