 Thank you very much. Thank you very much. I appreciate the introduction. And just for, you know, reference for those on the on the call. I've been working with Linux foundation since about 2008 as their outside council. So I've been involved in lots and lots of LF activity on the open source side. And now more recently on the standard side as LF is becoming extremely active in this important additional area of collaborative development. So what we'll be talking about today are the antitrust laws, or as they're referred to in Europe, competition laws, and, you know, by various other names around the world, and how those laws relate to standards development. Webinar that will be posted very soon that will cover the same ground with respect to open source development. So if you're curious, keep your eye out because you'll have an opportunity to see in what ways what I'm talking about today may come out a little bit differently in the open source context. So, what are we talking about when we talk about antitrust or competition laws and why do they even exist. Well, as the name suggests in in Europe competition. They're mostly about competition and making sure that it's fair, and that the activities of competitors don't harm the marketplace. And in the US in particular, most particularly consumers of products and services in the marketplace. So in the US, where we'd like to talk about the free enterprise system a lot. They're supposed to preserve competition and make sure that the marketplaces can work in a way that's fair. And in a way that doesn't lead to companies acquiring an undue amount of power, and using that power improperly. And in the US they're based upon the assumption that free competition is, you know, a an ideal form of conduct, obviously, in other parts of the world that aren't as oriented towards a capitalist way of thinking. They might have a different somewhat different emphasis than in the US, but in the US in particular, that's what they're aimed at they want to make sure that, or the belief is that if competition is fair, that resources will get allocated appropriately that lots of competition drives down prices that where there's lots of competition quality of goods and services tends to be better because with lots of competitors on a level playing field. They have to convince people why you should hire them or buy their products rather than somewhere else's. So basically, the more competitors you have and the more level playing field, the better off everyone is supposed to be. Obviously speaking, that's what the anti trust laws in the US are supposed to do is to try and achieve that endpoint, obviously, not always successfully. If you go to other countries. The overall concept, you know, is generally the same but the emphasis might be somewhat different. For example, in the EU. There's a greater emphasis than in the US on the competition side, as compared to the consumer side. It's a bit more oriented to be sure that companies don't become dominant to the detriment of smaller companies. And you can see how this plays out sometimes. If this is the kind of thing that you pay attention to in the news that very frequently the EU will bring investigations or charges against big high tech companies where the US doesn't. If you have a long memory, you can remember big investigations and big fines against Microsoft against Intel against Qualcomm against Google, none of whom were subjected to investigations for the same purposes in the US. So as I say, while the concerns are generally in harmony, the policy ideas that drive the actual enforcement of those policies and the actual framing of those laws, you know, does have some differences. Today, China is becoming more active in any trust laws and has adopted more and is refining them and their approach to any trust is not only again, somewhat different, but much more dynamic because it's still an evolving situation. So it's hardly reasonable to expect that anyone listening to this webinar is going to actually try and understand the differences between these laws. It's more important to just sort of tuck away that the laws are different. And that they're therefore you have to sort of always be mindful of what the general rules are and staying on the right side of them. Just so you have a good margin of error. And happily that's not at all difficult as you'll see as we go through today's program. There are things to keep in mind, but this is not a tricky or difficult area as long as you keep a few best practices in mind. That said, there are penalties. They sound a bit scarier than they are. But on paper, they can be quite severe. You may have noticed in the in the EU, they'll talk about finding companies up to figure out whether it's three or 4% of their global turnover. If you're talking about a $200 billion a year company, like the major high tech companies, you're talking about six or $8 billion. So the penalties for companies can be really substantial. They can actually also even be criminal in the United States with very substantial fines, and those panel criminal penalties can even apply to individuals. Now, before you get too concerned about that. Not only is that extremely rare, but when it does happen, it happens where the violations are really flagrant, and you're usually talking about, you know, the CEO or the CFO, or another C level executive you're not talking about, you know, a programmer in an open source project or a standards working group member. So again, good to know that these laws are backed up by real penalties, but no reason why you should feel personally in endangered or personally in the crosshairs. It's really much more likely to be your employers that would need to be concerned. So it's worth noting that more often than not, actual financial penalties or criminal penalties are never assessed in the great majority of investigations that are launched relating to antitrust, whether it be in normal commercial activity or standards. They usually end up in what's called a consent decree in the US. There's a similar term in in the EU. And what that means is, is that the parties, the regulator on the one hand and the company or companies. And or sometimes the standards organization. And there was a have been some investigations in the last few years that did involve standards organizations entering to this consent decree where the defendant isn't actually found guilty and doesn't admit to having done anything wrong, but they agree with the regulator on how they're going to change their behavior going forward. One example was a standards organization called GSM where it sets a lot of the telecommunication standards and fourth and fifth generation telecom standards. And what that focused on was the fact that some types of members had more control over the decisions made by the standards organization than other participants in the organization. And as part of that consent decree, they agreed to reset the balance and influence between members and that was the end of it, as well as continuing oversight by the Federal Trade Commission that's the FTC, going forward. How often do these pop up. Well, the answer is they kind of come and go in the United States. They sort of go in sort of a sine wave. If you look back in the early part of my career. The regulators were extremely active and at one time they were trying to break up AT&T which at that time owned all of the telephone systems in the United States. They investigated IBM, they investigated Microsoft, actually brought actions against each of them and actually tried to break up all three of them. AT&T actually agreed to break itself up. IBM and Microsoft were able to escape that. But it shows you, you know, the fact that they're not shy about focusing on the biggest companies of the industry and taking serious action. These days has been more activist than the Federal Trade Commission and the Department of Justice in the US. And as I mentioned, they brought some major actions against some big high tech companies that are household names. And in most cases, either extracted a consent decree, or actually levied very significant penalties against those companies. He has launched at least one action against the standards consortium. Since I originally put these slides together, I've become aware of another one where they're investigating the standards consortium. In the US, there have been at least three investigations over the past several years. So these are areas where the regulators are do take an active interest. And usually when an investigation is launched, it's because one company or several companies go to the regulators and say, look, there's something going on over here that we think you should look into and are able to convince the regulators to do so. As you might expect, sometimes those complaints are more the result of one competitor trying to take a punch at another competitor. But nonetheless, if a standards organization allows itself to get a bit sloppy, even though the regulator may turn out, eventually saying I guess there's nothing wrong here. The impact on a standards organization in particular, which since I have very few resources and very few personnel can be very extreme because it's hugely distracting and time consuming to respond to government investigations. And as I mentioned, China's an evolving landscape. So hard to make many comments about China, nothing to say say to you will be seeing things pop up in the news there, I'm sure. So what is it with all that introduction that you need to be need to be careful about. Well, as I say principally it's abuses by competitors, but competitors act through people. And when you are representing a company or possibly acting on your own involved in the standards organization, but particularly when you're acting for an employer, the regulators will look at you as being basically the extension of your employer. So the your actions would be imputed to your employers if you're acting as your employer has asked you to act. And you want to be aware of either doing things that you shouldn't do, or almost as much concern, doing things that are totally innocent, but maybe over the line, even though you have no intent to do anything wrong at all. But what they all relate to is conduct that could be viewed as competitors getting together to strike a deal in order to advantage themselves. Now, if you think about it, open source software and open standards are basically things that competitors get together to create and then do the same way. So if you think about it, that sounds a lot like a like an antitrust violation. But in fact, standards development and open source development are viewed as being in the words of regulators pro competitive and what pro competitive means is that the results for consumers are favorable. So standards in particular, if you think about it, are a way that allow different competitors to sell products that consumers and businesses can very easily compare. You can say, well, I can buy this product or I can buy this product. And if I want to switch from that product to this product, I can do so because they both adopted the same standards. Both those products are compatible. I can move my information and I can move my software from this competitor to that competitor. And the result of that is that consumers and businesses have more choices and competitors as I mentioned earlier, have to compete on value added features on better service on better security on better functionality. So that's the sense in which the trade off comes out in favor of consumers that even though different competitors are agreeing to standardize small portions of their product to act in the same way, the benefits of the consumers greatly outweigh any impact that they have on innovation. And one of the things that you'll frequently hear about in discussing any trust is the trade off between innovation and regulation. The idea is that regulation should do no more to restrict innovation than absolutely necessary. And that's one of the reasons why standards are tolerated, because typically a standard involves only a very small portion of the functionality of a device. If you think about a computer and Wi-Fi, the Wi-Fi technology in a laptop or a phone is a tiny fraction of all of the functionality of that device. But the value that you get from Wi-Fi connectivity is enormous. By the way, I should say remind people that the Q&A box at the bottom can be used to enter questions. If you have any questions in the course of my remarks, please do put them in there. We'll have plenty of time to come back to them. I probably won't stop during it because I can't see that while we're sharing the screen, but do feel free to drop your questions in there. Standards were also created by organizations, usually referred to legally as trade associations. And here's a quote from a Supreme Court case, a trade association by its nature involves collective action by competitors. Nonetheless, a trade association is not by its nature, a walking conspiracy, it's a redenial of some benefit, amounting to an unreasonable restraint of trade. And you really do get this, you know, they go on to say in particular, it has long been recognized that the establishment monitoring of trade standards is a legitimate and beneficial function, beneficial function of trade associations. So you shouldn't worry when you participate in standards working groups. The courts are very much in agreement, both in the US, the EU and elsewhere that this is a good thing to do. When should you be alert? Well, one of the things that I tell the Linux Foundation and other clients is the board of directors has to be really careful. And we do this, we map out, you know, what the what the board of directors talks about, I review the minutes, I or another person from my firm sits in on the meetings so there's good oversight there to be sure that everything is being done properly. And we're in face to face meetings or virtual working group activities. That's another situation where you should be aware of what is proper and what's improper activity and improper things to talk about. Generally, you're not responsible for what goes in the hallways. If you know two people get together and talk about something outside, that's that may be a concern for you and your employers but it's not a concern for the other members of the working group or for the standards organization as a generality, because it's just one on one, and outside of the actual sanction activities of the organization. So, what are these things you should not discuss? Well, as probably all of you already know, you don't talk about prices. An example of any trust violation is what's usually referred to as price fixing. And the most obvious way that that is bad for the marketplace is that if the major competitors get together and say, why don't we just agree that none of us are going to charge less than X. That means that they've just killed off competition at the price level that the consumers are never going to get a bargain because the incumbent vendors have all gotten together and fix the price. What may surprise you is it can also be a violation to set a ceiling. And that may have to do less with the ceiling on price, but the fact that there's some other part of the bargain that's going on in the shadows, you know, at the same time. I never also talk about the distribution strategies of your company or their competitive strategy or their market shares or territories. I won't go through these bullet by bullet you'll have access to the slides afterwards and can take more time on them. But the general idea is, is that how a company goes about competing should be known by that company and not any of its competitors. And one of the reasons is that if they start talking about it, they can basically be signaling each other. I'm going to do things this way other people can say, ah, I think I'll do it that way as well. And that way we won't be competing with each other as directly. So the way to stay safe is to just never talk about your, your employers strategy distribution channel sales strategy, number of sales people, you name it. The good news is that almost all of this information is the kind of information that you know you shouldn't be talking about anyway. Not because it's illegal, but because your employer wouldn't want you to be sharing it with competitors. So the good news is is that as a generality, most of the things you shouldn't talk about, you wouldn't be likely to talk about anyway. But it is easy to somehow drift into some of these discussions. If you're not keeping aware of them. Again, you, you would likely be totally innocent in what you were doing. But after the fact, it might look like improper behavior. So some more do's and don'ts. As I mentioned, if your company thinks it's confidential, it's probably not something you should share for any trust reasons as well. Another aspect is you should never exclude anyone from taking part in a working group or an open source project. Now this, you know, unless you're a maintainer, or a working group chair or something like that. This is generally outside of your, your work of your remit. But if you are, you know, part of the management of a standards project, then it is very important that you understand that standards organizations should always be open to everybody. The standards working groups should always be open to everybody because by excluding someone, you can cause harm. In particular, if a group of companies were to get together to try and exclude someone that could be a clear any trust violation. Again, this only applies if you're a manager, but when we set up certification programs or similar activities, again, everyone who's in the marketplace should have access to those programs and not be excluded, because if they are excluded from certification programs, their products may be less successful in the marketplace. So again, I'm going to sort of speed through these because they get down in the weeds, but suffice it to say that there are a number of these things that you can come back and mull over in little great greater detail because it's a rather long list. But these are all things that are should be regarded as off limits for discussion. Maybe a little counterintuitive is that when parties join a standards organization, they should not be asked to commit to implement the standard that the working group creates. Now that might seem a little bit strange and if you're all getting there to create the standard. Why wouldn't everyone have to adopt it. And the reason is partly because standards do restrict innovation. And even though it may be inconvenient to have competing standards, one of the benefits of competing standards is the marketplace can decide which one of things is best. So even though having multiple standards may seem like a dumb idea for any trust law purposes. But it's really just the same as any other product or service, the antitrust laws and the competition laws do not permit standards organizations for example to say, I'll stay out of your territory. If you stay out of mind, that would be just as big a violation as if a company did it with a proprietary product. Well, my button is not working. There we go. Okay. Let's talk about sort of the happier side, what are the things that you should do. Well, you should engage in joint marketing and planning activities. If your standards working group supports them. That's not deemed to be problematic. It's just a way of collaborating and leveraging your respective resources. It's very important if you're a chairperson right in the meeting to have an agenda for that meeting, and then stick to it because this creates a record of what the competitors in the room talked about. Do keep minutes and records and distribute them to all participants were appropriate if there's anything you're concerned about. I will ask LF to have one of its legal resources myself or Scott Nicholas or Mike Nolan or Joanna Lee to answer questions before the minutes get distributed. But again, the role of the minutes is to show anyone what it is that actually went on in that room. Be sure that chairs are familiar with the rules of proper conduct. So if you're a chair, or if perhaps a chair of a working group that you're in, who's not on this call, tell them that they that you heard a good webinar, and they might want to go check it out. So from the Linux Foundation perspective, one of the reasons we're here today is to make sure that participants and chairs are familiar with these rules. As I mentioned, there's another video that will be used to the open source side of the house. Do ask your company if you're if you have access to your own company's legal resources, or the foundation's legal counsel, a question if you're in doubt. It's another good example of the old line if you see something say something. If you're in a meeting and you think that the, or online and you think that the conversation is going somewhere it shouldn't pipe up, you know, just say I'm not sure whether I'm right or wrong about this, but I don't think this conversation or this thread is staying in between the guardrails. So don't be shy. You can always pick up that conversation again later. If you run it by legal counsel, and they say don't worry. But if they do say yep, good catch. You'll have done everybody a favor by by speaking up. So that takes me through the formal part of the presentation, and I'd be happy to answer any questions and I see that that there's a few there I'm going to stop my screen share and go over to our other slide so I can read these questions. The first one says, if a certification price is very high. Does it count as excluding some protectioners with fewer resources. That's a great question. And the way things work is that the antitrust laws generally permit these, whether it be to get a copy of a standard, or to be part of a certification program, as long as the court or even some standards and regulations actually restrict membership, and I'm sorry restrict access to standards to people who are members. All of those practices are okay, because after all there has to be some way to pay the bills for conducting the standards work and conducting the certification program, and perhaps doing worldwide trademark registrations. It's also okay to charge for these things, as long as the price is reasonably related to the cost of conducting the activity. So if a certification price was not only high, but higher than was justified by the cost of providing the certification program. Then yes, that could be enough to at least get the attention of a regulator, whether the regulator actually took any action would also have to do with whether the, or whether there was any liability, as compared to the regulator saying, we think you should the penalties would relate to whether the price was high for the purpose of excluding anyone. So in general, in order to be guilty of an antitrust or competition law violation, there has to be intent to engage in improper conduct, you had to intent to cause harm to someone. So in this question the answer would be, would it be a violation to have a high price that might exclude very small companies, probably not, unless the price was unnecessarily high, and if the intention was to exclude the little companies. So next question. You indicate that a standards organization should not allocate scope between them, but cooperation agreements are very common as a vehicle for creating unnecessary overlap. Can you spend a minute on this distinction. This is your excellent question, and you're very right. Most standards organizations enter into what are usually called MOUs for memoranda of understanding or liaison agreements with other organizations and they may have anywhere from one to 40, the more influential and the more broad the activities of a standards organization, the more widespread these liaison relationships can be. You're quite right. In asking the question, there's a very delicate balance between that. So sort of starting at the bottom, what are these organizations do at the most innocent level, relating to overlap, what they do is inform two organizations, where they are active. One is entering into an activity. The other organization may say, ah, well if they're already over there doesn't make any sense for me to do that to, you know, they do quality work. I'd be wasting my time. So at the most innocent level. It's a matter of having active communication that avoids overlap. That's accidental and needless. It would be improper, however, for the two organizations to get together and say, this is my turf. That's your turf. Stay out of my you stay on my turf, and I'll stay out of your turf. So while while these organizations can therefore keep each other in in form to their activities, and very often will instead of doing two different standards will collaborate on an activity. It's very common for them to form a joint working group, which in some ways is kind of the best of both worlds, because now you get the members and the competency of both organizations, plus you get the benefit that both organizations will then be promoting the uptake of the standard that results. So great question. And the answer is great for cooperation. But you can't take it far enough to be basically dividing the marketplace between you and protecting your, your respective territories and your respective areas of standards development. You said in passing that standards slow innovation, which can be the case, but another contest they foster innovation, right. Actually, I didn't say slow innovation, but I will pause on that because there is a perception that they do slow innovation. So let me answer your first, your question first, and then come back to that. Certainly standards also foster innovation. Absolutely. If you think about what are commonly referred to as network effects. You have enormous networks. If you think about telephone voice and texting. If you think about Wi Fi. If you think about any of the, any of the things where different products plug and play with each other. If you think about even agreeing on standard performance measures, all of those bring more companies into the marketplace. And once they have more products that have incentives to come up with more value added services. So for example, if you look at a car, it's amazing how many different things pop up in a car every year. You know, originally it was power windows. You know, then it was, you connect functionality for your car to plug your phone in. You know, it was automatic windshield wipers that go on when it rains. And you think, where do all these things keep coming from. Well, where they keep coming from is the fact that there's a lot of different cars, which implement a whole lot of different standards that they make basically make them functionally similar. You know how many miles per gallon are, you know that they all use the gasoline, the same gasoline, you know that they all have comply with the same safety standards. So the more products adopt a given standard, the more likelihood there will be that there will be more innovation on top of that standard. So what you notice in standards generally is that you try and push the standard to the lowest possible layer so that there's more room to innovate on top of that layer. And generally that's exactly what you see. You also see that standards tend to follow innovation, rather than preceded. So generally standards come about after there've been lots and lots of different goods and services tried in the marketplace. So if they've started to catch on, then the standards follow on the topic of speed. And particularly because this is an open source audience. One of the concerns or one of the things that that open source tends to not like about standards is that standards by definition are slower than open source. And the reason that they are, well, let me say that. Let me say that differently. Surprisingly enough, they're not always slower. If you think about a new open source project, getting to a first release in six months would be pretty quick. There are plenty of standards organizations that actually develop standards in six months as well. And probably the majority of the time these days, it's less than a year. The amount of time to first release the time between a standard and an open source commercial release isn't necessarily that great. What is different though, is that open source releases frequently and open standards do not. And the reason that open standards do not is because open source has a significant part of its value from the freedom to change. Whereas standards get their value from not having the freedom to change. If you think about plugging a plug in the wall, if you decided you wanted to make the prongs a different length. Well, you would have created a problem rather than solved one. So the value of a standard is that everyone does things the same way. And therefore, you want to keep things the same way for a period of time that provides value to the marketplace. If you're constantly coming out with new standards, particularly if they weren't backwards compatible, you'd be holding the marketplace back rather than taking it forwards. So standards organizations tend to have a three to five release schedule. And what they're doing there is they're balancing the benefit of stability against the costs of upgrades. The other thing that it's worth saying is that standards are not like open source in that they are most frequently a text description of functionality. So they again impose the minimum restriction on innovation, because they don't tell you how to achieve the result. They don't tell you the result you have to achieve. And frequently there can be multiple technical ways to achieve compliance with a single standard. So again, the marketplace has the minimal amount of constraint necessary. Now, having said that, increasingly, people in standards organizations, you know, may get to, you know, section 3B of the outline for a standard and look at it and say, Why the heck are we describing something here? Why don't we just throw in a bunch of code? This is silly. And increasingly that's exactly what working groups are doing. So they may put in code and say, This is normative code, meaning that in order to be in compliance with the standard, you have to use that code, or they may provide a text description so that you could write your own code. And then they also provide the code so that the implementer has the freedom to either use the code just the same way they might grab a module from GitHub, or they can write their own code based upon the text description of the functions. So that takes us through the questions that have been posted. Does anyone else have one they'd like to add or a topic they'd like me to expand on? And it looks like the answer is no. So at that point, I'll thank you for your attention today and pass the baton back to LF. Thank you so much, Andrew and Jory for your time today and thank you everyone for joining us. Just a quick reminder that this recording will be up on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day.