 Thanks everyone for having me. I like to talk a little bit about copyright and licenses, and then open source clients and responsibilities and finally about open change. If you do that, maybe a great background. I'm a lawyer by training. I started my career in licensing and especially open content and open source licenses a long, long time ago when I was international to add comments. Today, I'm a strategic advisor at Envision, which is a Daimler subsidiary working on software for the project. I run a company on the side called the Software Science Academy, and I'm also a strategic advisor to the OpenChain project, which is one of the reasons I'd like to introduce it here today. For disclaimer, I'm not speaking of Envision, because Envision decided to sponsor this event after my talks proposed and accepted. I'm grateful for being part of this today, but everything presented is my own. Thanks. When we talk about copyright, probably almost every post at software is protected by copyright. That means that the creator, the author, basically the developer or the exclusive right to decide what to do with the software. You may all be very familiar with this little icon, the C in the circle, which is originated from the US and it basically means all rights reserved. If you want to use the software, you need to negotiate and agree a license that gives you the rights to use software. You read that with many projects that are out there and available somewhere on the web, whenever there's no license attached to the software, basically the default is that you are not allowed to use it. So you need a license that you what you can do with the software. The particularities for open source licenses is that they are standardized and therefore they should be easy to read and to memorize, even if that's not the case for today's licenses. They are a direct license, meaning the rights are always granted from the developer directly, even if you may receive the software itself from a third party, which could be a vendor. So you can receive the software from any kind of people, but the rights come always from the developer, from the creator or the author of the software. In the European context, at least in the continental European context, an open source license is also a contract. That means that by offering the software under a license, you basically give someone the offer to use it and that person can accept the offer by using the software, which can be done comprehensively. So you don't need to sign anything, you don't need to officially accept anything that's being done just by using the software. This is the concept of open source license and this is officially recognized by many different German courts. I think the first court decision to deal with this kind of analysis was the District Court of Munich back in 2004. So this is a very old concept and there's no doubt about what open source licenses mean in the German context and the European context and especially also in the US context around the world. So most of the open source licenses grant very similar, even almost the same rights and that's defined by the Four Freedoms according to the Free Software Foundation or if you look up the open source definition, you will find that almost all open source licenses give you the right to use, copy, distribute and modify the software. However, most of them come with different obligations and some of the very familiar obligations are the copyright notices that you have to provide or you can provide the source code to make the source code available. One of the more complicated ones is the so-called copy left but there are different license obligations depending on which license you are looking at and that makes it somewhat difficult. Most context or most companies I've been working with is saying that, oh yeah, we understand most of the open source licenses, we know what we can do with it but they forgot that, you know, they also have to fulfill the license obligations. And here's just one example from the GPL which sounds very easy in the first, right? But when you look into the details and you start thinking about how to do this in practice then it gets quite complicated, right? So this says that you may copy and distribute Beberton copies of the program source code as you receive it in any medium provided that you consciously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty keep intact all the notices that refer to this license and to the absence of any warranty and give any other recipients of the program a copy of this license along with the program. So you are allowed to use the software but there are some obligations. And the same is true for something a little more complicated which is the copy left, right? So in the GPL again, GPL 2, it says you must cause any work that you distribute or publish that in whole or in part contains or is derived from the program or any part thereof to be licensed as a whole at no charge to all parties under the terms of this license. Now what exactly does this mean? And how do you handle this in reality? Well, when we talk about software compliance in a corporate context, it means that you have to look at many different software licenses, right? So you have a bunch of proprietary licenses there you tend to negotiate individual license fees and volumes and you have a big chunk of open source licenses where you need to understand and comply with the respective license obligations. When you look at the open source licenses individually you need to make sure that you also understand if they are interoperable, right? So different copy left licenses may not be interoperable with each other. So it's always important to look into all the details of the respective copy left license for example, GPL3 and Eclipse and so on and so forth to understand if you can use components coming from different sources under different licenses together in one project. So what happens if you forget or maybe intentionally neglect some of these license obligations that means that you are not only in breach of the license and the contract it also means that you end up in a copyright violation. And this is because most of the licenses or I should say almost all licenses are designed that way but some of the licenses explicitly stated for example in the GPL3 you have explicitly said that you may not propagate or modify a covered work except as expressly provided under this license. Any attempt otherwise to block a guide or modify it is void and will automatically terminate your rights under this license. So that means the moment you are not observing the license obligations, the license itself is gone. And that means that you are using a piece of software where you don't have the rights to use it, right? So in a legal analysis and the legal construction this means that rights are granted only under the you can call it resolutive condition that the license obligations are met. And when the license obligations are not met then the license is void and is gone. And the consequences you can find in the civil law and in the criminal law. And this is something more heavy I would say in layman's speech than just a breach of contract as a legal consequences. We can find possible claims by the rights orders. So for example, injunctive relief, the rights to information, compensation of course, reimbursement of costs. Perhaps you have to disclose some of your own source code if you have not worked with the GPL correctly or any other copy left license. And these details have all been enforced by German courts, right? So like the district court of Munich above but there are also other decisions by the district court of Berlin, for example and other courts in Germany. Now who is responsible for license compliance and for open source compliance? This is a tricky question. Of course, every individual developer who's working with open source should, you know understand the licenses and comply with the license obligations. In a corporate context, it is also important to understand that it's usually the management who's responsible for open source compliance. And we can find that in the German context again in the act on regulatory offenses which is in German, the Ordnumswidrigkeitengesetz but we can also find it in other laws like the Aktiengesetz, the legal acts on corporations in Germany and they all say the same meaning that the owner of an operation or undertaking or any company has to take the supervisionary measures required to prevent any breach of law. Let me just put it in close words here because the German law and the language used there is usually a little complicated. So it's not only the Ordnumswidrigkeitengesetz or the act I quoted before it's only the stock corporation act which says it more explicitly. The management board has to take suitable measures and it's responsible and it's one of the duties is to be liable for any damage resulting from not working on specific measures. So again, the legal language is a little complicated. I give you the full language here for your own studies but what you need to take away from this talk is that all of these laws have also been enforced by another court decision and in this case, it's the district court of Munich again who ordered a former Siemens management a member to pay 15 million in damages for the breach of duty with regards to an inadequate compliance system. So this was the first court decision in Germany that really detailed out the requirements for a compliance system. In that case, compliance was not about license compliance in the open source context. It was in the general context of what are the duties of proper management but you can take all of these requirements and apply it to license compliance in the open source context. It means that basically whenever you talk about open source compliance, compliance as a general fact is a matter for the boss. The management is responsible for a functioning compliance system and details and specific form of the compliance system depend on the type, the size and the organization of the company. So for example, a company like Siemens may have to fulfill with a different type of compliance management system than a smaller organization or a startup. It also depends on the type of relevant laws and regulations. And here I would say that copyright law is a very important law and intellectual property plays a big role in today's business. It also gives one another very important aspect of a compliance management system is the grounds for suspicion and the cases for non-compliance in the past. And in Germany, we all know that we have a lot of compliance cases in the context of open source going on. So any court would say, well, in the context of open source compliance there has actually been some grounds for suspicions in the past. Of course, delegation is possible. So the management does not have to do everything by themselves, they can delegate but they are responsible for monitoring and making sure that the compliance processes work. And that can again be justified through periodic internal or external audits and readjustments of specific management processes. Now in reality, I like to show this slide which I use, it's originally from the Linux Foundation and I think it shows quite nicely what today's status of the supply chain is. Basically suppliers are not really giving complete licensing information and this information is by no way in any kind of standardized. And when you have to deal with open source packages then the basic problem is that you kind of try to analyze everything that has probably been already analyzed by one of your suppliers before. So it's a double effort. And then depending on your customer they want some kind of information, a bill of materials. And then usually most customers have their own way of asking for a bill of materials. So there's no standard this way again. And this was the starting point for a smaller group thinking about how can we reduce friction and transaction costs in this current status. And this is exactly when the open chain project was born. You can find all the necessary information at openchainproject.org. Basically, open chain is an ISO 9001 like conformity assessment standard. So it provides a specification that asks you or asks you to know your own open source responsibilities to assign responsibility for achieving compliance to review and approve the relevant open source content and then to deliver open source documentation and artifacts. This is the important part that I mentioned earlier. So even if the license gives you the rights to use software in any way you want to you also have to comply with the obligations. And that usually means that you have to provide a company documentation. And then finally, the specification also talks about contributions. They call it community engagement. So you need to have a certain measurement in place that shows that you understand how the community works. So in short, what open chain really gives you is a minimum set of requirements for quality, consistency and completeness in the open source supply chain. Today, the open chain project is very close to becoming an official ISO standard. So we expect that to be announced later in September or October, I think. Before that happens right now, there's a self-certification questionnaire available that you can find on the open chain project website that helps you as an individual project, as a company, as someone who's just interested in learning more about open source compliance to work with this specification. And it works like a survey. So you can go on the website, register yourself and then you will be guided through a survey that asks you different questions. And here you can see all the different sections of questions that match to the specification that I've mentioned earlier. And once you have answered all the questions with the yes, you can qualify as a self-certified against the open chain requirements. Before we go to the final slide, which basically just gives you the opportunity to ask some questions, I wanted to close with some general thoughts on compliance. From my experience, being responsible for compliance in any context is a very tough job. It's usually, basically it's run under the radar. Let me put it like this. So if everything goes well, it's hardly noticed, right? Because if everything goes well, there's nothing to celebrate. But if things go wrong, then the big fire has started. And then it's usually the compliance officer or someone in charge of compliance who gets all the blaming for that. So being responsible for compliance is a tricky beast. I would say these people really deserve our attention and our support. In general, I would say compliance is not an option anymore. It's a necessity. And that's especially true for the open source ecosystem. Compliance gives you a competitive advantage, especially on the context of corporations because it saves you time and resources once you have the compliance process set up properly. And then compliance nowadays is also a key requirement for most of the software vendors, if not all software vendors, right? So who would buy software or receive software including open source components from a vendor who is not compliant, then that basically means that you have to do all the analysis and the compliance work in the company. And finally, I would say compliance is a key requirement for the entire open source ecosystem. So if we as part of the ecosystem don't understand the license details and the obligations and are not in a position to handle them appropriately, then I think the whole system is basically at risk. And that's where I want to close and hopefully we have some minutes for questions left. And if there are any questions later on, feel free to reach me at this email address. Thank you very much. Thank you. It looks like we have a question coming in. So I will wait for that to finish typing out. Okay, so first question is, what are your thoughts on running LibreOffice software in non-Library operating systems? Oh yeah, that's a tricky one, right? So I usually use, I'm not happy to offer that, but working with different clients, I'm forced to work with most of the proprietary stuff as well in order to be compatible and exchange data. So only on my private time, I run LibreOffice and these kind of things. So it's very hard to convince people to move from proprietary products to open source alternatives. I think that's my thought. It's very hard and I include myself in that. So it's a long way to go still. All right. Well, I guess we can go in another moment, see if anyone has any comments or questions coming in. Yeah, I have to admit that talking about and probably thinking about compliance on a Sunday evening at eight is something that really only very enthusiastic people probably go into. It's okay. Okay. So from the first question it was, there is a comment saying, sorry it was not LibreOffice, but LibreSoftware. So I misspoke on that one. Okay, so was the question then something different? Like you wanted me to talk about what free and open source and LibreSoftware and the differences and all these kind of political talks going on in the background? Probably not. So I can say hi, that's nice. Okay, so we have another question coming in. I'll let them finish typing it out. And it looks like our second question is, is compliance hard to enforce in educational settings, such as schools and universities, any suggestions on regulations that would lead to a greater adoption here? That's a good question. So I have seen many universities really trying to be compliant on all sorts of levels. So we talk about open source and software and especially in the context of open access and content. So my experience is that universities and educational institutions in general are really the, let me say good guys, trying to get everything right. The only problem that they sometimes have is that there's not enough expertise. So what I've done in the past, for example, is to just provide pro bono advice here and there on how to get things right. The bad guys in this game are the publishers. Let's put it like that, especially in the university context when it comes to publishing and not making really relevant content and papers available under an open access license. And some of the corporations that want to basically squeeze out technology from university in the technology transfer project. And then you have to negotiate and argue about open source licenses and also patents, for example, how to deal with patents in that context of technology transfer. So my experience is that universities and basically the background in education, they are really trying to get it right. And there's a huge interest in using open source licenses and making stuff available and finding partners in that context, but we have to support them.