 Here by an illustrious group of people who are all involved in an important policy and legal decisions within Major companies and free and open-source software. I'm gonna let each of you very very briefly Introduce yourselves and your roles at your company My name is Carol Smith. I'm in the open-source programs office at Microsoft I'm previously worked at github and Google, but I run quite a few programs internally at Microsoft now as part of the Ospo for advocating for FOS internally My name is Max Sills. I work in the open-source programs office at Google I'm an attorney there and we do inbound and outbound compliance, but we also do open-source Adoption and kind of selling it internally My name is Jelaine Lovejoy. I'm the open-source counsel at ARM And so I deal with pretty much the variety of legal issues in some probably not so legal come up at ARM and help form the ARM open-source office I'm Richard Fontana. I am an in-house lawyer at Red Hat. My work mostly focuses on open-source licensing issues and and particularly supporting software developers engineers at Red Hat Now as someone who's always looking at this from the role of the community It's a bit opaque to us how how what the mechanisms are within major companies in terms of bringing the message of free and open-source Software and we know that many of the faces that we see like all of you at our conferences Are some of the biggest proponents for free and open-source software in industry? I'm wondering could each of you say an example of a major win that you had in Bringing free and open-source software to your company and I guess we'll just because of the microphone situation We'll just go back and keep your answers brief because we so don't have a lot of time Yeah, so most recently at Microsoft. We've been building out a internal advocates program that is Focused around identifying people at different levels in different regions in different departments who are all in one way or another interested in free and open-source software and Bringing them together to be in contact with each other and then also Empowering them to be able to be advocates within their department within their region whatever the case may be and to be able to To talk about to be kind of our mouthpiece the Ospo's mouthpiece to to their teams to their regions and to be able to Feel like they can answer questions and advocate Themselves and so that we are not only providing policy ourselves and answering questions But we're also able to to empower other people to do it as well. So it's more of a community effort internally. I Think the the best thing we do on that front is Google summer code I think there's a temptation in that there's an incorporation to just consume consume consume Especially with with the profit motive and I think we do a particularly good job of giving back to the community and actually nurturing Projects and I think we've done a good job Kind of telling that story to our executives and showing that You get the most value if you give back so at arm we recently rolled out a new Sort of workflow process for request and approval for contributing or creating open source projects We had a process previously, but kind of didn't overhaul and got it into a database driven system With now we can kind of have better sort of reporting at what we're doing. So I think that was a pretty big win I mean the goal of that was to make it sort of easier for everyone involved in that process but in particular make it easier for engineers and The other sort of thing I would like to mention that Sort of related to that as something I saw recently that really made me smile in terms of like the sort of win factor was Watching one of our engineers present about Sort of some processes that he'd put in place for contributions to a project He works have but we contribute to heavily and he presented this sort of an internal open source event and Other engineers heard this and they started to emulate that without anyone sort of setting a policy or a mandate for that and I just thought you know if engineers can encourage other engineers without Basically me or someone else from legal nagging them and to do good practices. That's just like law Yay to the awesome engineers arm for that kind of seeing those kinds of things So I don't have a story about a big win So so red hat has been involved in an open source development from from its founding and before open source was actually Coined term so back when people were talking about free software solely I think so I don't have a big win story a lot of my work So there's we have an office at at red hat a department called open source and standards Which is separate from the legal department and they do some of the work that that open source offices other companies do in terms of like promoting strategic projects and and Community management and community marketing they might have a different answer to this but for me It's like a lot of little things that I've done over the years have been focused on first removing barriers to People outside of red hat getting involved in in projects that red hat gets started and second removing Obstacles to red hat engineers themselves Starting new projects without a whole lot of you know bureaucracy and so forth So we heard about wins Which makes begs the question when did things go terribly wrong? When were you trying to advocate for free and open-source software within your company? And it just all went disasterously That you can tell us So I don't have a story about a big like like fail But so so again like the The thing that I've worried about it to red have is kind of a first mover in open source I've I've worried and I think a lot of people at the company are concerned about this as well as red hat gets bigger and bigger We move further and further from those from those roots And we get a lot of people coming from other companies different kinds of corporate cultures not not as experienced in open source So how do we how do we in the legal department? make sure that we continue to have this environment where where developers are very free to to you know to start new projects and and You know to not have To not do what what legal department sort of naturally do which is sort of like like to clamp down and impose a lot of Rules and and and regulations on things. So that's something that I you know increasingly I'm concerned about and and it motivates a lot of my So I mentioned on the win about this new process that we rolled out recently So I think my my sort of example of things going terribly wrong was the previous process Which had improved slowly over years but still as someone when I was prepping for this suggested that you could put it as sometimes it took longer or took less time to write the patch than to get it approved and And and I would say as a lawyer because I can say this even though it's recorded I might get in trouble if you're a lawyer your engineers or your clients to and don't ignore them because I think sometimes in companies Emphasis is on the bottom line and closing deals and engineers needs Get a little bit Backburner not okay in my opinion I don't think the sales people can sell the products that pay your salaries if you don't have the engineers Making them. So if that's the argument you need to make to your legal department Then feel free to use that one So yeah, so you know trying to get that On-board and and making engineers lives easier, which I think sort of that theme Richard is talking about as well So I'm not gonna call it a failure. I'll just say it's a growth opportunity a growth opportunity growth opportunity gets marketing So we've been really interested lately in giving more and more projects to open source foundations And I think we're experiencing some growing pains the over how much control to give up so Everyone wants to emulate the success of an the organic success of an open source project That just kind of grows from bottom up but the I guess the legal temptation the the business temptation is to exercise complete control over projects and It's just kind of an ongoing dialogue about how it's kind of counterintuitive But in order for a project to be successful You kind of need to give up control and that means giving up intellectual property control giving up management control and actually letting Communities participate in determine the direction of a project and that can be really scary for for a big company So but you know, it's an it's an ongoing process Okay So That's right. I think there was a couple of recent projects where well, you know exactly what the fail Okay, the fail is we we weren't able to give a project away in a way that we wanted to and so the project was not able to grow And so we need that we we talked about that and we're trying to be a little bit looser I don't have a specific fails per se, but I will say that We experience a lot of different people who are on many sides of the spectrum from all the way from it should only ever be Proprietary I don't understand what you hippies are talking about all the way to of course. It should be false It's always fast Why isn't it easier for it to always be false? And I think the growth opportunities there for us are on Moving people who are farther on this side of the spectrum farther to this side of the spectrum and and not doing that in a way that is Like we're trying to sell or market to people internally But that we are available and we will answer your questions and we will help facilitate and we will reduce friction for you In any way that we can and we're happy to have the conversations that you want but at the end of the day sometimes they want to stay on that side of the spectrum and and that's Unfortunately or fortunately for them. I guess that's just the way that it's going to go So you all work at pretty big companies and And you're all Responsible for areas that cross that work across different areas, and I'm wondering how does this all work out across? Different departments in your companies and also different geographic areas, you know Are you able to standardize things across different cultures? And how does that work out for free and open source software? Actually think that the answer is probably no we can't we can't standardize in that and that that's kind of a purposeful decision We want to create the community internally that is across regions across departments across teams And by the way going back to my previous answer to the question and some of some teams of whom will never Participate in this and we accept that as a as a fact, but that the people who are enthusiastic Advocates and and adopters we want to empower them to be able to do the things that make sense for them and specifically for their situations with obviously within the bounds of our overall policy, but that they they we should empower them to do what makes sense for them in their particular situations and In that yes, it does vary quite a bit by culture and that's that's actually a good thing And so that's why we want this program to exist because we in the Ospo can never be able to can never Answer all all questions for all cultures and we we shouldn't we should provide the boundaries and the guidelines and then you can Work within those those guidelines however make sense for you so our company has gotten really big and it used to When I started a couple years ago When I was really new to everything I think I had like a very legalistic legalistic punitive mindset I had like a set of policies that had to be followed and everyone in the company had to listen to me I Grew out of that really quick, but it also and it failed terribly and it didn't scale So at this point we don't and it sounds like you had a similar situation What the only thing that scales at a big company is just Trying to be available to solve problems for engineers And so we've we've really shifted from from trying to tell people what to do to just offering ourselves a center as a center of Expertise because people are really hungry for knowledge on open source they really do want to contribute very quickly and I think the best thing we can do is just Try to figure out how to get out of their way and that that's the only thing that really scales So it's interesting a lot. I see here a lot of same themes Are I would you know echo some of those, but it's like a little different angle. I mean we're a lot smaller That may may be part of the difference, but we've got a pretty consistent Processes across the company which I think is important because you should be considering the same types of things and and So that's been good and kind of I think there was a bit more silos Previously and sort of takes a little bit of like, you know from the outside It's all one company so if you you know you you want to have some freedom to do different things But you also remember that from the outside, you know, no one's looking at it the same way, you know That you are within the company and I think like something I've noticed recently just to echo the sort of Providing the info and guidelines Just in terms of like putting open source code out there We've been sort of trying to create more guidance on sort of how to do that and how to do in a sort of consistent way Not to be like mandating certain things, but just to provide some consistency and I find Engineers are asking for that, you know, they don't like well I want to do this right or I want to put the license in the right place So, you know, how do I do that? So it's like well if you just have that info there then it makes it easy and it makes everybody's life Easier than having to ask the same question over and over So we we have red hat Engineers are involved in open-source development like across all the different divisions of engineering and actually in other Technical oriented departments that are not part of engineering. So so it's across the whole company across different geographic You know divisions I think that we To me it always made sense to have uniform kinds of policies and standards It never I never really thought that it was a good idea to have different standards for different groups there sometimes this happens that that we would do acquisitions and The acquisition would be a company that was already doing open-source development in a certain way that was different from how red hat was previously doing open-source development and some of those different practices Stuck on and I don't know if that was always positive. So I think that that we tried to promote a kind of Company-wide standard approach. We do have differences in culture across different engineering teams And I've tried to nourish and nurture nurture that not nourish I mean sometimes this comes up in in in issues of The kinds of tools projects want to use it very often so a legally relevant issue is is license Preferences of licenses used by different projects. We don't have a single preferred license And and at one time there was sort of an expectation at red hat because it came out of a Linux oriented culture that that You know most project would use GPL version 2 and and it was actually a pretty pretty Important thing to to establish that this was not Necessary for for all teams and some teams actually for for because of the culture of the communities They were working and preferred more permissive licensing and for red hat that was kind of a big big kind of change and and I've tried to encourage that and and have Diversity of that sort of philosophical or policy choice across different engineering teams and very much empowering Different engineering teams to make those sorts of what I think it was more discretionary choices This is this is a gimme for Richard, but I was wondering in each of your companies Have you been able to or are there parts of the new employee onboarding process that encourage the use of free and open-source software? And if so, have you have you have you been a part of you've been able to influence that and And just talk very very briefly about that. So the use of software sort of internal use of Oh, I mean so That's actually a big In I mean so so red hats products are sort of by kind of company de facto policy sort of open source license themselves There has been a big Kind of debate going on for actually, you know more than decade at red hat over this issue of whether it's Good or bad to use proprietary tools internally and we have some you know part of the issue is that we have some Some teams that feel very strongly that they should just use Free software tools, but this is very often the kind of the the older sort of established groups at the company like those who work on fedora And so forth and then you have kind of newer teams in a sense newer in terms of the company's history that tend to actually prefer you know using Not non open-source tools to get their work done, which is very often if they're engineers Engaging in open-source development. So It isn't really something that that I get involved in on the legal side. It's Something that I've sort of learned to accept as another aspect of diversity that that should be kind of tolerated I have my own preferences. I like I prefer Generally prefer free software tools, but but I kind of you know, I have many colleagues So yeah, I mean for the sort of internal use tooling I haven't been as involved in that we we did some time ago try to make that easier as well to get sort of Be able to use things that are under an open-source license because the you know risk is lower from the legal side But I think you know, you'd have to ask an engineer of what they think and I know there's some pretty strong opinions on Which I can't speak to I mean in terms of using open-source in our products you know, we were a member of open chain and and Actively involved in spdx So we've got you know various processes around that to make that easier and those sort of approval systems easier and more streamlined to make it You know easier to do the right thing and and use open source as appropriate in the given product. So So we use open source in every single product and every engineer that we hire touches open source like literally 30 40% of any Binary that we ship is just open source code So part of the thing that my group does is we educate all new employees on open source and on how to do compliance, right? within the first two weeks of their employment and We have like one hour with them. So we try to that's our one focused hour Maybe in their entire career at Google where we can talk to them about compliance and we're really focused on respect over legalism I think a lot of It I don't know a lot of engineers just want to grab anything they can to make their lives easier But what we try to teach them is that they are the open-source community We've recruited them from the open-source community and that we know they're gonna use open source And we're gonna ship a ton of it, but they must do so respectfully and when they reproduce a license that is for example it's not just a matter of complying with the terms of the license it's a matter of Respecting the community of people that helped us make money that helped to ship this product So going back to the whole work for a big company thing you had you had to specifically asked about new hire training and The evolution of our new hire training has gone all the way from we tried to tell you everything You could ever possibly need to know in the entire time You're gonna be here for 20 years all the way to We're not gonna tell you anything just figure it out yourself and then back again and then back again and then back again So this is an evolution because everyone in the company wants to tell you Specific things you need to know when you when you start at a company because that's met be the only time We're ever actually able to to get in touch with you So the answer to your question is no, we don't have it currently in the new hire training But it's kind of a function of the fact that it's it's kind of everyone has to be a new hire Everyone has to have topics in new hire training or no one gets to have topics in new hire training but with that said I think The engineers who are specifically interested in using FOS and participating in FOS Seek us out and find us and we have other internal methods like this Advocates program of getting finding those people and and making them aware of the policy at that point So we have one minute left so in the briefest way you can possibly say in one sentence or less What would you tell someone who was starting a new open-source programs office? That's really difficult. Yeah, go ahead Make sure you have a variety of perspectives in the group But whether it's like different roles across the different parts of the business So I will say there isn't one single way to have an open-source office or to handle open-source At a company we have a kind of division approach. We don't have an open-source office per se Sorry, that was one sentence so My one sentence would be keep open-source code away from company code segregated I Yeah, I think variety of perspectives actually I'm sorry I'm gonna I'm gonna stick like have a variety of perspectives because it could be the case that you don't even need an Ospo, or it could be the case that you do like there's so many so many possible ways you can do this have a variety of perspectives Let's give our panelists a big hand. Thank you