 the licenses have always played a vital role, especially on the perspectives of legal domain. And with the flux of the softwares coming into being and how do you decipher such software licenses? This is the path we will take today across to Sivashree Mukherjee, who is a leader in the Asia-Pacific region in Kosehwara. And the today's topic would be deciphering software licensing models. And the talk seems to be quite mind-stimulating and we are looking forward to Devisree for sharing his knowledge. Or do you Devisree? Thank you so much, Mr. Vikas. And first, thank you. And I'm humbled that I was invited for this session and for something that is dear to my heart, because this was my gateway into product counseling, I would say. So I come from an engineering background as well, an engineer-turned-noir, and have been working in the intersection of technology and the law. So what my role would entail is talking to the engineers, talking to the business folks, and not just work on the product compliance of things. It would also encompass working on the commercial models. And when we say commercial models, the commercial models take form in the form of contracts or the licensing agreements. And so that's why this field is quite close to my heart. The second aspect also is that if you look at NVIDIA's export, especially in the IT services sector, the software export revenue is about $190 billion going at about 12% to 15% year on year. And software is something which is there on all aspects of our lives, whether we use a phone. Even when we use a phone, we agree or click that I agree to the terms and conditions. I mean, very few people read those terms and conditions and are not aware of those implications. But yeah, we do agree to those terms and move ahead. It's spread across whether that be Canva, where we use, which we use to create different photos, templates, invitation cards these days, to your Photoshop's using YouTube, Google. Everything is a software, whether that be hosted on-premise or on-cloud. And then there are terms and conditions. There are implications here, which we agree to, which could be in terms of our privacy rights, renewal rights, et cetera. And we'll come to a few of these while we dig deeper into this session. Before we dig into this session, I just wanted to wish everyone a Happy New Year, whoever is celebrating in different parts of India. Now with that, I'll just... So how I have tried or how I would want to conduct the session is, one, I would want the participants and thank you to the participants who've joined on a Sunday evening. Thank you so much. I would want the participants to keep asking questions in anything that they are not able to understand. I can take it slow. I can try and come back with examples there, right? Or any questions the participants may have on software license. So how I would want to structure it is, I'll talk about the commercial models of licensing first, because it's very important to really understand that aspect of it, because that's what gets translated into the license agreements. Then I'll come to the license agreements and then dig deep into the terms and conditions that should be their basis on the different types of software which are there and the different models that are there, which would help not just in-house councils, but also councils looking to work on the technology domain and these, yeah, on technology domains and even for disputes, right? Like if you understand the crux of these contracts that's when it'll help you to work on disputes, whether that be litigation stage, arbitration, whatever. Okay, so coming to the different commercial models that there are, first would be a per user licensing model. Now, what is a per user licensing model? This is a very, you know, this is where an organization, let's say, wants to buy Photoshop licenses of the domain, right? And they have 10 employees who work on creating content where they create different, let's say marketing agency, they create different marketing minutes, right? And they need Photoshop for that. So they will procure, let's say, 10 licenses, right? And these 10 licenses will be linked to those 10 users. So this is user licensing model. Now, the user licensing model can have one once. It can be a named license also, right? So for example, the marketing agency says Debra Shimukerchi and XYZ are my users, right? And you have these name licenses for these particular users and you're not able to, let's say, transfer these licenses to others. Then comes the next level. The next level is what? It says user licenses, but these are concurrent users. So there can be 10 licenses which are procured by an organization. However, in the marketing department who need those licenses, let's say there are 15 people, right? Now, what the license agreement or the business model is, is that you will get 10 licenses and you can transfer those license to others as long as there are just 10 concurrent users, right? So 15 users may be using it, but cannot use it at the same time, only 10 users can be used, it can be used. So that is the per user licensing model. Then comes the per device licensing model. Now the per device licensing model is where the licenses are restricted to your device, that laptop, the server, the phone or any of these. An example could be the operating system, right? Windows, iOS, Android, right? Some of these come with, I mean, there are different licensing models for these as well, but some of these come with a device licensing model where each of those licenses would be restricted to that particular device. And then it may have the right to move one device to the other, but then you need to lock that license to the other device and remove the license from the previous device to which it was assigned. Next, coming to usage-based licensing model. Now what's a usage-based licensing model? And this is becoming quite common these days. And this is also from an enterprise perspective. When I say enterprise perspective, I mean a company perspective. This is something which has been used because this is mainly more economical, right? Where you only pay basis your usage. So you may not be paying for the entire set, the suite of features, but you may be paying using two features or three features and paying for that. Usually the usage-based licensing model is in terms of where you have a cloud hosted software, right? And you are using that software, but for particular calls, when I say particular calls, what I mean is that maybe you are using that software for some kind of an analytics, right? So you send a query and you receive back a response. So that could be one call, right? And the usage and the pricing is based on that. Another example would be, you know, which is the in thing now, a chat GPV, right? There are certain of these models where it is per query base or a lump sum of query base. That for 100 queries, this is the amount. Or for 200 queries, this is the amount that you need to pay. So this is usage-based licensing model. Then there is enterprise licensing, you know, which is similar. It's just like you get bulked with a discount share. So a company can buy, let's say 100 licenses and with 100 licenses, you know, they can give access to a hundred users and it could be a rotation basis where 200 employees are there, though concurrent 100 users can use it, right? The benefit there is to get the, you know, the cost benefit is there that you get bulk discounting for that. Then comes the subscription model. The subscription model could be both for on-premise as well as for cloud hosted. It is mostly subscription we link to cloud hosted like a Netflix, right? A Netflix you pay in advance for watching the content over their platform and you pay that amount in advance for that period. So it's duration bound. Then there could be hybrid licensing models, could be, I don't know whether you've heard of this term but this is a thing now where it's called a freemium model, right? What is a freemium model? And this is picking up quite fast in different markets globally. Now freemium model is where some of the basic features of the software or the platform is free, of course. When you go to the advanced features, that's when you have to pay, right? Now someone may ask, why are you giving those basic features for free? It is because the software organization company would want you to be used to that software and when you see the benefits of that software, that's when you may want to procure or advance to the other or the advanced features. And then there could be custom licensing model which could be a combination of any of these. So these are the commercial models which are there for software licensing, right? Now, coming to the legal aspects of it, right? The different software licensing models from a legal perspective. Now, first let's start with freeware, right? A freeware is a software which is there on the internet. It says it's free of cost or it could be there in a company's website. It's free of cost. Free of cost however does not mean that there aren't licenses governing those software, right? So you may download that software. You may use the software and you may distribute the software and use it for commercial purposes but you cannot modify that software as per your needs, right? So it is free of cost to use but not to modify. Then coming to open source licenses, right? So open source is something which where many of the engineers and many business folks think that, hey, open source is free software. I can do whatever I want with those components with that software, there is no restriction. But honestly, open source is like a ticking time bomb, right? If it is not used in compliance with the open source licensing terms. Now, I will not go deep into open source because it's a huge topic. We can have a discussion separately on that but why open source is risky, right? There are certain open source licenses like a GPL license which say that if you include the component governed by the GPL license into your proprietary software, in that case that entire code base, entire code behind that software becomes open source and then you will have to put the source code out. Now, what is the source code? A source code is the inner masala, I would say, right? That you don't want others to know, you know? That is the code which is readable by a human. That can be understood by someone, an engineer who reads it and bases that you have developed the software, right? So that source code, if that goes out in the public domain then basically anyone and everyone has access to that secret masala or that secret ingredient that you had running behind the software, right? So you wouldn't really want that to be distressed. So that is why open source licenses are good to use provided you know what the terms are, right? Open source licenses kick in only when you modify that open source component and you distribute it, right? And for a software company, distribution is the primary purpose, right? Like they will sell those licenses or license out those software in order to earn the money. So you have to be very careful with the open source licenses. There are few open source licenses which say you can do everything, you don't have to disclose the source code. Only thing that you do is you give an attribution, right? That, hey, you know, this person had created this bit of code and you just mention or give an attribution for that person or the developer. Now coming to the two most common forms of licenses, one being a proprietary software license and a cloud-based license. Now a proprietary software license and a cloud-based software license, both are basically proprietary licenses. The distinction is where the software lies. When I say where the software lies, I mean where the machine learning for, right? Now what is a machine learning? Or what is an object code? Not a machine learning code, but an object code. Now an object code is something that a machine understands, right? It's in the form of zeros and ones. So the source code is changed into a machine code and the machine then understands that code and then executes the software, okay? So we need to find out where that code lies and then we get into either a pure play on-premise proprietary software license or a cloud-based license. A cloud-based license is where the object code is in a server and when I say a server, I mean something like an AWS, Amazon web services. It could be Azure, which is Microsoft's cloud or it could be any other cloud. Let's say Google cloud or any other cloud, right? So here the risk changes, the nature of grant of licenses also changes. Now what I'll do is I'll dig deeper into some of the clauses, right? And when I say I'll dig deeper into some of the clauses, what I'll do is I will try to distinguish between a product-based company where the company is a software, purely develops a software and licenses that software and earns revenue. The other bit that I'll do is I will take examples from the information technology sector, right? And that is very important considering the huge $190 billion market that's there, right? So, and all they do is they develop software for their customers, right? So there are different licensing models as well there. I'll come to each of those. Or let's start off with an IT services company, right? And the licensing elements within that. Now an IT services company is what they do is a customer says that hey, Mr. Company X, I want you to create a particular software for me and provide certain services to me, right? Now the IT services company, what they do is that software is basically a work product, and the ownership of the work product goes to the customer, right? However, there could be, but however what the IT companies now are doing is they are becoming more of solutions provider, where they will have their own software along with the work product which is created. This software element is owned and retained by the IT service provider and the ownership is not transferred to the customer. So, there could be three types of situations. One, it's a pure play product where the IT services company has a software and they give access of that software to someone, to the end customer for using. For example, what could be an example? An example could be a bank. The bank has let's say a chatbot and the chatbot in the backend, for example, SBIs, you know, it could be forgetting HDFC's name, HDFCL chatbot, all these banks have chatbots, right? But in the backend, there is some kind of software which is running and that software could be that of the IT company. Now what the IT company will do is they will have license rights and restrictions provisions there, right? In the grant of licenses, they will say that, hey, Mr. Customer, we are integrating this software with your chatbot and however, the grant is only in the object code form, because you don't want to give the source code, okay? If you do not give the source code, then what happens is that the customer is able to use it but on the maintenance side, they will still need the IT service provider's help, right? So there is a stickiness which gets created, right? And the secret sauce or the secret masala is closed to the end customer. So they will say that, okay, we are giving you a license and the grant of license, what will it contain? The grant of licenses will clearly define the scope. That is, it is integrated only with your chatbot. It is granted only in object code form. Three, you will need to define the territory that the territory could be worldwide as well. It could be India, it could be just US or it could be any combination. You need to define the period for the license, right? That, okay, this license is for one year or for the term of the services, which could be three, four, five, whatever you ask. With a provision which says that it should be revocable. Customers will say that, you know, I have paid you the money, why is it revocable? Because they may misuse the license, right? So you need to create that right to revoke the license. And that it is, whether it is royalty, whether there will be royalty included with that license or not, that you need to mention clearly in the scope of a license. Second, what you need to do is you need to define the ownership of the intellectual property, right? Here, since it's a combination with their, you know, front-end chatbot. So what you need to define is that, you know, this software that we are integrating that we had created prior to the services or which we had created for a generic purpose which we can use for others. The IT service company will retain ownership of that software, right? It is very important because in these kinds of complicated cases where you have integrations, it is easy for someone to say, especially in our IT services kind of a sector where they might say that, you know, this is a combination, we need to use it. So, you know, there has to be a perpetual license or there has to be an assignment. So you have to be very careful in defining what your software is and in also mentioning that you retain all rights, titles and interests to that software which belongs to you. Then comes usage restrictions. In the usage restrictions, you will have to specifically mention, since this is hosted on, let's say, you know, your customers, servers or computers, customers will have access to the object code, right? You would want to restrict them from reverse engineering. What customers may want to do is reverse engineer to find out the secret source behind the software. Doing that, what happens is post the termination of services or post the expiry of services, they may be able to create a software because now they know the logic, how this was created, right? In object code form, they're not able to do it but if they reverse engineer it, then they are able to figure that out. Next comes the warranty, this came as, right? In the warranty, what you do, especially when it is on-premise software, that is software is on the computers or the servers of your customer, then warranty becomes very important because the customer would say, I want this software that you've installed to be working for, say, and you have to provide me maintenance for the entire duration of the license, right? But this is where you will lose the revenue for the IT service provider or the company, right? So what happens and the industry practices, you would say that, okay, if it's on-premise software, three months or six months is when I will give you a warranty, any bugs, right, or any issues that may arise, I will rectify that for your cost for you. Post that, post that period of three months or six months, you will have to pay me a maintenance charge, which I will, you know, which, you know, a yearly or whatever, however you decide the commercials of it, that maintain with the, using the, and, you know, you will pay me the maintenance charge and I will fix those bugs for you. Then what you need to specifically do is disclaim certain warranties, right? And when I say disclaim certain warranties, you need to first of all, disclaim that you warrant or you represent that your software does not entrench on any sexual property rights, right? Because, and why do we say that, right? This is becoming industry practice. Why do we say that? We say that because it is practically impossible for someone to really, sorry, find out whether the software is infringing on any patent, whether the software is infringing on any copyright. It is not, it is very, very difficult to figure out. Yes, someone may say that a copyright infringement only happens when there is access to that infringing material, but you cannot control your engineers, right? How much ever controlled environment to keep your engineers in, you don't know whether they have, you know, copied some aspect from somewhere, right? And I come to what happens if an infringement happens. I'll come to that as well, because the customers may say that, hey, why should I buy from you when there's no gallon, right? So, yes, you disclaim the IP infringement. On patent side of it, there is a concept called freedom to operate search, right? So before any software is launched into the market, there is a freedom to operate search which is done by a patent professional. And they will see if there are any other payments which infringes on the or which covers this product that you're launching. But the problem is no patent engineer or patent attorney can be sure that they have covered all this, right? So there could be that issue. So you do not, and you disclaim that one. You further disclaim that it is fit for a particular purpose. Why do you do that? Because you do not know always for what exact purpose the customer will be using, right? So you disclaim that. Third, what you do, you say that I disclaim any warranties which are not specifically mentioned in the contract. Now, some of the warranties that can be mentioned in the contract is that, okay, I will run a search, a bug test, right? I will run the software, I will check for any bugs or any issues or any malware is, right? And doing that, after doing that, I warrant you that I give you a warranty that there are no malware or there are no viruses in the software, right? You do that. So these are some of the warranties and the disclaimers to warranties. Then you would come to the limiting the liability, right? Like how do you limit the liability there? Now, as industry practice or before coming to the limitation of liability, let's talk about the indemnity permissions, right? As a practice or as become an industry standard in the software world, a software company will only give indemnity or third party claims for IP infringement, for breach of confidentiality, for breach of applicable laws, for fraud, misrepresentation and willful negligence, right? So these are what the company would give an indemnity for. Now, you may ask, hey, we are disclaiming warranties for IP infringement, but at the same time, we are giving an indemnity for that. Why are we doing it? Because if you do not give some sort of a protection, right? To your customer, your customers will not buy your product, right? So you're saying that I do not know whether it infringes, but if it does, I am giving you an indemnity, which will cover your losses and cover your costs. Then you come to the limitation of liability provision. Now, in one particular issue or one particular breach, you cannot break your company. It comes down to how many, how much business you're getting and how much risk. So the risk reward balancing act has to be there. So the industry standard will be, you give or you restrict your liability for the 12 months of payment for that software, whether that be a payment which is done in advance or PMS, which would be made at the end of there using the software, right? So it's paid or payable and you restrict it to the 12 months period. However, there would be certain exceptions to these, right? And the exceptions are usually if you breach law, if you breach, if there is an indemnity with respect to intellectual property. So these are usually all willful mismanaged or willful mentions, right? These are the few of the provisions for which you give a uncapped liability or you carve it out of the limitation of liability provision. The other aspect, and this is interesting is the termination assistance, right? So when you're selling to another company, that software may be a critical component of that company, right? So if it is a critical aspect of the company, suddenly at the expiry or the termination, you cannot stop your services or your software from being licensed now. So you have to provide a termination assistance period which goes beyond the expiry or the termination of the licenses in which either you win back the client where you renew the licenses or what happens is till the time the client figures out another vendor, you keep providing that software or the software licenses and it keeps being integrated with the client's systems. The another aspect which is interesting and many of us will face in the, especially in the IT services sector is with respect to escrow provisions with software. You've seen escrow provisions in other financial transactions but escrow becomes very important in software as well. What is escrow here? The escrow provision says that the IT service provider will put the source code of their software into an escrow provider. The escrow provider will check whether it's properly, all information has been properly provided and whether it can then run on the systems and whether the customer will be able to use it. Now, why is that? Let's say the vendor goes bankrupt, right? Or the IT service provided was bankrupt and it's not able to provide services. In that case, the customer for whom this may be critical is now of no use because the vendor is not able to provide the services. So you need that. Sometimes the escrow provisions will also include a clause which says that if you're reaching the contract or you're not able to provide certain services, then also the escrow will be released and we will get the source code. Getting the source code is again the secret recipe or the secret masala. So that's on the escrow provisions. Coming to now the security aspects of it, right? So there are security risks as well, less so when these are on-premise software, right? Because if it is on-premise software, it is anyway with the customer and for it to really breach, the customer's information security systems have to have played some part in that breach. There could be malware as well, but if it is due to a malware that this breach has happened, in that case, of course, it will be the liability of the IT service provider. Now, we are mostly talking about out licensing, that is, a company licensing its software to another company and in an on-premise platform, right? Let's look at it when it is hosted on a server, right? So when it is hosted on a server, in that case, there is anyways an argument which is anyways going on, which says whether it at all is a license or not, when you give access to that software which is hosted on the cloud, right? So in that case, the grant language does not say that, hey, we are giving you a non-exclusive license to use the software. It says we're giving you a non-exclusive right to access the software. And what is the difference then? The difference is where the software resides. If the software does not reside on on-premise, in that case, you're not really using the software or running the software. Software is being run in the cloud. In this case, you're just sending in input and getting out, getting an output from that, right? So that is cloud hosted. Cloud hosted software will again have another provision on the SLA's, right? Or the service level agreement, which is a very interesting concept which hits someone commercially. Now, if you look at AWS, right? On which Netflix runs, right? If you look at Azure, all these cloud service providers will provide you with a SLA and the SLA will have the uptime. That for how long or for what percentage of the time the software will remain up without a downtime. When I say downtime, I mean the software will not be accessible to someone. And also if there is a bug, how fast you will get a response if you raise a complaint and how fast it is, it can be mitigated, right? So on the first bit on, let's say a company has an SLA of 99.5% and another has a SLA of 99%. And I did a calculation, right? So if it is a 99.5% SLA, right? That means yearly one day and 19 hours, it will be down. It is 99.5%. By 0.5, changing 0.5% that is making 99.5% to 99% it is a yearly downtime of three days and 14 hours. So three times of that. If it is a critical software, for example a software running on a phone or hospital, right? And most of the software are now cloud hosted. So if the hospital is not able to retrieve data, let's say insurance data, let's say medical records, right? And it is down for three days. It is a big issue for the hospital, for the patients, for everyone. It's disruptive, right? So you need to have SLA service level reach credits as well, right? Where you say that, okay, if from 99% you drop down, right? Then for every minute or every hour or every day that you're down, you will give me a service credit, which could be a certain amount, right? Which the customer would ask in their licensing templates. Now, this is heavily negotiated between the software provider, the cloud service provider and the customer as well, right? So here also there's an interesting concept where you restrict the credit pool, right? So if the credit pool is restricted, then yes, the customer is also happy that they are getting certain credits. There is certain, without going to the court also, you have some remedy here, where you get the credits and you don't have to pay for that much amount. As well as from the, if you have restricted the pool of credits, then the service provider also knows the maximum liability in this case, right? And this is other than the limitation of liability, which is anyways there in the contract. So this is about the online or cloud hosted software. Cloud hosted software again has a very, there is a very important aspect now to cloud hosted software as well. What is that? That being, let's say this cloud hosted software is for a hospital, right? Now this hospital will need to share personal information, right? In this case, the data privacy laws will kick in, right? If the data privacy laws now kick in, in that case, you will also now have to have a data processing agreement between the cloud service provider and between the software which is hosted on a cloud and yourself or the customer, right? What will it say? It will say that first, hey, you need to comply with all the applicable laws. Two, you need to have, you will use it only for the purposes of providing services to us. You will not use it for any other purposes. And if there is a breach to notify me further, if it is, if there are financial or payment related data, you cannot keep it outside of India. If it is outside of India, it has to be processed and deleted real time. So all these provisions, not getting into the details of that now, it's a whole other topic. But those are the things that have to be mentioned in the data processing agreement. Note that the data processing agreement is an obligation on the buyer or that is whoever is collecting the personal information and sending the personal information, right? Or deciding the purpose. So a vendor may say that, we don't need a data processing agreement, but it is your responsibility to sign a data processing agreement in order to bind the vendor so that some of the services that are being provided by them as part of your larger services that also gets covered and you kind of cover or mitigate your risks. So, yeah. Now cloud service providers will also have one more aspect which is an end user license agreement, right? And end user license agreement is nothing but what you click as I accept without really reviewing or not always reviewing the terms and conditions. Now there could be pitfalls there as well, right? What could be the pitfalls? Pitfalls could be inadequate scope, right? If you do not know for what purpose you're supposed to use the licenses and you go beyond the scope, then you are in reach of license terms. And mind it, many of the software, they have audit provisions, license agreements have audit provisions where they can audit your systems, they can audit your networks to the extent some of the software components also ping their servers back at their, ping their servers back with the customer which says that hey, I have been now installed in this computer or that computer and then the software manufacturer or the software developers or the software company will see, okay, this company has bought these many software but it is installed in many more devices, right? So that becomes challenging. So you need to know what is your scope, the number of licenses that you have. You need to read the terms. There could be issues with respect to termination provisions, right? What could be the termination? And especially when it comes to something like, let's say a Netflix kind of a service, I'm not saying specifically Netflix. You know the renewal provisions, right? Whether you are able to come out or unsubscribe of the services, right? Whether, you know, you will be asked before, you know, your money is being paid, right? So those are the kinds of terms which would be there. From a company's perspective, it could be a lack of, let's say warranty disclaimers and especially if you're a global company, what lack of warranty stores does is, some implied warranties which are there by law which could have been disclaimed by adding to the contract. Not all warranties can be disclaimed. There's certain warranties which could have been disclaimed. If you do not disclaim those, those also apply to your product and to the usage there. So you will be subjected to those warranties as well and that increases your risk. Then there could be a inflexible, let's say pricing models, right? In adequate security or data provision clauses which could be there. So all these issues then crop up if you're not feeding the end user license terms. So if you look at a cloud hosted software, there would be these three main agreements that you follow. One, just to summarize, one, there would be a SaaS agreement which would be basically an agreement between the end customer and the service provider. Two, there would be terms of use. Terms of use will define how each user will use the software, the purpose, the scope, et cetera. So those would be covered. Three, the service level agreement which I just described, which is how they will respond, how they will fix the uptime, the downtime, et cetera. In, just to summarize, in proprietary on-premise software, there would be a simple license agreement which would again define the terms, define the ownership, define the usage restrictions, define the warranties and the same as the limitations of liability, the termination, the governing law and jurisdiction. Those would be defined. And finally, the open source license aspects, including open source in certain software, like I said, is risky. You should always read which open source licenses being used. For example, GPL, AGPL, these are of high risk because they put your source code in jeopardy where you need to disclose those. MIT, et cetera, are licenses which are less risky and do not require your source code to be disclosed. So that's a overall or bird's-eye perspective on the different license models and some of the terms. I just wanted to understand as to because, I mean, how much time do we have or if we can take any questions, if they are there. That's true, whether we have any questions. I was seeing that you have made it understand in a lucid manner. So, no questions are possible. Okay. Yeah. All right, so I think, yeah, so that was, I mean, a very broad level perspective, of course, digging deeper into, we could be deeper into each of these, those would require further time, but happy to answer any questions if there's anything on participants who have joined in live or happy to take them offline as well. I just saw the YouTube as well as on the chat. They're none. Okay, okay. Thank you, Dheeshvi. Thank you so much. Thank you so much, Sivikas. Thank you so much, everyone for joining in live and whoever. And yeah, you know, happy to discuss, please connect. Happy to discuss any provisions, you know, which may seem a little complicated or which we would want to discuss, yeah.