I think we'll get started. So Dan, thanks for joining us today. I'm not on the website, so Leah, could you tell me how many attendees we have? But we typically have around seven to 10 eventually joined. Yeah, yeah, in between Dan, Lynn, yourself, me, Hamza, and Sushant are also here as well. Sushant from Microsoft and Hamza, you're, who are you affiliated with? Huawei, very good. So Dan, we record these, so we'll make sure that those that couldn't make it today will be able to listen to the recording and we might have some follow-up questions from them. But this work group is part of the CNTF and we are just kind of looking, we kind of brought in CNI to begin with as our first order of business. And now we're looking at what areas of cloud native and networking are of interest to the community. And Leah and a few others had brought up Istio a while back with just service messages in general. So we thought it'd be a great idea to have you guys come on and present to us what is a service message, what is Istio, what are you guys doing? Leah and I, as you guys already know, are familiar with it but a lot of the community, I don't think that's familiar with it. And so, I'm trying to give you guys the opportunity to present what's going on and what's the future of service messages. Okay, Doke, I am happy to do that. And Louie Ryan is just asking me for info, both of them, please send me an update. Thousands of people are in their soil. Sorry about that. So the correct meeting is, sorry, I have so many windows open, it's difficult. Okay, so the correct meeting is this one. The Zoom number is the same, the meeting ID is the one you do if you dial in. Is that correct? Just saying the same number. Yeah, that's the correct number. And then the GitHub page is up to date now. Thank you very much. Ken, we also want to welcome to the call, Rui, Rui, where are you signing in from? Sorry, I'm on the East Coast. Oh, very good. Yeah, I didn't find a meeting, I go to the CNCF Canada, finally find a Zoom link. Okay. Well, there are fresh details up on that page, so very good. All right, let me see if I can figure out how, there we go, share my screen. And you tell me, are you seeing what I want you to see? That is, are you seeing an intraday issues slide? We are. Yeah, sorry. Was that a question? Rui was just saying, he saw it as well. Although right now, Dan, actually it went away, Dan. We saw it for a little bit and then now we don't see it. And now you see it again? Yes, we do. Okay, so what is the service mesh? These are some slides I threw together. By the way, this is a small group. There's no reason to be formal. Please feel free to interrupt with questions at any time. I'm a product manager on the Istio project and here at Google, I invited Lynn Sun, who is an engineer and master inventor at IBM. That's an official title, an award that they give to people who do a lot of inventing and learn recently, she has that, I think that's awesome. I've invited her to the call and we will probably also get Louis Ryan, who is one of our senior technical people at Google who will join the call as well. Product manager should imply to you that if any tough questions come, I'm gonna shunt those off to those guys. And I will start with what is a service mesh? These are some kind of general intro slides I give. Feel free to let me know if this is wrote to everyone in the call and would like me to go forward. At the end I have a feeling we'll probably get to just pure discussion. But let me tell you what we mean when we say service mesh, just to kind of level the playing field. And the first thing about service meshes is that, well we'll say they automate application network functions. Application network functions, we sometimes jokingly refer to as layer eight network functionality above even what the application does. Or you could think of it as layer seven and a half if you want to. And the goal of a service mesh is to automate a lot of things that people have formerly written code around. A canonical example I always use is retry logic. What do you do when a call fails? This is typically has been left to one of two things. Either developers write code about this. I have certainly in my own lifetime done this dozens of times. But what happens when a call fails? What do you do? Do you back off? Do you do an exponential back off? Do you add jitter into that? How many times do you do it? That sort of behavior is the sort of behavior that a service mesh aims to automate so developers no longer need to write that code. And that applies for routing decisions. It applies for circuit breaking. It applies for rate limiting. It applies for a whole host of features. I've got a list later on. But it does want to automate those. But the key part to a service mesh is that it automates those in a transparent and language independent way. Transparent meaning the developer doesn't have to write any code to use a service mesh. The developer doesn't have to. When we first announced Istio, I was at a conference and I overheard some people saying, oh, Google and IBM invented the service bus. And the huge difference between a service bus and a service mesh is a service bus is something you code to. You put messages on it. You use its API. It delivers those messages. A service mesh is transparent. Developers place calls to other systems. And the service mesh transparent. And in a language independent way, takes care of that functionality. And what I mean by language independent is, you don't need to embed a client library in your source code. You don't need to compile something in. Anytime you do that, of course, those things are implemented in language independent fashions. And a lot of what we talk about with Istio could be accomplished using existing technologies if you choose a certain language stack. If you're able to tell all your developers, everyone is going to use Java. And here's the library we use for communication. All of this logic could live in that library. The issue is that it would only work for Java. And what we've found is that many companies who are either with things they find in open source or building themselves are building this sort of functionality but they're doing it in client libraries. And that means that they either have to really restrict what their developers use or it means they have to deal with the difference in reality. Hey, hey, Ron. They have to deal with variability in their client libraries. This is something we faced internally at Google when we used to try and do this with client libraries is different capabilities in different languages. And Service Mesh aims to, by implementing these features in a sidecar proxy, remove any language-dependent needs from that developer. The reason we need Service Meshes, the reason these are getting a lot of attention right now has been this general move towards distributed applications. Because of containerization, because of what's going on at the CNCF really, with containers, with Kubernetes, people are moving to more and more of a microservices style deployment. It's very agile. They can have small teams who are delivering functionality, deploying very frequently. That's great for developer productivity. And it's very scalable. And applications are getting needing to scale more and more and more as you have more users on applications all the time. The Mobile Revolution, of course, has contributed to this. And because people are more frequently than ever deploying in hybrid environments where they're using their on-premises, data centers, maybe there's multiple data centers, they're using a cloud provider, they're using multiple cloud providers. But they have applications that are actually physically running in multiple places simultaneously. All of these trends towards containerization, microservices, and hybrid and multi-cloud deployments have been applications are more distributed. Now that applications are more distributed, the game has changed in what you need to do in order to monitor an application, in order to see what's happening in an application, in order to control a rollout and safely deploy a new component or a new entire version of application. And finally, security has changed significantly from the days when an app was a monolith and you had to secure and expose one IP and one port and that was it. Now you have an IP and a port that's exposed to the world but you also have tons of communication happening within that application and all of that needs to be monitored, secured and managed as well. The goal with separating out that service mesh functionality that service mesh functionality is to keep your application separate from the infrastructure. There was a time when I started my career when I was doing lots of communications software and you were in charge of everything back then. This is before, this is really before the internet TCP IP took over the world. It was certainly before everyone was using web APIs and HTTP and JSON. Adding all that network into network capability into developer tools has made developers much more productive and made them write much less networking code inside their apps. And what we're trying to do now is put even more into the infrastructure. So developers are focusing on building the applications that are relevant to their business. And it also decouples operations from development. Too often people are putting into source code into development the logic that should actually be capable of being changed at runtime at operations time. Doing a canary deployment is a perfect example. We have certainly seen people who would have logic in their source code that says, hey, where do I place this call to the regular service or to the canary version of the service? And that code doesn't belong in your application because then it's changing an application in order to change that code. That could belong somewhere else so that your application even if your developers are doing your ops or running it, you don't want to have to change the source code of your application where the business logic should live in order to change those things. So that's what a service mesh is. Now let me talk a little bit about what Istio is and how we've chosen to implement the service mesh. It is a service mesh, but more than that it's an open services platform. And I'll get into what I mean by a platform later, the APIs that people can integrate with. And its goal is to manage all service interactions in an enterprise. We really do. We started with Kubernetes. We think that most of the development that's happening in the world today is happening in a cloud native fashion and container based workloads. However, we also understand that most of the software that exists today most of the software today is still running in VMs. And when we talk to potential adopters of Istio, certainly people who are doing development in Kubernetes say, yes, I want some of that. I want to understand my traffic patterns better and I want to be able to control or roll out and secure it. However, those workloads that I'm running in Kubernetes are also communicating with other things things that I developed 10 years ago. I need to monitor secure and control that traffic as well. So Istio has a strong goal of being able to handle VM based workloads as well as the container based workloads. There are three main things at the core of what Istio gives you. Observability, control and security. And by observability, I mean what's going on in this application. An application as I said before is now a complex thing. Often many, many services could be dozens. It could be hundreds depending on who you are, how long you've been doing this and how big your app is. Istio has a general goal of helping to understand your application. The first thing it does, and this may seem like table stakes, but a lot of people just don't have this. It collects metrics, it collects telemetry from every service that's deployed on the service mesh. And it starts with what we call at Google the golden signals. If you've read the Google SRE book, you know what these are. The first three are traffic for a service, error rates and latency at various percentiles. Istio grabs all of those and sends them to the system of your choice. That lets you monitor essentially service level indicators for every service. Too often every service that someone brings up in an organization decides on their own what their SLIs will be. There's no uniformity there. It's very difficult. You can't build a standard dashboard. So we believe very strongly and sure you can monitor app-specific metrics if you want to, that's great. But you should start with a uniform set of golden signals. We also collect logs and traces from your apps. We believe in collecting logs on every call. Sometimes people ask us, so what percentage of the calls do you log? We believe very strongly in logging all of them. We don't keep logs for very long around here at Google, but we believe strongly in logging them and having tracing built into your app so that you can run tracing on a representative sample of those. Understanding the state of your service is, you know, signals are important for that. Understanding what happened, what something goes wrong, you need to understand why, you need to root out latency problems. Being able to have those logs and traces are very important. Finally, clearly mapping service interdependencies. This is something that a lot of people don't know and I think the thing that was first driving people to Istio was the ability to easily understand where their traffic's coming from. For any given microservice, what are its traffic levels and who's sending that traffic? That was something that was a bit of a mystery to people who didn't do a bunch of work within Kubernetes. So, help you understand this. And to do all this at the service level, not how many bits are flowing where, but rather how many calls are coming from service A to service B or service C to service B and understand, you know, view your traffic and your dependencies at the level of a service.  And basically that is control over how the network operates. What happens when a call fails? What is the retry policy? By taking advantage of what's in Envoy and being able to code on Program Envoy, Istio lets you control things like your retry policy, your circuit breaker.  The ability to run and experiment and say all traffic from internal sources goes to the new version of a service or all traffic with an off token that is generated for one of our users is a big deal. The ability to do a safe canary rollout and say let's generate, let's direct 1% of our traffic to the new version of the service and monitor telemetry. Canarying is a really big deal that people who are sophisticated in microservices would never dream of doing a rollout of a service without having a good canary capability. And yet Kubernetes doesn't give you a good canary and then finally things like applying access control and rate limiting to services. And then the last is security and Istio offers the ability to add MTLS in on your interest service traffic. MTLS means every service gets an identity and every call placed from that service will have cryptographically secure tokens that indicate who's placing that call. Once you have a strong identity on a call that means you can then have an authorization policy to say, oh, do I trust this? We hope that in the future people move from IP based security models to service identity based security models. We've done this at Google, we think it's a, both leads to a more secure network as well as a network that's easier to administer, easier to operate. Our architecture is we install a couple of components, Pilot and Citadel that push information out to sidecar proxies. Citadel issues certs so that we can do TLS. Pilot pushes configuration data, it pushes all the routing rules, it interacts with service registries. And of course we do use a sidecar proxy. We've done a lot of work with Lyft, with Lyft, Matt Klein from Lyft on the Envoy proxy. Our team was very happy to find the Envoy proxy when we started this project and they were happy to join us in IBM in letting us use their proxy. We do contribute upstream. We have a bunch of people actually who work on Envoy itself. It sits in the data plane. And then we have a component called Mixer. And Mixer is really where the, I said we think of Istio as a platform. Mixer is where other people can easily integrate. So Pilot pushes this configuration around. It does integrate with service registries aside from Kubernetes. So if people are doing VM based workloads and they're using console or Eureka, Pilot can integrate and read state from console and Eureka so that the service mesh knows how to direct traffic to those as well. It pushes out information about number of instances that are running so that it can do client-side load balancing and it also pushes routing rules. Anytime you're doing a canary deployment or want to route certain types of traffic based on the request, it pushes that data down into the client-side proxies so the client-side proxies know how to route their traffic. Mixer is what makes Istio a platform and not just a service mesh. And that is a set of APIs that allow at runtime arbitrary telemetry and policy backends to plug in. Istio is not a storage system. While it collects, I talked before about collecting the goal and signals and collecting the laws and collecting the traces. All it's doing is serving as a funnel for these. It puts the proxy in place. It knows when all the calls happen and it reports those to Mixer. Mixer in turn has an API that allows those data to be sent to arbitrary locations. Out of the box, we ship a Prometheus adapter but lots of vendors have done their own adapters leaves here from SolarWinds and SolarWinds has an adapter. We've seen Datadog create an adapter. I know that there are some other of the common ATM vendors are working on adapters as well. We have a couple of tracing both Zipkin and Yeager adapters for traces and there's a couple of logging adapters too. So Istio does not aim to be the storage for any of these but rather a common API. And the goal is that rather than create client libraries in different languages, rather than have people set up say log scraping and parsing pipeline which is very common. We place this proxy that all traffic goes through and that reports all this information in a standard way so that a mixer can, I mean so that a vendor can with an integration into one API collect data from all the services on a service mesh. And again, that's without involving developers writing and baking in a client library. We do the same thing for policy and mixer's policy API is used at runtime as a synchronous request to decide if a call can go through. Examples of policy would be do we accept calls from this IP address if things are coming externally? It can be of course do we accept calls from that service identity if the call is coming internally. Other policies are rate limiting policies. We at Google have an integration with our Apigee API management which allows us to do things like hey, this API call has an API key in it. Can you check to see if that's valid and if there's enough business quota left to run? So we see again, the interesting thing from vendors is with a single API integration, they can now offer their service for arbitrary number of backends. I did say this call is made synchronously policy calls. It is made synchronously but we do use heavy caching at both the proxy level and the mixer level to maintain performance. And then we have Citadel. Citadel is a certificate authority that issues certs and handles things like rotation, cert rotation so that all of your calls optionally can be secured. And as I said before, our goal was to let Istio manage your traffic for all workloads, not just Kubernetes based workloads. So we did start with Kubernetes because it was very convenient and because we can do things like auto-incheck the proxy which makes adoption easy in some cases, but strong goal to support non-communities based workloads. So here's where I always ask the audience, how deep do you want me to go? Do you want me to walk through the life of a request in the mesh or do you want to assume people here kind of understand what that's about and wanna get to more where are we, what features exist, what's coming? I don't know if Zoom has a poll feature. It's probably not, but I'm opening up to others on the call. Do you guys wanna go to the feature? Do you want more of the intro part? I think here we go to the features. Yeah, okay, I'll share these slides. They do go through what happens when a call is made on the mesh and you can make them. So let's go to the features and then we'll open it up for questions because that's what I really wanted to do and why I made sure that it gets here. We have reached Istio 1.0, actually 1.0.1 was released last week. Very happy to announce that and I'll talk about some of the features and what the state is and they're kind of grouped into these four groups. We are adopting the Kubernetes rubric of evaluating features which is alpha, beta and stable. When it features in alpha, the feature may change where we're evaluating it, we're evaluating our implementation of it. When we reach beta, we don't expect the surface of the feature to change at that point anymore, but we're working on hardening and when we reach stable, then we know people are using it in production as far. So this is where we got to with Istio 1.0 and I hope you can see the color coding there. I've got my gray, my stable features are in gray. The green features are in beta and we do think data is ready for production use by the way and then alpha start using them but they may change. And you can see that in terms of traffic management, probably most interesting here, we are supporting HTTP11, 2.0, GRPC and plain TCP traffic. One thing that's interesting is you'll see there's MongoDB has popped up there. One of the, I said before that we're very happy with the Envoy community. And one thing that's great is to see database protocols starting to be built into the proxy itself. And that allows the possibility of really interesting things. You don't typically think that a proxy sitting between you and a database would be able to do something like tell you how many reads you're doing for the database. And yet when we understand the protocol, we can do things like that. You also don't think about a proxy being able to do things like direct your reads to one instance and your writes to another instance. And yet as Envoy learns more and more about the protocols, it will actually be able to do that. That's a simple thing and it's not an unusual thing to think about with HTTP. But as the proxy gets more functionality for these protocols and we think Envoy will be doing that, we'll be able to do a lot more things. We do support ingress and egress as for Kubernetes with our gateway. We can terminate TLS in the gateway. SNI allows that to be from multiple issuers, of course. As you can see, you can do label-based routing, traffic shifting, and there's a bunch of the Envoy features that are timeouts and retries, connection pools, outliers, all of that is in there too. We are working on custom filters in Envoy. And one of the big kind of outstanding philosophical issues is how much logic do we want people to push into the proxy and how much logic should be implemented at Mixer. In terms of observability, we've got Prometheus, I mentioned before, we have a dashboard in Grafana, all kinds of things are in process there. As you can see, including SolarWinds, Google, we have a product called Stackdriver, ZipGain, and Yeager. We're working with the OpenCensus project on observability. And in security, we have a pretty good story now for service-to-service TLS, getting those credentials out to VMs, allowing you to do incremental MTLS, so telling a service, you can accept MTLS, but we have some legacy clients out there, so you don't have to require MTLS. That's important for people to be able to adopt this. And we're working on end-user authentication as well, the ability to validate Jots and perhaps use an open policy agent policy to describe what you will accept. So some of the things that changed in 1.0, I already talked about permissive mode or incremental MTLS. That was something that was new before MTLS was all or nothing, either your service required it or it didn't, and it made it difficult to slowly adopt this deal. I've talked a little bit about mixer adapters, and we've changed the adapter model and it made this tremendous improvement. Mixer adapters, which allowed a policy agent or a metric or log collecting agent to be integrated from another system, those were formerly compiled into Mixer. Now, those adapters are out of process and we have Mixer implements a GRPC API so that you can, at runtime, without redeploying Mixer, we're sorry, rebuilding and then redeploying Mixer, you can deploy new adapters. That's new and that's very powerful. And then finally, we made an improvement with authorization policies that if you are simply using authorization policies like is service A allowed to call service B, that logic is actually pushed down into the proxy now and it doesn't require calling out to Mixer. So even at the policies like that, do, if you're calling Mixer, tend to affect you not on your median request but on your say 99th, those are cash pretty heavily, so maybe on your 99th percentile, but this improves that even at the 99th percentile we won't affect latency on off calls. So we've got, I just checked yesterday because it's perf season and we got to know the metrics, 244 people have committed code to the Istio repo. We started this project with IBM but we've since then gotten participation from a lot of people. And when people ask, how do we differ from other service meshes? There's a couple of things. I do talk about our emphasis is platform and our desire to have one API that any vendor or backend system can integrate with in order to integrate with service meshes. But I also talk about the community that we're building and the fact that in addition to IBM now, VMware, Cisco, Red Hat have all joined us and much like that, what happened with orchestration? We think that the industry will be well-served if everybody consolidates around one. And lots of adapters have been including our own adaptive create that answer. Where is this running right now, running in production? Well, of course it's open source software so mostly I don't know. So we don't get to find out where people are running it unless they happen to tell us. These are some that have told us and have told us we can talk about them publicly. The weather company was the first large scale deployment. I think I remember the number, Lynn can correct me at 400,000 requests a second coming from the weather.com site and APIs. Descartes Labs is a Google customer was the first custom company that we know of that was running in production. They really needed the observability but we've seen some big names, both in HP and E-Day and some names that maybe you weren't familiar with before but are doing really cool things in auto trader and maybe. And again, these are just the ones that we know of and can talk about. There's a bunch of others that I haven't had permission haven't been given permission to talk about publicly and most of the ones running, we probably don't actually know. One of the points of emphasis and I think this is my last slide is that we've been talking about a lot is that many companies that are adopting Istio are not adopting all of the features. MTLS is a perfect example. Not everyone cares about MTLS. Some people trust their network. We at Google don't. We think it's a really good idea to secure every service in addition to securing your perimeter. But for a lot of people, that's more of where they're willing to take on. And that's an example of kind of all a cart or incremental deployment. We see other companies who are using it for traffic management, but using their existing ingress because they put a lot of work into their existing ingress. And we have another company I've seen that is using Istio for now for ingress only. And it's just to kind of get their feet wet. And I got a screen cap up here of a feature I think that Lynn worked on, which is a minimal Istio installation. And this I think will be a very common one, which is you just want to use a pilot. A pilot is a good API for configuring envoys. And it's envoys starting to get a lot of use around the industry. We're hoping that people actually consolidate around pilot as the best way to push the configuration to your envoys. And the minimal Istio installation is essentially just giving you a pilot so that you can push that configure out. If you do want to get involved, we have eight working groups. Our networking group meets every two weeks to 11 a.m. Pacific time. Go to Istio.io if you want to get information on that and join them. And the other interesting thing I wanted to bring up was one of the concepts that's just getting kicked around here now. And that is can you accomplish what's going on in Istio without a sidecar? I talked at the beginning about how sidecars are awesome and sidecars are great because they're language-independent. There is a little bit of a tax in terms of your deployment. You do need to deploy with them. And they do take some CPU and add some latency. Now, envoys is very efficiency, very efficient, both in terms of the latency it adds as well as the CPU that meets. And those are both things that we know that we can improve even from where they are. Right now, under ideal conditions, we know that it is, I think the latest figure I heard was 600 microseconds of latency. It's adding at the 95th percentile. So it's getting very efficient. However, there are use cases where microseconds matter. And in many of those use cases, people are using GRPC. And so one of the things that the GRPC and Istio teams are looking at is for GRPC, building in the logic into the GRPC libraries themselves, giving you the abilities of Istio without putting a proxy in front of it. This is not something that exists today. It's something that the teams are kicking around right now. Again, for very, very high-performance use cases, there might be some cases where that's necessary. So those are the slides that I had. With that, why don't we turn this to a discussion? And as I said before, Lynn is on the call and I was hoping she would be able to join so that we could, if anyone had had questions, they could turn to her instead of stump me. But do people have any questions? First down, I thank you for your time today and appreciate the discussion overview and open it up to any questions or discussion anybody wants to have. And again, going back to the proxy list, Istio, with the grant, it's just sort of a thought or a collection of discussions. Right now, if that were to play out, what form does that take? Is that surface mesh capabilities? That sounds like a surface mesh capability is built into a GRPC without necessarily need for, rather the proxy capabilities are in, I actually guess sort of all of the capabilities, including those of the proxy. So it would mean GRPC essentially implementing the XCS APIs. So we need the ability for pilot to push the same config that it pushes today to a proxy that tells it how to route calls. We push that directly into the GRPC client libraries. And of course, anyone who's using GRPC is already using client libraries. You need GRPC client libraries to place a GRPC call. So you've already kind of bitten off that am I going to have a client library now? And then it would mean that the two runtime calls essentially check and report that it would, GRPC itself would be able to check against Mixer for policy and would be able to report telemetry to Mixer. It is an architecture that we use, we used a system internally at Google called study that essentially did these things. And it really does come down to use cases where microseconds matter. And the one thing I would want to emphasize is that mostly microseconds don't matter. For most things that most people are implementing, milliseconds matter. And for some people, even tens of milliseconds matter. If we get, as I said before, right now, the envoy is in ideal conditions, as I said, under a millisecond of latency for almost everybody in almost every use case, that's great, that's fine. Now right now when there's lots of simultaneous connections, it starts adding more latency, it's getting close to like the 10 millisecond. That starts impacting a lot more people, especially if you have lots of internal calls for every external call, right? 10 milliseconds isn't a lot, but if you've got 100 calls with 10 milliseconds each, that does start to add up. So you just want to emphasize for most cases, the proxy itself is a really good solution. However, when there are people who are in use cases at a traffic level, such that microseconds matter, they're likely to be adopting GRPC for those anyway, because it's much, much more efficient than H2P11 and JSON. And in that case, it might make sense. So I think this is an area of R&D right now. This is not an alpha feature. This is just something that our teams are looking into. Yeah, nice. Oh, I see there's questions in the thing. Let me look at those. The slides, Nishith, yes, I'm happy to share these slides. I'll provide them to somebody and mail them out. The comparison of Linkerdee conduit and console, and I can see that Lynn has already started to answer that. Conduit and Linkerdee, they've merged those projects. I think they've said, conduit is Linkerdee 2.0, right? That's essentially what they've said. And I think that was good news. The big critique that I had heard about Linkerdee was kind of footprint and performance, and they started over with conduit as it made something that is much more performance. As far as console, you want to answer that. You've got the gist of the answer there, but do you want to give a little more color around that? Yeah, sure. So in fact, we actually were just discussing this with saying our team yesterday. So you guys know we had this console adapter integration with STL. Well, it would read the service registries from console and propagate to pilot. So pilot does a well of the services that's registered with console. So just recently, I think it was last week, console actually released this new thing. They call it Kubernetes and console. Well, when you run console with Kubernetes, you can have the services propagated automatically from console to Kubernetes and from Kubernetes to console. So we, our team are just looking at, where are we going to position our console adapter for pilot within STL? Should we be looking at this new feature, which would automatically propagate the services from the console registry to Kubernetes? So we are investigating on this and we do expect to publish recommendations and guidance by representing the STL community on, hey, this is how we expect the new console feature with Kubernetes and this is how you should use it with STL where hopefully that you would be able to add in STL to this feature, to be able to leverage the features of STL that Dan was talking about, like telemetry, traffic management and security and policy enforcement. So that's kind of where we are in investigation mode. Stay tuned. And I'll say one other thing that I said earlier, but I want to emphasize it. The biggest difference is that these, STL is really the only service mesh product that is coming from a lot of players in the industry. The others each have a company behind them and eight companies resources. We are putting significant resource in this. IBM is putting significant resource in this. DMware, Red Hat, that speaks to, we hope a kind of general agreement about, hey, we'll find the best way to do this as an industry, but also the amount of resource that's going into it. This field is changing very rapidly. We're implementing a lot and there are many, many dozens of people working full-time on STL right now and that's a big distinguisher. None of those other projects can have 50 or 60 people working full-time on it and Istio does. Yeah, and then the other thing I would add is, you guys probably know, I think a conduit was launched in KubeCon last December as it's like the initial release and it was perceived as kind of a competitor of Istio back in December last year when they had this initial announcement. But recently they, the fact that they are moving conduit back into LinkedIn is kind of a sign that we see conduit, they didn't see much value of having conduit by itself without part of the LinkedIn umbrella. So they kind of move it back to be more integrated with LinkedIn. So it's kind of, I feel like it's kind of not as a strong competition with Istio anymore, with that move and I feel the team kind of recognize that as part of the move too. I don't know if you guys agree. Yeah, I can say a couple of comments. Yeah, that could be quite possible. I think part of, or I know that I've spoken with that team quite a bit. That part of the logic there was not only did the LinkedIn, like the notion that when conduit was announced existing LinkedIn users, part of the perception is, okay, well, great, so we invested in LinkedIn and now it's going nowhere. There's a new project that now we need to figure out how migrate to and so even though that wasn't intended to be the message, that's just sort of implicitly, you know, implied as part of an announcement of a new project. And so in some respects, like sort of saving those users by saying, you know, we're really supporting you. There's a net new architecture 2.0 coming out. Also then conduit, in some respects, sort of a, I wouldn't say it's not sneaky, but it's not, but because they made it very public and they had the CNCF vote on it, but there's a way of getting conduit and that code base into the CNCF as well, given that LinkedIn is there now. And then conduit itself benefits from the couple or more years of name recognition that LinkedIn has. And so the users significantly benefit from, like not only the two things that Dan mentioned, but also the simplicity of install, which I think was another kind of challenge for LinkedIn was the complexity of the deployment. And so yeah, so there's some additional perspectives, just adding to what you said about how LinkedIn and conduit are now positioned against, against and or, you know, adjacent to Istio. Going back to the real quick, the this week's announcement about Kubernetes plus console, am I misinterpreting that or like is an integration or does this really affect the integration with Istio and console? Or wouldn't you just say, like, hey, if you're running the console plus Kubernetes integration where they're synchronizing back and forth between STD and console, wouldn't, you could just deploy Istio with the STD, with the Kubernetes integration as is today and leave and not run the console integration, just leave it off because you wouldn't, you know, it seems like in some respects you wouldn't have to refactor the console integration. Yeah, that's exactly what we are sought out, right? So we built the console adapter for Istio before this new announcement was available. We built it about a year ago, right? So there was a need when we built it that to be able to propagate the services in console back to Kubernetes while Istio control plane runs. Now with this new announcement, we're trying to figure out, is it still worth of engineering resources to keep maintain the pilot console adapter now that it's clear the console community has been choosing a new route by supporting the console and Kubernetes integration. And you guys probably seen our console headers announcement for connect support about maybe a month or two ago, which they add our envoy support as side card to handle mutual TLS within console connect. So it's kind of clear on the console community has chosen this route while they see things to go. And then from Istio community, IBM has done initial contribution of the console adapter. We haven't been getting a lot of tremendous help from the console community. So we're trying to reposition ourself to see if the new support from console with Kubernetes would actually maybe not needing to have the console pilot adapter like you were just saying. So we expect to kind of providing guidance to use how Istio can bring value to console and Kubernetes integration because that integration is all only about service registry propagation, not so much about the function provided as part of the service mesh. Thanks, Matt. Yeah. Yeah, make a lot of sense. Thanks for the insight. Any other questions? Is there a question? So I did, one other thing I'll say, and I didn't have any slides on this, but there has been some interesting work done. I know Thomas Graff is in this working group, I think, is that correct? Yeah. Yeah. Yeah, so anyway, they have an interesting work with CNI and with a circumventing part of the networking stack. In fact, the customer HP who I mentioned is actually using Istio with, sorry about that, with, I'm just getting a message here, of course. That always happened when I started talking with surveillance work. And I think that that's some other interesting, as you guys look at what's gonna happen in CNCF, that's the other area, like interesting area of development right now. Yeah, super, yeah, EVPF, super, super interesting. Well, it's like, I think Thomas is about the only one talking about XDP, man. Nebulin would suffer a little bit of challenge, well, not EVPF, but XDP suffers some challenges around later Linux distributions or later Linux kernels. But yeah, the performance numbers are phenomenal. The lower level layer of control that you can get by writing like an EVPF program. I think part of the challenge there is like, is the notion that some of those programs are lower low level enough that maybe not as easy to pick up as an SDO adapter or use something that's... That's right. And if we can get that right as an industry, which is, you know, SDO, especially with the Simflite adapter model, is an easy way to do an integration and will be the right way for most people. However, when people need to, for performance reasons or other reasons, do alternative things, there are ways to get deeper in and to integrate deeper in. I think that will be the right model. What Cillium is doing is very interesting. I mentioned before that one of the areas of interest for us is how much is the right amount of logic to push into the proxy itself? And then we have people who are looking at things in the assembly and whether or not there are easy ways to, or at least ideal ways to write logic that can be injected all the way down into the proxy. Anyway, but what Cillium is doing, and I think they've written kind of publicly about this case at HP is pretty interesting with respect. Yeah, I agree. Well, I definitely appreciate your time. We probably have other questions or comments that may bring you back to talk about a few other things with us and not too just in the future. But thanks for your time, Cillium. Everyone enjoy your question Tuesday. Okay, thank you very much for inviting us. I appreciate the opportunity. And yeah, I look forward to interacting with you guys in the future. Take care, bye-bye. Thanks, bye. Okay, see you then. Bye-bye, Dan. Okay, see ya. Thank you, bye.


In the year 2000, the United States ranked sixth in our human freedom index. It now ranks 23. So there's this, this is a particularly- Yeah, do you want to show that chart? Here's the ranking. We've got Switzerland, New Zealand, Estonia, Denmark, Ireland rounding out the top five, and then you go down US at 23 below Belgium and Austria and the United Kingdom. If you look at the graph of freedom in the United States, it doesn't look like the global, the global graph, it didn't, it wasn't increasing for 2000. That's one of the worrisome things that we found because you asked, why is there this increase? It's because all sorts of other countries are still increasing their freedom around the world. Not the United States. The United States is a very worrisome trend starting from around the year 2000 of a long-term steady decline in freedom that then with the global financial crisis, it accelerated. And we especially see that beginning in the year 2000 in the economic freedom side of things because of exactly the kinds of things that you mentioned. And out of the five different indicators in economic freedom, the broad categories that we look at, size of government, the legal system and property rights, sound money, freedom to trade and regulation, all of them saw notable drops during this period of time. Except that the rule of law indicator saw the biggest drop. It was a very big drop and that accelerated with the financial crisis, but that was already going on. And it really started with the beginning of the Bush administration. And we think that that's due to a lot of things, the wars, the war on terror, the war on drugs, the weakening of private property rights in the United States with the Kilo decision over a decade ago. I think that the financial crisis made things worse because there was a rise of crony capitalism or at least what people perceived as crony capitalism were industries and in fact, particular companies close to power got privileges and massive amounts of bailouts, even though that wasn't necessarily justified. And all of these things combined to weaken the rule of law because it's arbitrary and at the very least it's perceived as such. And when you have the rules of the game not viewed as fair, that's a real threat to other freedoms. But we did see other areas of freedom like government spending and monetary policy and freedom to trade start to go down as well. And this accelerated during the financial crisis, it started to recover some and with the pandemic it came down. Never did the United States recover its level of freedom that it had in the year 2000 when it used to rank at the top. Here's a breakdown of the analysis of the United States. As you mentioned, rule of law is at a meager 6.3 movement, 6.4 affected negatively by the pandemic of course, size of government, 6.8. What are some of the immediate steps that should be taken to reverse these trends and get the US at least back into the top 10 of freedom ranked countries? Well, I mean, there's a lot that can be done in terms of economic freedom. We're way below in economic freedom what we were in the year 2000 and that's in terms of free trade, in terms of regulations, in terms of sound money, and in every indicator we're below. And so all of those policies can be improved. The size of government is much larger today after Obama, after Trump, during the- After Bush, right? After Bush, it's just much larger than when Bush came in. If I may, in 2019, because this, when we talk about the COVID exception, 2019 spending, this was under Donald Trump and it was a record at the time, the federal budget spent for, or federal government spent $4.4 trillion. In 2020, it spent $6.6 trillion in 2021, 6.8. Last year, it went down to 6.3 slightly. This year, it's estimated to be 6.4. And this seems to vindicate the Higgs hypothesis of a kind of ratchet effect. So it's gone down from 6.8%, but it's much closer to that than it is to 4.4, which was already insane compared to Bill Clinton 20 years earlier. That's right. So I think that that hypothesis is still valid for the United States after these crises. And there were several crises during the Bush administration, which did help to increase government spending at a time, at least in the first part of his administration, where the Republicans controlled the Congress and the executive and that's oftentimes not a good thing. Yeah, and it's interesting now and not to get too into weeds about government spending in America, but when Obama came in in 2009, he of course, he won what was rightly considered a mandate at the time and the Democrats took, they had control of the House, but they took control of the Senate. He did have a blank check for two years and spending went up and they got everything they wanted basically and that elected a Republican Congress and then things started leveling off. I mean, I'm not a huge fan of divided government because it's at various points, it seems as if spending just keeps going up anyway, but at least in the late Bush years and the second half of Obama, things leveled off a bit because it seems a divided government put the brakes on certain speed. So behind all of these trends is how people view government and how people feel about society and politics and so on. And one of the things that we see is when you look at the global picture and you see the high point at 2007 and then it starts going down with the financial crisis, that's a period of time where you really see the rise of different forms of populism during this subsequent period of time all over the world, authoritarian populism of the left of the right and a lot of countries just taking over and then a lot of political systems having a bigger say in politics, including in liberal democracies has occurred in the United States. I would argue in both parties. What happened I think in the United States beginning during the Bush administration, which as I say had its own crises and expanded the role of government so it was reducing freedom is, if you look at the surveys by Pew and by Gallup, you see that over the past 15 to 20 years in the United States, trust in almost every institution in society starts coming down and it's hitting record lows on so many different institutions. We're talking about the media, Congress, the executive. Things like the Catholic church and philanthropies are actually also seeing a... These businesses, big businesses and other kinds of businesses. And so when there is a loss of trust in the main institutions in society that mediate interaction in society, you're in Latin American territory and that's when Trump came in. And I very much view Trump as a Latin American populist but I think that he didn't come out of nowhere. Something was going on in the United States that led people to think, hey, the rules of the game aren't fair anymore. We don't trust this institution or that institution. Yeah, and both he and Hillary Clinton, this was striking to me in the rhetoric in 2016, they both explicitly said the system is broken. They offered different reasons for why it was broken and what was broken in it and how they would fix it but it was fairly chilling. And I think on some profound level, accurate. I mean, certainly there's a reason why they were the candidates and they were both saying the system is broken. You can't trust the system. The system doesn't care about you. It's not watching out for you, et cetera. But of course, they took no responsibility for that system. Yeah, no, no, of course. They've been a part of it. I think that that's been a really big problem for, especially for the Democrats who have a lot of correct correct gripes about Republicans or Trump, they themselves have become at least a big part of the Democrats have become more radicalized but they don't take into account the role that their ideas had and continue to have in creating the political polarization. I very much see the political polarization in the United States and what's going on now as a legacy of Obama and even of Bush. So unfortunately, I don't think that there has been a great explanation so far analysis of why that has happened. And we can come up with a lot of plausible stories that I think can be compelling. But the fact of the matter is that this polarization and this rise of populisms either on the left or right or both has been going on all around the world in countries that are completely different from one another in terms of wealth, in terms of the political system, in terms of culture. I mean, we're talking about this happening in Mexico and Chile, two very different societies and in India and in Hungary. And the hardening of nationalisms and so on in Russia and in China, Turkey and in parts of Western Europe where major political parties have become radicalized or include very radical parties as part of their coalitions. Hey, thanks for watching that excerpt from our conversation with Ian Vasquez at the Cato Institute about the state of human freedom worldwide post COVID. You can watch our full conversation right here or another clip from that conversation right here and subscribe to Reason TV to get these conversations live every Thursday at 1 p.m. Eastern.


The plaintiffs, in most copyright infringement suits, are interested in money, in addition to or sometimes instead of the kind of injunctive relief considered in the previous segment of this lecture. In the United States, such plaintiffs are able to rely on three different principles when seeking financial recoveries. First, they can obtain, quote, actual damages, close quote. In other words, enough money to compensate them for the injuries they have sustained. Second, they can recover profits made by the defendants attributable to the defendant's infringing behavior so long as those profits are not duplicative of the actual damages sustained by the plaintiffs. Last but not least, instead of either actual damages or lost profits, plaintiffs may recover so-called statutory damages, sums of money that bear no necessary relationship to either the magnitude of the injuries the plaintiff sustained or to the profits wrongfully earned by the defendants. The first two of these forms of recovery, actual damages and defendant's profits, are conventional. Although the methods by which they are calculated in US courts are somewhat unusual, these two types of monetary recovery may be found in the copyright systems of most countries in the world and indeed are often granted to the victims of many other kinds of unlawful behavior, both in the United States and elsewhere. The third form of recovery, by contrast, is unusual. Relatively few countries currently recognize so-called statutory damages and there is considerable controversy over whether they should. I'll now spend about 20 minutes describing how these three types of financial recovery work. When I'm done, I'll step back from the trees and consider the ongoing debate concerning which dimensions of this forest make sense and which do not. The statutory authority for the first approach is contained in section 504b of the statute. As you can see, that provision entitles a copyright owner to recover, quote, the actual damages suffered by him or her as a result of the infringement, close quote. The purpose of this provision is to enable a successful plaintiff to recoup all of the money she lost because of the defendant's infringement. The most clear-cut example consists of profits the plaintiff would have earned had the defendant not encroached upon her copyright unlawfully. The conventional way of proving such lost profits by the plaintiff is to introduce evidence of the volume sales that the plaintiff likely would have enjoyed in the absence of the defendant's behavior, combined with evidence concerning the profit the plaintiff would likely have earned on each of those sales. A less well-established variant of this approach permits the plaintiff to recoup losses she sustained if she was forced to reduce the price of authorized copies of her work in order to compete with the infringing defendant. This component of actual damages certainly makes sense as a matter of theory, but case law support for it is thin. A recent addition to the set of types of actual damages is the so-called value of use theory. The idea underlying this variant is that a plaintiff should be able to recover from a defendant an amount of money equivalent to the license fee that the defendant would have paid to the plaintiff in order to obtain permission to engage in the conduct at issue. Somewhat more specifically, this variant permits a plaintiff to recover from the defendant the amount that a willing licensee would have paid a willing licensor for the right to engage in that conduct. In determining that amount, courts take into account such factors as the customs prevailing in the industry in question, the terms on which the plaintiff herself had previously granted licenses to other parties to engage in similar activities, and perhaps special circumstances that would have prompted the plaintiff to demand unusually high or low license fees. As I say, this so-called value of use theory is a relatively recent innovation. It was pioneered by the Seventh Circuit Court of Appeals in the Delthac case in 1985. The Court of Appeals for the Second Circuit, which as you know enjoys disproportionate influence in copyright law, initially rejected this basis of liability, but in 2001, in the case of Davis versus the Gap, the Second Circuit embraced it. A year later, the Ninth Circuit did as well. Nevertheless, the argument remains highly controversial. Critics contend that it fails to take into account the likelihood that if the defendant had been aware of the illegality of his activity, he might not have engaged in it at all, and thus would not have paid the plaintiff any license fees. In short, the critics argue, this theory gives the plaintiff a windfall. Finally, some courts have been willing to allow plaintiffs to recover under the heading of actual damages, sums of money necessary to compensate them for what might be described as indirect or collateral injuries. Included in this grab bag are such things as money, a plaintiff was forced to spend in order to modify her own product to compete with the defendant's infringing product, loss of goodwill because of the presence in the market of the defendant's infringing product, misled consumers into thinking that the plaintiff's version was not unique and ancillary revenue that the plaintiff may have lost because the defendant failed to give her appropriate credit for her creations. Either the plaintiff or the defendant may insist that these issues be resolved by a jury rather than by the trial judge. The way in which burdens of proof are allocated at trial is that the plaintiff bears the initial burden of showing a reasonable probability that there's a causal connection between the defendant's infringing activities and the plaintiff's injuries. The defendant then has an opportunity to rebut those assertions. If he fails to do so, the plaintiff is entitled to recover. The statutory basis of the plaintiff's right to recover the defendant's profits is also contained in section 504b. As you can see, that provision indicates that a copyright owner is entitled to recover, quote, any profits of the infringer that are attributable to the infringement and are not taken into account in computing actual damages. The last clause in this sentence prevents a plaintiff from using this device to achieve a double recovery. In other words, any profit the defendant reaped that derived from sales diverted from the plaintiff must be excluded from the plaintiff's recovery under this theory because they've already been taken into account under the heading of actual damages. As a practical matter, this exclusion means that the opportunity to recover defendant's profits is most beneficial to plaintiffs in two situations. First, where there are more than two competitors in the relevant market, and thus, that the defendant's profits were diverted not just from the plaintiff, but also from a third party. Second, where the defendant has a much larger business than the plaintiff and thus was able to sell many more products than the plaintiff could have done. Burdens of proof under this heading are allocated as follows. The plaintiff must introduce evidence of the defendant's gross revenues. The statute, as you can see, does not require the plaintiff to show that the revenue ad issue is attributable to the defendant's unlawful behavior, but the courts have added that important qualification to the plaintiff's burden. So what kinds of revenues count under this standard? The principle examples are those I just mentioned, namely revenues earned by the defendant from sales of an infringing product. What about revenues he earned from sales of related non-infringing products that were boosted in some way by sales of the infringing products? These are recoverable in theory, but difficult to prove. Occasionally, courts have also been willing to count under this heading, revenues generated by advertisements created and distributed by the defendants that contain infringing material. Usually, however, such recoveries are denied because the plaintiff is unable to establish a causal connection between the advertisements ad issue and the defendant's enhanced sales. Finally, revenue attributable to the enhancement of a defendant's goodwill caused by his sales of infringing products are, again, recoverable in theory, but almost never provable in practice. Of course, a defendant's gross revenue overstates the magnitude of his illicit gain. To determine his profit, we must deduct from his revenues the associated costs. For obvious reasons, the burden to introduce evidence concerning the magnitude of those costs is borne by the defendant, not the plaintiff. What kinds of expenditures may fairly be counted as costs? In answering that question, courts typically look to generally accepted accounting principles. An interesting nuance under this heading is that a defendant is permitted to deduct income taxes unless his infringement was willful. Intriguing issues arise when the defendant's product consists of a combination of infringing material and non-infringing original material contributed by the defendant. Under such circumstances, the defendant is permitted to introduce evidence showing what portion of the revenue generated by the composite product is properly attributable to his own non-infringing contribution and thus not properly payable to the plaintiff. Delicate and difficult questions lurk here concerning what features of products matter to consumers. Remember, for example, the controversy between the photographer Art Rogers and Jeff Koons arising out of Koons' use of this photograph as the reference work for this sculpture. As you'll recall, Koons' effort to excuse his behavior on the basis of the fair use doctrine failed. Rogers was thus entitled to damages. Included in the sum to which Rogers was entitled was the profit that Koons earned as a result of his infringement. Koons made a lot of money by selling copies of his sculpture. Specifically, three of the four copies he made were sold to collectors for a total sum of $367,000. A substantial portion of that sum represented profit. Koons argued plausibly that much of the profit was attributable to his own creative contributions, not to the value he derived from Rogers' photos. He also argued that some of that profit derived from a third source, specifically from Koons' artistic reputation. Koons is something of a star in the art world. The large amounts that collectors pay for his works are attributable in large part to the fact that Koons made them, not to their final form. In this particular case, Koons contended that Rogers did not deserve to share in that reputational premium. The Court of Appeals for the Second Circuit agreed. Here's the pertinent language, quote, on the subject of apportioning profits, the copyright law requires that Koons have the opportunity to establish those elements of profit attributable to factors other than the copyrighted work. These elements may include Koons' own notoriety and his related ability to command high prices for his work. To the extent that Koons is able to prove that the profits at issue derive solely from his own position in the art world, he should be allowed to retain them. We come finally to the controversial topic of statutory damages. Here's how they work. Section 504c provides that at any point before a final judgment in a copyright case, the plaintiff may renounce the recovery of actual damages and defendant's profits and instead opt to recover an amount of money set by a jury or the judge. How much money? The pertinent statutory provision sets forth some broad ranges but gives the decision maker lots of discretion and picking a point within those ranges. The currently applicable ranges appear on your screen. The default, as you can see, is between $750 per infringed copyrighted work and $30,000 per infringed work. If the defendant's conduct was willful, meaning that the defendant knew that his conduct violated the copyright statute, then the range is between $750 and $150,000. A lower range, as you can see, applies if the defendant's behavior was innocent, meaning that, quote, the infringer was not aware and had no reason to believe that his or her acts constituted an infringement of copyright, close quote. In other words, innocence in this sense has both a subjective and an objective component. To qualify for the lower range, it's not enough that the defendant was unaware of the illegality of his actions. It's also necessary that his misimpression have been reasonable. Who picks the amount of statutory damages within these broad ranges? Congress, as you can see from the text of the statute, clearly contemplated that, quote, the court, close quote, meaning the trial judge, would make that determination. But the United States Supreme Court, in the Feltner case, determined that the Seventh Amendment provides a right to a jury trial in all issues pertinent to an award of statutory damages under Section 504A, including the amount of the award itself. The upshot is that every time you see the word court in 504C, you should replace it with the word jury. What factors should the decision maker rely upon when setting that amount? The only guideline the statute itself provides is that it should be the amount that the court considers just. When after Feltner courts delegate this determination to juries, they usually instruct the juries to pick the amount the juries consider just. Sometimes, the judges suggest other factors that the jury could consider when making their choice, such as evidence of how much the plaintiff was actually harmed, the need to deter wrongdoing in the future, the nature of the plaintiff's work, and so forth. But these are just suggestions. Within the ranges set by the statute, the jury is largely unconstrained. If the defendant has infringed only one of the plaintiff's copyrighted works, say a novel or a musical composition, then, as we've seen, the maximum amount of statutory damages the plaintiff can recover is $150,000. But if the plaintiff has infringed two of the plaintiff's works, the amount doubles. If three, it triples, and so forth. The key variable, to repeat, is not the number of vacations on which the defendant has engaged in infringement. It's the number of works he has infringed. In some cases, that number is not obvious. For example, if I rip a CD containing 12 sound recordings, have I infringed one work or 12? For obvious reasons, it makes a big difference. The general standard the courts use in such circumstances is that the individual pieces are deemed distinct works if and only if they have independent economic value. In applying that criterion, the courts unavoidably exercise some discretion and often tacitly exercise that discretion in an effort to do rough justice. A crucial limitation on the availability of statutory damages is that, with narrow exceptions, they're only available if the plaintiff registered her work prior to the defendant's infringement. As you know from lecture number six, registration of a copyright is now optional in the US, but registration gives a copyright owner some advantages. The availability of statutory damages in case of infringement is perhaps the most important of those advantages. In addition to damages of these three sorts, parties who prevail in copyright infringement suits can sometimes recover their court costs and their attorney's fees. These amounts are not trivial. Attorney's fees in particular can be very large. Indeed, anxiety about possible liability for attorney's fees is often the principal driver that motivates settlements of infringement suits. That anxiety derives in part from the fact that both costs and attorney's fees are more commonly awarded in copyright cases than in most other types of suit in the United States. With respect to both costs and fees, the trial court is empowered to make awards, quote, in its discretion, close quote. The kinds of factors the courts look to when exercising that discretion include the strength of the losing party's substantive arguments, the stronger they were, the less likely will be the court to award fees, the legitimacy of the reasons why the losing party litigated the case, the need to deter abusive litigation by similarly situated parties in the future, conversely, the importance of not deterring legitimate efforts to defend legal rights or to resolve unsettled legal issues, and so forth. The same standards are applied when assessing requests for costs and fees made by prevailing defendants as when assessing such suggestions made by victorious plaintiffs. An intriguing variation on these themes suggested by Judge Posner in the Gonzalez case is that a judge should be more willing to award attorney's fees, particularly when the defendant's behavior was willful if the magnitude of the compensatory or statutory damages that the plaintiff could collect is modest, and thus, unless the plaintiff could recover such fees, she might be disinclined to assert her rights. Finally, it should be emphasized that attorney's fees, like statutory damages, are only available to copyright owners who registered their works prior to the infringement. This reinforces the incentive I mentioned a minute ago to register one's works. Underlying this rather intricate combination of rules are five general themes or objectives. Sometimes these themes reinforce one another, but sometimes they are intention. When considering how, if at all, the system of remedies should be modified, it's helpful to bring these objectives to the surface. When they conflict, it's necessary to decide which is the more important. The first and least surprising purpose is to compensate copyright owners, in other words, to indemnify them against loss. A copyright owner who has been injured by a defendant's infringement should be able to recoup from the defendant all of her losses. All four of the general theories of copyright law we have considered in this lecture series provide support for this first objective. Viewed through the lens of either fairness or personality theory, the rights that the law confers upon copyright owners are grounded in moral considerations, the moral right to a fair return for one's hard creative work, or the moral right to protection of the fragile bond between one's self and one's creations. Fidelity to those moral considerations requires, at a minimum, that copyright owners not suffer uncompensated injuries when their legal rights are abridged. Viewed through the lens of either welfare or cultural theory, the rights that the law accords authors and artists are designed to induce them to behave in ways that will advance some larger goal, generating and disseminating works that will advance net social welfare, or will foster a rich and stimulating culture. Authors and artists will not be so induced if they are exposed to uncompensated abridgments of their rights. So, as to this first point, there's not much controversy. The second of the objectives is the prevention of unjust enrichment. We don't want infringers to profit from their wrongdoing even if copyright owners do not suffer thereby. This is a very common sentiment, not just in copyright law, but in other fields as well. It looms large in contract law, for example. But despite its ubiquity, it's harder to justify and harder to connect convincingly to the general theories upon which copyright law rests. It seems connected to the same intuition that prompts us to recoil or object when a murderer writes a book recounting his crime and collects royalties from it. The third goal helps reinforce the somewhat shaky foundations of the second, deterrence. We want to craft remedies that discourage potential infringers from violating copyright owners' entitlements in the future. Litigation is enormously time-consuming and painful. A copyright owner forced to litigate can never be truly made whole. Thus, if possible, we want to deter people from infringing their rights in the first instance. One way to do so is to award and publicize monetary judgments that will make potential defendants think twice or thrice. The fourth ambition is punishment. Copyright infringement is wrong. We want to penalize the people who engage in it not just to deter similar conduct in the future, but because the infringers deserve it. Another word for this is retribution. Finally, copyright law, as you know by now, aspires to create and maintain delicate balance between, on one hand, the entitlements of creators, and on the other hand, the interests of the public in making use of their creations. The primary expression of the latter is the long list of statutory and judicial exceptions and limitations. Embedded in the copyright statute, the most famous of which in the United States is the Fair Use Doctrine. Against this backdrop, we want to craft a set of remedies that will maintain that balance. In particular, just as we want to ensure the copyright owners have appropriate incentives to assert their rights, so we want to ensure that users have appropriate incentives to assert their privileges. In this respect, copyright infringement is fundamentally different from homicide, say, or rape. In those contexts, we're not particularly concerned about over-enforcement. If someone is not entirely sure what constitutes manslaughter or sexual assault, and his behavior is, to use the legal vernacular, chilled a bit, we're not troubled. That such people are prompted to steer well clear of a vague line is not a serious problem. In copyright law, by contrast, chilling borderline behavior, in other words, discouraging people from engaging in activities that approach but do not cross the line of legality, is a serious problem. When setting and interpreting the rules governing damages awards, we want to avoid it. By now, the reason why these goals sometimes conflict should be clear. Goal number three, and even more so, goal number four, sometimes counsel larger awards than is optimal from the standpoint of goal number five. The context in which these considerations are currently most salient is statutory damages. Most countries in the world do not currently permit copyright owners to recover statutory damages. A thorough analysis of the law of each nation in this regard can be found in a forthcoming article by Pam Samuelson, Tara Wheatland, and Phil Hill. Phil, as I think you know, is one of the teaching fellows in the edX course for which these lectures were in part prepared. The authors of that study demonstrate that only 24 of the 177 member states in the World Intellectual Property Organization currently allow recovery of statutory damages, and very few of the countries that do have such regimes also have copyright-based industries comparable in size and health to those in the United States. The US is currently trying to change the state of affairs. Its diplomatic representatives are using various levers to try to induce other nations to adopt systems that resemble the system and force in the US. Why? Primarily because US-based organizations representing at least some copyright owners have asked them to do so. Critics of this initiative make three arguments. First, many countries, unlike the United States, regard punishment of offenders as an inappropriate function of civil damage awards. Punishment, they believe, should be left to the criminal law, to which we'll return in the last segment of this lecture. The reason why this is relevant is that over time, the US system of statutory damages has gradually taken on an ever more punitive role. Originally adopted primarily as a mechanism to provide compensation for copyright owners who have trouble proving the magnitude of the injuries they suffer, it now works in large part to penalize infringers. Many observers, especially outside the US, think that that's not a role for private lawsuits. Second, the critics point out that the broad ranges of permissible awards under the US system and the paucity of meaningful guidance concerning how awards should be set within those ranges give judges and now juries too much discretion and result, consequently, in unpredictable, even arbitrary, awards. Uncertainty of this sort is especially threatening to the delicate balance between private rights and the public interest. Third, and finally, some critics point out that the statutory damage system generates perverse results when applied in situations in which a defendant infringes a large number of works, each of which has only modest economic value. Because as we have seen, copyright owners are permitted to recover statutory damages for each work, the result is to enable them to recover amounts that dwarf the injuries that the copyright owners actually suffer. The context in which this unanticipated problem has proven especially serious has been file sharing. The large majority of the individual defendants who have been sued by the record companies for unlawfully copying and redistributing sound recordings through file sharing networks have settled the claims for modest amounts of money. But the few defendants who have not settled have incurred enormous awards. Jamie Thomas Rassett, for example, was found to have infringed the copyrights in 12 recordings and after a series of three trials, ended up, as you can see, with a damage award of $222,000. Joel Tenenbaum was found to have willfully violated the copyrights in 30 recordings and ended up with a damage award of $675,000. In both of those cases, the trial judges balked at the magnitude of the jury's awards. In both instances, the judges concluded that the awards were so large as to violate the federal constitution. In both instances, however, the Court of Appeals reversed, although the grounds on which the two courts of appeals did so differed. In the Thomas Rassett case, the Eighth Circuit rejected the defendant's constitutional argument on the following ground. Applying the Williams standard, we conclude then an award of $9,250 per each of the 24 works is not so severe and oppressive as to be wholly disproportionate to the offense and obviously unreasonable. Congress, exercising its wide latitude of discretion, set a statutory damages range for willful copyright infringement of $750,000 to $150,000 per infringed work. The award here is toward the lower end of this broad range. As in Williams, the interests of the public, the numberless opportunities for committing the offense and the need for securing uniform adherence to federal law support the constitutionality of the award. In the Tenenbaum case, the First Circuit concluded that the trial judge should have avoided the constitutional question. However, in so ruling, the First Circuit strongly intimated that like the Eighth Circuit, it believed the Constitution had not been violated. In both of these cases, the United States Supreme Court declined to review the Court of Appeals decision. As a result, we do not yet have a conclusive answer concerning the constitutionality of such applications of the statutory damage regime. And we're not likely to get a conclusive declaration in the near future. The net result is that the struggle over statutory damages will continue in the political arena. Reformers in the United States will seek to curb them. Skeptics in other countries will likely continue to resist them or more modestly to discipline statutory damages with guidelines more precise than the vague standards used in the US. By contrast, representatives of copyright-based industries in the United States will continue to defend statutory damages and argue for the adoption of the US model. I'll swear. How this struggle will end remains to be seen.


Why are calories eaten in the morning? Apparently less fattening than calories eaten in the evening. One reason that more calories are burned off in the morning due to diet-induced thermogenesis. That's the amount of energy the body takes to digest and process a meal, given off in part as waste heat. If you take people and give them the exact same meal in the morning, afternoon, and night, their body uses up about 25% more calories to process it in the afternoon, then night, and about 50% more calories to digest it in the morning. That leaves fewer net calories in the morning to be stored as fat. Let's put some actual numbers to it. A group of Italian researchers randomized 20 people to eat the same standardized meal at 8am or 8pm, and then a week later had them all come back to do the opposite. So each person had the chance to eat the same meal for breakfast and for dinner. After each meal, the subjects were placed in a calorimeter contraption to precisely measure how many calories they were burning over the next three hours. The researchers calculated that the meal given in the morning took about 300 calories to digest, whereas the same meal given at night used up only about 200 calories to process. The meal was about 1200 calories, but given in the morning, it ended up only providing about 900 calories, compared to more like 1000 calories at night. Same meal, same food, same amount of food, but effectively 100 fewer calories. So a calorie is not just a calorie, it depends on when we eat them. Why do we burn more calories eating a morning meal? I mean, is it behavioral or biological? If you started working the graveyard shift, sleeping during the day and working at night, which meal would net you fewer calories? Would it be the breakfast you had at night before you went to work, or the supper you had in the morning before you went to bed? In other words, is it something about just eating before you go to sleep that causes your body to hold on to more calories, or is it built into our circadian rhythm where we store more calories at night regardless of what we're doing? You don't know until you put it to the test. Harvard researchers randomized people to identical meals at 8 a.m. vs. 8 p.m. while under simulated night shifts or day shifts, and regardless of activity level or sleeping cycle, the calories burned processing the morning meals was 50% higher than the evening. So the difference is explained by chronobiology. It's just part of our circadian rhythms to burn more meal calories in the morning. But like why and what exactly is going on? How does it make sense for our body to waste calories in the morning when we have the whole day ahead of us? Our body isn't so much wasting calories as investing them. When we eat in the morning, our body bulks up our muscles with glycogen, which is the primary energy reserve our body uses to fuel our muscles. But this takes energy. In the evening, our body expects to be sleeping for much of the next 12 hours, so rather than storing blood sugar as extra glycogen in our muscles, it preferentially uses it as an energy source, which may end up meaning we burn less of our backup fuel, which is body fat.  That's where the inefficiency may come from. The reason it costs more calories to process a morning meal is because instead of just burning glucose, blood sugar directly, our bodies are instead using up energy to string glucose molecules together into chains of glycogen in our muscles, which are then just going to be broken back down into glucose later in the day. That extra assembly-disassembly step takes energy, energy that your body takes out of your meal, leaving you with fewer calories. So in the morning, our muscles are especially sensitive to insulin, rapidly pulling blood sugar out of our bloodstream to build up glycogen reserves. So at night, though, our muscles become relatively insulin-resistant. Our muscles resist the signal to take in extra blood sugar, so does that mean you get a higher blood sugar and insulin spike in the evening compared to eating the exact same meal in the morning? Yes. In that 100-calorie different study, for example, blood sugar grows twice as high after the 8pm meal compared to the same meal in the morning. So shifting the bulk of our calorie intake towards the morning would appear to have a dual benefit, more weight loss and better blood sugar control.


So this is the second part unit conversion videos if you haven't watched the first one You probably want to watch that because that sort of lays out some of the principles But now we're going to look at a couple more complicated problems and the first one we're going to look at is a volume conversion and in this case the particular things that I want to work with our leaders and Gallons Now you can probably look up some conversion factors but I happen to have one that related it back to cubic meters and 28.33 liters Is equal to seven point four seven seven gallons So if you have a conversion factor where neither side is one But you've got numbers on both sides of that we can still work with that So let's say I have an example where I've got 3.25 liters and I want to convert that into gallons So it is the same sort of process Where I look at okay, what do I have here on top is liters So I have to put that conversion factor the leaders one on the bottom and Then put the one I'm trying to go into which in this case is the gallons Up on the top the same thing happens here in terms of my units crossing out But now I have to be more careful with my numbers because I'm multiplying and dividing by numbers and none of those are one So over here my calculator app, which still shows some of my calculations from the first video I've got three point two five liters times seven point four seven seven gallons divided it by twenty eight point three three and That tells me that my final answer here is 0.8 five seven eight gallons summarizing three point two five liters is equivalent to zero point eight five seven eight gallons So that's what you do if you've got factors where neither one of them is a one So you have to both multiply and divide in order to get your conversion factors The next one that I want to go over as an example is what I'm going to call a double unit Conversion now that's not necessarily a standard title and in physics one of the common things where we're going to end up having this sort of situation is when I'm going to start off with something like a speed let's say 30 miles per hour and I want to put that into the standard physics units of Meters per second I'm going to have to convert miles to meters and hours to seconds So I need two different conversion factors in order for this to work and looking it up. We have that one mile equals 1,609 meters and One hour is equal to 3,600 seconds and that's because there's 60 minutes an hour and 60 seconds in each minute So that works out to be 3,600 seconds in an hour Now you can do this as two separate conversion problems or if we set things up with our fractions here What we can do is first work on the miles part of this and since miles is on the top the one mile has to go on the bottom and Then work on the hours part where since hours is on the bottom The hour has to go on the top In the end the miles cancel with the miles the hours cancel with the hours and I'm left with meters per second Now over here in my calculator. The way I'd actually put this in is 30 times 3,609 and technically divided by one even though the divided by one doesn't really make a difference times one divided by 3,600 and When I do that I get a final answer of 13.4 four Meters per second so I've gone from miles per hour into Meters per second by doing more than one conversion All in the same fraction looking at what's on top and what's on bottom to figure out where to place my conversion factors To get it into the final units. I want You might need to do a little bit more practicing to get comfortable with this But there's some examples for you guys to work with


Hi everyone, Joe Jaspy here with a brand new release 2021 top's clearly authentic baseball 20 box full case picker team number two big thanks to Everybody right here for getting in on the action Appreciate it. No fillers or anything like that Thanks everyone for making this happen All right We pulled some nice stuff out of the first full case break. Let's hope that trend continues in This full case And we don't have any more clearly authentic pick your teams for the time being Maybe we maybe we'll get another case or two in the near future, but for now Just only got a little bit of it We do have our final random box break in the store if you're watching live if you want to You got a little more appetite for clearly authentic all right one in case autograph acetate card per box Not on average It's just one guaranteed All right, here we go first one out of the gate is gonna be Wilson the contraris For the Cubs that goes to Jeremy Harder and the Cubbies Williams brother. I do like the acetate look. It's pretty sharp. All right next one is For the Expos that's Andres Galaraga, of course that goes to the Nationals Matt Johnson 61 out of 99 The big cat Andres Galaraga next up is an Oriole Dean Kramer Rookie autograph for the O's Joe Christian and the Orioles Next it's a Yankee. It's a rookie auto.  That'll be for Robert Flores We got some Giants Joey Bart four out of 50 Big big catching prospect for the Giants David Harrell big boys 007 could be future Buster Posey Buster Posey has been turning back the clock a little bit That Giants Dodgers series has been pretty great Another game tonight. We've got Jose Conceco a is 66 out of 70 Matt Medlin with Oakland landscape mode on this guy. It's Brandon Bielek 30 out of 50 Astros that's for Jackson and the Stroes Next how about some Padres? That's eight out of ten on that Padre that looks like That's Luis Petino. That is I Coppola with the Friars next one Ooh Ken Griffey Jr. Eight out of 30. That's awesome in that Alan and Ginter design Seattle Mariners Robert Flores with the M's It's a good-looking card. It's a question that Ginter Acetate design And we got Torrey Hunter. He's got some good penmanship there twins Jeremy Taylor With Minnesota halfway through this full case break Another ten boxes. Good luck everybody We got Kerry Wood for the Cubs Jeremy and the Chicago Cubs I think Fox Sports maybe did a great 30 minute or even hour-long special on his On that infamous game not infamous that famous game the 20 strikeout game pretty awesome Those throwing wiffle balls out there All right, then next we got shirt and apostle for Oliver Soria and the Texas Rangers nice rookie autograph for Texas Next we got Eddie Murray 29 out of 50 Old Oriole going to Joe Christian. It's Eddie Murray Then we've got Louise Castillo for the Cincinnati Reds Jeremy Taylor and the Red Legs Whoa, Jeremy Harder you were at that Kerry Wood game. It's pretty awesome You I think you'd get a kick out of that that little not really a documentary, but just a look back on that It was a nice episode a lot of a lot of a Lot of good first-person accounts with Kerry Wood. They got a good interview with him to talking about his game There's Scott Rowland to 50 Ben Smith with the film. What can you tell us about that game Jeremy? Was there a feeling from the get-go that it was gonna be a special game or was it just kind of one of those games where you Blinked and you were like wait a second. This guy's got 15 strikeouts already Trevor Rogers Nice Trevor Rogers autograph for Miami. He's been having a solid season real great season Michael with the Marlins Next one is a met. That's Andres Jimenez last spot mojo strikes again Jackson Last spot mojo. I'm telling you 70% of the time hits 100% of time was awesome Wish Harry would have been there. Yeah, I've been cool game for Harry Kerry to call. Yeah, that's it That's I can't believe he gave up a hit If he had if that ended up being a no-hitter that might have been one of the greatest no-hitters Of all time. I think this goes this way We've got Tanner Hawk rookie auto for the Red Sox. That's gonna be Richard in the Red Sox and Two more to go and that's a Juan Soto. Nice Matt Johnson with the nationals nice Juan Soto and the 20th box Final box here in 2021 Clearly authentic baseball pick your team to I don't think it was Jerry. I don't care. He was not numbered Last one is gonna be the wizard Ozzie Smith 34 out of 99 That's a really good-looking card for the Cardinals the X line With the red birds and there you go boys and girls that was 2021 tops clearly authentic baseball 20 box Pick your team number two. I'm Joe Jaspie. I'll see you next time for the next break. Bye. Bye