 All right, we're just about to get started with our next debate. So the next debate that we're going to have is on the topic of does careful inventory of licensing bill materials have a real impact on fast license compliance? And representing the affirmative, we have Jeff McAfher and Carol Smith. And on the negative, we have Bradley Kuhn and Max Sills. So with that, I will let you take it away, Jeff. That's me. Am I on? You are. I'm on. Okay. So welcome everybody. When I found out we were doing a debate... Richard, do you want to make a comment? Yeah, so I think they've reformulated or formulated the policy statement. So the policy statement is for the affirmative position is, a rigorous modern, fast compliance process must prioritize including an accurate inventory of fast materials. So we're good to go? Yeah. So I found out that we were going to do a debate. I got really excited because it was actually a high school goal of mine to be on the debate team, but we didn't have a debate team at my high school. So Carol and I really got into this and we're all set to go. So we're good. It also turns out that I cannot see with those glasses at all. So when I was on the plane over here at Turnout Bradley was sitting across from me on the plane here and I asked him, do we want to do this as entertainment and education or do we want to win? Bradley said, win. I want to win. And then when we started here, he came over and shook our hands. That was very gracious and he said, I look forward to doing battle. So that's just setting the context here. Anyway, so yes, the affirmative position, a rigorous and modern compliance process must prioritize an accurate inventory. It's very simple. The scale at which we're doing open source and software today, just far outstrips anybody's ability to manually take care of or understand the set of components they're using in their systems. Open source is showing up in all sorts of non-traditional software environments, people who are accustomed to managing open source, managing components. They may have very rigorous supply chain muscle within their company, but it's typically maybe hardware. If you're a car manufacturer, you've got amazing software, sorry, amazing supply chain capabilities, but really don't understand what's going on with software. So the only thing you can really do to help them is automate and have rigorous control over the inventory and put in place a comprehensive supply chain system. Fundamentally, you cannot comply with obligations you don't know you have. And if you don't know what software you're using and what licenses they have, you cannot possibly comply, so you must have a comprehensive system. It turns out that within modern software systems, something like 90% of them, guess it depends on who you talk to, have open source in them. And on average, when you look at GitHub, open source projects on GitHub, they have 180 dependencies on average. So think about what that means. Any given random piece of software on GitHub depends on 180 other things. So try to imagine you're building a comprehensive product or offering whether you're a government or a company, it doesn't matter. And you're trying to keep track of the open source that you're using. At minimum, you've got hundreds of open source dependencies and you need to understand what they are and what their licenses are. Flipping it around the other way, if you take the top 50 open source projects, there are over 3.6 million other projects that depend on them. So the scale here is just crazy. So because of the scale, without a rigorous inventory of your open source, you can't possibly manage it all. Now it also turns out that inventory itself is not enough. Because things like knowing where the source is, so how many people here use package managers? So there's a lot of hands going up for package managers. Did you know that on average, we looked at the data from Clearly Defined, which is a system we put in place to track open source compliance information. If you go and look at it, we did a fairly random sample of 200,000-ish current open source packages. 42% of them do not have any easily discernible connection to their actual source. So you've got foo version 1, and 42% of the time, you will not be able to find the commit in a repository that corresponds to that version of the package. So if you had a copy-left requirement to disclose source or whatever, you would not be able to do that in 42% of cases. If you wanted to understand in more detail the licenses involved or the source code involved in the package you're using, 42% of the time, you will not be able to understand that. So that leads us then to the data side of this. So we've got inventory, but you also need the data. Because you need to understand, you know that you're using foo, but you don't know what it is. You don't know what the license is, who the copyright holders are, what obligations you have. So in the ideal case, the components, the projects themselves would be producing all of this and making it easy for people to understand, but that's simply not happening. And I think as part of the comprehensive inventory and automation of compliance, we would be encouraging and facilitating upstream projects to be more explicit about their licenses, their source code connections, their copyright holders, things like reused software, right? Awesome project to help encourage projects to be better formed with respect to their compliance data. How much time do I have left? Okay, two minutes. So this is not a problem we're going to solve quickly. We got into this over a period of time, and it's a massive scale problem, so we need to do it iteratively. The first step is knowing what you're using, and that is the inventory side of things. Actually, I think that's all I have to say. So do you cross-examine it? Come on, who's going to cross-examine that one? You look so handsome. Thank you. Can you step a little bit further into the frame there? Sure. So take a poor, under-love developer from France, Germany, Belgium. They're not paid. They are working on free and open source software because they love it. How much time and energy should they spend making sure that they can provide a good bill of materials for a corporation that won't pay them? Well, it's an interesting question because I think they should spend as little time as possible, and that's actually part of the idea of automation, is that we would have in place guardrails so they would not actually need to know much about this. It would all mostly happen for free. But I'll also put it to you a different way. If you're an open source developer, small, independent one, in the company, working for the government doesn't matter, if you're putting out open source and you're distributing a docker container, for example, do you feel you need to be compliant with the licenses in the thing you're distributing? Show of hands. So you need to be compliant. That small, independent developer needs to be compliant. They should be spending as little time as possible, and the way we facilitate that is through automation and rigorous systems that understand the inventory and obligations. You talk about a software bill of materials. How does that different from the requirements of a given license? Well, I didn't mention the word software bill of materials on purpose, but because that has... Does anybody know what that means, or how many definitions do you have? I've got seven, so... So what are you proposing that's different from license compliance? The idea here is that you know what you're using, so you have an inventory of what you're using, and you understand the characteristics of the things you're using, whether that be the license requirements, the obligations in those licenses, the vulnerabilities or whatever. If you want to put that all together and wrap that up and call it a software bill of materials, that's cool, and I would go along with that. And that then would include a list of the obligations that you have. Does that answer your question? Yeah, it's great. So Jeff pointed out that I want to win this game, and it's always a shout from the audience you can't win this game, so I'm not sure how to take that. I'm actually... I dropped out of high school debate after the first debate because I couldn't stand taking a position that I didn't agree with. I agree with my position. In fact, in most cases I agree with the policy statement, which by the way does include a bill of materials, is part of what our opposition is arguing for, and I think a bill of materials is a useful thing. I think it has value. The question is a question of prioritization. What is the most important thing we need to do to yield this bill of materials and otherwise generally create good and coherent understanding of what software is in people's distributions and supply chains? As it turns out, there is a better approach than first trying to construct a bill of materials and prioritizing that. If you first construct the required source code that you must disclose anyway under many FOS licenses and you are sure that that source code is the correct source code for the binaries and other items that you are distributing, the construction of a bill of materials becomes quite trivial. In fact, if you care about free software you're just going to give all that source code to everyone everywhere and not prioritize it. A bill of materials is only of interest in its isolation to those whose goal is to make proprietary software. As a free software activist, which many of you in the room are, I think you would prefer to focus on something that pushes toward software freedom rather than aids and abeds the proprietorization of free software. That source code that you might construct will contain all the licensing info. It will contain all the licenses that you need. It will contain all the information you need to figure out how to comply with those licenses and disclose those licenses downstream. It contains everything that would go in a bill of materials anyway. Just give them the source code. Ultimately, this is a resource question. Our opposition has already conceded that this is a huge problem. That there are hundreds and hundreds of dependency. They've even said, however, that they can construct an automation process and do this for free. Many of the problems of doing this via software are various different complex graph algorithms and so forth. Many of them are proven to be NP-complete. Many of them are proven to be undecidable in computer science. These are not problems that we as technical folks know how to solve, because computer science says it's extremely difficult to solve them. So the proposal that we can solve these problems by automation and therefore put no unfunded mandate on upstream is completely incorrect. Ultimately, construction of a bill of materials is an unfunded mandate to upstream. Prioritizing it is taking the work of companies who want to make proprietary software out of free software and requiring upstream projects to do that work. Ultimately, if we simply require the source code to be right and complete, we have de facto bill of materials for everyone who gets copies of that software, and we've solved the problem. We don't need to prioritize isolated bill of materials construction. And I yield the balance of my time. I got a question. Oh, first. All right. I'm on. Good. Well, thank you, Bradley. That was illuminating. So it was interesting that I would like to hear your response to when I asked how many people here use package managers, and I would say the majority of the people put up their hands. What's your feeling about that? Was that a good thing? Is it a good thing to use package managers as a question? I think it depends on the technology you're using. I don't think that question could ever be answered in the abstract. Okay. So we also observed during my presentation that 42% of packages in the package management ecosystems do not identify readily their corresponding source code. This is a challenge to how would you view this as corresponding to your desire to disclose source code as being the solution to compliance? Well, again, I would say that you may be making the case there that the prioritization of improving package managers for source code disclosure might be a good idea, but that's still not prioritizing bill of materials. In terms of bill of materials, perhaps not, but in terms of enabling automation and rigorous inventory, it would be, would it not? Well, many of the package managers already do have source code. For example, if you take Debian's package manager, for example, take Fedora's package manager, for example, the two largest and most used distributions, all of them have a clear way to rebuild from source code into a package. Right. And do so for all their dependencies. Yes. Unfortunately, not all ecosystems are as well-formed as their amazing partners we have in Debian and so forth. How would you deal with them? Well, I think it would be wonderful if you wanted to fund work on package management as a corporation for those ecosystems. But again, that is still not prioritizing bill of materials. It's prioritizing package management, which has all the things you want to simply fall out. So then in our final minute, can you define bill of materials? I am on the negative side. I am arguing for something different. But you're arguing, we should not have bill of materials. You must have a definition of bill of materials. I am arguing that everything that I've ever heard proposed in your affirmative statement or any other statements about bill of materials is available as part of the complete source code that is correct for a given piece of software. Unfortunately, except the correspondence between what I'm actually using and what the source code is, which is the critical link that's missing. Well, I would answer that with if you don't have the complete source code of what you're running, you have bigger problems than not having a bill of materials. You can't even build your product. But I would argue that's a subjective process point, not a qualitative compliance point. If you can tell me how to rebuild a binary without source code, I would think that would be an amazing thing to learn. But not everybody needs to be able to rebuild their packages from source code. That's not a question. That's true. So I wanted to build in the affirmative on a lot of what Jeff was saying, and I wanted to particularly emphasize the importance of thinking about the reality of how modern software development is done today. I think Bradley is arguing for a position that absolutely in a utopia and the ideal case would work for everyone all of the time and that we would all be living happily together all using free software. But the reality of modern software development is that as pretty much everyone in this room is using a package manager, many package managers don't include the link to their source. And indeed, I could as a software developer at my small nonprofits that is under resourced, that's trying to get its website constructed, choose to only use those packages and to be quite precise every time I NPM install anything, checking each individual package to make sure there's a clear link to its source. I could, but that's not the reality of how we do modern software development. The reality is, and again I want to echo Jeff's point about scale, the reality is that there are people working every day in small organizations, large organizations, individuals who are installing packages and taking on hundreds, if not thousands of dependencies each time on behalf of their company or on behalf of themselves. And they are taking on all the compliance obligations of every single piece of software that they are taking a dependency on. And the reality is they're not checking to see if each of those has a source location. Can they build from source every single time? And unfortunately, this is the world that we live in. And indeed, the world that Bradley is talking about would be an ideal world to live in, but we live in a world in which we need to create practical, pragmatic responses and solutions to enabling software development at scale and at the speed and efficiency that we need. Now the important point here is that we still need, it still needs to be accurate and precise much as the license requires because compliance is the most important point here. We would need to be in compliance with everything that we are using. But again, the reality of the way development works is that often people are moving faster and not doing the due diligence that they need to do. And so what we need to do is we need to put systems in place through automation that will first get an accurate inventory of the things people are taking dependencies on and second, provide the information about those pieces of software they are using so that they can meet their compliance obligations. And in fact, this is a problem that is well suited for software development because we want to move efficiently, effectively, pragmatically, practically. And we can introduce, as software developers, systems that provide these guardrails that Jeff was talking about around the software development process, these can be quite lightweight systems and they can accommodate one-person software development shops. But it is still the case that even if you are an unresourced one-person software development shop working at a non-profit, making 100 euros a year that you still have compliance obligations yourself in the software that you are using. And yes, that person who's making 100 euros a year at that non-profit might really want to live in Bradley's world where she compiles everything from source every single time, but maybe she doesn't. And I think we need to introduce systems and understand that there can be processes that can accommodate those people as well. And in fact, if we build these systems in this way, that we might actually be encouraging people who are sort of burying their head in the sand, if you will, around their compliance obligations to actually move into a world in which they are able to comply with the software they're using there. They're actually, instead of just ignoring the problem because they make 100 euros a year at their small software development non-profits, that they actually have a system in place that provides them a lightweight set of guardrails around providing the list of packages that they are using, the license that is associated with those components, who its copyright holders are, if that is applicable, and a link to the source location then pass that along to their consumers or potentially work with the upstream project depending on what the situation may be. And again, I want to emphasize that it's the reality of the world that we're living and that is most important here. I can see that Bradley lives in a utopia and that, in fact, if this were all readily available and every time that I ever consumed a software package of any kind, I already had its link to the source and it was clearly licensed and I clearly understood all the obligations that came along with that license for each set of thousand dependencies that I took a dependency on, I would like to live in that world, too. But instead, what I would like to emphasize is that we all need to still meet our compliance obligations and our compliance burden and what's most important there is an accurate inventory of the software that you are using and depending on and the data around each piece of software, it's licensed, it's source location and it's copyright holders and that is how I would define and build materials, by the way. I yield the balance of my time. So, Carol, thank you for telling me that I live in a utopia. My first question is, given that I live in a utopia, can you explain to me why most of the software in my utopia is proprietary if it's my utopia? Because in your utopia you live in a world in which people use different visions, they run different kinds of businesses and they have different goals for the kinds of software that they develop and the kinds of software they want to use and sometimes they want to make a choice to use that kind of software. That's not always the case, so often they will use FOS software but it can occasionally be the case that they have made a choice. Maybe that you wouldn't make, I concede that, but maybe they have for themselves made a choice to use that proprietary software in your utopia. So, you mentioned that licenses involved require accurate and precise bill of materials. Can you give me an example of a clause of a FOS license that requires bill of materials? I cannot, but I argue with the premise. So, it is not, in fact, the case that any of the licenses require a bill of materials. However, the licenses in and of themselves do have other obligations without having gotten a list of the things you are using in the first place. You cannot comply with those obligations by definition. Can you tell me what percentage from your point of view of resources should be spent on building bill of materials instead of checking to make sure you can reproduce items from source code? How do you divide up the percentage of resources that ought to be spent? I think that would be a larger discussion that we as a community should have around how proportional it should be to the amount of people that we think are in non-compliance or bearing their heads in the sand because they don't realize that they're using a particular component that's licensed in a particular way. We have to address those in proportion to the number of cases that we see in the field, if you will. How do you respond to folks who say that if you focus on reproducible builds, which you've conceded will also yield the correct bill of materials if it's used individually, it also solves all sorts of problems like security and so forth. How do you argue if you're saying you should keep the narrow focus of prioritizing build materials over this other solution that would actually not only help with the build materials issues, but a whole swath of other issues that we have in software? Again, I think the two have to coexist because it is the case. I absolutely agree with you that, for example, Debian has essentially people make different choices and different decisions. Some people are living in software development ecosystems that are not as well constructed as Debian, and I think we need to accommodate them, we need to bring them in. We need to have conversations with them because they have the same compliance obligations that we do. My friends, who profits who profits from a software build materials? That's all I want you to ask yourselves. Jeff used words. He used scary words that made me feel sad. Jeff wants to enable automation. The other side wants a rigorous inventory. We must mitigate risk. So I want you to check in on yourselves. Just take a moment and think. Feel into this. Do we generate a bill of materials out of fear? Out of fear for getting sued? Out of fear that we're not satisfying our corporate overlords? Or do we generate the source that is required because we love developing software? It really boils down to a choice between fear or love. Now there are other problems with their other side as well. The behaviors we do today become the precedent for tomorrow. So think about this. When you wake up every morning do you want to develop free software? Or do you want to spend an endless amount of time creating SPDX identifiers? Do people enjoy this? Is this fear or love? The whole point of open source fundamentally is about low friction. It's about making cool stuff that is fun as quickly and cheaply as possible. And the people who support bill of materials I think they found that there was not there were markets for fear. There are vulnerabilities in your code that need to be scanned. We need to go back thousands and thousands and thousands layers up in your dependency chain to identify all the potential problems you might have. Does this lead to better software? Who thinks that would lead to better software? We argue that you should have a bill of materials. But we argue slightly differently. You should convey the source. If people ask for credit you should give it. When you compare between fear or love love is giving developers credit. Love is funding developers. Love is making sure that the actual software development ecosystem is supported. Fear is creating an industrial complex without benefitting anyone. I'll yield the rest of my time. We have to cross examine you. But Max the most important question do you choose love over fear even when it's hard? Particularly when it's hard when you're doing software development with tens of thousands of engineers or tiny financial resources. Can you really choose love even in the most difficult dark times and even under the constraints of finances resources? How does one really choose love? We need to define what a villa material is. I think you should do your best to understand where your software is coming from. I don't think that means you need to contract with a vendor to integrate with clearly defined. I don't think that means you need to hire a bunch of lawyers who can hire more lawyers who can hire another vendor to do an spdx or phosology audit on your system and tell you there's problems. I have another question. Why as a lawyer do you choose love? I'm glad you asked. I'm glad you asked. A good lawyer chooses love. What we want to try to do is actually make a better world and the lawyers that are in the room today care about the free software movement. I think that you have to do what you can to make sure that licenses are respected. You have to do what you can to make sure that you are complying with your software. That does not mean creating additional obligations that no one asked you to do. I actually have a real question. I feel like many lawyers have advised many small and large organizations that the bill of materials at an accurate inventory understanding your compliance obligations is actually the solution here. Do you disagree with the client in that way? That is exactly what our position is. We should be conveying source. We should be conveying license text. We should do our utmost but we should not be putting an unfair obligation on unfunded developers to do unnecessary tasks. But aren't we really, isn't the reality of the fact that we're living in a world that we should be doing that and that people aren't and that we still have to continue to develop software living within that world? Yes, I agree with that. I yield it out. My debating partner whom I love, not hate has brought up this idea of risk and risk is the central question. The compliance industrial complex wants those who adopt free software to believe that it is inherently risky to do so. There's only really one risk. We heard about this in the previous debate. My esteemed colleague, Pam, pointed out that most of the compliance problems, in fact all of the real compliance problems are in non-copy left licenses. I'm sorry, in copy left licenses that non-copy left licenses really don't have serious compliance problems. What is the difference? Copy left licenses require disclosure that the source code in non-copy left licenses do not. When you infringe a non-copy left license the remedy is simple. You are contacted by a developer whose copyright notice wasn't in the right place or whose credit wasn't given properly and you give it. There is no real risk for a company. The risk is not providing the source code. I have done enforcement actions many times in my life as most of you know and occasionally they will give me a bill of disclosure to a request for source code. As if the bill of materials is the source code for the project. It is, of course, not. However, if I had the source code it would include the bill of materials automatically. I believe firmly that a bill of materials is useful and I believe that bill of materials exists in the source code disclosure. I yield the balance of my time. Well, you might notice that I started out as a aggressive debater all dressed up under the covers. It was actually a mild-mannered open source developer just kind of hanging out. At this point, things are not always as they seem. Bradley asked a question earlier on. I think it was something in effect of naming a license that requires a bill of materials, something paraphrasing that. I would actually ask, is there a license out there that requires me to build from source? The answer, as far as I know, is no. The premise is that you all should be building from source. But everybody who put up their hand when you said you're using a package manager are not building from source. So it's not a requirement. It's an undue burden to put on you to build from source every of the thousands of things you use so that you can meet the compliance obligations that Bradley's putting forward. Now, I would also say in rebuttal our esteemed opponents here have repeatedly said or implied that somehow we are proposing undue burdens on upstream folks. In fact, it's actually the opposite. We are hoping, we are trying to put in place automation and facilities which actually relieves them from maintaining all of this compliance information for the things they use. Because we recognized earlier that as an open source developer putting out software, you are in fact required to comply to the licenses of the things you use. So you have this burden of compliance already and we're proposing automation and facilities to make that actually easier for you so that when you go to deliver your software you are compliant for free or automatically. There is a mild burden we'll say which you have already when you put forward a license if you put forward a license that says something to the effect of you must include a copy of this license with your software distribution. There are packages and package manager ecosystems out there where the producers, the publishers of packages are not encouraged or facilitated to include the license in their package. They're actually not making it easy for their consumers to comply with their own license. Similarly, if you're supposed to attribute copyright holders, if you don't put the copyright holders somewhere in your text, we're not going to be able to attribute them. So the requirement here, the desire to do it in a mildly structured way not as PDX necessarily that has never been the proposal here is that people put it in some place that's understandable. That's it. If people can understand and get clarity that is be clearly defined had to work it in somewhere. To have their compliance information clearly defined within their code then it's easy to comply. It's trivial. That's it. We're doing question. First, I just wanted to say thank you. This was a very exciting debate. So much emotion and and vigor that can hardly contain myself. I wanted to let you know that Bradley's Utopia is actually close at hand. I have to share with you the fact that using NuGeeks as a package manager with one command I can obtain exactly the source code for it exactly the software that is installed in my system the transitive closure of that source code in tarball format and then I can rebuild it and there is a bill of materials. But my question is about the bill of materials whatever form it may take I'm curious to know do you believe that it's possible to actually understand all of the obligations and comply with them because it seems that there are so many different licenses if you actually knew how they're all interlocking there might be contradictions. We do not take the position that a bill of materials will make the legal judgment for you of how your obligations interact simply that they may exist and that in fact in the world we're now living in you could in fact first of all be using a piece of software you don't even know what you're using in the first place but more to your point that you could be using a piece of software and not know how it is licensed or that it is licensed. The legal obligation interaction is entirely the work of a lawyer to do once you have that information. I would also ask that disclosing the source does not absolve you from the need to understand your obligations either so simply disclosing the source doesn't tell you that the licenses you're using are compatible right so that's not the answer you still need to interpret the licenses and understand the obligations. Yeah we can see it in both their proposal and our counter proposal that you need legal judgment I think we would agree to that it's just much easier if you have the source code not just a mere build materials. I see thank you. So since Max opened the door to bringing crazy things into this discussion. Yes for those who propose that all people who are distributing software build everything from source all the time have you considered the climate change impact of that sort of policy. I don't propose that as we've heard from the GnuGeeks project it's not that you must rebuild from source yourself the fact that it has been done and can be verified when needed is the important issue. I don't think everyone should always rebuild from source from the very beginning and we didn't argue that in our position statements. We argued that it should be possible and the source code should be correct. Now at some place in the supply train that has to be verified and there is a matter of trust at some point where you have to trust that someone in the supply chain did verify that it's built from source. But that's an unrelated issue to the question of whether we should prioritize building the build materials separate from that source disclosure. So actually I largely agree in the sense that if we were able to go from binary package to exact source code in a very rigorous way I think then all we really need is that inventory and I'm not saying build materials I'm saying the inventory of the component you're using so you know which source you should be disclosing or which licenses you should be complying with. You did allude to it here at the beginning but I'll just sort of clarify the point which is without a, and this is for the anti-build materials people, without a build materials how is someone supposed to make the analysis on whether or not there are licensing compatibilities so you're telling me that I have to go through hundreds of thousands of pages of source code to figure out exactly what's in there whether or not all of the license obligations are being met and why doesn't at least make that the more feasible way to do it. So to be clear we were not taking an anti-build materials position because Carol spent an entire week reading debate theory I had to take a crash course yesterday the debate strategy that you would use was counter proposal we countered with getting all the source code generates an adequate set of materials and information that would mitigate any risk that could possibly come up so from my point of view if you have the full source code that builds everything you won't have maybe in the perfect format like line by line the bill of materials but you're going to have everything there that built it and you can easily study what's in front of you and figure out. Not the people who have to, not the lawyers, not the lawyers that you all concede are needed who have to make the license compatibility judgment call I don't have the ability to go through source code and say oh look you know here is each package and what the license assigned to it is. I think you're absolutely right. I think we need a list of licenses we also need, but that's not but the question is what is a bill of materials what exactly is it because all I've heard is that it's a marketing term that gets sold to people who are afraid and don't understand open source the companies that come talk to us to try to talk about bill of materials talk about all the vulnerabilities that are in our software that need to be found and if we don't find them everything is going to be destroyed bill of materials is a term used for fear mongering and I think fundamentally what we're against is fear mongering but we absolutely support understanding what your obligations are and having them in a convenient format so that you can comply. I would add to that that we think that it's going about the hard way to try to construct the bill of materials without having the complete source code. Once you have the complete source code we can much more easily automate the process. The process is hard to automate without having the source code first. I just wanted to very quickly clarify that we are not pro-fear mongering. So and just quickly Max brought up fear and love. There's another element to this is ignorance and living in ignorance is not an excuse, not a way to go about it. So knowing what you have and understanding it is great. Having the source code and to understand licenses I mean Philippe has his hand up back there he's done an amazing amount of work on license understanding and going through like just parsing and understanding oh that license text matches this actual license. There are thousands of licenses and the matching algorithms as much work as folks here have done are really horrendously hard to get right. So actually understanding the licenses in an automated way let alone a human readable way going over thousands of components and megabytes and gigabytes of source code is just not feasible in today's world. So as a non-legal person I think you are all wrong because I think that one of the problem that we didn't mention in the debate between source code and bill of material is tools around that. So you don't mention the fact that if you don't give the receipt to the people to build the software from the source you miss the point. If you don't give the version of the compiler's version of the value tools which are around you miss the point and by the way the GPL also requires that you provide information on how to make the software. So I think that's an important part which is a mistake for me. And I was although I suppose I aired in my debate construction that I didn't say that I was relying on the GPL definition of complete corresponding source code. When I talk about source code I mean what the GPL requires which does include all the things you talked about as part of the scripts used to control compilation installation executable. What side are you asking for Jim? I'm filled with fear and love. Fear and love. Both of them at the same time. So you know Machiavelli said that it is best to be feared and loved but if you cannot be loved you might as well be feared. So I guess sort of question for the audience because I've heard a lot of moaning about this in my own practice. How many in the audience for my own perspective and that of our panelists here actually mandate the builds of open source components that are consumed from source inside your organization by show of hands. I'm calling that halfish, two-thirdsish and I guess the question back to the panelists then is going back to Jeff's point that a huge number of developers are consuming jars of maven for which they cannot easily identify the source what's the positive solution. Centralized CICD that contains the compilers and the source to the compilers that we can all share and cryptographically digested links to confirm that those sources are the same that we can all share how do we solve this problem? I would absolutely love if we had reproducible builds across all the ecosystems that we're doing. I think it would solve so many problems if only we could get it right like the Debian and other folks have done. But the reality is we're not living in that world. I will briefly put my work at the Solver Freedom Conservancy on and say reproducible builds is a member project of conservancy. They do not merely want to work on Debian although that was their first focus they want to make all things reproducible and I would love if even just a fraction of the billions of dollars of resources that would be putting into build materials was donated to the reproducible builds project and that would be a huge difference. I would just add on to that that I agree and I think we have to do both because we need to have existing compliance processes that help with compliance obligations today and then we need to also be funding and resourcing the things that will move us towards Bradley's Utopia but they are not mutually exclusive. So my question is kind of for everyone on the panel here and it's one really about culture and there seems to be one thing we agree on that there should be some sort of inventory whether we pull it from source or whether we create a bill of materials and when I think of it culturally in terms of software development you have many more people other than the developers involved. You have product managers, project managers you have lawyers sometimes involved but you have all these other people making business decisions and others. How do we culturally indoctrinate them into the culture of open source so that if we take from the last debate where they said we may not need enforcement like legal enforcement because businesses will do it themselves if we had a bill of materials that was always provided and part of the ecosystem so the project managers and investors always saw it and it was always front and center not through source but front and center wouldn't they then help be part of that culture so that we don't have to go to court to enforce it because it would be top of mind and if that is the case then wouldn't we want to go towards bill of materials and work with our package managers to automatically create those but as part of open source culture I think that's a great question I do think that the true solution to compliance has to start with the culture of compliance but I think people should be taught to enjoy open source they should be taught to code and have fun and make projects some project managers lawyers, product managers people who are in that chain there can be a very unhealthy culture of companies for the notion that GPL is viral and it will infect the idea of infection coming everywhere and that's the kind of fear mongering that I was referring to earlier it really just boiled down to what you define as a bill of materials is it a thing that you use to avoid something or avoid a risk that you're afraid of that you don't understand that makes you very uncomfortable and panicked or is it a tool so that you better understand your software is it something that you do because you're afraid you're going to lose your job if you don't do or is it something you do because it's enjoyable it helps you build better software it helps you support people better so I think that's the cultural thing is people have to be taught that this is enjoyable and not just drudgery that makes no sense we agree I'd like to make two points not so much questions the first is that words matter and bill of material is clearly a world of the industrial world it's been borrowed from the industry and if you go from industry to military industry industrial complex it's very short distance and it's clearly a world so it's bill of material is about something that's been imposed to us by the industry that's one thing the second thing is ignore licenses for us again I think it's completely crazy not to build software from source it's similar to buying a phone that's been built from the sweat of child labor or eating GMO grown food or anything that's very responsible leaving aside anything about license that's it and I wanted to say make love not war I take a little bit I think you're shading on the question it might be a little too intentionally provocative and I'd like to just say I don't I take a little bridge with that but I agree that in fact it may be the case that folks all should be building from source and in fact they are making poor decisions for themselves if they're not but people make poor decisions for themselves every day often decisions that affect other people and we still need to build legal systems other systems in the world crosswalks that help put guardrails around people making bad decisions for themselves or for others I work on the fear side of the source so and I'm debating every day with my lawyers what they need they want bill of materials you can't imagine how much so but where's then how we can meet I would like to support open source developers yet on the other hand I must fulfill the requirements of a legal side so is it would it be a good idea out of all the bill of materials that we create somehow make that as a contributions to the projects without them being acceptable for corporate consumers which would help increase the usage and then make a business out of that how can we bridge those two sides because I think we need to I actually think the definition of bill of materials here is important because I don't think there's in I don't believe that there is any goodness to be had to upstream projects for them to receive a list of the inventory I'm using my production of my thing I don't think anyone needs my list of open source I'm using I think what they want is the source if I changed it and all the things that are associated with the obligations of the license so I would not argue for upstreaming a bill of materials maybe others would argue differently I have been very concerned about this issue of some time that this idea of a perfect machine readable licensing information which I think is a fiction anyway and that we've cut so many corners that the supposed computer readable licensing information and projects is really mostly inaccurate but even if it were accurate it becomes trying to push it back to upstream becomes an unfunded mandate to upstream from my point of view companies have generally forgotten that most of the reason that they want to use open source and free software is because it's saving them tremendous amounts of money from their own development time they're getting lots and lots of software they don't develop from scratch so if they have a little extra work they have to build the bill of materials that they need which they can do easily from source by the way from my point of view then they probably have to do that investment but it was probably a lot cheaper than it would have been to develop all that software from scratch themselves yeah sure I just wanted to point out once again I mean I largely agree but I do need to point out it's not just companies that are on the receiving end of this open source projects that distribute stuff also have to do all the compliance so those open source projects now have the burden of going and reading all the source and finding all the licenses and interpreting them all so that's there regardless it's not just the big companies that are it's everybody the NGOs, governments small projects etc so I think I think, oh Carol did you want to so I think that's all the time we had for questions so just to ask the audience how many of you felt that you learned something from this debate that's good we all win we all win I have to admit I actually thought this was really good the last debate was really good too but I was really impressed with this I think many of the participants here hold some of these views in a heartfelt way I'm not sure about Max can you ask if anyone's mind was changed? yeah, was anyone's mind changed? no was anyone's mind changed? no, okay well that's not necessarily bad we all win we all win we have a couple minutes to choose display