PANEL: Open Source and Free Software License Compliance And Users
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Kuhn, Bradley M.
Sullivan, John
Ballhausen, Miriam
Ricci, Davide
Fhlannagáin, Eilís Ní
Compliance with Open Source and Free Software licenses remains a perennial topic of discussion among policy makers in our community. However, little attention is paid to the motivations why these licenses have specific requirements. Specifically, at least for copyleft licenses, the licenses seek to bestow specific rights and freedoms to the users who receive the software integrated into the devices they use. This panel, containing a group of industry experts, consultants, and license enforcement experts, discusses the challenges and importance of assuring downstream can actually utilize the compliance artifacts they receive with products as intended by the license.
 Hello, everyone, and welcome to our panel for our FOSDEM legal and policy dev room on compliance. This has become somewhat of a staple for our dev room. We're doing it, of course, remote this year because of the pandemic, but we have a couple of great panelists that are going to dig in today to discuss the issues of doing GPL compliance with a focus on what happens for the customers, the users, the individuals who get devices, how do we assure that they have the source code they're supposed to get under copy left licenses that works, and we're going to talk about it from a number of different perspectives from folks all over the industry. I have joining us today, first of all, John Sullivan, the executive director of the Free Software Foundation. We have Davide Ricci, the director of open source technology center at Huawei. We have Eilish Nilonigan, also known as Pidge, who is the CEO and CTO of Togan Labs and the chief architect of Network Grade Linux. And coming to us from the legal side, we have Miriam Belhausen, who's a lawyer at Bird and Bird and focuses on copyright law. So to get started, I would like to start with asking John a question because, John, you worked for the principal person at the organization that started the whole idea that software freedom was an important issue way back in 1985, and we're really the first to talk about why it's important. Can you tell us a little bit about why the issues of compliance with copyright, the copy left licenses fit so directly and importantly with the issues of the compliance requirements, the details in those licenses that companies and redistributors have to follow? Sure. And thanks for having me on the panel. I'm looking forward to the rest of this discussion. I think it's a very special thing about free software that it is designed to have both fully commercial and non-commercial purposes. And so we, at the FSF, use this as a social movement for sure with an ethical foundation and an ethical mission, but these chances to talk together with the people that are using the software commercially and have experience doing that and hearing their experiences is really an important part of that. So the primary copy left license, I think that we have in mind is the Gidu general public license and that has a very simple requirement and it's a phase that you have to share when you distribute a program to another person. You have to share the source code, which is what you as a programmer or what the programmer is that you hire actually use to modify the program and create the program, the human readable code. And the reason that that's requiring it is because of binary program that's not particularly useful other than for purposes of being able to run it or hand it off to somebody else so they can run it too. If you wanted to understand anything much about how the program works or you want to be able to make changes to it, you have to have the source code for that. And that's the whole reason for free software where it's existence is so that users are in control of the devices that they have, the software powered devices that they have rather than those devices being in control of them. And if you can't inspect the program that's running on your laptop or your phone or in your car, then you can't actually know what it's doing other than trusting the company that gave you that software, you know, trusting that they're telling the truth. The same point of example is unfortunately where that doesn't pan out. And then second of all, even once you understand it, if you want to be able to make a change to it, you also need the source code for that. And I think the closing key thing here is just that these rights aren't just for programmers. Anybody, if they have the source code, can go to a programmer and ask them to make a change for them, just like you can get your car repaired at a mechanic or have someone else fix the HVAC system in your house. But you can't do that unless you have the rights to the source code and the freedom to take it to other people and ask them to do things. And Pidge, that's why I want to come to you here, because one of the focuses of your work is, as I understand it, is to help people and help those who build these devices, which are these days a lot more complicated than they were when these licenses first came out, to actually make that software build and work correctly and create these compliant source releases that are required under these licenses. Can you talk a little bit about what you're seeing in your work and trying to help your clients get that source code right? And what the challenges are that they face with regard to the interaction between the details of that software and its source code and their compliance requirements. Right. So a little background here. When people do a lot of software compliance work, they're doing it around one chunk of the software, undoing an entire firmware blobs, so entire Linux stacks. And it's complicated because you just, it's not, I need to know what software is on it and what the licenses are. You also end up needing to know how it's built and how it's all tied together. So with a lot of my clients, it's initially, why do we need this? Can't we just throw out the metadata and just have it that way and not actually provide the source code? They can get the source code from upstreams, that conversation. So there's a period of buy-in initially, and then the complicated work happens, which is going through each and every bit, figuring out which source package is using, because one bit of source code or one package may have multiple things that come out of it with various different licenses. So for example, I don't know, I use this all the time, puzzle. Puzzle may have puzzle, puzzle dev, puzzle docs, and they're all going to have very different licenses. So it's understanding everything from nuts and bolts all the way from initial build system all the way to how everything's built to how everything's deployed. So there's a lot of teaching developers, things that they shall not do, like static compilations of close-arge software against GPL code, which we have to have that conversation. And software developers are clever and they go, what if we do a shim layer and, and, and you know, just stop trying to get around that. So there's a lot of education on the corporate side that I end up having to do to teach developers how to do this, how to do this correctly, and how to do compliance activities afterwards. Does that answer your question? Yeah, it does. And I want to go to Davide now, because what you're, what you're doing is you're looking from inside your company and trying to build up and answer these questions so that your employees know how to do this correctly, how to incorporate free and open source software into your products. Why don't you tell us a little bit about how you design that strategy from inside a company to make sure that you're getting that final source release at the end, as, as Pitch says, is looking at the entire firmware blob and making sure you have what's required for the entire firmware, not just one part. So first of all, the, you know, I've done this couple of times, I've done it at Windriver and I've learned at the Intel OTC school up in Portland, and then I'm not doing this a while way. So first thing that you had to do is just do it first. Even before you start building codes, you know that you're going to be using open source software when you build an operating system. So first thing that you had to think is, how do I ensure the compliance, right? And how do I do it incrementally? So over time, I mean, initially it was a lot of, you know, guests and let's figure it out, you know, work. Right now we have good standards that are coming up, for instance, Linux Foundation with the open chain standard, which is really industry-oriented. Free Software Foundation is helping us a lot, especially in Europe, helping Huawei to actually do it, right? But you know, it's about, as I said, if you want to go with open chain, it's about creating a policy, funding the policy. So essentially you got to make sure that it's funded. There's people to actually follow the policy. Training individuals so that developers, managers, they know what the process is, what their roles is. So then at the end of the day, everybody knows the dues and the don'ts. And then when you start building that build of material that tells you, hey, in this device, there's this software, these are the licenses, this is the manifest, these are the author, this is the license that we think the software has. Oh, and by the way, hey, IP analysts, can you go look because some licenses are not clear. At the end of the chain, you have the best possible accuracy when it comes to the build of material. There's no 100% accuracy in businesses about risk and gain. But as a general manager, I don't want to go to market with a big unknown. So at the end of the day is the most accurate build of material that gets me through. And if there's a red flag that is flagged by, you know, from you by the team, then, you know, you take a risk-based decision. But that's pretty much the process you follow. Yeah. And so you identified risk and that brings me to want to ask Miriam about that question of risk because ultimately the reason, if there were no requirements in any of the open source and free software licenses that we have, particularly the copy left ones, no one would worry about any of these questions that Davide is talking about. So Miriam, what do you see? We're so many years now into adoption of open source and free software in companies. When you talk to your clients, what is their legal concern? What is their fear? And on the other side of it, are they able to see it, convert that legal risk into let's make things better for our customers? Like where do you see that divide happening in the clients that you're talking to? Yeah. Happy to answer that. And also, thank you for having me on this. So to be honest, I think there's a big difference between different types of companies and the risks or the issues that they see. So there are, let's say, companies that have been in the software business for a very long time and they've been working, developing with software. They are really knowledgeable already. They know what they're doing, maybe kind of like Huawei. And as David just said, they are looking into this. They are working on strategies. They are looking at the software that they're using. They are looking at it from the beginning. And they have very specific questions. And they generally also already know how they would handle certain risks. And then on the other end of the spectrum, you have more, let's call them traditional companies coming into the software space that have maybe just built whatever device, let's say a fridge for years. And now all of a sudden, the fridge is smart and uses a lot more software and they are working with a lot more software. And that's really not their core business so far. And they tend to be looking at the software development and the risks they assume open source software has from a totally different perspective. So with these types of companies, you would still hear questions like, well, how can we even use open source software? There's a copy left in there and all of that is a really big risk. So you kind of have to find out where do they stand, how far along in this development are they? How much have they looked into this? What type of developers are they working with? How knowledgeable are they? And how much are they pushing? Are there maybe differences in the different areas they are working in? So yeah, that's a big spectrum, I would say. And so I want to connect that up to ask John because when you talk about the risk reward and analyzing that, I think from the activist side, you probably look at this a little bit differently. So the reward, I would guess, to the activist, admittedly I'm an activist too, so I know this is true, that the reward is that with copy lefted software being in these devices, it means software freedom for people who get the devices with the source code correctly. But of course, the risk is the risk of non-compliance. And in your world, that means software users don't get freedom. So when you look at this, how do you reconcile all that question of risk and help to educate and explain to people that the risk is really a reward because your customers get software freedom? Yeah, and I think that it's important for anybody distributing particularly copy left software to understand that this dynamic is what gave them that software to begin with. And so the risk of non-compliance, on one hand, an important part of it is that you're not respecting your users, your customers, anybody that's receiving the software from you, but you're also sort of in a long-term way undermining your own business model. Because this collaboration model is what created the software that you're using that you're able to ship with your products. And if you're not doing that properly, then you're not enabling possible participation by other people. You're not enabling bug reports. You're not enabling the entire culture that created this thing that you're able to use. But yeah, it is for us, it's more than just the risk from a very short focus. The company perspective is possibly being sued or having to go through a complicated legal conversation with somebody. And that is certainly a risk that people should worry about. And one of the things that we do is enforcement at the FSF on the new software that we hope copyright over. But really, we want everybody to participate in this process and treat this process as something that benefits them and creates a level playing field where no competitor of yours is getting an advantage either by skipping out on some of the requirements here. So I want to go back to Pidge because that interesting thing about the competitor issues, one of the important things about free software and copy left in particular is it assures that everybody's on equal footing. So Pidge, when you're looking at this from an embedded side of building these firmwares and checking the compliance of the firmwares and checking they build, what concerns do you have as you're doing the analysis to sort of get to the conclusion of, well, does the source code really work? And are we putting something out there that can actually be collaborated over as far as the technological solution versus just kind of meets the bare minimum of the requirements, which might not necessarily inspire that kind of collaboration. Can you talk a little bit about how that divide gets handled when you're doing this kind of work both as an upstream and for a client who's asking those questions? So I'm going to plug the project that I work on, the doctor project in that. I have to because when I wrote the initial pass through the license compliance stuff and when I was told to write that, I was told to go talk to the lawyers about this and I'm like, screw that, I'm going to go talk to Bradley because he's one doing license compliance. You remember the conversation, I'm sure. And I went and talked to the lawyers and then I talked to Bradley and then I was like, okay, this is what he's looking at. So from my perspective, the outputs that the doctor project gives should also be able to be inputs as well so that people can do this. And it makes sense from an embedded perspective because if you look at where embedded is going, if your refrigerator is embedded, refrigerators last what, 10 years? I don't want to be maintaining firmware for 10 years. I want the community to go out and do it. So from my perspective, it goes, there's compliance at the top of the stack, but it goes all the way down to the bottom of the build system and ensuring that the things that come out of the top of the stack are able for the community to go take those and regenerate them all from scratch. Now, there are folks that do not like doing that and I tell them to suck it up because it makes no sense not to do that. So that brings me back to a couple of things that Davide was saying. So there is this and I always promise I'll ask a few hard questions. So this may be a hard one. But you mentioned a lot of these initiatives in your initial comments there that are out there related to bill of materials and trying to get just a list of licenses, which I think everybody would agree is the first step you have to do. One of the concerns and I'll show a little bit of my bias here I've had is that it's kind of what Pidge is saying is that that's a necessary but not sufficient thing to really get a compliance source code software build. So can you talk a little bit Davide how you're treating this inside of a company when you're looking out there to say, well, okay, we do need to get that bill of materials together, but then we have to get a source release that actually works and that our customers can rebuild and reinstall the software onto our devices in the field, which I think we all agree is a technologically challenging thing to do. How are you looking at that and addressing that when so much of the compliance focus is just on that initial step and sometimes misses that later step. So I think those are complementary matters. And you know, it's hard to just draw a line, right? And I think it kind of goes back to a couple of things. Number one, why a company is in open source, right? So I think unless you're really 1970s software company that still believes that, you know, the value is in the software itself, I think most of the software companies today has moved past the idea that you monetize the software itself, and it's about monetizing what's on top through value at services, etc, etc. So in that perspective, software becomes the vehicle to, you know, value at services and monetization. So I mean, you don't want to take any risks. I mean, you want to be complying until the very end of it, because you actually won't meet people to use more and more and more of the software that you contribute, because by using that, that becomes the vehicle for you for an upsell, right? So when the business comes into the picture, now you understand that that's not a cost, like screw it, you got to suck it up. No, it's not a cost, it's actually a value, you want to do that, right? And then as you start doing that, it's kind of natural that you're going to try to drive efficiency into the process of this, it's called compliance envelope, so that from the very beginning to the very end, things are, you know, that are added onto that have a piece of information, right, so that this compliance envelope can traverse, right? So I think, you know, in general, you know, it's seen as an obstacle or a cost. And I'll tell you something different, right? Or something more, it's a cost if the organization is not mature enough to have figure out what is the business model on top of the code and the source code itself, but the moment that the organization is mature enough to figure out the business, the path to money, then being compliant adds up and helps you actually monetizing and making business. And I'll tell you this is the last thing, you can see the maturity of your organization by this question, when you start implementing compliance into an organization that is getting mature, but it's not quite there. The typical thing is, can I just use phosology? And it's like, kind of, if this is about your accuracy, then maybe it gets you 20% of the way, how about the red flags and the Christmas tree, then now you're going to have to go fix to make sure that the accuracy is high enough, right? And then, oh, I need to staff a team. Yes, you need to staff a team, because that's kind of important, right? So if you want to suck it up, you're going to suck it up properly. So get a team on board, because that's what you had to do to ensure that compliance envelope accuracy across the board. I think I'm going to spend the next five years paraphrasing Davide to say the mature companies should believe software freedom is part of their business model. So I know that's not exactly what you said, but you're sort of hinting at that, and I really like that. You can quote me on that. Oh, that's wonderful. I got to quote you on that for sure. So Miriam, I want to come back to you. Following up on something that Pidge said that I really like to hear you comment on, there has been this divide going back to when my career began in the 90s. So it predates even to heavy discussions of false compliance of engineers want to do what they want to do and get the product working and lawyers just get in their way. And lawyers give them instructions that don't make any sense. How are you looking at how we're going to do this going forward in the next generation? How do we get lawyers and engineers to talk together as equals who are working together on a team to do the right thing rather than being at odds with each other? How do you see that fitting into the future of compliance? I think one part of the solution to that might be to actually get lawyers to understand the technical backgrounds or at least understand the developers that they are talking to. I know there are some good projects even at university where they start to teach lawyers at least basics on development and software development and they at least have to pick that up. But I don't know if that's happening everywhere and enough. But I think that's one part of the solution so that you can actually understand what everyone is saying that you're talking to. The other thing I think is, again, maybe a solution for lawyers. They should start offering solutions and not just saying what doesn't work and trying to get them to find, to get to a solution together maybe. And at least I often find that when you explain the background and why some things are an issue or are a risk or whatever courts ruled on it differently, developers tend to understand that because they think really structured and in that regard very similarly to lawyers. So you get to a point where you can kind of get rid of the issues and focus on how you can move forward. I think rather quickly actually if you start at a point where you understand each other. Yeah, I definitely agree with that. So John, I want to turn back to you on that question. I think one of the things that we've tried to do in the activism world is that kind of connection you were talking about about why companies should really see it as their benefit to give software freedom to their users. And I so often see, and I'm sure we've all seen this, going back to Davide's point of the mature company, the less mature companies don't get this yet. So how do you see the words and requirements of the license, like what would you say to a company that's not mature that Davide is referring to? What would you say to them, John, about like to get them to stop focusing on just like meeting the bare minimum of the requirements and actually engaging in software freedom in a way that would benefit their company? Yeah, it's a question, I mean, I think part of it is to your company's robbing concern about reputation, you know, and I think that's definitely one part of the approach is to discuss that and the fact that this software constructed through sharing really is a community and it's in the company's interest to be a good citizen within that community and that will have benefits to them both depending on what business sector they're in, of course, but different kinds of benefits to them, one of which being when they do make a mistake, if they do make a mistake, there'll be a lot of community goodwill there, knowing that it was a mistake and plenty of people, including the Free Software Foundation, willing to help advise them on how to do things properly, as opposed to just filing a lawsuit. And I think so that the reputation and that kind of good citizen aspect is important. We'll also point to examples of where new and exciting things have been done as a result of the software being distributed to users and probably you've written about the things that have happened with the router firmware from that source code having to be released since it was built on another GPO code and that lets you knew your software that could be used by companies and put in their products and shipped. And then, of course, we want companies to be socially responsible and I think that is a persuasive argument in today's world especially and it's talking to companies about how do your employees care about this, your customers care about this, you as a hopefully human being that desires to be ethical in this world should care about this and try to approach it from that standpoint as well. So I think there's all of those, the reputation, the practical benefits and the ethical, socially responsible reasons to talk about. Yeah, so I want to go to Pidge then because Pidge, one of the things that I feel, I feel and you can confirm or deny if this is, if I've got this right, but I feel like when I look at what you're trying to do, you're basically trying to get the details right for what John is talking about. So and by that I mean, I see the kind of work you're doing is saying, well, yeah, I want to make companies be socially responsible, do the right thing with compliance, but I want to make it straightforward, easy and design well for their engineers, like build that connection that Miriam was talking about between the engineers and the lawyers understanding what needs to be done and make it as part of a rote task like doing good testing on your software and doing other engineering and software development practices. So can you talk a little bit, and remember that the FOSDA audience is pretty advanced. So if you can get a little bit in detail of how do you see we do that as a technical matter so that when you, so that someday when you start from Yachto, you know, if I started from Yachto, the thing on the other end is going to be that compliance source release and Yachto is going to give it to me or whatever project it is that would give it to me. So I'll give you an example of some of the last people we worked with for the past couple of years and we were doing compliance work with them. Every release and they were doing like, you know, scrum sprints. So it was like once every three weeks, every release for multiple machine firmware, all of that. And I'm going to defend FOSOLOGY here. It got, all of that got generated, thrown up on the FOSOLOGY site using the metal license tools layer and someone went through and someone who was familiar enough with the build system went through and did that work. And we found issues like, you know, because it wasn't a one off compliance thing. Okay. Yeah, we're done. We're released. Done. We don't have to do this again. It was a continuous auditing of the entire process and not just auditing. Did we go through and create a manifest? It was, did we go through, create a manifest? Did we go through, create a bill of materials? Do are all the metadata in the, which is the, the scripts that control compilation out there, not just for GPL stuff, but for MIT, for BSD, for all of it. Did we ensure that anything that was code embargoed because it was closed source license not make it out as well? Which is important, you know, because there is closed source stuff on this. And also how much GPL three is on that because embedded developer, well, not embedded developers, embedded manufacturers don't necessarily like GPL three because they have difficulty with some of the things if they're trying to do a box that's locked down. So you know, there was this entire process that we had to go through and we went through it once every three weeks and it was continuous. So when we start talking about compliance and thinking about compliance, we have to stop thinking about it as this one-off thing that we do in thinking about it as a continuous integration, continuous test, continuous audit and continuous testing of the stuff that comes out at the end. Is this usable for the end user? Is this something that's useful? What happens if Bradley comes knocking on our door? You know, when these are things that we all have to start thinking about what we were doing with this client of ours. So David, you're often in the position of being inside the company who would be a client to something like this. And I want to pick up on something you were saying about the mature company. We'll see that this is valuable. One of the things that we haven't really seen yet because we've seen so much, like we're talking about so much effort going into the build material stuff, we've got PID sort of doing your base firmware that you start from, AIDS compliance that PID was just talking about. But when do you think a company like Huawei can get to the point where it doesn't just want to participate upstream in Linux, like the full upstream, which I know it does, but wants to be participating in things like let's make an entire firmware that everybody is collaborating on instead of each company doing their own firmware. And then that would mean, of course, less going back in and trying to get that firmware into compliance if everybody's using that same firmware base. How do you think we can get there? And can we even get there? Or is this divide between upstream and final build going to continue to be so wide? No, I think it's going to go on. And it's about deep fragmenting and deep fragmenting and deep fragmenting and deep fragmenting, if I take the auto project and I've been lucky enough to be one of the founding fathers back in 2010 when I was at Wunderber, right? So that's how I know our friend here. And it was about creating one common set of technologies and tools for deep fragmenting the embedded device industry, meaning that it didn't reinvent the wheel, it didn't recreate the Linux kernel, bash, Apache, boa, whatever that is, it didn't reinvent BigBake, but it really creates an ecosystem, a sandbox where partners with the same goal in mind shared that effort so that each and every one of them could benefit in the end, right? And so that is this broad. Now that goes to Huawei. As a matter of fact, my team is responsible for launching in Europe Open Harmony, which is the Huawei-led open-trist initiative to create an operating system that powers consumer devices. So this is Yachtso, consumer devices is this, right? So it's not the entire industry, but it's this. So we are using a leverage in BigBake, Yachtso LTS, but now we also need to support smaller devices that use Zephyr. That's another project, right? So now we get together consumer companies, device makers just like Huawei, Samsung, LG, just making names up, right? Just to give an example, Bosch, Siemens, LG, Sony, et cetera, et cetera. And now you're defragmenting the consumer device industry, meaning that you're not creating something called open harmony, right? But it's an open-source play with those companies re-use Yachtso, tailor it to consumer devices and defragment that industry. And they all participate in that open-trist project in the compliance activity that we just mentioned so far. And at that point, once you have consumer companies just working together, right, to defragment the industry, it's very easy because consumer companies are B2C, so they serve the end consumer and you are at the end of the chain, right? So I think we're going to proceed by defragmenting and defragmenting and defragmenting. And so long as this compliance envelope traverses this defragmentation effort, you will see participation. But defragmenting has to be there as a business goal, right? If there's no business goal in defragmenting, then participation is now going to be possible. That makes sense to me. I want to go back to Miriam now because when I continue to hear all of everybody else here talk, I want to sort of see what the lawyers are saying because one of the things I've noticed is the lawyers are actually end up being on the front lines of this because the first time they realize they have a compliance problem, they're going to make a comparison to GDPR, which of course we in the US where I'm based have to comply with because we give services to Europeans. And while even for an organization like the one I work for, where we really care about the goals of GDPR, it's still a pain to comply with GDPR. It's still work to be done. And every once in a while, I'm like, oh man, we really have to do our website that while GDPR says we have to. So Miriam, I want to ask you how much, I'm not going to make you say percentages, but give us a sense of our companies where Davide is trying to say they ought to be and trying to build these firmwares or are companies coming to still coming to look at open source and free software and saying, darn, it's annoying thing I have to comply with that I'd rather not have to do. Why do I have to do it? What's the majority of what you're seeing and what do you tell them to move them from one side of that to the other? Again, as I said before, for, you know, what risks do they see? I think the spectrum is just as wide on that area. So I've had clients say, yeah, we are now facing enforcement and actually we knew we had a problem there. We should have fixed it. We just didn't have the manpower to do it. Or we had to focus on GDPR on whatever else. And we had to put our teams there. That's kind of the middle. And then you have on like the upper end of the spectrum, you have companies coming in saying, we know there's open source software. We know we are not using it as much yet, but we know we're getting there. We're actually getting into the software business now as well. And we want to comply just for the sake of complying because we think it's the right thing to do and we want to focus on that. And then on the other end of the spectrum, you still have a few companies that are really troubled by the idea or don't understand the reasoning behind it. But they usually get to a point where they say, well, it does make sense and I think we have to comply rather quickly. But again, it depends certainly on the companies they're talking to. I have to say I'm impressed how it has changed over the last years. It has gotten a lot better and a lot easier to sell compliance and to sell that they have to work on compliance. Most of them are really already at a point where they know they have to fix whatever issues they have and they just need to find a solution. So I'm certainly glad to hear that things are changing. I tend to be an eternal pessimist and think that it's not going to get better. But I also want to throw the same question to John. I mean, John, do you feel like at the end consumer level, people who get these devices, do you feel that we're getting to a point or moving towards a point where people feel empowered like they do in the wireless router market? Because most of the wireless routers you can install an alternative firmware that's completely free software. I know from my work that that doesn't exist in any other sub-industry. Do you see it moving in that direction? Is Davide's dream getting there as Miriam Wright that the companies are moving or do we have a lot more work to do? And if so, what's that work, John? I think we have a lot more work to do. I think that I agree that there is much more widespread awareness. You can tell we're not in Brussels in January because I have just done it in my face. But yet you there's much more widespread awareness of free software and what it is and much greater willingness to use it and engage with it. I think that I do see the problem from a end user perspective is that there are so many other forces now pushing towards locking down devices for different reasons and also just so many more kinds of devices. Now I'm not just can you rebuild the software on your laptop or your desktop or even your router, but your phone. If you have an iPhone which has free software on it, you can't really install your own. You can technically apply and be a developer and install some of your own software. But there's no way to have a marketplace for free software on that device because it's prohibited. And so there's a lot of other pressures working against user freedom. And that's one big area where we have a lot of work to do. We have a certification program respects your freedom where we're trying to promote businesses that do embrace fully 100% the notion that all the software on a device should be free. When it comes to compliance, it's, you know, I do worry a bit about the kind of it's good enough or our approach is good enough. We check enough of the boxes that we're going to reduce our risk. And that's what we're aiming for. I would like to definitely see more adoption of the actual values behind all this and just more understanding that most of these compliance challenges arise because of the common because of the attempt to combine proprietary software and free software. So, you know, we want to encourage people to push the envelope in the other direction as opposed to trying to see how much proprietary software you can get away with distributing alongside the free software with the free software, you know, push it in the other direction and see how much of your software you can distribute as free as a solution to the compliance challenges makes them a lot easier. And so the risk is saying this is all Pidge's job to solve. Like I do want to ask Pidge, like, like, how, like, how do you do that process with like a client when a client comes to you and they're having embedded firmware and it's a mess and you're trying to tell them switch the octa do this. Are you able to get through to them to the other side where there is a big advantage and change them into that mature company that we've been talking about, get them to care about the end user installing it? Or are you or do they just come to you and say fix my problem so I don't have to think about it again and I don't want are they telling you help us lock down your device? Are you having to push back with your clients about that? Yes and no. I think that what a lot of the people that I have talked to, they understand that either this is the right thing to do and not necessarily for moral or ethical reasons, but for entirely selfish reasons. You see this kind of in like some of the EU things with GAIA acts where they want privacy and open firmware all the way down to the chip level because they don't necessarily trust close binaries, close bobs on the chip. You don't trust that. So I think that from a lot of folks, it's coming from either a I never want to get that email from Bradley or I never want to do this where I get kind of called out for using open source software in my products and not doing it. So like most of the folks that are there aren't fighting this, like the ones that I'm dealing with, but no, I'll ask you that. Those are the folks who are coming to me already. So it's the ones that are coming to folks that are the ones that we worry about, right? They're the ones who either don't think that they have a problem or don't know that they have a problem. So the ones that I talked to are already on board. So that brings me over to Davide and probably asked the hardest question that just has to be asked because Huawei is not a company that's known for its transparency. It's had some trouble with that. It's been accused of spying. It's been accused of doing things in the firmware that we in the free software world have always argued. Well, if your software is free software, we can check and verify. Do you think that's going to be an argument going forward inside your company to say if you do this and allow the users to rebuild and reinstall the firmwares on Huawei devices, I would argue that it gives you a great answer to the problems the Huawei has faced. But I'd like to give you the opportunity to kind of address that and how do you connect up the transparency and other issues that Huawei has struggled with with the transparency and user freedom that is inherent in FOS as you become a mature FOS adopting organization. Yeah, I think the answer is all in. So it's Huawei in first person, right? Huawei can be considered a person, a juridical person, right, has been particularly hit by services being pulled off or pulled away for the nature of known free services, right? So if a player in the industry feels that by using known free software, then your business is going to be impacted, then, I mean, no, let's use free software. Let's use open source software. Not only that, if by using and by doing free software and participating in a community as an active open source citizen, now all of the bad marketing that I'm getting, right, it's going to go away because I contribute first, I participate second. Now all of a sudden I'm using technology that everybody uses and contributing technology to the world. I'm not vendor locked in anymore. My brand in terms of transparency, protection of IP, et cetera, et cetera, you know, just gains value, I mean, all in, right? So in essence, that's the reason why my group was created. In essence, that's why after years and years and years of career in open source, you know, many companies in the US and Europe, Huawei came to me and said, listen, we're all in in here. Can we build the open source technology center in Europe and be all in when it comes to open source because it's good for us, it's strategic, it's good for the world, so let's go for it, right? I'm saying selfishly, selfishly, open source is really good, it's the strategy, it's the real strategy. Okay, well, we're coming towards the end of the session and so to make sure that everybody gets a chance to say what they want to say, I want to go through and give everybody a minute or so to say whatever, something I didn't ask as moderator that you really want to make sure we covered or that you wanted to bring up. And I've been keeping track of people who have seen me looking over to their side about time. Miriam's had the least amount of time to speak, so I'm going to start with Miriam. Is there anything you wanted to say about FOSS compliance that we didn't get to? Yeah, one point I had been meaning to make before when you were asking John and Pidge, actually. I think one thing, one development that I really like is that companies are looking a lot more into contributing back and getting engaged into open source software projects, not only using but also looking at the other side. I think for many companies, that's still a bit harder to look into that and to figure out where do I get engaged, what makes sense, where do I put my teams, what do I look at, but it's happening a lot more and at least we do get a lot more questions around that and I think that's a good development in this space. Thank you. So John, do you have anything that we didn't cover that you wanted to make sure was brought up? Yeah, I think that we're talking about compliance in particular with Copy Left and I know that a lot of people are talking about sustainability right now when it comes to the free software that they depend on, learning that the projects they depend on are maybe only maintained, actively by a couple of people and are in a precarious situation. And I just want to emphasize how important we think Copy Left is to sustainability. Copy Left is the thing that ensures that free software will be getting more free software as opposed to more of a mis-sic licenses that put software out there that can then just be used to get proprietary software to market quicker and that really undermines the sustainability of the whole system that businesses are being built on. So that was one thing I wanted to make sure was out there and I just wanted to offer our help at the FSF and we do our best to maintain good kind of best practice documentation which helps establish community norms and make all this a lot clearer for people and we do a lot of kind of unsung work for improving licensing hygiene and the projects that we noticed. We even did a little bit with Big Blue Button actually that helped them clean up a few things with their licenses. So, you know, we're here to help. You can always contact us at licensing.fsafe.org. And I just want to encourage everybody to go as far as you can to push the envelope as far as you can. You know, don't lock down the device even if you think you might be able to get away with it. Embrace the idea that people can do and do creative things with your products that will then probably benefit you in the long run as well as well as just being a socially responsible thing to do. And I can't help but jump in to say that free software builds for devices make the devices life last longer and it's fewer devices ending up in landfills which is another type of sustainability problem. And I want to go to Pidge and ask if there's anything you wanted to add to it. I didn't ask or something about cost compliance. You wanted to tell everybody? No, but I do want to second that in that if you are using open source and building a business on open source, it needs absolutely no sense from a business perspective to starve open source. So, if you are using a lot of open source and not contributing back either financially or patch is welcome, start doing that now because it is a business sense thing. It just makes business sense. On top of that, if I'm relying on things from a security perspective that there's three people who work on the project and only one of them is getting paid to work on the project, that's an issue and as open source, we need to get the larger utilizers of open source to start contributing back more and more. Davide, anything you wanted to make sure we covered that I didn't ask about? No, I think you asked all the hard questions. You gave me a chance to reply. So, it's great thing. So I'm just going to compliment what was just said. I mean, when it comes to contributing open source software, it's so business and ecosystems are created for, ecosystem is created for business reasons. I mean, companies get together because there's a business sense. But because there's a business sense, mature organization measure the number or the efficiency of a project in terms of decreasing contributions or increasing contribution. Meaning, if I'm the first to start a project and I get a second partner, third partner, fourth partner, fifth partner, I'm contributing 70%, 80%. Over time, I want to see that going down. I want to see that evenly distributed. Because if it's not evenly distributed, A, I'm the bully of the ecosystem. It's not open. I'm dominant. It's not good for marketing. And it's not efficient for me. So back to mature organization, it's about contribution. It's about being all in and it's about sharing this burden together of contributing together and building something together. So that's how businesses think if they're mature enough. Thank you all so much for being here. I'm going to go round and round about with everybody one last time and just give you a chance to say any URL or project that you want to promote to have people to look for further information. I'll start with Miriam. Anything you want to promote or ask people to take a look at? We actually had to have at least one time someone saying you are mute now. Sorry about that. Sorry. Now I have to think there is actually a GDPR project that is open source. I think it's the French authority that's putting out a lot of open source software around GDPR compliance. So maybe plug them because I think it's a good idea to do that. John, is there anything you want to give a URL or something to promote for folks to take a look at? Oh, he's on mute now too. Second time. Yeah. I think maybe we will actually have an announcement shortly about a continuing legal education series online to go with our conference, neighbor planet and marsh. And that's one place for every try to help lawyers, especially from corporations, advanced business owners in this area and also get this kind of time talking with each other. If we're going to do an online version of that, shortly just watch FSF.org for more information. Did anything you want to promote as we wrap up? The Octa project as always because I have to. But also I'm working on a new project called Network Great Linux. It's going to be announced in a few weeks. But look for that coming out soon. And Davide, you get the last word, anything you want to promote that you're working on that you want folks to take a look at? Yachto project, Zeffra project, Linux foundation, the Cliff Foundation, Free Software Foundation, open harmony. You guys have funded FOSDEM and that's it. You guys keep up the good work. This is going somewhere. I want to thank all our panelists for doing this difficult, difficult remote panel and we're so glad that you joined us and we hope that next year in Brussels we'll all be together and be able to go out to dinner after our panel then. Thank you all for being here. Thanks, Brad. Thank you. Thank you, Bradley. Goodbye guys. It was a pleasure. Bye.
 Hello, everyone, and welcome to our panel for our FOSDEM legal and policy dev room on  compliance.  This has become somewhat of a staple for our dev room.  We're doing it, of course, remote this year because of the pandemic, but we have a couple  of great panelists that are going to dig in today to discuss the issues of doing GPL compliance  with a focus on what happens for the customers, the users, the individuals who get devices,  how do we assure that they have the source code they're supposed to get under copy left  licenses that works, and we're going to talk about it from a number of different perspectives  from folks all over the industry.  I have joining us today, first of all, John Sullivan, the executive director of the Free  Software Foundation.  We have Davide Ricci, the director of open source technology center at Huawei.  We have Eilish Nilonigan, also known as Pidge, who is the CEO and CTO of Togan Labs and the  chief architect of Network Grade Linux.  And coming to us from the legal side, we have Miriam Belhausen, who's a lawyer at Bird  and Bird and focuses on copyright law.  So to get started, I would like to start with asking John a question because, John, you  worked for the principal person at the organization that started the whole idea that software  freedom was an important issue way back in 1985, and we're really the first to talk about  why it's important.  Can you tell us a little bit about why the issues of compliance with copyright, the  copy left licenses fit so directly and importantly with the issues of the compliance requirements,  the details in those licenses that companies and redistributors have to follow?  Sure.  And thanks for having me on the panel.  I'm looking forward to the rest of this discussion.  I think it's a very special thing about free software that it is designed to have both  fully commercial and non-commercial purposes.  And so we, at the FSF, use this as a social movement for sure with an ethical foundation  and an ethical mission, but these chances to talk together with the people that are  using the software commercially and have experience doing that and hearing their experiences is  really an important part of that.  So the primary copy left license, I think that we have in mind is the Gidu general public  license and that has a very simple requirement and it's a phase that you have to share when  you distribute a program to another person.  You have to share the source code, which is what you as a programmer or what the programmer  is that you hire actually use to modify the program and create the program, the human  readable code.  And the reason that that's requiring it is because of binary program that's not particularly  useful other than for purposes of being able to run it or hand it off to somebody else  so they can run it too.  If you wanted to understand anything much about how the program works or you want to  be able to make changes to it, you have to have the source code for that.  And that's the whole reason for free software where it's existence is so that users are  in control of the devices that they have, the software powered devices that they have  rather than those devices being in control of them.  And if you can't inspect the program that's running on your laptop or your phone or in  your car, then you can't actually know what it's doing other than trusting the company  that gave you that software, you know, trusting that they're telling the truth.  The same point of example is unfortunately where that doesn't pan out.  And then second of all, even once you understand it, if you want to be able to make a change  to it, you also need the source code for that.  And I think the closing key thing here is just that these rights aren't just for programmers.  Anybody, if they have the source code, can go to a programmer and ask them to make a  change for them, just like you can get your car repaired at a mechanic or have someone  else fix the HVAC system in your house.  But you can't do that unless you have the rights to the source code and the freedom  to take it to other people and ask them to do things.  And Pidge, that's why I want to come to you here, because one of the focuses of your work  is, as I understand it, is to help people and help those who build these devices, which  are these days a lot more complicated than they were when these licenses first came out,  to actually make that software build and work correctly and create these compliant source  releases that are required under these licenses.  Can you talk a little bit about what you're seeing in your work and trying to help your  clients get that source code right?  And what the challenges are that they face with regard to the interaction between the  details of that software and its source code and their compliance requirements.  Right.  So a little background here.  When people do a lot of software compliance work, they're doing it around one chunk of  the software, undoing an entire firmware blobs, so entire Linux stacks.  And it's complicated because you just, it's not, I need to know what software is on it  and what the licenses are.  You also end up needing to know how it's built and how it's all tied together.  So with a lot of my clients, it's initially, why do we need this?  Can't we just throw out the metadata and just have it that way and not actually provide  the source code?  They can get the source code from upstreams, that conversation.  So there's a period of buy-in initially, and then the complicated work happens, which  is going through each and every bit, figuring out which source package is using, because  one bit of source code or one package may have multiple things that come out of it with  various different licenses.  So for example, I don't know, I use this all the time, puzzle.  Puzzle may have puzzle, puzzle dev, puzzle docs, and they're all going to have very different  licenses.  So it's understanding everything from nuts and bolts all the way from initial build  system all the way to how everything's built to how everything's deployed.  So there's a lot of teaching developers, things that they shall not do, like static  compilations of close-arge software against GPL code, which we have to have that conversation.  And software developers are clever and they go, what if we do a shim layer and, and, and  you know, just stop trying to get around that.  So there's a lot of education on the corporate side that I end up having to do to teach developers  how to do this, how to do this correctly, and how to do compliance activities afterwards.  Does that answer your question?  Yeah, it does.  And I want to go to Davide now, because what you're, what you're doing is you're looking  from inside your company and trying to build up and answer these questions so that your  employees know how to do this correctly, how to incorporate free and open source software  into your products.  Why don't you tell us a little bit about how you design that strategy from inside a company  to make sure that you're getting that final source release at the end, as, as Pitch says,  is looking at the entire firmware blob and making sure you have what's required for the  entire firmware, not just one part.  So first of all, the, you know, I've done this couple of times, I've done it at Windriver  and I've learned at the Intel OTC school up in Portland, and then I'm not doing this  a while way.  So first thing that you had to do is just do it first.  Even before you start building codes, you know that you're going to be using open source  software when you build an operating system.  So first thing that you had to think is, how do I ensure the compliance, right?  And how do I do it incrementally?  So over time, I mean, initially it was a lot of, you know, guests and let's figure it out,  you know, work.  Right now we have good standards that are coming up, for instance, Linux Foundation with the  open chain standard, which is really industry-oriented.  Free Software Foundation is helping us a lot, especially in Europe, helping Huawei to actually  do it, right?  But you know, it's about, as I said, if you want to go with open chain, it's about creating  a policy, funding the policy.  So essentially you got to make sure that it's funded.  There's people to actually follow the policy.  Training individuals so that developers, managers, they know what the process is, what their roles  is.  So then at the end of the day, everybody knows the dues and the don'ts.  And then when you start building that build of material that tells you, hey, in this device,  there's this software, these are the licenses, this is the manifest, these are the author,  this is the license that we think the software has.  Oh, and by the way, hey, IP analysts, can you go look because some licenses are not clear.  At the end of the chain, you have the best possible accuracy when it comes to the build  of material.  There's no 100% accuracy in businesses about risk and gain.  But as a general manager, I don't want to go to market with a big unknown.  So at the end of the day is the most accurate build of material that gets me through.  And if there's a red flag that is flagged by, you know, from you by the team, then,  you know, you take a risk-based decision.  But that's pretty much the process you follow.  Yeah.  And so you identified risk and that brings me to want to ask Miriam about that question  of risk because ultimately the reason, if there were no requirements in any of the open  source and free software licenses that we have, particularly the copy left ones, no one  would worry about any of these questions that Davide is talking about.  So Miriam, what do you see?  We're so many years now into adoption of open source and free software in companies.  When you talk to your clients, what is their legal concern?  What is their fear?  And on the other side of it, are they able to see it, convert that legal risk into let's  make things better for our customers?  Like where do you see that divide happening in the clients that you're talking to?  Yeah.  Happy to answer that.  And also, thank you for having me on this.  So to be honest, I think there's a big difference between different types of companies and the  risks or the issues that they see.  So there are, let's say, companies that have been in the software business for a very long  time and they've been working, developing with software.  They are really knowledgeable already.  They know what they're doing, maybe kind of like Huawei.  And as David just said, they are looking into this.  They are working on strategies.  They are looking at the software that they're using.  They are looking at it from the beginning.  And they have very specific questions.  And they generally also already know how they would handle certain risks.  And then on the other end of the spectrum, you have more, let's call them traditional  companies coming into the software space that have maybe just built whatever device, let's  say a fridge for years.  And now all of a sudden, the fridge is smart and uses a lot more software and they are  working with a lot more software.  And that's really not their core business so far.  And they tend to be looking at the software development and the risks they assume open  source software has from a totally different perspective.  So with these types of companies, you would still hear questions like, well, how can we  even use open source software?  There's a copy left in there and all of that is a really big risk.  So you kind of have to find out where do they stand, how far along in this development are  they?  How much have they looked into this?  What type of developers are they working with?  How knowledgeable are they?  And how much are they pushing?  Are there maybe differences in the different areas they are working in?  So yeah, that's a big spectrum, I would say.  And so I want to connect that up to ask John because when you talk about the risk reward  and analyzing that, I think from the activist side, you probably look at this a little bit  differently.  So the reward, I would guess, to the activist, admittedly I'm an activist too, so I know  this is true, that the reward is that with copy lefted software being in these devices,  it means software freedom for people who get the devices with the source code correctly.  But of course, the risk is the risk of non-compliance.  And in your world, that means software users don't get freedom.  So when you look at this, how do you reconcile all that question of risk and help to educate  and explain to people that the risk is really a reward because your customers get software  freedom?  Yeah, and I think that it's important for anybody distributing particularly copy left  software to understand that this dynamic is what gave them that software to begin with.  And so the risk of non-compliance, on one hand, an important part of it is that you're  not respecting your users, your customers, anybody that's receiving the software from  you, but you're also sort of in a long-term way undermining your own business model.  Because this collaboration model is what created the software that you're using that you're  able to ship with your products.  And if you're not doing that properly, then you're not enabling possible participation  by other people.  You're not enabling bug reports.  You're not enabling the entire culture that created this thing that you're able to use.  But yeah, it is for us, it's more than just the risk from a very short focus.  The company perspective is possibly being sued or having to go through a complicated legal  conversation with somebody.  And that is certainly a risk that people should worry about.  And one of the things that we do is enforcement at the FSF on the new software that we hope  copyright over.  But really, we want everybody to participate in this process and treat this process as  something that benefits them and creates a level playing field where no competitor of  yours is getting an advantage either by skipping out on some of the requirements here.  So I want to go back to Pidge because that interesting thing about the competitor issues,  one of the important things about free software and copy left in particular is it assures  that everybody's on equal footing.  So Pidge, when you're looking at this from an embedded side of building these firmwares  and checking the compliance of the firmwares and checking they build, what concerns do  you have as you're doing the analysis to sort of get to the conclusion of, well, does the  source code really work?  And are we putting something out there that can actually be collaborated over as far as  the technological solution versus just kind of meets the bare minimum of the requirements,  which might not necessarily inspire that kind of collaboration.  Can you talk a little bit about how that divide gets handled when you're doing this kind  of work both as an upstream and for a client who's asking those questions?  So I'm going to plug the project that I work on, the doctor project in that.  I have to because when I wrote the initial pass through the license compliance stuff  and when I was told to write that, I was told to go talk to the lawyers about this and I'm  like, screw that, I'm going to go talk to Bradley because he's one doing license compliance.  You remember the conversation, I'm sure.  And I went and talked to the lawyers and then I talked to Bradley and then I was like, okay,  this is what he's looking at.  So from my perspective, the outputs that the doctor project gives should also be able to  be inputs as well so that people can do this.  And it makes sense from an embedded perspective because if you look at where embedded is going,  if your refrigerator is embedded, refrigerators last what, 10 years?  I don't want to be maintaining firmware for 10 years.  I want the community to go out and do it.  So from my perspective, it goes, there's compliance at the top of the stack, but it goes all the  way down to the bottom of the build system and ensuring that the things that come out  of the top of the stack are able for the community to go take those and regenerate them all from  scratch.  Now, there are folks that do not like doing that and I tell them to suck it up because  it makes no sense not to do that.  So that brings me back to a couple of things that Davide was saying.  So there is this and I always promise I'll ask a few hard questions.  So this may be a hard one.  But you mentioned a lot of these initiatives in your initial comments there that are out  there related to bill of materials and trying to get just a list of licenses, which I think  everybody would agree is the first step you have to do.  One of the concerns and I'll show a little bit of my bias here I've had is that it's  kind of what Pidge is saying is that that's a necessary but not sufficient thing to really  get a compliance source code software build.  So can you talk a little bit Davide how you're treating this inside of a company when you're  looking out there to say, well, okay, we do need to get that bill of materials together,  but then we have to get a source release that actually works and that our customers can  rebuild and reinstall the software onto our devices in the field, which I think we all  agree is a technologically challenging thing to do.  How are you looking at that and addressing that when so much of the compliance focus  is just on that initial step and sometimes misses that later step.  So I think those are complementary matters.  And you know, it's hard to just draw a line, right?  And I think it kind of goes back to a couple of things.  Number one, why a company is in open source, right?  So I think unless you're really 1970s software company that still believes that, you know,  the value is in the software itself, I think most of the software companies today has moved  past the idea that you monetize the software itself, and it's about monetizing what's on  top through value at services, etc, etc.  So in that perspective, software becomes the vehicle to, you know, value at services and  monetization.  So I mean, you don't want to take any risks.  I mean, you want to be complying until the very end of it, because you actually won't  meet people to use more and more and more of the software that you contribute, because  by using that, that becomes the vehicle for you for an upsell, right?  So when the business comes into the picture, now you understand that that's not a cost,  like screw it, you got to suck it up.  No, it's not a cost, it's actually a value, you want to do that, right?  And then as you start doing that, it's kind of natural that you're going to try to drive  efficiency into the process of this, it's called compliance envelope, so that from the  very beginning to the very end, things are, you know, that are added onto that have a  piece of information, right, so that this compliance envelope can traverse, right?  So I think, you know, in general, you know, it's seen as an obstacle or a cost.  And I'll tell you something different, right?  Or something more, it's a cost if the organization is not mature enough to have figure out what  is the business model on top of the code and the source code itself, but the moment that  the organization is mature enough to figure out the business, the path to money, then  being compliant adds up and helps you actually monetizing and making business.  And I'll tell you this is the last thing, you can see the maturity of your organization  by this question, when you start implementing compliance into an organization that is getting  mature, but it's not quite there.  The typical thing is, can I just use phosology?  And it's like, kind of, if this is about your accuracy, then maybe it gets you 20% of the  way, how about the red flags and the Christmas tree, then now you're going to have to go  fix to make sure that the accuracy is high enough, right?  And then, oh, I need to staff a team.  Yes, you need to staff a team, because that's kind of important, right?  So if you want to suck it up, you're going to suck it up properly.  So get a team on board, because that's what you had to do to ensure that compliance envelope  accuracy across the board.  I think I'm going to spend the next five years paraphrasing Davide to say the mature companies  should believe software freedom is part of their business model.  So I know that's not exactly what you said, but you're sort of hinting at that, and I  really like that.  You can quote me on that.  Oh, that's wonderful.  I got to quote you on that for sure.  So Miriam, I want to come back to you.  Following up on something that Pidge said that I really like to hear you comment on, there  has been this divide going back to when my career began in the 90s.  So it predates even to heavy discussions of false compliance of engineers want to do what  they want to do and get the product working and lawyers just get in their way.  And lawyers give them instructions that don't make any sense.  How are you looking at how we're going to do this going forward in the next generation?  How do we get lawyers and engineers to talk together as equals who are working together  on a team to do the right thing rather than being at odds with each other?  How do you see that fitting into the future of compliance?  I think one part of the solution to that might be to actually get lawyers to understand  the technical backgrounds or at least understand the developers that they are talking to.  I know there are some good projects even at university where they start to teach lawyers  at least basics on development and software development and they at least have to pick  that up.  But I don't know if that's happening everywhere and enough.  But I think that's one part of the solution so that you can actually understand what everyone  is saying that you're talking to.  The other thing I think is, again, maybe a solution for lawyers.  They should start offering solutions and not just saying what doesn't work and trying to  get them to find, to get to a solution together maybe.  And at least I often find that when you explain the background and why some things are an  issue or are a risk or whatever courts ruled on it differently, developers tend to understand  that because they think really structured and in that regard very similarly to lawyers.  So you get to a point where you can kind of get rid of the issues and focus on how you  can move forward.  I think rather quickly actually if you start at a point where you understand each other.  Yeah, I definitely agree with that.  So John, I want to turn back to you on that question.  I think one of the things that we've tried to do in the activism world is that kind of  connection you were talking about about why companies should really see it as their benefit  to give software freedom to their users.  And I so often see, and I'm sure we've all seen this, going back to Davide's point of  the mature company, the less mature companies don't get this yet.  So how do you see the words and requirements of the license, like what would you say to  a company that's not mature that Davide is referring to?  What would you say to them, John, about like to get them to stop focusing on just like  meeting the bare minimum of the requirements and actually engaging in software freedom  in a way that would benefit their company?  Yeah, it's a question, I mean, I think part of it is to your company's robbing concern  about reputation, you know, and I think that's definitely one part of the approach is to  discuss that and the fact that this software constructed through sharing really is a community  and it's in the company's interest to be a good citizen within that community and that  will have benefits to them both depending on what business sector they're in, of course,  but different kinds of benefits to them, one of which being when they do make a mistake,  if they do make a mistake, there'll be a lot of community goodwill there, knowing that  it was a mistake and plenty of people, including the Free Software Foundation, willing to help  advise them on how to do things properly, as opposed to just filing a lawsuit.  And I think so that the reputation and that kind of good citizen aspect is important.  We'll also point to examples of where new and exciting things have been done as a result  of the software being distributed to users and probably you've written about the things  that have happened with the router firmware from that source code having to be released  since it was built on another GPO code and that lets you knew your software that could  be used by companies and put in their products and shipped.  And then, of course, we want companies to be socially responsible and I think that is  a persuasive argument in today's world especially and it's talking to companies about how do  your employees care about this, your customers care about this, you as a hopefully human being  that desires to be ethical in this world should care about this and try to approach it from  that standpoint as well.  So I think there's all of those, the reputation, the practical benefits and the ethical, socially  responsible reasons to talk about.  Yeah, so I want to go to Pidge then because Pidge, one of the things that I feel, I feel  and you can confirm or deny if this is, if I've got this right, but I feel like when  I look at what you're trying to do, you're basically trying to get the details right  for what John is talking about.  So and by that I mean, I see the kind of work you're doing is saying, well, yeah, I want  to make companies be socially responsible, do the right thing with compliance, but I  want to make it straightforward, easy and design well for their engineers, like build  that connection that Miriam was talking about between the engineers and the lawyers understanding  what needs to be done and make it as part of a rote task like doing good testing on  your software and doing other engineering and software development practices.  So can you talk a little bit, and remember that the FOSDA audience is pretty advanced.  So if you can get a little bit in detail of how do you see we do that as a technical  matter so that when you, so that someday when you start from Yachto, you know, if I started  from Yachto, the thing on the other end is going to be that compliance source release  and Yachto is going to give it to me or whatever project it is that would give it to me.  So I'll give you an example of some of the last people we worked with for the past couple  of years and we were doing compliance work with them.  Every release and they were doing like, you know, scrum sprints.  So it was like once every three weeks, every release for multiple machine firmware, all  of that.  And I'm going to defend FOSOLOGY here.  It got, all of that got generated, thrown up on the FOSOLOGY site using the metal license  tools layer and someone went through and someone who was familiar enough with the build  system went through and did that work.  And we found issues like, you know, because it wasn't a one off compliance thing.  Okay.  Yeah, we're done.  We're released.  Done.  We don't have to do this again.  It was a continuous auditing of the entire process and not just auditing.  Did we go through and create a manifest?  It was, did we go through, create a manifest?  Did we go through, create a bill of materials?  Do are all the metadata in the, which is the, the scripts that control compilation out  there, not just for GPL stuff, but for MIT, for BSD, for all of it.  Did we ensure that anything that was code embargoed because it was closed source license  not make it out as well?  Which is important, you know, because there is closed source stuff on this.  And also how much GPL three is on that because embedded developer, well, not embedded developers,  embedded manufacturers don't necessarily like GPL three because they have difficulty with  some of the things if they're trying to do a box that's locked down.  So you know, there was this entire process that we had to go through and we went through  it once every three weeks and it was continuous.  So when we start talking about compliance and thinking about compliance, we have to stop  thinking about it as this one-off thing that we do in thinking about it as a continuous  integration, continuous test, continuous audit and continuous testing of the stuff that comes  out at the end.  Is this usable for the end user?  Is this something that's useful?  What happens if Bradley comes knocking on our door?  You know, when these are things that we all have to start thinking about what we were  doing with this client of ours.  So David, you're often in the position of being inside the company who would be a client  to something like this.  And I want to pick up on something you were saying about the mature company.  We'll see that this is valuable.  One of the things that we haven't really seen yet because we've seen so much, like we're  talking about so much effort going into the build material stuff, we've got PID sort of  doing your base firmware that you start from, AIDS compliance that PID was just talking about.  But when do you think a company like Huawei can get to the point where it doesn't just  want to participate upstream in Linux, like the full upstream, which I know it does, but  wants to be participating in things like let's make an entire firmware that everybody is  collaborating on instead of each company doing their own firmware.  And then that would mean, of course, less going back in and trying to get that firmware  into compliance if everybody's using that same firmware base.  How do you think we can get there?  And can we even get there?  Or is this divide between upstream and final build going to continue to be so wide?  No, I think it's going to go on.  And it's about deep fragmenting and deep fragmenting and deep fragmenting and deep fragmenting,  if I take the auto project and I've been lucky enough to be one of the founding fathers back  in 2010 when I was at Wunderber, right?  So that's how I know our friend here.  And it was about creating one common set of technologies and tools for deep fragmenting  the embedded device industry, meaning that it didn't reinvent the wheel, it didn't recreate  the Linux kernel, bash, Apache, boa, whatever that is, it didn't reinvent BigBake, but it  really creates an ecosystem, a sandbox where partners with the same goal in mind shared  that effort so that each and every one of them could benefit in the end, right?  And so that is this broad.  Now that goes to Huawei.  As a matter of fact, my team is responsible for launching in Europe Open Harmony, which  is the Huawei-led open-trist initiative to create an operating system that powers consumer  devices.  So this is Yachtso, consumer devices is this, right?  So it's not the entire industry, but it's this.  So we are using a leverage in BigBake, Yachtso LTS, but now we also need to support smaller  devices that use Zephyr.  That's another project, right?  So now we get together consumer companies, device makers just like Huawei, Samsung, LG,  just making names up, right?  Just to give an example, Bosch, Siemens, LG, Sony, et cetera, et cetera.  And now you're defragmenting the consumer device industry, meaning that you're not  creating something called open harmony, right?  But it's an open-source play with those companies re-use Yachtso, tailor it to consumer devices  and defragment that industry.  And they all participate in that open-trist project in the compliance activity that we  just mentioned so far.  And at that point, once you have consumer companies just working together, right, to  defragment the industry, it's very easy because consumer companies are B2C, so they serve  the end consumer and you are at the end of the chain, right?  So I think we're going to proceed by defragmenting and defragmenting and defragmenting.  And so long as this compliance envelope traverses this defragmentation effort, you will see  participation.  But defragmenting has to be there as a business goal, right?  If there's no business goal in defragmenting, then participation is now going to be possible.  That makes sense to me.  I want to go back to Miriam now because when I continue to hear all of everybody else here  talk, I want to sort of see what the lawyers are saying because one of the things I've  noticed is the lawyers are actually end up being on the front lines of this because the  first time they realize they have a compliance problem, they're going to make a comparison  to GDPR, which of course we in the US where I'm based have to comply with because we give  services to Europeans.  And while even for an organization like the one I work for, where we really care about  the goals of GDPR, it's still a pain to comply with GDPR.  It's still work to be done.  And every once in a while, I'm like, oh man, we really have to do our website that while  GDPR says we have to.  So Miriam, I want to ask you how much, I'm not going to make you say percentages, but  give us a sense of our companies where Davide is trying to say they ought to be and trying  to build these firmwares or are companies coming to still coming to look at open source and  free software and saying, darn, it's annoying thing I have to comply with that I'd rather  not have to do.  Why do I have to do it?  What's the majority of what you're seeing and what do you tell them to move them from  one side of that to the other?  Again, as I said before, for, you know, what risks do they see?  I think the spectrum is just as wide on that area.  So I've had clients say, yeah, we are now facing enforcement and actually we knew we  had a problem there.  We should have fixed it.  We just didn't have the manpower to do it.  Or we had to focus on GDPR on whatever else.  And we had to put our teams there.  That's kind of the middle.  And then you have on like the upper end of the spectrum, you have companies coming in  saying, we know there's open source software.  We know we are not using it as much yet, but we know we're getting there.  We're actually getting into the software business now as well.  And we want to comply just for the sake of complying because we think it's the right  thing to do and we want to focus on that.  And then on the other end of the spectrum, you still have a few companies that are really  troubled by the idea or don't understand the reasoning behind it.  But they usually get to a point where they say, well, it does make sense and I think  we have to comply rather quickly.  But again, it depends certainly on the companies they're talking to.  I have to say I'm impressed how it has changed over the last years.  It has gotten a lot better and a lot easier to sell compliance and to sell that they have  to work on compliance.  Most of them are really already at a point where they know they have to fix whatever issues  they have and they just need to find a solution.  So I'm certainly glad to hear that things are changing.  I tend to be an eternal pessimist and think that it's not going to get better.  But I also want to throw the same question to John.  I mean, John, do you feel like at the end consumer level, people who get these devices,  do you feel that we're getting to a point or moving towards a point where people feel  empowered like they do in the wireless router market?  Because most of the wireless routers you can install an alternative firmware that's completely  free software.  I know from my work that that doesn't exist in any other sub-industry.  Do you see it moving in that direction?  Is Davide's dream getting there as Miriam Wright that the companies are moving or do  we have a lot more work to do?  And if so, what's that work, John?  I think we have a lot more work to do.  I think that I agree that there is much more widespread awareness.  You can tell we're not in Brussels in January because I have just done it in my face.  But yet you there's much more widespread awareness of free software and what it is and much greater  willingness to use it and engage with it.  I think that I do see the problem from a end user perspective is that there are so many  other forces now pushing towards locking down devices for different reasons and also just  so many more kinds of devices.  Now I'm not just can you rebuild the software on your laptop or your desktop or even your  router, but your phone.  If you have an iPhone which has free software on it, you can't really install your own.  You can technically apply and be a developer and install some of your own software.  But there's no way to have a marketplace for free software on that device because it's  prohibited.  And so there's a lot of other pressures working against user freedom.  And that's one big area where we have a lot of work to do.  We have a certification program respects your freedom where we're trying to promote businesses  that do embrace fully 100% the notion that all the software on a device should be free.  When it comes to compliance, it's, you know, I do worry a bit about the kind of it's good  enough or our approach is good enough.  We check enough of the boxes that we're going to reduce our risk.  And that's what we're aiming for.  I would like to definitely see more adoption of the actual values behind all this and just  more understanding that most of these compliance challenges arise because of the common because  of the attempt to combine proprietary software and free software.  So, you know, we want to encourage people to push the envelope in the other direction  as opposed to trying to see how much proprietary software you can get away with distributing  alongside the free software with the free software, you know, push it in the other direction  and see how much of your software you can distribute as free as a solution to the compliance  challenges makes them a lot easier.  And so the risk is saying this is all Pidge's job to solve.  Like I do want to ask Pidge, like, like, how, like, how do you do that process with like  a client when a client comes to you and they're having embedded firmware and it's a mess  and you're trying to tell them switch the octa do this.  Are you able to get through to them to the other side where there is a big advantage and  change them into that mature company that we've been talking about, get them to care about  the end user installing it?  Or are you or do they just come to you and say fix my problem so I don't have to think  about it again and I don't want are they telling you help us lock down your device?  Are you having to push back with your clients about that?  Yes and no.  I think that what a lot of the people that I have talked to, they understand that either  this is the right thing to do and not necessarily for moral or ethical reasons, but for entirely  selfish reasons.  You see this kind of in like some of the EU things with GAIA acts where they want privacy  and open firmware all the way down to the chip level because they don't necessarily  trust close binaries, close bobs on the chip.  You don't trust that.  So I think that from a lot of folks, it's coming from either a I never want to get that  email from Bradley or I never want to do this where I get kind of called out for using  open source software in my products and not doing it.  So like most of the folks that are there aren't fighting this, like the ones that I'm dealing  with, but no, I'll ask you that.  Those are the folks who are coming to me already.  So it's the ones that are coming to folks that are the ones that we worry about, right?  They're the ones who either don't think that they have a problem or don't know that they  have a problem.  So the ones that I talked to are already on board.  So that brings me over to Davide and probably asked the hardest question that just has to  be asked because Huawei is not a company that's known for its transparency.  It's had some trouble with that.  It's been accused of spying.  It's been accused of doing things in the firmware that we in the free software world have always  argued.  Well, if your software is free software, we can check and verify.  Do you think that's going to be an argument going forward inside your company to say if  you do this and allow the users to rebuild and reinstall the firmwares on Huawei devices,  I would argue that it gives you a great answer to the problems the Huawei has faced.  But I'd like to give you the opportunity to kind of address that and how do you connect  up the transparency and other issues that Huawei has struggled with with the transparency  and user freedom that is inherent in FOS as you become a mature FOS adopting organization.  Yeah, I think the answer is all in.  So it's Huawei in first person, right?  Huawei can be considered a person, a juridical person, right, has been particularly hit by  services being pulled off or pulled away for the nature of known free services, right?  So if a player in the industry feels that by using known free software, then your business  is going to be impacted, then, I mean, no, let's use free software.  Let's use open source software.  Not only that, if by using and by doing free software and participating in a community  as an active open source citizen, now all of the bad marketing that I'm getting, right,  it's going to go away because I contribute first, I participate second.  Now all of a sudden I'm using technology that everybody uses and contributing technology  to the world.  I'm not vendor locked in anymore.  My brand in terms of transparency, protection of IP, et cetera, et cetera, you know, just  gains value, I mean, all in, right?  So in essence, that's the reason why my group was created.  In essence, that's why after years and years and years of career in open source, you know,  many companies in the US and Europe, Huawei came to me and said, listen, we're all in  in here.  Can we build the open source technology center in Europe and be all in when it comes to open  source because it's good for us, it's strategic, it's good for the world, so let's go for  it, right?  I'm saying selfishly, selfishly, open source is really good, it's the strategy, it's the  real strategy.  Okay, well, we're coming towards the end of the session and so to make sure that everybody  gets a chance to say what they want to say, I want to go through and give everybody a  minute or so to say whatever, something I didn't ask as moderator that you really want  to make sure we covered or that you wanted to bring up.  And I've been keeping track of people who have seen me looking over to their side about  time.  Miriam's had the least amount of time to speak, so I'm going to start with Miriam.  Is there anything you wanted to say about FOSS compliance that we didn't get to?  Yeah, one point I had been meaning to make before when you were asking John and Pidge,  actually.  I think one thing, one development that I really like is that companies are looking a lot more  into contributing back and getting engaged into open source software projects, not only  using but also looking at the other side.  I think for many companies, that's still a bit harder to look into that and to figure  out where do I get engaged, what makes sense, where do I put my teams, what do I look at,  but it's happening a lot more and at least we do get a lot more questions around that  and I think that's a good development in this space.  Thank you.  So John, do you have anything that we didn't cover that you wanted to make sure was brought  up?  Yeah, I think that we're talking about compliance in particular with Copy Left and I know that  a lot of people are talking about sustainability right now when it comes to the free software  that they depend on, learning that the projects they depend on are maybe only maintained,  actively by a couple of people and are in a precarious situation.  And I just want to emphasize how important we think Copy Left is to sustainability.  Copy Left is the thing that ensures that free software will be getting more free software  as opposed to more of a mis-sic licenses that put software out there that can then just  be used to get proprietary software to market quicker and that really undermines the sustainability  of the whole system that businesses are being built on.  So that was one thing I wanted to make sure was out there and I just wanted to offer our  help at the FSF and we do our best to maintain good kind of best practice documentation which  helps establish community norms and make all this a lot clearer for people and we do a  lot of kind of unsung work for improving licensing hygiene and the projects that we noticed.  We even did a little bit with Big Blue Button actually that helped them clean up a few things  with their licenses.  So, you know, we're here to help.  You can always contact us at licensing.fsafe.org.  And I just want to encourage everybody to go as far as you can to push the envelope  as far as you can.  You know, don't lock down the device even if you think you might be able to get away  with it.  Embrace the idea that people can do and do creative things with your products that will  then probably benefit you in the long run as well as well as just being a socially responsible  thing to do.  And I can't help but jump in to say that free software builds for devices make the devices  life last longer and it's fewer devices ending up in landfills which is another type of sustainability  problem.  And I want to go to Pidge and ask if there's anything you wanted to add to it.  I didn't ask or something about cost compliance.  You wanted to tell everybody?  No, but I do want to second that in that if you are using open source and building a  business on open source, it needs absolutely no sense from a business perspective to starve  open source.  So, if you are using a lot of open source and not contributing back either financially  or patch is welcome, start doing that now because it is a business sense thing.  It just makes business sense.  On top of that, if I'm relying on things from a security perspective that there's three  people who work on the project and only one of them is getting paid to work on the project,  that's an issue and as open source, we need to get the larger utilizers of open source  to start contributing back more and more.  Davide, anything you wanted to make sure we covered that I didn't ask about?  No, I think you asked all the hard questions.  You gave me a chance to reply.  So, it's great thing.  So I'm just going to compliment what was just said.  I mean, when it comes to contributing open source software, it's so business and ecosystems  are created for, ecosystem is created for business reasons.  I mean, companies get together because there's a business sense.  But because there's a business sense, mature organization measure the number or the efficiency  of a project in terms of decreasing contributions or increasing contribution.  Meaning, if I'm the first to start a project and I get a second partner, third partner,  fourth partner, fifth partner, I'm contributing 70%, 80%.  Over time, I want to see that going down.  I want to see that evenly distributed.  Because if it's not evenly distributed, A, I'm the bully of the ecosystem.  It's not open.  I'm dominant.  It's not good for marketing.  And it's not efficient for me.  So back to mature organization, it's about contribution.  It's about being all in and it's about sharing this burden together of contributing together  and building something together.  So that's how businesses think if they're mature enough.  Thank you all so much for being here.  I'm going to go round and round about with everybody one last time and just give you  a chance to say any URL or project that you want to promote to have people to look for  further information.  I'll start with Miriam.  Anything you want to promote or ask people to take a look at?  We actually had to have at least one time someone saying you are mute now.  Sorry about that.  Sorry.  Now I have to think there is actually a GDPR project that is open source.  I think it's the French authority that's putting out a lot of open source software  around GDPR compliance.  So maybe plug them because I think it's a good idea to do that.  John, is there anything you want to give a URL or something to promote for folks to  take a look at?  Oh, he's on mute now too.  Second time.  Yeah.  I think maybe we will actually have an announcement shortly about a continuing legal education  series online to go with our conference, neighbor planet and marsh.  And that's one place for every try to help lawyers, especially from corporations, advanced  business owners in this area and also get this kind of time talking with each other.  If we're going to do an online version of that, shortly just watch FSF.org for more  information.  Did anything you want to promote as we wrap up?  The Octa project as always because I have to.  But also I'm working on a new project called Network Great Linux.  It's going to be announced in a few weeks.  But look for that coming out soon.  And Davide, you get the last word, anything you want to promote that you're working on  that you want folks to take a look at?  Yachto project, Zeffra project, Linux foundation, the Cliff Foundation, Free Software Foundation,  open harmony.  You guys have funded FOSDEM and that's it.  You guys keep up the good work.  This is going somewhere.  I want to thank all our panelists for doing this difficult, difficult remote panel and  we're so glad that you joined us and we hope that next year in Brussels we'll all be together  and be able to go out to dinner after our panel then.  Thank you all for being here.  Thanks, Brad.  Thank you.  Thank you, Bradley.  Goodbye guys.  It was a pleasure.  Bye.
compliancepanel_0_179.png compliancepanel_180_2375.png compliancepanel_2376_9515.png compliancepanel_9516_11291.png compliancepanel_11292_11603.png compliancepanel_11604_12179.png compliancepanel_12180_12335.png compliancepanel_12336_12683.png compliancepanel_12684_19631.png compliancepanel_19632_19739.png compliancepanel_19740_20015.png compliancepanel_20016_20543.png compliancepanel_20544_20687.png compliancepanel_20688_20783.png compliancepanel_20784_24035.png compliancepanel_24036_24923.png compliancepanel_24924_26855.png compliancepanel_26856_26939.png compliancepanel_26940_27119.png compliancepanel_27120_27383.png compliancepanel_27384_27467.png compliancepanel_27468_28511.png compliancepanel_28512_28631.png compliancepanel_28632_35531.png compliancepanel_35532_36047.png compliancepanel_36048_40871.png compliancepanel_40872_41555.png compliancepanel_41556_41603.png compliancepanel_41604_41723.png compliancepanel_41724_42035.png compliancepanel_42036_42251.png compliancepanel_42252_42887.png compliancepanel_42888_44267.png compliancepanel_44268_45383.png compliancepanel_45384_47411.png compliancepanel_47412_49655.png compliancepanel_49656_50951.png compliancepanel_50952_52067.png compliancepanel_52068_55643.png compliancepanel_55644_56867.png compliancepanel_56868_59123.png compliancepanel_59124_60719.png compliancepanel_60720_67883.png compliancepanel_67884_69335.png compliancepanel_69336_72215.png compliancepanel_72216_72263.png compliancepanel_72264_75647.png compliancepanel_75648_77531.png compliancepanel_77532_77687.png compliancepanel_77688_78551.png compliancepanel_78552_78611.png compliancepanel_78612_78899.png compliancepanel_78900_79016.png