Can you hear me now? So this might be boring for people who aren't lawyers. It might be boring for people who are lawyers. But something I was really interested in. It could also be terrifying for non-lawyers, too, I suppose. Sometimes non-lawyers find contracts really scary. So I'm going to talk about the on-popular open source licenses. Just to get off, I am a lawyer, but I'm not your lawyer. Looking around the room, I'm pretty sure I'm definitely true I'm not the lawyer for anyone in this room. This isn't legal advice, nor is this presentation intended to be comprehensive. It's only 20 minutes long. And these are my opinions, not the opinions of my employer. You can tell because even though my employer paid for my trip, I didn't use their slide deck. So you don't know who I work for. So OSI category has about 83 open source licenses that they've approved as being open source. And they categorize them. And if you go to their list of licenses, they identify which ones are the popular licenses. So these are the licenses that I think everyone's pretty familiar with. There's a reason why they picked them off Apache, the BSDs, a subset of the GNU licenses, MIT, and the Mizzile public license. But there's actually a lot of other licenses besides that. So if you dig a little bit deeper, they've got other categories of licenses too. It's just informational about how these things are. But there's licenses that are international licenses, special purposes licenses, miscellaneous licenses, uncategorized licenses. Licenses are involuntarily retired. The interesting thing about this is that a lot of these categories are kind of meant to indicate to people. I'm like, don't use these. Superceded, non-reusable. The problem that I see a lot in contracting, my company only provides professional services. And we only provide professional services around free and open source software licenses. So typically when we have a contract, they're going to mention the use of open source licensing. And in those contracts, typically what they do is they just talk about open source generically, or open source as approved by the open source initiative. And this is a pretty typical one. If anyone uses AWS, you agree to this clause where it says that some of the material is going to be provided to you underneath a separate license, and it's an open source license, and that you agree to those terms. When I see that in a contract, I try to read all of the resulting material, but this basically sweeps in anything that counts as open source. Now for this particular clause, they don't even say as approved by OSI. But I also see this pretty typically in contracts as well where they say you can only use source code that's distributed underneath the terms of a license as approved by the open source initiative and listed on this website. But there's a lot of them there. So my question to myself was like, why do I keep agreeing to all these licenses if I've never read them? I should actually read all of these licenses. So I went through and that's what I did, and I pulled out some of the things that I found those licenses that kind of surprised me. Things that I don't really think about when I think about an open source license. I've got my idea of what it means to be open source. Yeah, there's the open source definition, but I also have my theories about how you can deal with those things. Now it doesn't actually line up with all of the open source licenses that are approved by OSI. Certainly not all of the licenses out there that are substantially similar to them or that people call open source. So I'm gonna focus on the licenses, the properties of licenses that aren't popular or things that I think were kind of surprising there. So all of these licenses have met the open source definition or at least OSI at one point said they did. I'm not sure if all of them would be approved again because the way approval happens has changed over the years. So some of these are older licenses. But my goal here is just to give you a sense of when you say that you're agreeing to, that you're okay with an open source license or you'll take material underneath any open source license approved by OSI, these are some of the terms that you might be agreeing to. So the first thing I wanted to point out just to tell you that there might be some really surprising things here is what kind of material do these licenses apply to? Now two really popular licenses, the AGPL and the Attachee 2.0, they're not surprising, right? AGPL applies to any copyrightable work and Attachee 2.0 applies to anything that's a work of authorship. Now at least underneath US law, those are basically the synonymous. Those terms mean basically the same thing. But if you look at other licenses out there, they're not that broad. So some of these licenses only apply to software and they leave software undefined. So it's written in English so it's gonna be the common meaning of the word software in English, right? If you're using the zero clause BSD license, you can't license anything underneath zero clause BSD that's not software. Same thing with the IFC license. I don't think those two licenses are particularly uncommon actually. They seem to get used a lot even though that's not things that people usually think about as examples, but they're widely used. There are less common licenses, the adaptive public license, which I know there's software out there that's using it although I've never come across it in my job. That only applies to computer programs, whatever that means, they don't define it. And the CESA license, which maybe is more popular outside of English-speaking jurisdictions, only applies to software and documentation. And then you have other licenses that are really specific, right? Licenses, these are the non-reusable ones. The framework license only applies to the framework's code base, whatever that is. They don't actually define that, right? But there's a license that you can't actually reuse anywhere else. But it's out there. So and some of these licenses are there. So you can't actually just pick up any of the OSI approved licenses and use them at anything because if you tried to license your material underneath the framework's license, you wouldn't be licensing anything all because you're not frameworks and you can't make the framework's code base. So in general, what are these licenses applied to? Well, I think there's probably three categories, right? There's the licenses that apply to all copyrightable works, right? Which is what I typically think of. You can apply these licenses to anything. But then there's also the licenses that only apply to software and documentation. And sometimes that actually gets a little hairy because we'll talk about those associated things that get sweeped up in there. And then there are the licenses that just apply to software. So I know it's a common practice amongst open source projects to say, well, just put everything in the Git repo and we'll apply one license to it. We don't need to worry about how we license the documentation. But if you're using a license that only applies to software, you're not actually giving a license for that documentation. Or if you're writing a video game and you wanna have an open source video game, typically what I expect out of the video game, right? Is that you've got the game engine. That's the software. And then you've got the levels and all of the character art.  So you actually do have to look at these licenses and their scope a little bit more. So just don't assume that all the licenses operate the same, is my point here. And I'm gonna show you some reasons why as we go through this. It's similar for the material that applies to is the rights that are granted. I tend to think of all open source licenses providing you basically the same rights and the differences between them will be the conditions that are placed in those rights. But that's not actually true. So the Apache license, again, it's a pretty prototypical example. They grant you a copyright license and a patent license. And I'm not gonna get into like patent versus copyright license kind of stuff that people talk about or these lawyers talk about. But it gives you all of the statutory rights underneath US copyright in these licenses. So you can pretty much do whatever you want. But then there are other licenses out there like the fair license, which literally says usage of the work is permitted provided that. So the only thing you can do with material provided underneath the fair license is usage. What does that mean? I mean, I would actually say it means you could use it and that's not the same thing as modifying it. It's not the same thing as distributing it. It's not the same thing as making copies of it. So if you're actually gonna look at that text of that license, like the conception of what you can do with OSI approved license software, it's pretty wide ranging here. It doesn't mean that you can actually modify it. Now, I think probably at the time that they approved this license, there was an idea that this actually meant that you could use it for many things including modifying and distributing it. But my question to you is gonna be that happened. I think this license was approved about 20 years ago. When you bring this in front of a judge or if you get into a contract dispute with your partner in this or the person you gave it to you, like they might have looked at the word usage and thought the word usage meant usage. And that's not what it means or not what OSI thought it meant when it was approved. There are other licenses that are a little bit more complex. So maybe the fair license is so simple you can say, well, that's clearly not what usage meant. It has to mean those broader rights. But when people get more specific about what they mean for those rights, it's a little bit harder to make that argument that they were just being sloppy with their language. So the open group test suite license says that you can modify it, sure, but you have to keep the original test modes are being preserved, right? So you can make modifications to this but you have to leave the stuff that's already there in place. You can't remove stuff. And they're really specific actually about this, right? So if you make modifications to it, you have to make sure that the executables that come out of it have a different name so they can't conflict because you have to leave the originals in place underneath the original executable names. And on top of that, you're required to write documentation on it, right? So I'm pretty sure that everyone's who's software developer in this room has never written a piece of software and then failed to write documentation at the same time, because we all know that's the best practice and we would never do that but you might have some colleagues out there who are a little sloppy and they don't write documentation. But here's a license that says you're violating the open source terms if you don't write documentation, right? There's also licenses out there that remember, these are only licenses that have been approved by OSI, right? So I know there are other popular open source licenses out there that are similar to this one that aren't approved by OSI but this one's been approved by OSI. The QPL from Trolltech, I think this was, QT was distributed on it for a long time, so a pretty popular package that says you can copy and distribute the software in an unmodified form, right? That's a right, of course you can do that, right? You can make modifications to the software and you can distribute your modifications but only as patches, right? So you can't actually distribute your modified software, right? You can't just put that in place. You've got to distribute the unmodified software and then patches along with it, right? That, I don't think that's a normal expectation. So there it's fulfilling the expectation that you can modify it but it's being really specific about how you can distribute those modifications. So I'm not gonna read all the licenses to you and I'm not gonna list every license but I just wanted to go through some surprises there. So one of the things I think is most surprising and most concerning to me is when there's restrictions on the use of the software because I tend to tell people, like well what's open source software? I'm like well open source software is software that you can use without any kind of restriction. Like that's literally what I tell people when I talk about this stuff and then there might be restrictions on like modification or distribution but you can use it for anything, right? Well the frameworks license has a restrictions on use of if you're gonna provide services around this they actually specify how much money you're allowed to charge for those services. It's gotta be a fair market value license. Now the first time I read this I thought like oh that's kind of like a cap you can't charge too much. Then I thought wait, if I was actually the licensor maybe that's a floor because maybe I was trying to create a market for it where I said well I wanna provide services and I don't want someone coming in and undercutting my prices so if you're gonna sell services you at least have to be selling the services for at a price that would be worthy of business for me. You can't knock me out of the market by giving services away for free. This is in an OSI approved license. And then restrictions on use too. I think most people think of the network copy left license as having a restrictions use, right? If you're using your open source software and a cloud platform that SaaS, right? Software as a service. I can't remember the acronym that the meaning for free software foundation uses right now software as a slave or something like that I'm sure. And I'm like they think of network copy left licenses like oh if you use this that means that you have to share the source code and the example they always point out is the aphero general public license. Well I'd like to make one thing clear here. All of the licenses, there's 10 licenses that I would classify as network copy left licenses. Of those 10 licenses there's actually one license that doesn't actually have conditions on the use of the software and that's the aphero general public license, right? The conditions on the aphero general public license actually have to do with modification of the program. If you modify an AGPL program and then you use it to provide a SaaS service that's when you have to offer that source code. But if you don't modify it you don't actually have to do that, right? So it's not a restriction on use but those other nine licenses those all do restrict your use of the software. If you use that software to some degree you need to provide a source code. And some of those are actually really kind of interesting. The open software license which I think is really interesting because if you look at this large ecosystem of the license here there's a lot of derivatives of the open software license out there. This is really influential at least for lawyers who wanted to make their own at least in a period of time. And they make it clear that external deployment means using the software. If you use that software you offer that software someone else to use you need to distribute your source code to them, right? And it's on use, it's not on modification. There are other licenses that do it too and how they get this scoping out there, right? Because there's some criticisms of the AGPL license about well it's only to people who access the software. Well what does that actually mean? Is there a way of getting around that? The European Union public license at least version 1.2. Just a caveat on this as well it's not a criticism of OSI. I appreciate the people who are on that board are doing this volunteer and it's a very hard job. I'm on boards and nonprofits as well. I was only looking at licenses that have been approved by OSI and are also listed on the website. So I think the EUPL has, 2.0 has also been approved but it was not listed on the website at the time that I made my list. I don't know if that has changed because I made my list a couple months ago. So version 1.2, if you provide access to the essential functions of the software to anyone you've got to give them a copy of your source code. All right, so there's a way of shading who you have to give this to it. So it's not just people you give copies of the software to, you have to provide source code too. It's not just people who are accessing the software but if they have access to the essential functions of it. So if you think about like the MongoDB disputes right now if anyone is following that, that's the essential functions, right? Like that might actually be a little bit broader than what they're proposing underneath the server side public license.  The reciprocal public license has an even broader one. Modifications means, so the scope of the software here they actually go beyond just the program that you're talking about. It's not just the program that's licensed under the reciprocal public license. You have to provide source code too. But you have to provide the source code to any program that replaces or otherwise alters the original functionality of the licensed software. So if you've got another program running side by side with your reciprocal public license software that is somehow modifying its function, right? Like maybe it's closely related to the APIs or you're doing a callback or something like that. You can kind of expand the scope of this copy left software distribution requirement. Now I don't know if that's a good idea. I think there's probably a reason why a lot of people haven't come across reciprocal public license software. But it's out there as an OSI approved license. So if you're really interested in making sure someone's distributing all of the software that they use to host your software, you might want to distribute only through reciprocal public license. I suspect not a lot of people will use your software at that point because they're scared about that scope. But there's an OSI approved license out there for you to use. Now just to get to the stats, I don't plan on getting through all of my slides because I went through and had a fairly comprehensive spreadsheet until I got bored and gave up keeping track of things. But here are some things that I thought were interesting about these OSI approved licenses. And I say over because towards the end around license 75, I just stopped updating my spreadsheet for common things. But there are over 30 OSI approved copy left licenses that are copy left. I actually think it's probably about 50-50. So the idea that copy left isn't popular, it's not true. Most businesses who are writing open source software licenses are making them copy left. Copy left is what businesses want. Over 24 of these licenses have a choice of law clause. So for those of you who aren't lawyers, that's determining what jurisdiction's law is gonna apply, right? So if you use this license, you might be finding out that you're subject to the laws of the Netherlands. Even though you've never been to the Netherlands. Or Japan, if you're using a particular font. Over 18 of those have a hard-coded specific jurisdiction. 19 of the licenses have a choice of venue. That means the court that you're gonna have to bring your cause of action in, where you can sue, right? You might find yourself, even though you've never been to Colorado, you've never been to the United States, all of a sudden you find out that if you wanna sue to enforce your license, like if you use the reciprocal public license, you've gotta go to Colorado to bring that lawsuit. Which would be weird, right? If you're suing the guy down the street from you in Belgium and you've decided you both mutually agreed that the only court you're allowed to use are the Colorado courts, a little strange. And there's, I thought this was kind of weird. There's one license approved by OSI, and this isn't really a problem. Like I think this is fine. That doesn't have a warranty disclaimer. And I just kind of like assumed warranty disclaimers were universal to all open source licenses. And I wasn't even keeping track of it until I came across this one. I was like, oh, maybe we should start reading these warranty disclaimers. So here's a list of the jurisdictions that I found amongst those licenses. I won't read them all. New York was the most popular. I thought California was gonna be in the lead for a while, but it turns out New York was the most popular. And these actually really matter. So some of these jurisdiction selection clauses don't actually just apply to the license. But one of them says any action or suit relating to this license, right? So that could actually be like on your contract claims, your personal injury claim. Like if you're using a piece of hardware that's running open source software that's licensed underneath the open software license, and it injures you, right? It's a lawnmower because lawnmowers are gonna have free software in them now if they don't already. All of a sudden you have to sue for losing a finger in whatever jurisdiction that the open software license actually defines. Some of these jurisdictions can be modified by the licensure, they just kind of, that little default to one location, but a lot of them can't. And it's a very similar situation with venues. This is actually really interesting. I do, my company does a lot of contracting with state and local governments in the United States. So there's some interesting things there. So some of these jurisdiction selection clause and venue selection clause depends upon who you are or your role there. So underneath the European Union public license, you'll actually pick the law of the country where you have a presence. And if not, it defaults to Belgium. Which I thought was, you know, that actually kind of made sense. Rico, when they wrote their public license, they had a pretty normal clause. I'm like, well, we're gonna do this in California. You can only sue us there. That's where all the lawsuits are gonna take place. But specifically, Rico can sue for an injunction anywhere they want, right? So they can come after you and stop you from doing stuff. But to resolve the ultimate dispute, you have to come to California, right? Cause why not make yourself privileged? So just reading these things are actually kind of interesting, right? Like you can't just look at the conditions that you're dependent upon. You also have to look at the more legally boring kind of stuff. Same thing with warranties. No license to the original work is granted except underneath this disclaimer. Well, what's interesting about that is that jurisdictions actually restrict what kind of warranties you're allowed to have. And they might invalidate your warranty if it's too broad. Some jurisdictions will say that if you disclaim a warranty so broad that personal injury and death can't be compensated, you're not warranting against that, then you gave no warranty at all. Well, if you gave no warranty at all, you don't have a license, right?  So maybe we need to pay attention to those a little bit more. I know I'm getting close on time here and I don't plan on getting through slides, but there's other interesting things here, too. Third-party beneficiaries, that's not a thing underneath open-source licenses, right? The only person who can sue to enforce is the copyright holder. Well, unless you're using the adaptive public license, in which case recipients, any recipient of the software can sue any other recipient of the software. Or if you're using the NASA open-source agreement, in which case the United States government is allowed to sue you. Anyone like jury trials? Don't use the Eclipse public license version one. Like you won't be having one. There are some other weird things, too. I won't go through these in detail. Attribute requirements, if you're using the attribute assurance license, you've got to sign it with a GPG key, which I thought was kind of weird. So that's my time, but I just wanted to kind of make the point of when you're using open-source licenses, read it because you might be surprised at what you're agreeing to.


The CTK is a great idea. It provides a convenient automated conformance verification mechanism for API implementers. However, when we tried it, we noticed a few major loopholes in the conformance verification because of architectural issues. And we believe the CTK can leverage specmatic to address these problems. In this video, we will be going over major issues with CTK 5, which makes it ineffective in testing the conformance of API implementations. Let's begin with a quick demo. This is the party management API version 5 on the TM forum website. I have downloaded the open API specification, the CTK and the sample implementation code from here onto my laptop. Here I have the sample implementation code running on my laptop. Let's execute the CTK and see what happens. The tests are passing. The CTK ships with an open API specification for this API. Let's open that in postman and try to execute one of the requests. Here's the post slash party API. The base URL has been configured in a postman environment variable to point to the application that's running here on my laptop. As a sanity check, let's just send this request to the application and see what happens. Okay, we get a 404. And that means that the application has not implemented the slash party API. But that means that the application is in fact not in sync with the API specification that we just imported. But how can that be because this is the specification that comes with the CTK and we just ran the CTK and we saw all the tests passing, which should have meant the application is in sync with the specification and has implemented all the APIs in it. But very clearly it has not. So to understand how this could come about, let's spend a little time digging into the architecture of CTK 5. TM Forum provides an open API specification, the first source of truth on its website, and the CDK for conformance testing. CDK v5 at its core leverages Cypress to test the API implementation. CDK v4 used to use Newman. There's a report generator that generates the report published for the conformance process. But it also contains its own copy of the API specification, which is another source of truth. And this is the first problem. There are now two sources of truth and they can diverge. In fact, just a minute ago we saw how the CTK specification for the party management v5 API was out of sync with the sample application. Now let's compare the specification on the website for party management with the specification that shipped with the CDK. This is the API specification for TMF632 v5. If you look on the left, you'll see APIs like Hub, Individual, some listeners, and organization related APIs. Now let's take a look at the API specification that ships with the CTK for this API. And this time you see a very different set of APIs. The individual and organization APIs are completely missing. And there's a new pair of APIs here for party, which was not there before. It's clear that these are two different sources of truth and that they've significantly diverged from each other. Now, coming back to the architecture, we realized upon deeper inspection of the code that this is not the only issue. The next piece of the puzzle in the CDK is the changeme.json file. This is where we define the application URL and also provide the payload sent in the request. The request that we provide here is not validated against the open API specification and hence can be out of sync with the spec. This is problem number two. The Cypress test directly sends these requests to the application and only verifies the response against the schema in the CTK's copy of the open API spec. Now, the Cypress test itself is a third source of truth because it does not generate tests based on the open API spec. It has actual logic in it. As a result, the test implementation duplicates a lot of the details that are already present in the open API spec, which is problem number three. All this means in the original open API specification, only the response schema would be verified. All other aspects like request parameters, error responses, property such as optionality, nullability are not getting verified at all. Substituting the Cypress setup with Specmatic can solve all these problems. In our proposed architecture, the API specification on the website would be the primary source of truth. The Cypress tests in the CDK would be replaced with Specmatic. Specmatic reads a configuration file called Specmatic.json and gets from it the link to the specification on the website. This would be the only specification in use, thus addressing the first problem of duplicate specifications. The CDK would also contain a directory with test data.json files containing the payloads for making requests. Specmatic would validate these payloads against the specification before using them, which addresses the second problem of unvalidated responses. Then for every API in the specification, Specmatic would run contract tests using the validated payloads and would validate the responses again using the specification. Now, while the Cypress tests set up hard codes, the API definition, thereby duplicating the OpenAPS spec, Specmatic instead generates the tests based on the OpenAPS spec in a completely no code manner, thereby totally avoiding the duplication and in the process immensely simplifying the architecture. As a bonus, Specmatic can stub out other dependencies of the API so that the conformance of the API can be tested end-to-end in isolation. Specmatic can even do fault injection to make sure the application can handle timeout and other outages from its downstream dependencies. Let me now demonstrate the issues that we've pointed out in the CDK and how Specmatic can address them in a side-by-side comparison. We'll be using the OpenAPS specification CDK and sample implementation for TMF 642 version 5 provided on TMForum's website. Let's say a developer makes a change to the application, which is incompatible with the specification. To show what might happen, we've modified the TMF 642 sample application to require a new key called recurrence. Here's the create alarm controller, which handles the post slash alarm API, and here is the code that throws an exception if the recurrence key is not found in the request. Here I've got the application running on my laptop. Let's run the CDK and see what happens. Here 22 of 73 tests have failed. Now if this key is really needed, the right way to fix this is to get the specification updated. The wrong way to fix this is to directly update changeme.json and add the key, which is what we've just done. We'd expect the CDK to catch this and as a result, tests should fail, giving the developer feedback. Let's try running the CDK again. Okay, we have 73 of 73 tests passing, but clearly this means that the CDK has not realized that the request payload does not match the specification. And then this in turn means that the application is out of sync with the specification despite passing all the CDK tests. Now let's put this same payload into this file for specmatic.json to read. It's the same payload from changeme.json, including the extra recurrence key. And now let's run specmatic contract tests. There you go. Specmatic validated the payload against the specification and immediately complains that the recurrence key is not in the specification and thus the test fails. Specmatic simply does not accept a payload that diverges from the request schema in the OpenAPS specification. Another issue that may not be obvious at first glance is that the CDK only verifies two execs responses. The four execs response schema goes completely unverified. Since the CDK is already passing against this application, let me run specmatic directly with generative tests switched on. With this feature switched on, specmatic actually sends specification invalid requests that are intended to trigger the four execs responses from the application. Let's see what this looks like. Let's take a closer look at the test that triggered this error. All right, note that type here was passed as null by specmatic. Specmatic did that because it knows that type is not supposed to be nullable. It's just a string not nullable. And so it actually created a request with null in the type. And so the application has returned a 400 bad request. But there's something wrong with the response. Let's make a note of the keys here. There's message and there's errors. And the concern is that at type in the specification was not in the response, code was also missing, reason was missing. And there's an extra key in the response. Key named errors was not in the specification. So let's turn to the specification itself to see what 400 responses are supposed to look like. So let's look at this. Right enough code and reason are mandatory keys they were missing in the response. Let's check here. Yes, right enough at type is a mandatory key as well. And it is missing in the response. And the errors key in the response was not in the 400 response here. So specmatic has correctly identified the problem with the response. And it has picked up on this because it actually triggers and validates 400 responses, which the CDK does not. Now for this next demo, I've switched off request validation in the sample application. Here's the code where I've done that. Now let's run the contract tests with generative tests switched on. We see expected 4xx status but received 201. But the question is why would specmatic be expecting a 4xx status? For that, we have to look at the request because 4xx is an error that means bad request. So we can see here type null. And we know now that this is a specification invalid request because at type is a non-nullable field, as we have seen before. So the application should be returning a 4xx response, but it's handling it and returning a 201, which makes it out of sync with the specification. And this is even worse than returning 4xx that does not match the specification, which is what we saw earlier when validations were on. Specmatic discovered this through the attempt to trigger the 4xx response, but the CDK misses this issue completely. Let's also review the API coverage summary provided by specmatic after the contract test ran. This is a list of the APIs in the specification with their test results. And here's a count of the APIs that have not been fully implemented. And here's a very crisp summary of the test results as a single value total API coverage, which represents the percentage of APIs that adhere to the specification. In addition to these issues, the CDK today verifies a subset of paths for TMF 642 and others that we've checked, and it does not verify aspects of the request such as optionality, nullability, etc. So to recap, the CDK's core responsibility of verifying conformance suffers because the source of truth or API structure and behavior is duplicated several times. TM Forum can address all of these issues by simply replacing the Cypress API test setup with specmatic contract tests, which we believe is the more suitable tool for this use case.