 So thank you for joining this bird of a feather session. The idea is that I'll do a short intro presentation. He has to set the stage for hopefully, I will not take up more than five, ten minutes. And then I really hope that we together can share our experiences of how we as OSPOS can engage with the legal department, how we can form long and lasting relationships. That sort of stretches beyond just that I know someone in the legal department. They know me, sort of how can we formalize that and put that into a structure within companies. I really don't have all the answers. So I'm really grateful to see people here to discuss this and share experiences and share sort of what could be possible best practices. But I'll sort of start very briefly here. My name is Jim Oberg. I work for the Ericsson OSPO and a little bit of a confession. I'm a lawyer by training. But trust me, I tried to spend my entire career getting away from that profession. That's now with the OSPO instead. So being from Telco, I like standards. And having never hosted a birds of a feather session before, I figured I wonder if there's any standards or anything sort of best practices for this. So I went and found the IETF, the Internet Engineering Task Force, RFC for how you do a bird of a feather session. And a little bit of a funny story. My manager, he's an IETF guy. So I do joke with him that, well, IETF, you guys never do anything useful. So when I found this, I'm like, oh, this is actually useful. So I sent it to him and like, oh, look, IETF actually did something useful. I retract what I said previously. So then, of course, he said, well, obviously, you haven't done your research carefully enough. If you had done that, you would have found a much newer, much better RFC on how to host a bird of a feather session that I authored. So he sent me that. So I read this, and hopefully we're a little bit inspired in the process here. So also, in terms of open source awareness in the legal department, I think this is at least my experience of how it started. You're typically in the denial phase in the legal department. Either we don't know what the open source is. And if we do, we don't use open source in this company. We don't. Well, you pretty soon move on from that to realize, oh, we are using open source. This is the risk. Why have no one told me about this risk? Why have no one told me how I can manage this risk? So you move into the anger stage, or the legal department does. Then, sort of entering the bargaining stage, could we please stop using open source? I would make my life in the legal department so much simpler if I didn't have to manage this. Of course, as everyone here knows, we're not going to stop using open source. That's not viable. That's never going to happen. So you enter the depression stage of we are so screwed because we can't figure out this open source thing from the legal department. Hopefully, you advance from there and sort of into the acceptance stage. We're, okay, we just need to be smart about it and develop strategies and processes for managing open source. I think sort of, at least in my case, I constantly go back and forth between the acceptance stage and the depression stage because I learn new things and realize we don't have the processes for that. So we're screwed until we have developed the strategies and processes for it. And I'm gonna start now with sort of the interactive session here by asking all of you a question. What's your job? Is everyone here with an Ospo? Lucky guy. But I think sort of, even if outside or in an Ospo, I mean, there's a number of roles you will have. And sort of the way I viewed them is that for me, I'm a lawyer, but I also act as a guardian. I'm an enabler of us doing open innovation and doing open source. I'm a bit of a problem solver for the processes and stuff that we have. Sometimes psychologist, sometimes technologist, sometimes a gardener in the sense that I need to build an ecosystem and build a community internally and let that grow. Sometimes an interpreter between the legal department and the engineers. And sometimes a bit of a cultural anthropologist. I, you know, you study this weird tribe of open source developers. What's their culture? How do they engage? And the same sort of studying the tribe of lawyers in the legal department. What do they do? So with that, we could move into sort of the funds part of this. Sort of what are your experiences of how you engage with the legal department? How do you form that relationship? What should it look like? Perhaps your Ospo is hosted with the legal department. That makes things simpler. Perhaps you have someone from the legal department working part-time with you. If we could get the mic out in the audience if someone would like to start sharing experiences. In the meantime, I can sort of share my experiences of this is that it's been really challenging getting first of all the attention of the legal department and getting them sort of to fully engage with us in the Ospo. Because we need, even if they're not subject matter experts in open source, we still need their buy-in and sort of their blessing for the processes that we want to implement. And how we want to deal with certain licenses and how we roll out training in the company. But getting that has been sort of challenging because if you're a corporate lawyer and you look at, okay, what's my list of priorities? Open source is typically pretty far down. It's sort of, it's one of those risk things that you need to manage. And perhaps you're somewhere on that curve I showed where it's like you don't really understand it, you don't really want to touch it because it's a little bit uncomfortable. So for Eric's, and it's typically been sort of, the legal department has been very happy to point towards me and say, well, you're a lawyer, you figure it out, then we don't have to touch it. I guess that's one way of solving it. But I'm sure it's not the only way. So if anyone would like to share their own experiences. So anyone have any sort of, how does it look in your company if I ask the question to the room? Do you have any full-time legal support? We have Ospo, and we have compliance team consists of probably 10, nine, 10 people. And we handle the questions about the legal related questions from the engineer, you know, a cross-organization, but sometimes if it's too complicated like Linux kernel, how to modify this and how they can do it in details, then we can just forward that question to the legal team. Otherwise, we've built that questions within the Ospo compliance team, but any advanced or more complicated advanced questions, we just connect. But we have a very good relationship between legal team. So that's how we handle. So that's really interesting. Would you mind expanding on how did you develop that? Was that already established? Or did you have to sort of work to, A, get their understanding of your questions and sort of, B, to sort of dedicate the time to work with you? So our compliance team have got one or two lawyers. I mean, half lawyers, half program managers, and then they are actually, you know, common questions like licenses. You know, which license we need to do this and that. And then we have, you know, we can handle it. Any complicated question we just connect? I mean, we don't have a formal process really. Any questions we cannot handle? We have passed it to one or two persons who are expert on open source in the legal team, because we have a big legal team across the enterprise. And then I think we have one or two people who are, in that team there are more members, but we have one or two people we contact to in the legal. So it's not a proper process, but we have a quite simple process right now. Did I answer that? Yes, yes. Thank you. I'm sort of fascinated by the topic myself because I find it so hard internally to get that support. And when we get it, it's typically based on, I know someone in the legal department and sort of they're doing me a favor by sort of bumping my request up of the queue essentially. So I'm really looking for like, how do you structure that? And it sounds to you like you have those internal resources of people who are experts at that. And I guess that boils down to like a HR question on how do you get legal department to prioritize that they need to have that competency? Because if that doesn't even exist in the company, where do you start? So that's at least for our own journey. What we have tried to do is sort of paint these different risks that comes from our consumption of open source and our contribution to open source. And sort of point that these are really risks that sort of had these been introduced by anything else than open source. Legal would be all over them trying to manage these risks, right? But since this is open source, it's just software, legal don't really want to touch it. So I think that that sort of expertise you point to. I think that that seems like that would be a critical component in sort of having that Ospo legal department relationship. Another sort of layer to this is of course that whenever we do an M&A transaction, whenever an M&A transaction is done, you're not only dealing with Euro baggage, you're dealing with sort of the history of sort of bad practice of whatever company you're buying. In my previous life with my current employees, and I still, I did a few of these, and sort of it's never good. It's always a lot of work because you have a history of built up bad behaviors over years and sort of lack of compliance or lack of processes. It's a wonderful way to slow down the M&A activity within your own. Yeah, let's just put it like this. It was never the open source, the diligence track that slowed down our M&A's or as always, other issues and other timelines we had to work with. But sort of it's there, so it's there, do you guys feel that you, you have the legal support that you need internally or is there any here who sort of source that externally that you have external legal counsel you turn to? And that you then sort of have budgeted for like we're probably gonna spend this many hours on or spend this much money on buying legal support externally because we don't have this competence internally because that's sort of been one thing we've been pushing at sort of get our legal department sort of to take the responsibility or pick up the torch and have this relationship with us where they can support us. It's really by saying that these are risks that needs to be managed and questions that needs to be managed, but unless we have sort of your buying and your help will have to go externally for this and do you really want us to spend sort of good money externally that sort of you could have used for a headcount instead? So if we go back a little bit here to this graph, how do you, does anyone have any experiences of how you lift your legal departments from this depression stage and into the acceptance or even from sort of the denial stage? How do you help progress them? Because I guess that's also one thing that that's sort of key for a lasting partnership is how do we get from we don't use open source over to, okay, we use open source, but we need to be strategic and smart about that and we need to have sort of good processes that are in our contracts so that we manage that risk that could be introduced. Is there sort of anyone who've been on that journey? I see you nod, sir. So any experiences from that that you're willing to share? I just think it's a never-ending journey because if you're in any sort of a mid to larger size organization, it's going to be a big risk and it's going to be a situation where the pendulum is always swinging in one direction or another. Nothing is ever staying the same and I guess this really is true across any organization because we are all seemingly tasked with two and a half jobs these days. Everyone's very busy and so when you go to your legal department with a, hey, I need help in this space, it's yet another challenge that they may not prioritize and what you have to do is work hard as a open source leader within your organization to develop not just your legal organization but your compliance organization, your security organization and it can be easy to stay in the depression stage because there's quite a bit to do but the thing that can I think help is that you have to constantly help frame the situation is not a problem to be solved but an opportunity that needs to be taken advantage of because ultimately open source is still a big driver of innovation and by framing it in that argument and educating the different constituents you have to work with you have a better chance of getting them to lean in rather than to lean out. I think that that's some really wise words on that. Thank you for sharing that perspective. I think sort of to share where we at Ericsson is in this journey, I think we are sort of or the legal department is somewhere between denial and depression, sort of we haven't yet gotten someone to this stage and it's a matter of training and persistence, I hope we can get there but it's also the risk of, or the risk that I've seen of having an Ospo and having someone then presumably legally trained there is that sort of legal is very happy to pass that off and say, oh, but you can deal with that. It's no longer our problem because that should be the Ospo's problems. I think the division of sort of responsibilities seems to me to be very important here, especially like should we bother the legal department with every license review that we need if we encounter a new license in our consumption phase? Do they need to be involved every single time if it's just another BSD variety? Perhaps not, if it's something completely new like that we haven't seen before, then perhaps they should be. So how we have tried to solve that internally and I'm not saying we've been successful but it is to have these different steering bodies and license review committees where we sort of require legal to be there and to engage and sort of to sign off on, yes, the legal department agree that this is how this license should be interpreted and sort of staff that with the right competences from engineering, is this feasible? Is this sort of right interpretation and sort of help the legal department understand sort of what's this very strange legal text that is an open source license? Because from a legal perspective, open source licenses are far from perfect, as I think everyone knows, right? So another question to the audience from me is, do your companies have a license review board or a contribution review board? So before you're allowed to bring in open source, do you need to review the license ahead of time and then you maintain a list of that or how does it work in your organizations? So in my organization, we have an open source project map and basically you have to fill in specific terms like the license, potentially contributing partners you should name a strategic element so why you are actually contributing and also it's a long list also with an exit pass and an entry criteria and what the level of contribution is which you want to do and then it goes into a formal approval process. This is silence, this approval process so it's bound to a maximum of two weeks taking locations into account which typically come in and by this we have a map of about 200 projects to which you can see this and we're still growing this because different entities of the company were following different processes and now we're streamlining the whole thing but it soon also gets seen as a hurdle for developers because it's another form to fill and they simply just want to contribute, right? And they don't want to see all these compliance things to be handled so and this is then where the acceptance on developer get lower but it's actually a formal way of getting this sorted and an easier way to do it second contribution later on. So that's interesting, so that's for the contribution part do you have something similar than for when you consume open source, when you bring in new components? Actually the consumption is often quite easy as soon as you go into then not only consuming open source elements or more in the embedded part if you bring it into the product then it gets into a scanning tool, there's license scanning and there's a list of approved licenses, there's a list of approved elements and as soon as there's a new component identified with potential license element which you don't want to see or which is not really fitting then it goes into a formal approval of press from an open source partner, open source officer so they do a check on this but they want to make sure that everything is properly matching together so it's typically done by the project and there's formal process presided. And to share sort of one thing from my side that I found to be a very, very helpful tool when engaging with legal departments is it's not pointing to that all of these are risks, risks, risks and it will create a lot of work for you. It's pointing to the solution and the tools that are available such as Open Chain for example which is a very good sort of best practice standard essentially of how should we do open source compliance and then point to that there's sort of these and these requirements will naturally fall to legal or we need legal's involvement to be able to sort of in good conscience say that we are conforming to this standard so that's gives us sort of some external validation in saying this is not just our strange idea that legal should be involved and this is sort of best practices and it's well documented that it is well best practices. But it seems like one best practice is to have these review boards or bodies or sort of where you can have this cross culture interaction between sort of the legal department and the open source team and I guess also the IP team and other relevant stakeholders. That seems to be one way of doing it. If we look at sort of how some other auspice have done it we haven't done it that way but I think there's auspice that are made up of majority lawyers hosted within legal organization. Of course for them it's easy. They have a lasting relationship with legal department because that's where they are employed. At least they hope it's lasting. I would if it were my employment at least. Or you have sort of people employed that in the legal department that will sort of part time dedicate towards the open source matters. I think there are probably benefits and downsides to both. If sort of if your perspective is that I'm a lawyer and I now specialize in open source does that then mean that you only do open source? You become very, very narrow, right? Is that good or bad for your career? I think those are also things that needs to be taken into consideration. Like how do you create this as a viable career path or at least sort of not that's something that would hinder a lawyer's career. So for example, if we would take someone from legal department and say you're now gonna be in the OSPO organization that that's hosted somewhere else. Perhaps it's hosted within R&D or it's hosted with the sourcing organization. I mean, if we take that for instance, say you're now gonna be hosted here then that person is no longer with the legal department. And that's something we at least have seen that that could be sort of perceived as a hindrance or sort of something that would be bad for their career. It would be sort of hard to explain if they were looking for other employment or advancement later that, oh, you weren't with the legal department of this company. Why was that? So I think that's another challenge. And it's certainly not a challenge we've been able to solve. Perhaps it's a challenge we need to solve as a community by educating the broader legal community of the importance of this and sort of redefining perhaps a corporate lawyer's role a little bit that they shouldn't just sit in the IP or in the legal department. There's sort of other legally defined legal roles that could be filled in other parts of the company such as the OSPO. And perhaps that would be one way of creating this lasting bridge. So I don't have much more material and I think we said that we would leave 10 minutes for sort of questions from online if there were any and also if there's any questions in the room. Is there anyone else who sort of wants to ask the collective wisdom of this room for their experiences and no questions online? Well, I think we can then give people 10 minutes of their lives back.