 Hi, everyone. I'm Ingrid Betonen and I'm head of the intellectual property legal team here at Nokia and I'm here with my colleague Jonna Soinenen, who's head of open source initiatives and by way of introducing today's topic it's often said that people are afraid of things they don't really understand and today we'll tell you not only about how we do open source compliance at Nokia, but about our journey in demystifying open source within Nokia and removing that fear factor. But first to tell you a little bit about our company. So Nokia is a company with 155 years of history. Over time we've made various things, toilet paper, boots, gas masks, and also mobile phones. And today we have a leading position in telecommunications with an end-to-end portfolio and around 1.5 billion euros in net sales. We're a complex and diverse company and we have almost 100,000 employees in 120 countries and what we are today comes in part from big acquisitions from Siemens, Motorola, and Alcatel Lucent just to name a few. We've made some 129 billion euros investment in R&D over the past couple of decades and today we have over 20,000 patent families, including a leading portfolio of standard essential patents. Since GSM times, Nokia has been a leader in developing the telecommunications standards which enable global interoperability. Long gone are the times when you weren't able to use your European handset in Asia or the USA. But in order to achieve this, what we've done is to actively and openly disclose our proprietary technologies, our most cutting-edge proprietary technologies, making these patented technologies available to third parties on fair, reasonable, and non-discriminatory terms or or franned license terms. So all in all, given the size, complexity, and patent-focused company that we are, you can appreciate that Nokia wasn't the easiest place to set up a forward-leaning, company-wide open-source process. Yes, but despite all that, we've actually been active and we have been using open-source from very early on. We actually had products already in by the end of 90s that were using significantly open-source and we started basically having our open-source process also already in 2004, where we introduced open-source as part of our product creation process and we created our own tool to support our open-source compliance called TALACO and we're using that tool still today. But also there, of course, what we needed to do is contribute to open-source as we were using a lot. We needed also to change and influence open-source. So we also started to contribute to open-source quite early and we have done it in different levels throughout the history of the organization. Obviously, quite recently, we have increased our contribution to open-source quite a bit more as open-source has become an integral part of the telecommunication industry. And we are basically there, now we have even products, again, that are based on open-source technologies such as OpenStack and Kubernetes. So what do we think about open-source in general today? It's quite obvious that we don't just download random stuff from the internet and just contribute to any place. Oh, you don't? Oh, yes, that is, it might sound like different sometimes when we're doing it, but it's actually, no, there is a method to this madness. What we basically have is criteria of how do we use open-source. So we basically look at that this software comes from a reputable source, it actually does what we are supposed to do, and it has actually good quality. I'm like, those are things that are very important. But even maybe more important is when we look at that where we contribute, because this is one of the key questions for our organization is actually to look at that where you contribute, what you open and what you keep closed. And therefore, we are actually doing that with quite careful. How do you look at that, which are the right places to contribute? You look at it the same way, or that we look at it the same way, as we look at what makes open-source projects successful. What you need as the first thing is basically you need a shared problem. So you have to have a problem that everybody recognizes, and everybody thinks that it's worthwhile solving. And usually that, and important is, of course, solving it together. So what is there usually the important thing is that it's a problem where there's a little differentiation. Because if companies are competing in that area, the interest of actually solving that together goes away. The other thing is what is important that in the open-source project, and in the work itself, people are aligned. People have a common goal, and they want to solve the thing in the same way. If you don't get alignment, you don't get people working towards the same direction. The other thing is, which is often forgotten, is actually the governance. The open-source projects need to be somewhere where people feel welcome. They feel that they are treated on the equal footing. They are treated well, and they can actually contribute and influence the work. And this is important for an open-source project being successful. But it's also important for us when we get active in something that we basically feel that we are welcome and we can contribute. And our contribution is regarded as something that is wanted in that approach. The other thing is what is then needed is support. So not only that there is a willingness and alignment, but people are actually also willing to invest, that people are willing to put developers there, and willing to develop and spend time in the project. Last thing is, of course, is timing as well. So the thing is that basically it sometimes starts need to align. It's not just that you have the other things, but you also have the right time to solve this problem. And those are the criteria that you need to meet to have an open-source project be successful. But this is also what we think, that these are things that need to be aligned when we contribute to something, and when we get involved in something, especially when we become a member in an organization. And the thing is really that for us is that one cannot mention it too often. It has to be a little differentiation that people are actually willing to work on that, rather than competing. But what do we think that our open-source is going forward? We believe that open-source evolution will continue. We think that there is a really a need in shared R&D in our industry. And this has been shown in many cases in the technology now. And we believe this will not go away. That's why for us already, this has become part of our R&D development. It's not an external thing, but actually we have built it into our processes and into our R&D teams. And it has become at least in part something that people just do as their normal thing. It's not that mystical or magical anymore. It is real work and part of our R&D development. But this doesn't mean that the differentiation would go away. We think that differentiation will continue. And we will continue to building commercial software and we will continue to have proprietary innovation. And what we think is that this is actually good for the industry. There is also benefit from having competing implementations and competing products in the market to drive the industry forward. Now taking this all in and thinking that, okay, how do we make actually a successful open source process? We started to think when we redesigned our process by having kind of like certain goals in mind that we had to meet in order to this process to succeed. One of the first things was basic, well, not one of the first things. The main thing was that the open source process is there to support the business and the R&D. Basically making our business successful and enabling the business in the market and enabling them to do the best products they can using open source where they want to and contributing in the open source in the most efficient way. Then of course what was important for our legal is that we actually do the right thing. I mean like this is not normally what I say about legal departments but here it's true they were really just interested to do the right thing. Which means that you comply to the different licenses. You don't comply just to what is written down but what is the spirit of the license. And this is very important. You have to do this in both when you use open source and when you contribute to open source. In the end you are using what other people have contributed. So you should respect that. The last thing but one of the important things really keeps a criteria for us was to protect the Nokia IPR. And this is basically protecting our patent portfolio and making sure that we don't license something that we don't want to license and we don't jeopardize something that we don't want to jeopardize. And this was very key for us to make sure that in a company like ours we can actually be successful in open source. So at a high level key to the success of our open source process have really been a few simple yet difficult things. People, communication and collaborative spirit. What we did in reformulating our open source process was to bring together representatives of each of the relevant interests. R&D, legal and our patent business. We handpicked people for their ability not only to represent their own particular interest vigorously because of course that's important. You want the lawyer to be able to represent legal principles very strongly. You want the patent business to stand up for their asset. But we wanted those people also to have an open source facilitating mindset and a strong sense of collaboration. And the team of people we have within Nokia who does open source compliance is known as the FOSS advisory team and they're the team that's driven the how of Nokia's open source compliance process. From the perspective of business enablement we realized early on that open source compliance needed to be as and Yone alluded to this before an integral part of our product creation process. So our product teams need to be transparent about open source usage from an early stage of their product development and then we screen this intended usage using our homegrown telco tool that Yone mentioned. I'll talk in a minute about the criteria we use when we're doing this screening but importantly the screenings a dynamic process. So our process allows teams to change their mind flexibly you know as they need to do during the course of their product development. They're able to flexibly update their compliance check as and when needed. And of course and Yone mentioned this as well it's important not only that our businesses can use open source software but that they can play an active role in contributing to open source projects. We're really not a fan of forking and we would prefer that our businesses can be actively engaged with the upstream. And to enable this our internal process covers not only the screening and approval of use of open source software but also of outbound contributions. So from a legal perspective as Yone mentioned we try to do the right thing. Now we aim to support safe and compliant engagement with the open source community whether we're using open source software or whether we're contributing to open source projects and we're aiming not just to comply with the letter of the licenses but to comply with the spirit of the licenses. As a lawyer I'm proud to say that we don't set out to prohibit particular activities. We don't set out to prohibit any particular licenses. We do start with a business minded business facilitating approach. We work with our R&D teams really to understand their use case and to assess case by case whether it would be problematic for Nokia to comply with the applicable license terms and to go forward with what they want to do. And here again our telco tool comes into play. We use the telco tool for doing our legal reviews and for documenting our recommendations. Perhaps the hardest nut to crack in all this has been the tension between Nokia's intellectual property interests and in particular our patent interests as against Nokia's business interests in open source engagement. You know there have been different ways that other companies have tackled this challenge. I've heard of cases where companies have just segregated their open source activities or their patents into a non-affiliated legal entity. And that's certainly one approach but at Nokia we rather see the need for open source to coexist with patents and patent licensing and to handle tensions really as we would handle any other case of competing business interests. So we would weigh the respective interests and assess in the particular circumstances which one should prevail. Here the area of technology in question is usually decisive. And Iona mentioned this already that there are some fields where Nokia's proprietary IP assets and I'm not just talking about our patents I'm talking also about our proprietary software implementations are critical business differentiators areas where we compete with others in the field. Our crown jewels if you like and generally it's determined that in these areas we can't compromise the interests that we have by participating in projects that would require us not only to grant royalty free IP license but also to make our proprietary source code available to the world. But at the same time there are plenty of areas where Nokia and other companies benefit from a shared effort in creating necessary but generic and non differentiating implementations. And over time we realized that it would actually be possible to map out the areas which are more or less suited to open source engagement. And internally we talk about this approach as the Swiss cheese model are you intrigued. Anyway the cheese represents Nokia's most valuable and differentiating technology and the holes which you know are still part of the cheese other places where open source initiatives could be interesting to pursue. One thing that's worth noting is that we screen not only open source contributions for IPR related conflicts but but also open source usage and our telco tool includes an IPR check function where potential issues are flagged for further investigation. Well hang on I'm like I hadn't noticed this before but you basically have called us nice all this time. That's the first time you've noticed. Oh well I'm a little snow. Oh okay now I know where we stand. Right, the snow road is anyway. Yeah exactly the squeaky voices. Anyways just to quickly summarize what got us here. So our main thing was really to enable the business. Enabling R&D, enabling us to both use and contribute to open source in the kind of like best possible manner. Making sure that there were no artificial boundaries between the R&D teams and the contributions and the usage of open source. To do that we had to recognize that basically patenting and patents and open source can exist in the same organization and make sure that both sides are respected and that was what enabled us to create this process and that the governance around it. But to enable to do that was basically it needed people and it needed the right people like Ingrid said that people had to be handpicked in the kind of like making sure that they are willing to work together they respect each other but especially that they were enthusiastic about open source and that was key to our success here. So like anything else in the end it's just down to people. Isn't it? It is indeed. I have one question for you. Sure. Why did we call this presentation flies like an arrow? Well of course. Would you believe if I would say that it's because it's so efficient our process? Oh yes indeed. Well it actually comes from that that time flies like an arrow fruit flies like a banana. Okay thank you very much. We're now ready to take your questions on the all the channels that where you can send it.