Speaker 1  0:00  
Good afternoon and welcome to today's webinar novel models for software licensing of software content and data presented by Autumn. My name is Sammy Spiegel, one of autumns professional development managers and I will be your staff host for today. All lines have been muted to ensure high quality audio and today's session is being recorded. If you have questions for the panelists, we encourage you to use the q&a feature on your zoom toolbar. If you have a technical question or comment, please feel free to use the chat. Should you need closed captioning during today's session, the zoom feature is turned on and available on your toolbar. Before we begin, I would like to take a moment to acknowledge and thank autumns online professional development sponsors, Marshall, Gerstein, IP and the Michelson Institute for intellectual property. We appreciate your ongoing support. I now have the pleasure of introducing you to today's presenters. After 19 years at MIT us technology licensing office, Daniel Danny is now at Duke University's office of translation and commercialization, where he's at the forefront of intellectual property licensing and technology entrepreneurship. His chief focus is outreach, marketing and licensing of physical sciences and digital innovations and leveraging translational funds for investments in nascent technologies. Dan also provides strategic support for developing multi year corporate alliances, establishing new corporate contract fund partners, and negotiating IP terms for significant sponsored research agreements. Dan's IP experience spans patents, copyrights, trademarks, corporate license negotiations and patent portfolio monetization strategies and skills are well suited for translating research and technology into business and industry commercialization opportunities. Dinesh divakaran is regional vice president of partnerships North America with Oaken in this role, he leads our WD partnerships and collaborations for the French American unicorn with the healthcare ecosystem across North America. Dinesh has 15 years of business development experience in building partnerships, fostering innovation, commercializing technologies and developing ventures. Prior to joining oak International was vice president of healthcare business development North America at sensing health PLC. And before this, he worked as the director of digital innovations with the Office for translational commercialization at Duke Health and Duke University. At Duke Dinesh led the commercialization of digital innovations and data assets through licensing spinouts and collaborations. He also sat on the board of three startups had a short stint in venture capital as a fellow at alumni ventures, and over several years has received SBIR STTR grants proposed grant proposals as a panelist at NIH and NSF. Dinesh worked in technology commercialization and venture development at North Carolina State University, Texas a&m university system and University of South Florida. He has also served on the Forbes Business Development Council innovation committee at h AI NSS. And Cloud services and software committee and LEA is currently an executive in residence with the Duke Institute of Health Innovation Dinesh received his PhD in electrical engineering from the University of South Florida and his MBA from North Carolina State University. Welcome Dan and Dinesh I will now turn it over to you and Danna, let you screen chance to begin today's presentation. Okay, thank you.

Speaker 2  3:42  
As I look, perfect, excellent. Okay, thanks everyone is as I look out across the room, I want to thank everyone for joining us. That's a joke, can't see any of you. But Dinesh and I are excited that you've decided to spend your Thursday lunch with us. As we just heard, Dinesh and I bring decades of experience on the mat on the matter of software in general. And I have, I guess, a confession to make the title of this is novel models for licensing software, content and data. And I guess my confession is that not all of these models are new. They might be new to you, in which case, great, but some of these are sort of tried and tested, licensing models that we continue to use in the course of all the different types of assets that Dinesh and I have come across over the years and we thought it'd be good to share some of those with you, and to discuss some of the advantages and disadvantages of these models. What Today's presentation is going to do is kind of just give you meta information about these models. We're not going to do an anatomy of a license. We're not going to dig into any language terms. or conditions that would get sort of too much in the weeds. And we'd quickly run out of time. Because even looking at simple quote unquote, terms and conditions of agreements can sometimes spark lots of different variations of how it works at one university versus another. So our goal today is to kind of give you a sort of spectrum of different licensing models that we've seen that have helped us in the past. And hopefully, they'll be helpful to you, too.

Unknown Speaker  5:29  
Okay, some housekeeping. Stuff that we have to get out of the way.

Speaker 2  5:42  
Okay, there's Dinesh, there's me. Alright, so here's our agenda for today. First, we're going to discuss the different range of intellectual property assets that we are hoping to discuss today is going to include the world of software, but not just software, there are other content that is not necessarily tied to software. And sometimes these is called copyright. Other there's other names for it that you might be familiar with. And we'll have a couple of discussions about that. And then, of course, the the ever sort of looming world of data licensing that's trending right now. And we'll have a little bit to say about that. And then we'll kind of break into some of the models themselves. And I guess, if you want to think about it, well, we've broken these into sort of the beginner, intermediate, and more advanced models. And some of these, again, are just how we see them, they're not necessarily how you should identify them, something that we might feel is intermediate, you might feel as basic and vice versa. So let's not get too hung up on on those kinds of distinctions. And then we will try and close with some examples where we might change the names to protect the innocent. And then finally, some time for any questions that you might have about this. Alright, so let's get going. The first thing that we want to discuss in our licensing models, of course, is software. And I'm of the opinion that software is so ubiquitous now to what the research endeavor, that it cannot just be sort of limited to the software licensing folks in a tech transfer office, or if you happen to be at a company or sort of another organization, such as a hospital or data provider, whomever is sort of tasked with leading the efforts of the digital portfolio, that digital assets, I think that, you know, our time has come so to speak, and that, you know, software spills over into things that are no longer just the realm of computer science or electrical engineering. You know, we see it in, you know, biomedical engineering, we see it in biological engineering, we see it. in genomics, we see it in Health Tech, we see it in edtech, we see it in so many different ways popping up even Architecture and Urban Studies, and Civil and Environmental Engineering. Even social studies will often have computing models and simulations, which lend themselves to digital assets. So I think software is kind of a universal subject. And so talking about it makes a lot of sense from my perspective. And so it's good, I think, for people in general, not just specialists, such as Dinesh and myself, and those in the audience. I think generalist who are licensing managers should have a good grounding in these topics. So software, when we're looking at how to license software, of course, we're going to be talking about source code, sort of the big, most lowest hanging fruit of the digital asset. But we could also license object code or executable code. And you may have projects in your university that are more SAS, where there is some kind of, you know, web service being provided maybe even running on a on a university server that has out facing subscribers or users, where they come to input data or input some kind of question. And then the model runs behind the scenes and then outputs a certain answer to that subscriber or to that user. And so those types of examples do kind of create their own licensing models, they're not as straightforward as handing somebody a piece of code that they're going to take off and, and run in their local environment. There's also end use licenses. These are the kind of shrink wrap Think of them like in the old days when you would just purchase a CD ROM or a CD or a DVD with the code on it and bring it back and plug it into your machine and download the code and start running it as a client and you're in Vironment, we still have and use licensing at universities. We'll talk a little bit about that. And we contrast that against what I would call a developer license, which is where you're getting rights to not just use the code, like, you know, the way you can use Microsoft Office or PowerPoint, but a developer's license where you're getting access to the source code, so you can get in the code, change it, make derivatives, and then sort of distributors sell those changes as well. And that's, I think, is an order of magnitude different license agreement, and, and therefore has to have some different concepts in different terms. So we'll talk about that enterprise license, I think, similarly is usually a more comprehensive and bigger license, because you're thinking about it, through like the highest level of commercialization enterprise level, there's open source license models, of course, these can be sometimes very simple and easy as in just giving permission for someone to use one of the OSI approved licenses. But they can also get a little bit more complicated, particularly if you are kind of piggybacking on a commercial license with some kind of open source, as in a push and pull model for bringing software out into the world. So we'll talk a little bit about that. And then, of course, last but not least, sometimes you might actually license your software with a patent, particularly like a protected algorithm or something. And these combination patent and software licenses create their own unique challenges and opportunities. And we'll have a model that sort of fits that copyright other basically anything under the universe that could be non software content. Sometimes this takes the form of curriculum. I recently had an example of this, where we were developing some AI machine learning curriculum to teach courses and stem for, you know, like grades K through nine, or K through 12. And so all of this material, all of this content, which wasn't software, but it also wasn't a textbook, they were as a need to license it and sort of digitize it, and sort of make it available to different students both, you know, through traditional courses, as well as through like online courses. So this type of curriculum and course material, I think, is a good example, when you have these types of copyright other licenses, what do you do with them, you might have photographs or images or artwork that's created in your school, and people might want to have access to them either to reproduce or distribute, or to put them in other forms. So that's a different type of license, questionnaires, you know, intake forms, you might have very complicated questionnaires that might onboard folks in like your medical or health system. And these in and of themselves are certainly copyright protected and generated in the course of the university work, and so represent an asset of the university. And so what do you do when when folks want to sort of have access to those and do things like that. And this, of course, extends to Ed Tech, FinTech, health, tech, all of that stuff kind of can be swept into that data, I'm going to turn over to Dinesh who wants to talk a little bit about the different types of assets that data provides.

Speaker 3  13:27  
Thanks, Dan, I'm with data. I mean, some of it intersects with content in a way but or, or copyrighted data. But let's look at it in terms of two or three different aspects of data. One is raw data streams, these are not copyrightable. And what do you mean by copyrighted data? I mean, for example, in healthcare or medical image that is annotated could is considered copyrighted data. So you know, that's why I said, there's a lot of intersection with the non software copyrighted asset domain here. You can talk about polished and annotated data. For example, as I said, that you could have a medical imaging an x ray that's annotated by and specifically for the purposes of building a training data set for AI or machine learning. Very, very popular now talking about clinical data, data that's in the EHR. And it's important to realize that not all healthcare data is in the EHR. There's a lot of data that's outside the EHR and other in other domains. But you generally talk about medical and patient data. This is both point of care data and clinical research data. And, you know, structured data that is generally stated and structured in the EHR in a in a specific format. Unstructured data in the form of nodes were popular ways using NLP or natural Language Processing to process that data. And now there is a lot of interest among a lot of health tech companies and AI and drug discovery companies to look at multimodal data. They're talking about structured data on structured data, astrology data, genomic data, moleculer data. And as I said, some of this data is not in the EHR. Some of this data needs to be digitized, for example, if you're talking about histology data, talking about slides that need to be digitized. An important aspect when dealing with data. And we can use the healthcare example here is that is? Is it subject to HIPAA? Or is it identifiable data or is the de identified data? Now, there are different standards here. For example, if you're dealing with the US standard data, if you want to license data, it's generally advised that is de identified data in to be compatible with HIPAA. But if you're looking at, say, GDPR, in Europe, it needs to be both the identified and anonymized. Another aspect of data is you could compile data in particular formats, and I feel are using sufficient creative expression and building these compilation, it could qualify as a database, and then you could have copyrights on the compilation itself. So that's one aspect of data. So I mean, if you look at a real complicated database, a database of annotated medical images has a copyright on the compilation, but individual image, annotated images also have copyrights associated with them. So these are examples of complications that could come up when you are looking at these different forms of data. Also, an important aspect very important aspect. Have you built this data base or data set? You're on your own? Is it locally sourced? Or is it publicly aggregated by which you are scraping the internet and getting data from other sources? And then you have to look at do your diligence and figure out just like, where did I get the data from the Do I have the rights to compile the data within my database or merge it with my data. And those kinds of things need to be looked at. Also, when you're dealing with the search, you're going to be dealing with IRB compliance issues, and also what they look like with regard to releases and permissions. These hazards, these have impact not only on licensing data, but also on data access agreements, data transfer agreements, some of which do not fall in tech transfer domain in some of the offices but could be in research administration domain. But it's important to look at IRB compliance and look at the IRB document outs of consents and so forth. So that you are you are well informed when you are working towards licensing your data. I talked a little bit about regulatory body compliance, I mean, you're subject to HIPAA. In the US, when you're dealing with healthcare data, there are other forms of compliance that you need to deal with when you're dealing with financial data, or even data that's associated with children's, you know, those kinds of there are other kinds of laws that are applicable to that. When you talk about also now there are certain states that have come up with their own consumer privacy acts that cover data like California that I believe in, or Iowa has its own new Consumer Protection Act. In Europe, you deal primarily with GDPR. And it's still applicable in the UK. In Canada, it's PIPA and you have certain provinces that have their own consumer privacy laws that you need to be aware of. An important aspect I'm going to talk about a little bit is medical imaging. And when I'm talking about medical imaging, this can be DICOM images really associated with the radiology or other forms of medical imaging. But primarily what is important is if you're looking at radiology images, if they're just raw medical images, they are effectively not copyrightable. And they are in the public domain. It's very important to understand that aspect of it that just an x ray without any annotations is not equivalent to a person taking a photograph if person took a photograph that would have been copyrightable. But the medical image in its raw form is not copyrightable. But if it's annotated, the annotated medical image is copyrightable. So that's an important aspect of IP that you need to understand when you are dealing with licensing radiology images. There are other kinds of medical images like you could digitize pathology slides and create histology data. There are different IP provisions that apply in those cases. But in general, you have to be a little more careful and do your diligence when you're licensing anything that is just not structured on structure or data because there could be other IP provisions that you need to be aware of for licensing that kind of data. Extending more to the next slide, I think it's yellowest. Right?

Speaker 2  20:10  
I believe so. Okay, so now that we've gone through, what are the fodder for some of these licenses, let's kind of get into the models themselves. And again, I've tried to list some that I think kind of increasing complexity, starting with things that are a little bit more straightforward. And I guess for me, the the most straightforward of these are end user software licenses. Because these are fairly simple and fairly straightforward. And my experience, these are not very long licenses. And the grant is often just to use them, meaning rights to copy, make a local copy, and even make an archival copy. But there usually is no rights to distribute, and certainly no rights to create or own any derivatives. Because this is just like, you know, buying Microsoft Office out of the store and putting it on your machine to use. You're you're renting it and you're using it, but you're not owning it. And you're certainly not getting into the source code in order to play around with things. So these also can include a trial license or a test license, particularly when a company is not quite sure they want to purchase it, they might ask for a short option 90 day trial, in which case you can essentially give give them the rights to play with it along similar lines, and convinced themselves that they'd like to sign up for you know, the full end user license, the financial situation of an end user license, usually, if cash, many times an upfront license issue fee, it could be a one time lump sum license issue fee, send us $5,000 in his $10,000, and that'll cover the entirety of the license, you can set up annual payments, you know, $5,000, upfront and then $1,000 Every year, thereafter that you use it throughout the term, you can get a little clever or creative to say, you know, the term is indefinite until you stop paying. So if you want to use the software for the next 15 years, as long as you keep paying the sort of annual payment every year, you will consider you're licensed. And if you do not make that payment, we will consider you having decided you no longer wish to have the license, in which case, the termination clause will kick in. So you can kind of dovetail your term and your fees to that. But more often than not, it's an upfront one time fully paid up fee for a particular term, one year, five year 10 year, whatever makes sense for your particular activity. Dinesh, did you want to add anything to end user software licenses before we move on to open source? No, I'm good, you can. Okay. So I think another straightforward and kind of basic licensing model, but still very effective are open source licenses. And I'm sure many of you listening in out there are familiar with this. And again, open source can, you know, kind of evolve from simple to not so simple very quickly. But I'm more thinking of the straightforward open source licensing here. Your university may, in fact, like my former institution be very much involved in directing open source licensing, we would actually approve open source licensing for our researchers, they would identify the code that they wanted to put out on GitHub or to provide to the public, we would then go through a hopefully fairly quick vetting process to kind of clean things up and make sure we were comfortable with it going out and then actually issue a formal approval, which was just a letter saying it's been, you know, now approved for release under open source license acts that, you know, hopefully you've already worked out ahead of time. And what we were doing in this process was vetting for third party code issues, making sure that we weren't accidentally releasing someone else's copyrighted content, making sure that we had the appropriate permissions, or that we were building if there were other open source licenses embedded, that, you know, our code was correctly embedded into it and we were not in any way violating previous terms of open source licenses with our own contribution And then lastly looking at the funding and sort of sponsorship obligations that might have been affiliated with that software to make sure we were not, for example, usurping an industrial sponsored research agreement where we had obligations to a sponsor or company to offer them licensing first. And if we, you know, graduate student not really knowing put something up directly on the internet, guess what we're now not being compliant with that sponsored research agreement. So we'd at least want to make sure that we felt comfortable that the code that was going out was not just a pipeline, direct from, you know, over caffeinated graduate students into the public without at least having one quick way point, or a smarter short layover at the licensing office to lay eyes on it. And open source licenses. As we all know, we're not writing the licenses they pre exist. OSI open source Foundation, is the sort of housekeeping seal of approval when it comes to open source licenses, they come in different flavors, it's your job to pick which one best suits, whatever it is, your goals are, for that open source release. And you know, they can be varied from things like copy left canoe GPU, all the way to very permissive and sort of user friendly licenses, like BSD and MIT open source. And these are conversations that you would have with your researchers are ahead of time when they were thinking of opening it. And they do, in my experience, need guidance and help. Because all too often, they just pick a license that they think works or is in vogue, based on what their others are doing, or what the internet says they ought to do. And they're not always aware of some of the strings attached with open source licensing, in particular, some of the copyleft provisions and things like that. So having a conversation and sort of being transparent about, you know, some of the rules of open source, we're always, I think, welcomed by our faculty and by our research researchers. And it would always be driven by what the goals are for the release, like what constituencies are primarily intended to use this. So you're trying to service academics that you're trying to serve as researchers and you're trying to sort of thwart true commercialization, for some reason or not. And those would be conversations you can have, a priori. The last thing I'll want to mention about this is certain open source licenses that your university might be approving, might contain clauses that are worth a look by at least your licensing office, and perhaps your Office of General Counsel. Because there are increasingly patent clauses being added in to open source licensing, which seem innocuous, but, you know, they can be depending on how you read the language. And the language is often broad. How you read what you read into the language can potentially affect your university. And so things like the GNU GPL, v3, and other licenses, like Apache are specifically granting rights and patents that are affiliated or related to the code. And again, sometimes that makes sense, if you have a patent on x and you write software for x, it's not, you would not want to license the software in X without giving corresponding rights in the patent for x. Otherwise, you are kind of contributing to the infringement of that patent by releasing that code. But we're more concerned with examples where there's, you know, software that it does x, and then you have patents in your portfolio that are y and z, not necessarily done for that software, or even by the same team that did that software, but nonetheless, are in the same milieu in the same sort of area of what software X does, let's say it's perhaps software to help with automated driving algorithms. And if you have patents that are unrelated to this particular software, but perhaps in a broad level, read upon that subject. Are you inadvertently granting rights in those patents Y and Z simply by releasing software x. So something to consider something to think about particularly if you have licensed patents Y and Z exclusively and promised not to grant rights to others. And your long comes, you know, software acts by a different team, and it could be conveyed can be construed to potentially have some other patent rights being granted.

Speaker 2  29:54  
Okay, let's talk let's keep moving down the line. We have some another more licensing model that's becoming increasingly popular is equity only software licenses. And I'm not sure if I could pull the audience, I'd want to say how many of you have this at your home institution, or at least have heard of it. And I bet a fair number of hands would be raised. These essentially are useful tools for working with your computer science faculty are sort of doubly faculty and other software researchers, particularly ones that are wary about working with the tech transfer office, they might have these preconceived notions about what the tech transfer office does, they might have preconceived notions about, you know, software patents in general, and therefore, you know, want to release everything under open source, and then use that as a means for getting the software into their own companies, kind of through a backdoor channel, the equity only software license, I think, provides a nice sort of middle ground to say, you don't have to be you don't have to be forced to sort of backdoor your software into your LLC into your startup, we can do a very streamlined, simple negotiation for that software, in exchange for, you know, a little bit of equity. And I think this is a nice sort of middle ground, where the university acknowledges that they had some important end to the creation of the software, and therefore into the startup, and the faculty member or the entrepreneur acknowledges that, yes, you know, I can sort of give something back to the university and to the graduate students that perhaps assisted with the creation of this, and still not have it be too much of a burden, or too much of a hassle for me to go through in order to get my business up and running and off to brown. So in an equity only software license, and there's many variants, but they all seem to have some common themes. And some of the common themes are, you know, that you're essentially providing software assets only, no patents, I think patents would sort of kick this into a different licensing model. But if you're dealing with software assets only, and not necessarily enterprise software, but sort of the kind of software, where, you know, it took six months, maybe 18 months to have to rewrite, and there's a value in just getting access to this code. Right now, rather than having to be forced to hire new engineers that are not graduate students or postdocs and rewrite it, there's a certain value proposition there. And that value might be, you know, a low single digit percent of equity, we often will have no dilution protection in these licenses to protect that low single digit so that we're not completely diluted immediately. And that could be sort of based on some higher threshold of funding. I think the final point I want to make about an equity software only license is that if you get pushback from your faculty as to why, why are you doing this, you know, I don't feel like I need to pay this equity to you, I would remind them that it's very, it's very rare that these pieces of code sort of pop up out of the ether completely as an island. And oftentimes, they do involve students in the lab. And those students are not going to necessarily leave to join the startup to join that faculty members, you know, organization. And so having a small amount of equity that the university can sort of hang on to, will allow us to then distribute that, you know, proceeds back with the other inventors or people who are integral and in getting that software up and running. And so at this thing from, from an equity and sort of fairness model, it makes a lot of sense. And when we presented that argument to faculty at my former institution, when we were kind of pitching this idea, that was the one thing that I think, really made resonated with them and said, Yeah, no, this is right. Because, you know, I might have six students in my lab, maybe only one of them will spin out in the company with me. But those four or five other ones that stay because they have to finish their degree or they're otherwise interested in their own plans, you know, they also should benefit from their contributions to the to the code that we were working on as a team. And as equity, you know, once it's cashed out would be a royalty check to them, as opposed to perhaps nothing. So something to consider. Dinesh, I'm gonna let you sort of handle the next bullet on data.

Speaker 3  34:40  
Sure. Let's look at the data use agreements. We're not just talking about data license agreements, were talking about other kinds of agreements that could be associated with the data that universities do, for example, data transfer agreements, data sharing agreements. There are different ways to call this data access agreements. A Business Associate Agreement that generally healthcare, or an AMC or healthcare system signs with vendors is also a form of a data access agreement. So I mean, there are lots of straightforward data use agreements that are templatized by healthcare systems and AMCs and universities. And they're fine to do that. The the there are some that can be tied to different types of data. For example, a business associate agreement is generally extremely important when a vendor is getting access to bhi, especially when he's dealing with the healthcare system or a hospital. Now, an important aspect of it is you need a clear title of data is requirements. That is you need to own and control the data if you're providing somebody with us with access, or licensing the data. So the clear title of data is required, because the licensee is also going to ask for certain, you know, representations in the license agreement, if they're getting access to the data or licensing the data from you. Now, it's also important that certain types of commercial licensing of data, and right now we are looking at, for example, there is a lot of interest in licensing clinical data. But the lot of the for example, Duke has a policy on licensing and clinical data, and there is a clear policy on how revenue from that license is distributed. And there is there's a special provision within the policy for what they call us data answers. These are individuals who have actually kind of contributed in a creative sense and gone about both to develop to developing that specific database or data set. So in that case, it's somebody who's not just collected the data at point of care, like a nurse or practitioner, it is somebody who might be graduate students sitting in the office who spend hours annotating the medical imaging data so that you can build the training data set, and then they license that training data set. You know, when you see some revenue, you would like to make sure that the bat individual also is receives a reward as a data enhancer. In the absence of data and answer, there could be a policy of how it is played, almost all money, the general consensus, it goes back into research funds and some sort of a way. But, you know, data policies, and especially sharing and distribution of revenue on a data policies is relatively new. But it's it's increasingly being seen at institutions. This is in addition to other original data policies that universities have always had regarding research data. And there are a lot of the overall, because of a lot of change in the last two, one or two decades. Even those policies with regard to research data are being updated at multiple institutions. So it's important to to understand data policies, especially when you're licensing data, even if it's non healthcare non even if it's non clinical data, you need to make sure that you are doing your diligence with regard to just like you will do your diligence to open source software, and you make sure that you are following data policies, you could also be subject to certain provisions if say, for your in California, and you might be subject to CCPA for some kind of data that you're licensing out. So you need to be aware of these when you're especially licensing it out. And so internal policies, regulations, all of this is important when you're dealing with data use agreements.

Speaker 2  39:05  
Okay, okay. All right. So moving on. Another licensing model that I've come across is, again, something I kind of previewed earlier, which is the SAS model or software as a service. And this situation will come up sometimes, if your university or if your researcher is kind of running a web app or a web service, in other words, hosting some back end processor. And folks are hitting it, not necessarily from within your university, but oftentimes from outside your university. They're coming to a web page and they're, you know, essentially on demand, getting some processing done, and then taking that output out. And it could be many different things. I've seen it done in the context of you know, biomedical engineering reading and doing certain types of molecular structures, finite element analysis. But they all kind of serve this, the input is the data, the sort of engine or the machine that processes the inquiry, lives on a server oftentimes in the university system, and then returns this output to that web page, which is then used by the subscriber or user. And I think the first question that I often have about this is, should your university even be hosting the server. And I think if this is done in the context of research, there might be a grant, government or otherwise, to kind of drive this, it probably makes sense that the university is the right place for this hosting of this service. I think the question becomes more complicated, if there's talk of spinning it out or talk of commercializing that which this inquiry that this processing does. And it's at that point where things can get a little bit hazy, because you essentially have university resources, the servers sort of being used in both worlds research, and then potentially, with half a foot sort of leaning out towards a commercial plan. And I think that's when conversations need to be had about whether, you know, if you are in essentially developing a licensing model, to move this into a more commercial space, you're going to have to have that maybe unpleasant conversation about how the server and all of the university's sort of housing also needs to move out of, you know, university space and into more commercial, whether it be cloud or physical presence. And then another situation that has come up in the same scenario is what to do with all of the sort of users, the subscribers, the people who are bringing their data. And it can be, it can be tricky, because usually those folks are registering in order to use the platform, they're essentially becoming subscribers or members of the service. And there could be interesting data that gets collected about who these users and subscribers are not to mention sort of the repository or libraries of that which they're bringing to the table to these inquiries. And sometimes, what the company is also after, in addition to wanting to spin out the sort of processing machine, and monetize the output, is also monetize the subscriber information and have access to hundreds, if not 1000s of people in the public who have now come to grow to rely on this service. And an example in my former institution was, you know, there is essentially a tool that can help you create web apps very easily for your smartphone, I'm sorry, smartphone applications. And there were lots of different users from all different walks of life, who had signed up to be able to kind of quickly and easily without knowing a lot about how to build and code, smartphones, how to build apps. And so we quickly had 10s of 1000s of subscribers from all over the country. And we knew a lot about them, including sort of their sandboxes, where they built all of their tools, and you know, had all of their personal preferences for what it should look like and how it should be colored and how the fonts should go. And you can imagine that a lot of that data is very important, particularly if you are someone who's in the business of commercializing tools for the public. And maybe you want to sort of tap in to that subscriber base that data and then sort of sell them other tools or other services or things that might help them along. And so what we found was folks that were trying to monetize this, we're also very interested in getting access to all of the subscribers and all of the data that was being housed essentially, as a part of this research effort. One problem, you look at the terms of service, when we onboard them, we specifically said in the terms of service, that we would not use their data for commercial purposes, and you know, we would otherwise not, you know, exploit them or sell these subscriber lists. And so often, companies tend to do and so, you know, we actually had to explain to the potential commercial parties that you, you know, we would be perfectly comfortable licensing them the software so that it can be, you know, taken out of the university and brought into more of a commercial context, but we would not be migrating or porting the data and the subscribers over as part Have the deal. And you know that and, you know, may or may not affect whether or not that deal goes through for you. So the monetization models can get pretty tricky when you're dealing with this, if you have sort of something that is completely research and you know, indigenously researched from beginning to end, and it's the goal of the faculty member or their graduate student, to sort of bring it commercially from the onset, in other words, starting at zero, completely start over with a commercial, I think it's a lot cleaner than because you're not kind of mixing, you're just sort of providing a straight up software exchange, and then it's they that are going to go out there and try and build the commercial website and at lower and attract perhaps the research users over to the hopefully, more tried and tested and perhaps sleeker looking commercial version. So that's the play there, when you're dealing with sort of web hosting and web server tools, or sort of data input models, where they're just providing it input and then want to sort of get valuable output out. The next one on our list is what I've called the developer license or the enterprise level software license. And I think, you know, this is the license where, unlike an end user software, they actually do want the source code. And they want to be able to sort of live in the source code to change it and sort of make it their own and branded as their own and go out and either sell seats to the software or sell the software itself or sublicense the software. So, so to me, this kind of represents a very much more comprehensive license template. And the grant of rights is often the most expansive with sweeping in all of the rights of copyright and a few others along the way. And so, this is going to look like I think, a traditional patent licensing situation, where you have all of your terms and conditions, all of your range of financial provisions at your fingertips, right, you might have upfront fees, you might have license issue fees, license maintenance fees, you might have royalties tied to sales, you might have royalties, tied to seats, or subscriptions. But basically, anything is fair game and sort of developing, how this license will unfold. And if you're dealing with an enterprise level type of software enterprise level, meaning something that has already scaled, we're not just looking at, it works for five or 10 users, but we're hoping to kind of bring it to the level where you know, it can compete with Salesforce, or Microsoft, or AWS, there are there are, there might be few and far between. But there are pockets of code within universities that have been slowly honed and slowly perfected over the years, if not decades, often with federal funding along the way. And these represent very sophisticated, very complicated code bases that can scale and can handle heavy volume, and can sort of be commercialized fairly quickly. And I think when you're dealing with those sorts of assets, it's important that you really kind of give it the gravitas that it deserves and thinking through all of the different financial models that will work and not just limiting yourself to what you otherwise would do with sort of quick use code or sort of just get it out and hopefully have something come back. Dinesh, did you want to add any insights on the enterprise level software or developer license? Sure,

Speaker 3  48:53  
I think there was some questions from the participants also, I would say that an example of say, enterprise or commercial grade software is if your clinic clinical software developers developed a software for use of the healthcare system, this could be a clinical decision support tool or digital therapeutic or something like that. And if that has been retrospectively validated, prospectively validated and it's found its way into point of care, then that's, you know, well developed software that is commercial grade or enterprise grade. That it's not only for health tech, you're, for example, your Educational Administrators or developers within your IT office at the university could develop software for use for ad tech or educational administration or something like that. And that could be very well developed software that you know, that has taken years and a lot of investment to double weapon that could be commercial grade software. So that is where you distinguish it from software that's just been developed for, say, research purposes that has not been translated beyond research purpose. Of course, even that, like Dan said, research software, if you start building capabilities over several years, it could mean it could one day get translated into enterprise grade software. I think that's an important criteria to understand when you're making the distinguishing. So when you're licensing that kind of software, there is a wide range of pro financial provisions that go into that kind of license.

Speaker 2  50:35  
Yeah, excellent point. I think another example, at least is, and I think the medical sort of software is a great example, if you have sort of anything that resembles a medical school or some kind of health system, you're often going to see software that's been, you know, built and honed and tested, and maybe even actually run in beta within the hospital environment. And that certainly, I think, brings it further along to technology readiness level, my former institution, we had a lot of research centers and institutes often funded well by the federal government, and particular some that were sort of interested in defense projects, servicing, you know, the Air Force and the Department of Defense. And these are constituents where things have to work. These are not just sort of computer science, graduate students coding something up over a long weekend with, you know, a lot of caffeine. And these are programs that have been developed, in some cases, over 10 years, with government agencies as the end user, and they are, you know, by rule, need to work and need to work well. And so things of that sort things that weren't, you know, came out of Lincoln Laboratory at MIT, these represent enterprise level platforms. And they might have a commercial equivalent, particularly in a cyberspace environment, right, where you're trying to understand vulnerabilities to networks, and how sort of malicious parties might hack into certain networks, things, of course, that the Department of Defense is very much interested in, in, in developing, promoting and using, you could see how something that was built with 10 years of DOD funding might have a commercial play for cyberattack in the commercial sector. And to me that that would be an example of an enterprise level software, as opposed to just some, you know, insight that a computer science faculty member had used a graduate student to, you know, code up something six months later, and that was hoping to sort of get some traction with it in the marketplace, different story. All right. So now we're moving on to patents and software licensing. And these I think, come up more often than not. And I'm not going to get into any of the backstory of the difficulty of padding software, and Alice and all those other things that, you know, many of us have heard or have been exposed to elsewhere. I will just as an assumption, assume that you know, for whatever reason, you've decided that a patent on the technology makes sense. And you've sought it and might be pending, or it might be issued. But in any event, you have some patent asset. And there's also some code that goes along with it either to implement the algorithm, or to sort of act as kind of two sides of the same coin. I think in those situations, you're dealing with a the most advanced licensing model, but there is, and in some places, this actually might be one agreement, as in a patent and software license agreement. I have also done in the past, separating these out into two separate license agreements, a sort of license to the patent and a license for the software that get obviously negotiated in parallel, but again, two different contracts. And why in the heck would we do that? Well, if you actually look at what goes under the hood of both, there are some nuances, right. The grant of rights in a patent license is not identical to the grant of rights and a software license. There are different terms of expiration, there are often nuances in the reserved rights, there are nuances in sort of the limitation of liabilities, and even in some of the indemnity language, reps and warrants can sometimes be different for copyright as opposed to patent. So you have a choice. You can either generate one agreement that kind of houses all of these under one roof, making sure that you have different language in the appropriate parts to cover sort of these nuances and not just conflating them all into your patent boiler template, or you can separate them out into two Make sure that each two are covered separately. Disadvantages to separating them out and handling them separately, of course, come up when you're trying to figure out how to charge for this, because the licensee is certainly not going to want to sort of split the money between patent and license, they're going to want to just pay one hole to cover the technology capital T, that they feel that they are getting from the university. And so how you kind of cleave the right financial provisions, and make sure that you're not double dipping becomes a challenge when you you know, bifurcate, and separate these into two different licenses, but it can be done. And, you know, I've certainly done both in the past with MCs degree of success. I think one other thing that needs to be paid attention to carefully in these sort of arrangements are your definitions of sub licensee, and what it is to actually sub license. And this is because sublicensed and sublicensee has a slightly different meaning in the world of software. I mentioned before, like when you go out and you buy Microsoft Office, you know, from the store, you don't actually buy Microsoft Office, you don't own Microsoft Office, you're licensing Microsoft Office from Microsoft. And you might own the sort of physical instantiation of it, if they're, let's say it was a CD or a DVD, if you can even still find those anymore. But in certain situations, you know, the first sale doctrine applies to that CD or that DVD that if you then sort of pass it on to someone, you're you may be able to but the underlying rights in the software do not transfer. And this is why you are only licensing, you know, Microsoft Office, you are not owning Microsoft Office. And so when we license software, we are often by definition, you know, sublicensing are our end users. And if you then plan to sort of have other tiers, or other users, your customer might need to essentially distribute it to its customers, then you're dealing with sort of different tiers of sub licensing, and it can get very confusing. But in a software license, we're used to that. And we have sort of language to sort of carefully define that. So it doesn't get confusing when you then combine that license with your patent license, and what we think of in the patent world as a sub license and sublicensee. That's when sort of trouble happens. Because these things can kind of really get confusing and overlapping. And so my recommendation is, make sure your definitions, you know, are concise. If you're combining patents and software into one license, you might even want to introduce the concept of a patent sub license versus a software sub license. And make sure your definition of sublicensee corresponds to which one you mean, if you just use sort of the sublicense moniker, whether capitalized or not, I think it's going to create confusion. And if it's going to confuse the folks who are drafting the license, just think of how confused the people actually downstream of the license are going to be when they're trying to interpret the license. And they weren't there sort of drafting it and weren't privy to all the emails and conversations that tried to hopefully explain it. Okay, flexible range of financial provisions. This, again, is going to be you know, wide spectrum of choices available to you because this is sort of the granddaddy license, right. So you've got all of your levers at play Cash, royalty, sublicense, income, equity, etc. One of the things I mentioned when I would split a patent and a software license out, I would sometimes in order to avoid double dipping or to avoid sort of the cash essentially being used in both agreements with a comment that says, you know, these, these payments are meant to be, you know, one hole not individual per license is, you know, I have done some where I would take the equity for example, that I didn't otherwise put in my patent license, take it out and put it into the software license. So I'd have royalties and cash and other sort of fees based into the patent license the equity in the software license, just to kind of separate the two and have a natural cleave point. not recommending that that works in all situations. Just giving you an option of something I've done in the past. More often than not, I tried to keep the all of the financial position provisions identical in both, again with language that said this was not meant to serve as double dipping 5% and patent and 5% of royalty and software does not mean we're collecting 10% It just means that you can sort of game it where you kill one agreement in order to better your royalty situation by keeping the other one alive.

Speaker 2  1:00:09  
Something else to consider when you're dealing with patents and software. Of course, we know, patents expire much sooner than a copyright. And so what happens to the license and the rights, more importantly, the money once that patent has expired, and you need to make sure you have some consideration of you know, that situation unfolding. And something to consider is, while we do not recommend keeping the royalties the same for patents and software, in the event of a patent expiration, that could be seen as patent misuse, having a royalty step down, I think, is perfectly natural and perfectly in order. When a patent expires, for example, let's suppose your patent and software royalty is 5% of net sales of licensed product. And once the patent expires, let's say hopefully, you know, 20 years into the future, you then are left with just the software. And the software can be essentially a royalty step down that goes from 5% down to two or 1%. Acknowledging that software, that is that old is likely not going to have quite the same inherent value as it did on day one. So some some things to consider some tricks to consider. Another thing I think we need to consider and those arrangements are, you know whether or not you have an exclusive versus non exclusive for all software for all patents, you know, are you going to sort of like pencils, in your pencil case, choose which assets are being licensed exclusively versus non exclusively, you do have the ability, for example, to license the patent exclusively, perhaps the software non exclusively if that's to your advantage, or some other arrangement that makes sense. Nash anything to add on that slide?

Speaker 3  1:02:05  
No, I would just say that just to follow up on what Dan said, it's also possible, especially when you're dealing with the software licenses to separate end users from sub licensees. So you could lose language to say that sub licensees have broad copyright rights, you know, for to modify code itself, however you want to define it. But you could define end users separately and say that they are, though they are sub licensees in a legal sense, they are being treated separately because they would not. You can't expect sub licensees to sign up to your indemnification and warranties language, so you could separate that and an agreement also.

Unknown Speaker  1:02:46  
Great. Alright, this next one's you Dinesh.

Speaker 3  1:02:48  
Yeah. So we're going to cue advance novel models, however you want to call it we have worked on. One is this concept of a third party services agreement. And I had done some of this when I was at Duke and it was successful and work. And we tested it out, you know, via JBS universities are generally restricted and, and even if your nonprofit AMC, some healthcare systems are generally restricted from providing services, due to various regulations, sometimes state sometimes federal, sometimes policies and out the university. Now, it's possible that you could enter into a partnership with a local dev shop, which is a software development shop, this could be a small business or medium size business that could be local, or it doesn't need to be local, where you enter into an agreement with them to provide services in conjunction with your licenses. So this, what happens is the you know, whenever you're licensing software, it's very much required that you need to provide services, this could be customizations, this could be add ons, this could be functionality improvements, all those kinds of things, or day to day, answering emails regarding from the licensee, all those kinds of aspects. And so you could reach an agreement with the dev shop and they could provide the services, lies and when you license the licensee generally receives the software from the university, you could still be doing the software license via and then tie the services to what has been provided by the from the dev shop. It's actually a win win for both the University in the dev shop because the dev shop gets business. And they they want would love to partner with, with universities in which they get repeat business. I mean, if they have a software and you have 2015 20 licensees that require services, that's a win win for both the University and the dev shop. And you could also you can get royalties and services, revenue from the dev shop from whatever was provided and this this can be pretty significant to now. One of the open questions Then we have tried it out is, can you provide services on open source software. And there are some ways, especially if you register a service mark associated with the software. And in Ember, there are complications, you need to know how to set up a control mechanism to make sure that you're that you are vetting the quality of the service, and so forth. And there are mechanisms to do that. But you could do that in that sort of fashion, even to provide services on open source software, not on everything. But things where you have repeat customers, multiple licensees out there, you could use these third party services agreements, they can be exclusive, the generally, dev shop prefers some some level of exclusivity, because they want to be sure that you're not signing up for dev shops to do the same work. But yeah, you could, most some of these agreements we have done have been what we call us exclusive services providers agreement. Then if you can go to the next slide, please. There is another agreement that you could use, which we call as a joint copyright agreement. Generally, I've used it only for software and content or copyrighted content only. It's generally where you know, there's no, we're not talking about patents, because inventorship is, comes later, we're talking about two organizations, generally a university healthcare system, or a company that has worked collaborating together to develop some innovations of software. And that could be that you could come up with and say that the copyright in the software code or the content is jointly owned between the two parties. And but all commercial rights are consolidated with the company. You want to call them a licensee, you can call them a licensee, but they're not actually a licensee, they're joint owner of the IP with you. So you are effectively you know, you, you know, you are all the commercialization rights is with the company, while you retain sir, as a university in certain limited academic and research rights to the software, or the content that's created. And this, we have used this with a couple of vendors that have approached the universities and for the healthcare systems. And they have wanted to pilot and develop software together with us, or even with, for example, to spin out startup companies, where we effectively had somebody come in who are already set up a startup company, but wanted to develop a complementary product with us or something like that. And we I mean, the range of financial terms could be the you could get equity in the company. So in the startup company, there could be royalties, there could be revenue, coming back, all those kinds of things. It's very analogous to an inter institutional agreement, but it's different. And you could you could use this agreement to in collaborations with the with commercial companies, as you. And that the next slide, please. So I'll talk a little bit because this is very popular now, again, especially for licensing clinical data. But a lot of these lessons apply to general data to one of the most important things is when you're licensing clinical data, is to make sure that you're licensing, not data non exclusively, sometimes you could do other things like there are there are examples where you have exclusivity, time to try, you know, there's exclusivity for a certain time period. Generally, we try to stay away from that as much as possible. But real exclusivity for clinical data restricts the ability for us to do research. And so that's not advisable. So we prefer non exclusive licenses. And generally we prefer licensing de identified data, as per HIPAA provisions versus pa if it's bhi, it's a limited data set. We, it's it's advisable to use a field of use within the license agreement when licensing clinical data, understand what the licensee wants to use it for. And to include that field of use within the agreement. The term is extremely important. How long are you licensing data for? Is it five years? Is it 10 years? Or what happens at the end of the term? Do they destroy the data? Do they keep on copy for archival purposes? What do they do? Those are important things territory is extremely important when you're dealing with clinical data, preferably advisable to keep it to the United States. And even companies if they want data or your own access to the data, you should keep it within us servers and they can VPN in or something like that and get access to the data. That's because when you send data to Europe, you will be subject to GDPR and other provisions. And also there are sub there are database rights in Europe that do not exist within the United States as IP rights and there are complications regarding that. So it's generally advisable that you keep the territory to the United States sublicensing rights restrictions you just don't want somebody to sublicense the hell out of the data. You want to make sure that it is Properly sublicense to maybe an affiliate or something like that, but not restricting any further sublicensing. So you can have control over the data, derivative rights on copyrightable data and databases, this is important, you want to make sure that any annotations or medical images are not removed so that your data doesn't go back into the public domain, you want to make sure that appropriate derivative rights are protected, and how, you know, person can add more annotations, but cannot remove existing annotations. These are examples of terms that you could put, most of these are protectable, not only under copyright law in the provisions, but also in the contract law in your contract, as he put it out, these are some of the best practices, we have generally followed when licensing clinical data. Some of these could be applicable to other forms of data to then Next slide, please. Now talk a little bit about dual licensing data dual licensing, and you can use this for data, clinical data also, you could any data that is copyrightable, or databases, you could use Creative Commons non commercial licenses to release that data for academic research purposes. And the non commercial aspect of the Creative Commons licenses, I can talk from experience here, a lot of commercial companies will not download the software, actually, I have heard companies advising employees to, to not even download that kind of data on their personal computers. And, you know, just kind of like if you put a non commercial clause, you can pretty much sure that a lot of commercial companies are not going to download and use your data for non academic research purposes. So you could make the data available publicly for academic research purposes, which is required as per your mandates, but you could then do commercial licensing at the same time. So, you know, we have done that we, we put a breast tomography data set out while I was at Duke, on, on the cancer imaging archive on a non commercial license. And we also did commercial licenses for that same data to startup companies and even large companies. So do your licensing of data where you are, you know, just like you can do a license software, if you choose an appropriate open source software package, you might be able to do licensed software depend, of course, a lot of considerations you have to take into account. But you can do a license data in this sort of format, meet your obligations to release data for academic research purposes, while also commercializing data at the same time. I think, yeah, let's go to the examples. Okay.

Speaker 2  1:12:44  
Yeah. So. So now, a couple of quick examples, just to kind of bring it all home. We've already talked about a few examples, while we were going through the models, but for End User Software, again, I see a lot of this with, you know, numerical solvers, sort of engineering models, Fourier transforms, turbine and airfoil analyses, finite element analysis types of code. This is essentially just pay to play, right, someone wants to use this tool, again, you know, just like they want to use PowerPoint, and they want to buy it off of Microsoft nonexclusive, these are commercial licenses, oftentimes, I'll license these for a one time fee, you know, 5000 10,000 15,000. And these are, you know, licenses just to use on their own shrink wrap licenses, standalone licenses, they're not necessarily meant to be embedded or inter woven into other product software, other clients software, although there are exceptions, we have a tool that we call the fastest Fourier transform in the West. And this is a by its nature, this is a thing that helps with signal processing. And so it gets embedded into applications that involve analysis of signals. And so it can be used for audio applications, it can be used for all kinds of signal processing applications. And so as such, we allow this particular code to kind of be incorporated in to other client offerings, and then, you know, purposed and packaged and resold, but our but our royalty structure reflects that. Like another example, often called a hybrid software license, hybrid, not necessarily meaning patent and software, but hybrid. In this case, as in, you know, it's the same asset it's software, but we're releasing it under two different licensing models at the same time. One is open source, one is commercial, proprietary, and the goal is to try and use one to aid the other. So we use open source, you oftentimes copy left to release code to facilitate sort of academic and research use, because academic and research use usually not have any issue with sort of copyleft terms like under the GNU license. However, companies do not generally like copyleft terms, it potentially risks them having to release an open their proprietary code openly depending on how they interact with it and link to it, things like that. So if you're a commercial entity, you will often want to pay for a closed quote, unquote, license, proprietary license that's, you know, a traditional bespoke license that your tech transfer office will do. But you can use the two again, together, either one to serve the other constituents, even on corporate constituency, or the company might actually learn of the code through the open source channel, and play with it. And let's just say a isolated sequestered sandbox that doesn't necessarily, in fact, them and then when they're ready to sort of graduate into a more commercial use license, they come knocking on your door and ask for the commercial version. And in this case, what we would do in my former institution is kind of keep the code bases separate, making sure that the open source software had its own channel to evolve, if there were changes that were being brought in from the public or other open source users that were not necessarily being generated from my former institution, you know, they could sort of evolve nicely in their own area. And then a more behind closed doors, if you will, version of the code that we would keep proprietary, that would not necessarily port any changes from the open source. Fountain, in order not to create conflicts or other types of issues, that we could then license companies when they came knocking for the closed version. So having I think this separation helps keep it clean. If you are not keeping your code bases separate, you can create a situation where you're inadvertently commercially licensing things that might have open source contributions from you know, folks that are outside your university environment. Alright, Dinesh, I think this one's yours.

Speaker 3  1:17:30  
Yeah. Then we talked about those third party service agreements, as I said, we have examples where we have licensed software to help tech companies. And these companies have been both small and medium sized companies who have agreed to these third party agreements. At tech companies, even software startups would, as we decided we're not going to name the companies here. But, you know, you could also have also used these giant copyright agreements with some of these examples help get tech software companies. It's a you know, given that, at Tech is something as unique as universities that we all have expert, strong expertise in health tech, when you have an AMC or healthcare system, you have strong expertise, and it's quite natural that the kind of software you're developing this domain would be, would be, could be would be rolled up, loved, validated, tested, deployed, be beta tested, beta tested, and then you know, used in at an enterprise level. So these kinds of agreements can be useful when you're dealing with those kinds of grade of software. When it comes to data licensing, I'm going to talk about clinical data here again, there are examples of licensing structured and unstructured EHR data that we do DICOM images, they bring their own level of complexity, because you not only have to de identify the meta data, but also the image at a pixel level. And you know, there is software out there that could do some of this. And there are, there are universities and AMC is developing software in house to do some deification, with DICOM images. With historical and genomic data. Again, these data are not in the EHR historical data even needs to be digitized. The slides only exist in a heart format. And we need to go through digitization for a molecular tumor board data could be in PDFs, and that, again, is not in the EHR, there could be another pace and then figuring out what that is licensing. PHR try to avoid it as much as possible. But if you're licensing PHR make sure you have the consent to license that PHR, I mean, that's the most important criteria.

Speaker 2  1:19:49  
Do you want to define PHR for those in the audience that might not know which means So,

Speaker 3  1:19:54  
patient health information actually subject to HIPAA weather identifiers that help can help companies identify patients and potentially release private information healthcare information of these patients. If you need, there are there is one or two examples in which we are licensed PHR. But we went back to make sure that we had the concepts or we we consented the patients before we license the PHR. But it's very important to make sure that in a licensing bhi that you're dealing with very limited data sets, and enterprise grade level data pulled from the entire AMC or the healthcare system. So I mean, just overall, these are some of our experiences dealing with licensing data.

Speaker 2  1:20:42  
Okay, I think that actually concludes the majority of the presentation. We made it through together congrats, everybody. I believe there are some questions in the q&a, which I will migrate over to look at real quick, if you have a question that you'd like to ask, I guess you can start to put it into the q&a, and we'll do our best to answer as many as we can. Time allowed. All right, so let's see question. I'm not sure if I'm going to go in order. But Oh, Cindy. Hi, Cindy, Cindy asked when you have to vet open source going out? Is that process through the general disclosure process to the PTO or something else? If I didn't mention that directly, it's actually both it starts with our intake, our disclosure form our we have a specific software disclosure form. And we would ask a question on their into Do you want this released as open source? Yes or No? If they check, yes. Then another question would be okay, what open source license would you like to use, we would have generally point them towards the ones we'd like. And, you know, if they create if they selected one, for example, with one of those explicit patent grants that we talked about earlier, we would sometimes then advise them why we can or cannot move forward with that particular choice of license. But the other thing that the form had, which is Uber important is we would have them list all their third party codes that's on or embedded in their disclosure. And so they would list everything that's not that they did not originate. And hopefully list, you know, where did it originate? Who's the copyright holder? Or at least, you know, what license? Do they know that it's been, you know, brandished under, and then a link to that license, so that we could follow up and just kind of vet that third party code by looking at those licenses and making sure that either the rights for us to you know, modify, and redistribute are there or if not, you know, we'd have to go back and have them remove, or otherwise, you know, figure out a workaround for that. So it's the intake form would help us with the initial request, and also some of the basic information, then after the intake form is submitted, and we have a case, we then have conversations with them email or other, we work through all of the issues, get it to the point where we're comfortable with it, and then issue this letter from the tech transfer office that says, Okay, you it's been approved, you can now upload it to GitHub, or, you know, bring it to the public however you wish. Okay, another question looks like may have been answered by Dinesh. But how do you handle financial provisions for software patent licenses? If the software developers and pan inventors are not the same people? And I think the, again, looks like Dinesh, you provided a, you know, an answer that talked about different royalty rates for software and patent. And I think the way we would sort of answer this, I would answer this is it's likely that there could be differences between authors and inventors, as we would call it, because not everyone that writes code is necessarily contributing to the to the patent idea and vice versa. For example, your faculty member, your PI might be listed as a, an inventor of the patent, but may not solely themselves without actually writing any code, right? How dare they lower themselves, and the graduate students would actually do a lot of the writing of the code. So on the sort of disclosure form, we'd have a patent case, which might list the faculty member and perhaps some subset of the graduate students who can, you know, can help conceive of any of the claims. And then I saw a separate software case, where we would just be the authors who helped contribute to the code and not necessarily the faculty member. And so the, you know, we'd start out with a standard distribution one over n. And if there were any changes to that, that we had to make, you know, we'd have to obviously, you know, explore that and make sure everyone was in agreement with that. The the actual split of money between the cases like let's say A there's a patent case and a software case and $100 comes in from the licensee, how that $100 gets split to the patent case in the software case, but also be, I think subject of a conversation is the, you know, which one is sort of more important if it's, it's easy when they're equal. And you can just say 50% goes to the patent 50% goes to the software, and then you will distribute to those inventors and authors according to your own university distribution plan. But it gets a little bit more interesting, if you know, the argument is the patents worth 70%, the software is just kind of a quick implementation, maybe it should only get 30%. I've also seen it flipped, where the software is actually kind of more important, because it's works big enterprise level code. And you know, the patent is just there to attract investors and VCs, but, you know, not really sure whether or not the patent would survive any kind of legal challenge. So that's how you would that's how I would deal with that. Next question, if companies interested in licensing a piece of software developed our organization, but also wants to know how from the faculty, how do you factor in faculty know how and a license? And Dinesh also answered that online? I'll take a stab at adding No, how is a very, I think, it's it's a fact of life, we're gonna have to sort of deal with know how I've always wondered exactly how to define know how, because we're not allowed to actually claim that we own what's inside all of our faculty and students heads, you know, that for the most part is what they bring to the table, and often what they're doing in their private time consulting and doing all that other stuff. That being said, if there are clear cut ways of defining know how as Dinesh has said, you can otherwise put it in a license, but it should not be something that is otherwise covered under their patent otherwise covered or covered under a copyright, or, you know, otherwise covered under some kind of trademark. And so what you're left with, is this kind of nebulous ether of in between squishy stuff that you want to call know how And sure, I guess if, you know, you want to put it in the license and say that, you know, we're providing it, we can but again, I generally never been super comfortable with licensing know how, certainly not exclusively. And, you know, for the most part, I would leave that for our graduate students and faculty to work out separately privately, through consulting arrangements and things like that. Okay, moving over to some more questions. Could you share your experience on terms related to licensing software for nonprofit entity or licensing software to an entity that wants to integrate the license software with their own? I'll start with the second one, maybe Dinesh, you can answer the first one.

Speaker 2  1:27:53  
Certainly, it's very common for licensees to want to integrate the software that they're licensing with their own, in some respects, that's, I think, why they're coming to license the software, you know, they want to package it or repackage it, remix it, repurpose it, and then put it out with their own trademark brand on it. So that makes sense to me. And that I think, is very common. And that's why we have license agreements, the ability for them to do that. Now, what this creates, of course, is an issue of what what's going to happen to that derivative, that derivative that the company is creating, think of it like layers of an onion, you're providing them sort of the core part of the onion, they want to put some layers around that. And that represents potentially their own work, their own derivative, and who's going to own that derivative. Now, in my old institution, we would let the company own those derivatives. Because we felt that was part of the quid pro quo of what they were paying for, by licensing the baseline anyway, I know Dinesh, you have a sort of opposite view where, you know, in your old agreements, Duke would actually own the derivative works that were being created by the companies and Duke would retain ownership of those changes. I think regardless of where you fall out on who owns the derivatives, you do need to marry it back to your royalties. Because if you're not collecting royalties on derivatives, then what you're essentially doing is incentivizing your licensee to start changing the code on day one of the license and sort of undercut or remove you from the equation as quick as possible. So if you license them x, you give them the ability to create y, but you're not charging a royalty on Y. They're going to start moving towards creating y as soon as possible, and then eventually get out from trying to pay royalties on x, because they've essentially argued that they're now living in wild land. If you have a royalty structure that says regardless of whether you you create a derivative or not and regardless of who owns it, you're still going to pay a royalty on it than that. Question is moot. Because you're saying we're giving you the Head Start, of course, you're going to do better things with that code embedded into your own, make it better, faster and stronger. But you're going to acknowledge that we gave you that Head Start and push to get you there. So you're going to obviously pay us some portion related to the program and some portion related to that derivatives, where you want to sort of down grade the royalty on that derivative over time, as a separate question you might need in your agreement, where perhaps, you know, five years out 10 years out, those royalties get lower, acknowledging that companies putting more and more of their own imprint on the code and relying less and less on that which they licensed from the team within the university. I've also seen it reversed, where, you know, we're expecting them to create it, you know, and do something better. So the royalty goes up over time, because we're taking a risk and giving it to you at this early stage at a very low price. And so as it becomes more well oiled, and services, the sort of customers better, that's when the university can finally sort of share in the upside of it all. So good question. Dinesh, why don't you take a stab at licensing nonprofit entities? Or the next question, which has to do with perpetual license of source code.

Speaker 3  1:31:23  
We have some experience licensing software when I was a due to other universities that use the software. These are other nonprofit universities that use the software for, so I'll put it in the ad tech category, but it's more Yeah, so you could do it as SAS licenses, you could do it as there are some problems that you have to deal with. But the terms of the license generally are payment based, they pay an annual fee, a year to use the software. So I mean, pretty much. IBM also licensed software, for example, to a federal lab, and I would name the federal lab, but we actually use a third party services agreement to provide the services to the federal lab while we license the software to federal lab. So there are different ways you could do this. When your license is off. All

Speaker 2  1:32:21  
right. I know there's like one or two more questions, we'll probably try and respond to those separately via email, because we are pretty much just over time. And I want to be respectful of everyone's day. So thank you very much for your time. Sammy, I'm going to turn it back over to you for the final close up.

Speaker 1  1:32:38  
Yeah, absolutely. Thank you. And I know attendees, there's lots of good conversation happening on the autumn Learning Center, where you'll get the recording access for this session, I'll make sure that discussion board is also turned on. And Dan International, make sure you have access to that. So we can also continue the conversation there if you're looking to get more of your questions answered. And on that note, I just want to say thank you both so much for leading such an informative discussion. It sounds like we could have multiple webinars on the topic and have enough to talk about so maybe we'll have to get you back soon. And attendees. Thank you for your participation. As a reminder, the recording for this session will be posted within a couple of days on the autism Learning Center and it is included in your registration fee. We'll also have a slide handout available for you there as well. And please remember to complete the evaluation which will open automatically when the session closes out. And last but not least also to help continue the conversation today. Don't forget that the software course will be happening live in person in Baltimore on September 19. And 20th. Registration is open online on the autumn website underneath the autumn University header. So you should find all of that course information there. And with that, I will say thank you all so much, Dan and Dinesh thank you again for leading the conversation and I hope that everyone has a wonderful rest of their afternoon. See everyone soon. Thank you. Bye

Transcribed by https://otter.ai