 I am going to talk about what we currently have issues in open open source licenses. I am from the side of Cologne and my colleague Karina which actually submitted the talk. She is from Berlin. So the German Aerospace Center is a research organization of the German government. We are doing research on transportation, space research, energy and aeronautics. And we are also a German space agency among other things. We distributed this in Germany with 20 sites currently, 8,000 employees and about 5,500 are scientists actually. And also we have offices outside of Germany like here in Brussels or in Paris, Tokyo and so on. And within our lab, within the German Aerospace Center, we have a lot of software and a lot of open source and free software. This is actually a picture two years ago here at Foster which I took of somebody you might know. So the software scene and software development at DLR is very diverse. So we have many, many domain scientists from aeronautics and space and so on. All of them have certain thoughts and things in their minds and usually they are implementing their ideas into software patches. That's the basic way of working. And so software development at DLR at our lab is very important. Like 1,500 people are working full time on software development. That means we spend 150 million euros per year personal costs for software development. It makes us one of the largest software companies, if you will, in Germany at least. But actually we are not a company. And the characteristics, the people who are developing software, and this is very similar to other similar organizations like Research Labs and maybe also universities, that our developers have no training in software development at all. So some of them had like programming courses at universities like the course in C programming or Python or other colleagues have courses in Fortran programming and so on. And the problem is that they have no education but now have to do a huge amount of the time they are doing in software projects actually. Space experts, domain experts for aeronautics and transportation and all this kind of stuff. They just have to do programming work because this is essential in every scientific field today. Like especially in the field of where we are doing a lot of data science and so on. And a lot of these people just, many of these people or colleagues don't work on huge software projects actually, but they do something like exploratory programming, like small scripts or entering a bit of code, bits of code in Jupyter and no big books and so on. And we use a lot of technologies, more than 30 programming languages like with Fortran and Ada and MATLAB and Python and so on. And a lot of, we use a lot of open source software and we produce a lot of open source software with many different licenses. That's where part of the problem is coming. So we have a huge number of software projects. One of our problems is that we don't have a real overview about our software projects. So it's very heterogeneous from the organization point and it's very hard to get an overview and it's just not possible today. And regarding open source software, usually the software starts within the lab and then it's exposed as a source license to the outer world. Here are three examples from the Earth system modulation field, from traffic simulation and from aerospace design. And the software packages are used from other researchers or from other companies. And contributors come from also from other research labs and universities and also from companies. Problems that we have, what we had in the past is that we published open source, that we had issues with licenses. So things which are not going to really talk about. But one of the things that happened is that our government in Germany gave software away to another country and stated it was open source. And it was not. It was the software of our lab of DLR. And well, there was a journalist from the Spiegel magazine and he discovered that and there was a little trouble coming up. So we fixed this with a lot of effort and then we had a couple of other problems where the license compatibility was not fulfilled and so on. And in general, colleagues didn't know about open source licenses and which license to choose and so on. And the problems that we have are not as problematic as like with our hardware. This is much more expensive, but it's also not nice and we try to avoid it. And like in 2012, there was a letter by our CIO who sent a letter to all the employees with some tips and warnings about open source and dealing with open source licenses and so on. But the situation is really complicated because if you are a developer and especially a researcher which are not interested in software engineering and programming and in license issues, it's really hard to understand licensing and open source license in particular. For example, at the ICPC conference last year, there was a talk about a study, do software developers understand open source licensing? Well, the general conclusion is that developers understand open source licensing if there's one license involved, but it's really if they struggle if there are multiple licenses involved. Usually in most projects, this is the case, that we don't have just one license but we have multiple licenses and we have also issues of license compatibility and so on. And well, what we try to do in the past years is to take some actions for our colleagues, for our employees, for example, information, provide information on trainings, knowledge exchange possibilities and consulting and support. And I'm going through all of this briefly. So information and trainings, what we set up was a training for open source licensing. It's not about developing software, it's about only about legal issues on licenses. And it's a regular training in our education program of DLR so every employee can sign up every year. And it's a short training, only four hours, like from 10 to 3 p.m. or so. And it's one by two persons, a legal expert for the real legal topics and second person is a software engineer. And together we are presenting the basic stuff about licensing and how to select open source licenses and how to use open source software. And it took place in various sites at DLR throughout the years and a couple of people from different institutes attended and the people who came there, most of them didn't have very deep knowledge about open source licenses. That's our main audience with these trainings. So when we asked three of the training, nobody said that he or she has deep knowledge about licensing issues and the topics of the training. We also asked them for the expectation on the trainings. We got a lot of feedback what people want to learn over you about licenses and so on. We learned about legal basics and the feedback after the training shows us that we fulfilled the expectations of our colleagues. At least the ratings were good or very good. So I think this has turned out very well. And what we also did is like brochure like in real paper and information about legal basics. It's developed by a law firm in Germany from Berlin and funded from DLR sources. And the open source brochure contains a couple of chapters and sections about distribution of unmodified code and modified code. It has lists of all liabilities for licenses which are widely used at DLR, for example DBSD or Apache license and so on. And covers of course concepts like copy left and so on. And this is one page of the open source brochure which we distribute in our lab. We have checklists so colleagues can go to these checklists and mark all the points of say the projects fulfill these points. And it also has a lot of information about very different things related to open source and software development. And it also has some kind of decision trees for example for choosing a license for their own projects. This brochure is in German only currently but we are working on an English version of the Creative Commons license which we can distribute in the future like this year somewhere. Next thing is knowledge exchange between our colleagues. The first thing that comes to mind when you think about knowledge exchange is a wiki and also we set up a wiki in our central wiki installation where we have wiki pages for everything and since a couple of years there is an open source section with question and answer section and information and link lists and so on. This is like the single point of information for open source issues at DLR. I think this is very common in standard but what we also set up is kind of workshops, knowledge exchange workshops. This is for peer to peer exchange between our colleagues which come to a place together and we have this knowledge exchange workshop for different topics at DLR like for software engineering and visualization and photonic systems and so on but also for open source and also open science and open access and these kind of topics. This is currently open for any DLR employee. Currently we have a limit of 60 participants per workshop. This is an interactive program, short lectures and everybody has to introduce it himself or herself and we have lighting talks and discussions in small groups and so on. So for example last year everybody had to make a small poster introducing herself. Actually this is Karina who was supposed to talk here now. And then we can go around to the posters and everybody can ask questions and explain what he wants and what he offers and so on. Well of course sometimes it's hard to understand what people offer. That is also one of the problems that we have that we have very strange minds in our lab. They are thinking about concepts like how to integrate satellites into an industry for all infrastructure and well then if you have to go to them and ask about the open source licensing then they basically explode. So this is the interesting part of the job. And also we gather the feedback for our workshops and for the different topics and also for the expectations that people have and the most important expectation was to get knowledge from other people. We send the same lab from colleagues which have the same problems. The feedback form showed that we had to fulfill this expectation. So we will continue with this kind of workshops, internal workshops for knowledge, not exchange. And we have a lot of findings which came out of these workshops which we can use for further actions and further activities within DLR. Very general findings which we in part already know before that we use open source a lot and that people want to publish open source more and more and so on. And there were also critics of open source software and we discussed these topics too. For example for things like earning money and the business aspects and so on. And one of the things that we needed a formal process definition and what to do for employees if they want to publish the software as open source. This was missing, it's now available because we developed it in the last month, last year. So this was one of the outcomes of these kind of software and knowledge exchange workshops. And of course another topic that we set up in another area is help and consulting. If people at DLR have problems related to any kind of licensing or any kind of open source issue, there are actually a couple of departments who might help for like the technology marketing division, they help in general licensing questions and topics like property rights and so on. We have the legal department of course who can support and for general legal questions of copyright questions and we have a software technology division who helps in license selection and all things related to development. And of course during these support actions we have typical topics are what are criteria for choosing open source software or what are best practices for your own open source project and so on. And what we set up for this and we found out that this is also very important, just a very simple single email address, open source at DLRD and any employee can send an email to this address and we will help these guys. And well of course everybody from outside of DLR can send us emails to this address and we will probably help these guys. And what you also did is that we choose a couple of licenses which were approved by our legal department and colleagues and employees can use this out further asking anybody. Like the simplified PC license, Apache license, Supernode, Eclipse public license. These two licenses are really widely used at DLRD for right of project. And of course we have a lot of other licenses which we are using but if one of the colleagues want to use one of these licenses they don't have to ask anybody again. And another thing we decided a couple of years ago that we don't go and develop our own license. A couple of related institutions are doing this like the European Space Agency and NASA and so on. They all have their own open source license or their own license and we decided just that the existing licenses, the existing open source, all the approved licenses are enough for our project and that's it. And it works in practice so there's really no need for our own license. And for support and help also we have a section in the Wiki where there's a discussion board and Q&A section which is very frequently used currently. So I think the key messages of my talk here are that we at DLR, our strategy was regarding the open source licensing is that we first offered specific information to our employees and provided room and space and time for peer-to-peer discussions and for knowledge exchange. Then afterwards, just afterwards we came up with formal process definitions and something was just given from the board of directors and so on. And we have positive evaluations for all of our actions and so we can continue on this road and also other research organizations at least in Germany but also currently in the US like copying this kind of way that we are doing. Okay, that's it. Thank you. If you have questions, just ask. Thanks. You like to allow just credit knowledge rather than direct it from above but it seems like when it comes to choosing licenses you're not actually giving your engineers that much choice. Obviously one of the big choices of license choice is whether you use copy left or not and the three approved licenses by default had no copy left, no copy left and I think a little bit of copy left. So one of the most difficult decisions is not in fact in front of that. So I can see how that would make it easy but yeah, if you have any comments on that and you just decided not to use copy left licensing with DLR. Does this question is too long to repeat? Yeah, so the question is basically why do we choose only licenses which do not have copy left in it and this was not by intention so we just came up with these two licenses because a lot of people ask for specifically these licenses and it's totally possible that we add another license like GPL or other licenses to this list. It's just the current state. Is this the list that you're producing software or the list of licenses that you're using? The license that you're using for software that we initiate? Yeah, I think you was first. What organizations do work for them? Is it a function of how big they are? How big roughly is DLR in terms of number of employees? The question is how big is DLR in the employees? We are currently more than 8,000 employees. Yeah. Do we have public domain in Germany? As far as now we cannot do this in Germany. But I'm not the legal expert. Who choose without passing through the legal department? Yes. But for instance, if I were a copy left license after I was in the legal department, have you got any experience about some of yours tried this way? Like I want to choose a copy left license and ask... So the question is can people choose a copy left license and if you have experience with employees doing that? Yes, we have a lot of experience. Many projects of DLR have, for example, a GPL, a GPL or other copy left licenses. And it's not only legal department where we have to go through, but also actually you must convince your manager actually. But that's a side note. But in general a lot of people did that before, yes. Also copy left licenses. No, we look into... Yeah, okay. The question is in what basic is it accepted or not? So in each case we look into the specifics of the project and does it make sense? Does the license make sense? And in some cases we like my department or other people suggest other licenses and sometimes we just say yes, this is okay. But especially this project is currently a bit more formalized also with decision trees and so people can make the step for choosing license by themselves more and more. Yes. So the question is do we provide the actions and services to external parties? Yes, sometimes. For example, we did it a couple of times for other research institutions in Germany. Universities and research labs. And also in one case for a company, but this is not our main focus. There's choice of licenses. Sorry, can you repeat? Why not push every all of the TLR programmers with one license as opposed to permitting... Ah, okay. So the question is why do not push everybody to use these licenses? For one license. One license, especially one license, yes. No, this is a strategy which we tried out before. For rice technologies, for programming actions, for licenses, for development infrastructure and in a really free mind research environment like the art is not going to work. So people want to do their own stuff, their own way, their own license and so on. And so we have to provide offers, but we do not make pressure arms and to choose just one single license. We don't want to. No, that doesn't conform to our way of free thinking and to do what you like basically. Okay, thanks.