So, good morning. Welcome to the first session of today. And we are going to start with a keynote from Malcolm Bain, who is going to tell us a little bit about the legal aspects of the software that we write and use.

So, I give the floor to you, Malcolm. Thank you very much Joanna. This is a difficult task. It's a keynote on the second day. You've all woke up very late. You have a hangover. You probably haven't had your second coffee yet.

And half of you are still having breakfast somewhere. So, we'll see what we can do. Especially, it's the legal terms in the middle of a technical conference. So, the interest is probably pretty low. I'm going to have to bend down all the time, because I'm a little bit tall. And that microphone is a bit low. Can you hear me? Yes. You can? Okay, good. You can hear me. Okay. So, if you're not really interested in the licensing issues,

it's great to have an extra 40 minutes of sleep. Or go back and have some more breakfast. I was invited here because I gave a talk last year. Was it the year before, Joanna? I live in Barcelona. I'm English. Although, I have big doubts about being English at the moment.

Anyway, so I live in Barcelona, which is obviously a good reason for thinking about that. And then, I go to Girona. Who's been to the Sig Libri in Girona? So, you've probably seen me before. Some of you may have seen me before. Because I try and go every two years. I like the wine and the food in Girona. It's good. Anyway, so I was invited because Joanna saw me there.

And said, I think it would be quite interesting for the Phosphogee Europe to have some ideas. Because, obviously, you obviously get everything wrong. I heard people talking about licensing in the corridor. They got it all wrong. And you need to get things straight. I say this because I'm a lawyer. And all lawyers obviously know that they know better than everybody else.

So, it's not quite true, actually. I find that most of the engineers I speak with know a lot about open source licensing. And sometimes they know more than I do, which is really good. Anyway, so, thank you very much for the keynote. Give me lots of time. Usually, I give them ten minutes. So, you're going to have to put up with me for at least forty.

I'll try to make it thirty because we're starting a bit late. Anyway, so licensing. Basically, I want to run through the licensing. And this is not really going to be a class. I'm not giving you a class. This is a conference. So, I have a first question for you. Do you know these guys? Silence in the room. Come on, guys. You're not that young.

The one on the left with the hat? Clint, you know that. The one with the glasses? Oh, more difficult. He's called Sergio Leone. And the one in the conductor? Hey, you put Clint Eastwood and Sergio Leone together. And what do you get? Ennio Morricone, thank you very much. Do you know what had anything to do with open source?

Silence in the room. Come on, I need some lateral thinking here. No, not yet. I'm sorry to say that Ennio's music is not under Creative Commons, ShareAlike or any other form of open source licensing. I think Warner Brothers or whoever it is, or some label would be very cross with you if you put it to the background, to your startup,

when your GC is actually starting up and you put a bit of the mission, you know, get everybody motivated. I think he'd make a big cross. Anyway, no, these guys, these guys, these were the precursors of open source licenses. They have been supporting open source for a long, long time. And my mission today is to explain a little bit why this is.

It's also to make this a little bit more interesting than giving you the fact that the BSD has three clauses and the GPL has five pages and the clause 2B of the GPL 2 is the copyleft clause, which we all know, so I'm not preaching it, okay? These days, if you go to these consultants,

they talk about best practices or they talk about challenges and deviations that have to be corrected, yeah? Or they talk about risk management, okay? In the old days, it was much, much more simple, yeah? They called a spade a spade and they said, hey, the good, the bad and the ugly, okay? So what I'm going to talk about a little bit,

is the good, the bad and the ugly in open source licensing. Especially the ugly, I'm a lawyer, we always look at the dark side, we always have this bad habit of saying, what if, you know, everything goes wrong, that's when we get money, we get paid when everything goes wrong. So we really like the ugly, the ugly is my hero. Anyway, the good, obviously, we don't want to speak about.

Anyway, so the good, we all know this guy, we all want to imitate him, style. The good thing about open source licensing, well, the good thing about open source licensing is that we have freedom. We all know that, we all know the four freedoms, to use, to study, improve and share. Richard Stallman would be a little bit cross with me, because this is not really what he said in 0-1-2-3,

but it's basically the four freedoms. And we all know that these freedoms are expressed in the licenses. So, obviously, the licenses are a key feature of open source, because without a license, you don't have open source. Quick question on that. No, I'll ask it later, okay? Anyway, so the result of this, the result of this,

the other good thing is obviously we have free software projects. Anybody participating in an open source project, free software project here? Yeah? Who's not putting up their hand? Yeah, I thought so, everybody. Okay, we have free software communities, are we a member of a community? We all are, we're all here, okay? We do hackathons, anybody participate in hackathons? Good fun. And anybody had free beer?

Ooh, that's much more difficult to get. Yeah, well done. Tell us the secret. Oh, excellent, okay. Which country would that be so I can visit it for the summer? Ah, excellent. Anyway, so look, the good thing about the licensing is we get all these freedoms, yeah? And obviously in the old days, it was considered like the far west,

these crazy guys, and they're, you know, breaking the boundaries and doing, you know, once upon a time in the west, I think is a good way of expressing this. The basis of these freedoms are the licenses. We have a fair selection of free software licenses or open source licenses if you want.

They're fairly clear, they're fairly easy to understand. Not all of them, I do admit it. I think some of the licenses were written by lawyers. This is to make it really complicated for you guys and to give us a lot of work, okay? But if you look at the licenses that are drafted by engineers, the MIT, the BSD, they don't have more than 350 words.

I don't know if this is an expression of the capacity of the engineers or if it's just that, you know, engineers do know how to write things really short, really sweet and understandable. Anyway, you did very well. When the lawyers got involved, we got the Netscape public license,

we got the Mozilla public license, we got the GPL version 3. I mean, how to cut your own veins, you know, trying to read, has anybody tried to read the GPL version 3? Okay, are you still suffering from post-traumatic disorder? Yeah? Okay. Well, that's something the lawyers get into. Anyway, we have these licenses, okay? I call them the untouchables because we should not touch these licenses, okay?

They are there, they're to be used, and we all read them every day before we go to bed. We shouldn't change them, and for the moment, please, guys, don't make any more, okay? So I don't want any here about a geographic open source license or a GIS something, free software public license or something like that, okay? Use one of the ones that already exist.

So those are the licenses, and they're there, and we know them well, okay? And as a result of this licensing, in 30 years of practice, I think we have now the characteristics of what we do can be expressed by this film. Have you ever seen this film in the line of fire? Yeah? Dedication. You know, I think it's expressed pretty well by Clint,

of course, my hero, Clint, okay? And we have what we have in terms, what I call ETs. The ET is clarity. Well, the MIT is clarity. GPL is not, but never mind. Adaptability, accountability. We have all these ETs, which are really characteristics of our communities and of the software we make, okay? Longevity is for Clint. It's not for anybody else, okay?

Although is anybody still using Linux 1.3 or something? No? It probably still works. It probably works pretty fast, actually. Anyway, so the consequence of this licensing feature, which I'm about to comment on, is that we have a set of documents

which establish the guidelines for our communities. They establish the way we work. They establish the legal relationship between heterogeneous communities, people who don't even know each other. Well, this is why we have the conferences, so we get to know each other. But before you actually came to these conferences, you probably had legal relationships,

not any other type of relationships, huh? You had legal relationships with third parties, other people in the room, who you probably didn't even know, and you didn't realize that you had a contract with these guys. You had a license with these guys. So this is an amazing phenomenon. It doesn't really exist. In the old days, a contract had to be between two parties who knew each other.

They signed it. They shook hands. They spat in their fingers, and they did that. Whatever they did, okay? Today, in the digital world, and especially in the open source free software communities, we have these relationships based on these documents, which have established a well-known, hopefully, and solid terms for doing business,

or for creating communities, whatever. So I think that's an important fact to understand, and one of the reasons why we actually do insist, from a legal point of view, that we try and use the licenses that we know, and we don't invent new things. Because, obviously, we look at the bad. This is the hero of the film. You've seen the film, The Good, the Bad, and the Ugly?

You know the standoff at the end? Come on. Without the standoff, you've got to go and see this film. Who's not seen this film? Don't be embarrassed. You can put your hand up. You can look forward to go and see some of the classic. Anyway, this is the bad guy. This is Lee Van Cleef. I think he's a much better actor than Ugly. But I think he also represents some of the things that you guys are not doing right, okay?

First thing, first problems we're seeing in open source licensing. Someone forgets to put a license on it, okay? Last time we looked at GitHub. I know everyone's moving out of GitHub. We're going somewhere else. I don't know why. There's some pretty good open source cool guys in charge of GitHub now.

There are about 30, between 40% of the projects that did not have a license. Yeah, yeah, it's free to use. You know, I don't need to put a license on this. Okay, do you know what the rule is if you don't put a license? Big silence in the room. You can't use it. All rights reserved. The default rule on copyright law is it's all rights reserved.

Even if there's some form of implied license, you get a license to use it in a single territory where you live for five years. That's pretty useless. Well, it's probably enough for proprietary software, but it's pretty useless for open source software. Okay, so it really is important to think about putting a license. And we've seen recently that GitHubs has,

and I don't know about GitLabs, they have some of these kind of like pop-up click-through wizards for choosing a license or whatever. It's not brilliant, but it's better than doing nothing. Second thing. Ooh, ooh, ooh. Cutting and pasting without attribution.

Yes, I know. I can all see you looking down at your knees and saying, I didn't do it. I didn't do it. Come on. How many of you have cut and pasted? Yeah, how many have cut and pasted with attribution? Put your hands up, put your hands up. Yeah, well done, well done. Okay, come on, guys. Snippets, all this stuff on the web, all this stuff shared in the forums, all this stuff taken distinct

specifically from source form to GitHub, you need to attribute. You need to respect the license that that code is under. And if there's no code, you go and speak to the author. I've audited, oh, you can see how little hair I've got? That's from auditing open source projects, okay? Probably about five years after they've been published,

they come to me and they say, hey, Malcolm, could you just check we're doing the licensing okay? And this is when I start losing hair and whatever. Losing sleep, losing my children, whatever. So, you know, you look at this thing and it's got about 250 dependency packages and they've got no idea what's in there.

And then they say, where did this get this code from? Oh, I just downloaded it from the web somewhere. Oh, big one, okay. Modifications, how many of you have changed code, modified other people's code? Yeah? Did you put your copyright and your name next to that modification? Did you realize that you could actually change the license or put your own license on that modification? Depends on the license, yeah?

Well, many, many of us, at least many of the projects I've looked at, they've made modifications, they've adapted, they've improved, they've ported, and they forgot to either attribute the original code or they forgot to actually indicate the authorship and the license of their own code. So, yeah, there's some bad ones there. What about these ones, okay? Ooh, rookies, any rookies in the room?

No, you don't go to, yeah, that's not true. You don't go to conferences if you're a rookie. Well, if you do, you'd be good, okay? Rookies is the phenomena we've found over the last 20 years of people thinking, those licenses written by the MIT or by, you know, Stanford University, they're pretty shit. I can do better, yeah?

I mean, or the ones written by Eben Moglen, you know, the lawyer for the FSF, I can do much better than Eben, okay? So why write my own license? Yes, of course, or I take a license, perfectly good license like the BSD or MIT, and I add extra wording just to give it a bit of flavor because plain vanilla is boring, okay?

So we all know Jason. Who hasn't used Jason? Yeah, what does Debian think about Jason? Does Debian think that Jason is free? Does Debian think that Jason is not free? Well, April this year, Debian decided not free. Jason's out.

We're not including Jason in the Debian distribution. They may not need it, okay? They may not need it in the Debian distribution, but they said that do no evil is an additional restriction which is contrary to the Debian free software guidelines, okay? So a little sentence. I think it's funny. It causes havoc, absolute hell. It's good for me, huh? Really good for me. Good business for me.

I have to advise on companies saying, can I include this Jason in mine? But it's not very good. The free beer license, anybody use the free beer license? Maybe you did. Did you use the free beer license? Is that how you got your free beer? You didn't? Oh, maybe you're the author of the free beer license and that's how you got it. No? Okay, so you're not Paul Henry.

Anyway, so he says, well, you know, free, do what you want, good, standard open license, but buy me a beer if you see me. It's actually, he did it quite well. He did put it in the conditional. He said, if you think it's good, then you can buy me a beer. So it's a condition. So actually it's not a restriction. And then we've got the deaf and repudiation license,

which I think is probably the best open source license there is. Okay, so the software may not be used directly or by any living being. Why are you laughing? Has any of you guys involved in artificial intelligence? Hands up if you're doing anything to do with AI. Yeah, okay. When are we going to have computer code

which is written by machines? Or should I say since when have we got computer code that has already been written by machines? Yeah, or used by machines. Okay, so maybe we can think of the Internet of Things and all these sexy buzzwords. I have to mention these buzzwords. A keynote is not good if you don't mention artificial intelligence, machine learning, deep whatever it is.

Deep linking? No, that's something else. Anyway, so we're getting into a world actually where machines are creating code and being used by machines. And so maybe the deaf and repudiation license is the next step in human open source licensing. I don't know. Anyway, so one of the issues we have is that we're seeing many, many, many licenses.

You think generally speaking there are how many licenses? Recognized? About 60. Good. Extra points for that person. There are about 60 or 70 recognized. I think the open source initiative is deprecating a few of these. In fact, if you look, for example, in Black Duck,

which is one of these commercial scanning systems, they share about 1,500, 2,000 different versions of open source licenses. And that causes hell for license compatibility, license compliance. But it's really good for my business. So please continue doing this type of thing.

Another of the bad. I'm still doing the bad here. Another thing is the way open source projects makes it so difficult to understand what the license is of the project. It's so easy. If you're on GitHub, there's a little place for putting your license and expressing it. So many times you get either nothing or you get in the readme.md, you get this is free license, use it as you want.

Okay, that's a license. But it makes it so difficult. And you've got all these dependencies that you incorporate into your packages. And you don't properly express those dependencies. And then you've got all those sub-dependencies that you don't realize are being incorporated into your packages. And the sub-sub-sub-sub-sub-dependencies, which all get pulled in,

you distribute the binary and you're in complete and non-compliance with the licenses of those sub-dependencies. Okay. So, you know, the other... Frantic, I think, is probably a really good way of... Have you seen Frantic? No. You haven't seen Frantic? No? Excellent film. Harrison Ford goes to Paris, he loses his girlfriend,

as one usually does in Paris, and he gets Frantic looking for her. Okay, what's the same thing? We go Frantic trying to find what licenses... Just this morning, in our legal network, we have a legal network, a community like you guys, and we share ideas. It's odd, lawyers are sharing, but we do. And someone sent up a message saying,

oh, I've got this package, I can't find the license, can anybody help me out here? We get a message saying, I've got this package, I've found three different versions under three different licenses, and the code is all the same. Which is the proper license? Hell. Okay? So you guys think, yeah, open source, it's really easy. You guys, us guys as well, huh? Yeah, we just, you know, pick and choose, pull in some packages,

compile it all the way. And you forget there's a huge legal infrastructure underneath that, which really you do have to take account of. And we find this very weird because, and I won't go into the ugly yet, oh, you thought the bad was bad, you wait for the ugly. You guys are coders, are you coders? You do code? I do code as well.

I've got the civil code, the criminal code, yeah, got the road code, the high rate code. The same thing, it's a set of rules. Is that what you do when you program? You use a set of rules? If, then? Yeah? If you use this software piece, then include a copy of this license. I know, I did basic back in the 1980s,

before it was even visual. In fact, before it was even basic, whatever, so. It was then, if, then, does anyone remember? If, go to, and you had to put a line number. Ah, only the white haired people. Oh yeah, you can, yeah, I know, I can see. Yeah, I did, I, anyway. So, so, so if, just think of it, guys, this is your mantra when you go to sleep. If I use this software package,

then I look for the license, and then I include a copy in the route, okay? Anyway, so, if you thought that was bad, you wait for the ugly. Cool guy, I really liked his acting. Okay, the ugly, so what happened to the ugly? Okay, big bad number one, not complying with the terms, okay?

You think these licenses are really easy, they've got two sentences. MIT says, you can do what you want with this code, but then it adds, provided you do what? Anybody know what the MIT says? Yes? Not quite, but close,

I'll give you 90%, okay? You just keep a copy of the copyright notice, okay? And maintain a copy of this disclaimer. So there are two things there, okay? So, so many times, have you done, have you issued code, have you released codes, you guys? Who's released code? Who's checked all the licenses of the packages they're releasing?

Oh, a few of them. Who's included a copy of all the licenses in those things? Yes. Yeah, less and less hands going up, okay. Have you included all the attribution copyright notices? It's actually quite easy, because if you distribute the source code, it all comes with it. So the question is, when you distribute binaries, in this world where everything is going a little bit more commercial, and where the business is starting to understand

that open source is stable, good quality, and supported, they're actually using more and more open source, and they're actually packaging this and making binaries. And the problem with binaries, we all know, is that you lose all the interesting legal bits, okay? All the comments, all the headers, everything gets kicked out. And you don't have these special, you know, important things, like copies of the license,

or access to source code, yeah? Have you made sure you provide access to the source code? You did? Okay, excellent. Well, this is the problem, for example. Imagine you're driving your BMW, as one does, the X7 or X5, or whatever it is, you know, and you've got this big onboard entertainment stuff. It's all packed with open source. Genevie, big open source consortium,

of car manufacturers, they all get together for the onboard entertainment and information system. And it's all Linux-based with hundreds and hundreds of packages there, okay? How do you distribute source code with a car? Has anybody bought a car in the last few years?

Depends. I'm a lawyer. Okay, depends. Has anybody bought a car in the last few years? Did you get a USB key with a car, with all the source code packed in it? No? Did you get a DVD with the car code? No? Did you get an offer of three years to get the code if you wanted it? Then you can go and report Nissan,

or Toyota, or BMW, okay? Not Toyota, because they're my clients. They're probably doing it pretty well. No, I'm joking. I'm not a Toyota lawyer. But Toyota are actually pretty good on this. Nissan printed out a 250-page document with something like 400 open source licenses in the back end, because they thought that was the best way

to comply with the license and copyright attribution. Dear me. Anyway, if you're actually curious and you're waiting in a traffic light, you know those traffic lights are a bit too long? You should go click, click, click, click, click through the onboard entertainment and go down to the legal bit at the end. You've got all the licenses there. They're pretty good. They're including the licenses there. They don't include the source code.

But you get an offer usually, okay? Build instructions. You guys release build instructions as well? Okay, who's using GPL code? Okay. Do you know the definition of complete corresponding? I don't, so it's okay. It's not a test. Okay, you get to have coffee if you don't answer.

Yeah, okay. Well, it's everything you have to put in there to rebuild the code as it is, which means not just the source code, but also the scripts, the instructions, whatever it is, the makes, whatever, okay? Many, many times we see that that is actually not included in a package, and even less so when it's a company binary, okay?

Anybody done no evil? Everybody always being good? You know, they have a halo like this? Yeah, I can see, yeah, okay, yes. I can see it, okay. Well, be careful when you use JSON. Anybody using JSON? We all use JSON these days, don't we? Okay, so we all have to be really careful, especially about 10 o'clock at night on Friday afternoon, Friday evening,

that we do no evil, like consuming too much alcohol or walking down the high street naked or things like that. Whatever one does, one gets one thing off on Friday afternoon. Anyway, so this is typical non-compliance, and this has caused a lot of headache, to such an extent, actually, that, oh, this happened. You go to court. We're seeing more and more, unfortunately,

in the Linux environment, there's a couple of people, at least one person, who thinks that it's a good business model to sue binary distributors and actually get money out of them because they failed to include a copyright notice or they failed to give access to the complete corresponding source code. This is causing hell in the community,

to such an extent that several large companies are no longer using Linux distributions, which is really bad for the community. This is going up the chain, so it's not just up the stack more than the chain. So this is only good for us, so please do this, and for journalists who think it's a great idea on Slashdot or whatever it is

to make noise about it. But it is a problem. We're trying to deal with it. We're trying to calm things down and make it easier for you guys. But you have to pull your weight as well. You have to do some heavy lifting, okay? So you guys have a mission, okay? You have a mission. Have you seen the film Mission? Join us. Next conference,

I want to put some good films at the beginning or the end or in the middle of the conference. Okay, come on, guys. You haven't seen the Mission. Ah, Mission's one of the best. Yeah? Gosh, it's got oboe. It's got the oboes. It's got Gabriel's oboe in the middle. Wow, classic. Okay, and it's got Robert De Niro. It's not even Clint. Okay, so you guys have a mission. You have a mission that even for a little bit of money

or a little bit of extra effort, please help us. Please make it sure that you are complying, you're doing your homework. Because if you do it, let's put it this way, if you do it at source at the beginning when you're actually in the middle, it's really easy. All the information's there and it means I don't have a job. No, that's not good. Please continue with your current practices of doing nothing

so that I continue with my work of having to audit the code and give these long pages of documents where you have to include this copy of the BSD and that copy of the BSD and that copy of the BSD. Okay, it's not difficult. You've got the build environment. You're using Eclipse. You're using Maven. You're using whatever it is you're using. I don't know what you're using in the geographic information system area.

But you've got these features, functionalities. You've got GitHub or GitLabs or whatever where you can actually upload all those licenses. You can put license on your own code. You can put a header saying copyright Maria 2018. You know, this code is under the MIT license, which you can find in the source, whatever it is, okay? Identify, okay? Identify all those dependencies

and sub-dependencies. There are tools for it now, which is what I'm going to talk about, okay? Creating a component catalog, which makes it easy because when your code gets incorporated into the latest version of BMW because they're using some geographic information system, which is what they're doing now, you want your authority. You want to be there. You want to say, hey, you know what? My name is in the latest BMW X5

or Toyota, whatever it is, Prius, I don't know what the version is. You can go and say, hey, guys, every version of the BMW that gets sold, my name's on that car. So, and if you want to be real negative, you can create one of the, you know, be a rookie. You can create your own license so that not only your name gets in there,

but your own personalized license gets in there. Whoa. For 50 years' time, they're going to be scrolling through those things saying, who the hell were those guys? Anyway, so what I'm saying is the mission here is, it's a please, please. It's good for you. It's good for us. It's good for everybody

is to actually, when you're doing your coding and you're doing your algorithms, think there actually is a bit of a legal algorithm there that you have to comply with and make it all hunky-dory easy downstream for the people you're working with, okay? So here's a little bit, some beginning of some ideas of how the perfect world would be like, okay?

This one's got Kevin Costner. Not a fan of Kevin Costner, but it's got claims as well, so I'm including it, okay? This is a good one. Okay, we've got tools to do this now. Anybody starting using these tools? SPDX, scan codes, okay? Software 360, okay? Anybody read the reuse recommendations?

Good. So you actually can say this morning, I learned something. Okay, well done. Okay, so look, we've been working for the last six years in the legal open source community to actually help you, because I know you see this as red tape, as a burden, as something, a pain. I'm not saying where.

And we want to make it easier for you to be able to do this in build time and developing as a normal part of the process. So we've got some tools there. SPDX, SPDX is a markup language for identifying licenses in a short single sentence. So instead of saying, you know, copyright 2018 Maria,

this is under the GPL version 3 or later version. If you want a copy, you can go to Massachusetts and go to Boston and ask Richard Storm for a copy. Okay? All you have to do now is put SPDX-licenseidentifier2.gplv3. Okay? This is machine readable. So if your code then gets scanned two, three, four years from now, someone's trying to find out

what was the license of that package with that strange guy from the geographic information system you can put in this code. It's easy. You've got the SPDX code identifier. Okay? There's some RDF behind this. There's some tools so that you can actually get automates. So if you've got 250 packages or dependencies in the binary,

you can actually have what we call a bill of materials, which is a piece of paper or a file, an XML file, which identifies every single one of those licenses. And it has not just license identifier, but it has the authors. It has exceptions. It has additional information. SPDX is pretty cool. There's a great tutorial by David Wheeler.

David Wheeler was very famous. He wrote a paper about 10, 15 years ago saying why do you use open source or whatever. It was fantastic. But now he's done a new one on SPDX, which is pretty cool. Okay? And it would be really, really good if you could start identifying your files with an SPDX identifier.

Okay? You can read it. There are tools for doing it. They're actually being integrated into the development environments like Eclipse, so you can do that. Scode scanners. Scode scanners. Code scanners. This is when we want to find what licenses are attributed to, and we get just a big dump of source code. And either you hire 20 interns to go file by file,

looking for the file, or you put it through Fossology or scan code or tiny scan or whatever. Okay? And they come up with a list of the licenses or at least what's declared licenses. And then they have a big list of all the files that have no license at all, which of course you have corrected because by now, by this afternoon,

you've put an SPDX identifier on every single one of your own files. Anyway, so this comes up with a document, an XML if you want also, or some form of information exchange where you can actually trace the different source packages. Reuse. Reuse actually is just a set of guidelines. It's from the Free Software Foundation Europe, which is the German-European sister

of the Free Software Foundation, setting up some best practices of how to develop code. And they basically got three main recommendations, which is to provide the exact text of the license, include a copyright notice, and pry it in inventory or a bill of materials for all your dependencies.

Okay? If possible, do it in machine readable. So again, in SPDX or something like this so that it's all much easier downstream. Okay? What else have we got? Software 360. So Software 360 is a project from Siemens. We know Siemens, don't we? Yeah, we're good on Siemens, Munich-based large company. Okay.

They're very into open source, basically because they build lots of stuff for the car industry, and the car industry has lots into open source. They also do nuclear reactors and things like this. So they think open source is pretty good because it's more stable than other types of software. And they realize that one of the big differences and difficulties was maintaining documentation. Anybody had an issue with maintaining documentation?

Yeah. We all know that. Okay. Well, at least for the legal bit, and maybe you can adapt this for other types of documentation. Okay. But at least for the legal bit, they've got this sexy document repository management system where you can attach a bill of materials and a copy of all the documentation

to a specific version that you're releasing. Okay? They're doing this because they're doing CI. Is that right? D-I-D-I-C-I-C-I-D-I? Continuous integration and distribution. And so when they're updating the software for the nuclear reactor in real time or for the very fast train, so just as it goes through the junction,

they have a software update, and it says please wait while we're updating the software. You can just imagine that, yeah? Okay. They're making sure that in that train they get a copy of all the corresponding source code and the copyright notice, which is much more important than actually making sure that it works. Yeah. Don't take any Siemens trains anymore.

So all those TGVs, all the AVAs, okay? No, no, no. So yeah, they're doing CIDR, whatever it's called, and obviously if you need lawyers to get involved, we have a kind of two-week, three-week cycle. So if you're doing continuous integration, it just doesn't work. So they're doing this. They shared this software for doing real-time updating

of all the license information so that it gets fed in in the development environment and then when it goes into production, you've got the right thing there. So it's pretty cool. That's pretty cool. It's in Eclipse environment. I'm sure we can do versions for other development environments, okay? And then, of course, what we're trying to achieve, don't say you haven't seen Cinema Paradiso.

You have to leave the room if you haven't seen Cinema Paradiso. Come on, guys. There. Okay. Are there any... The ladies in the room, of course they've seen Cinema Paradiso, yes? Yes, we will. Yes, it's... Next one. You start with... No, you start with a mission.

And then you put Cinema Paradiso. Come on, guys. Ennio. This is the music by Ennio. It's brilliant. It's fantastic. Okay, anyway, so... The Quartermaster. Quartermaster is a tool that we're trying to put together. It's a guy from Merkleburg who's in charge of some of the Linux stuff in Germany and he's got this project called Quartermaster which is basically a workflow manager compliance tool chain.

So it's a set of... It's a plug-in type infrastructure where you can plug in scanners, plug in SPDX stuff, you can plug in different tools so that you can put your code or your development process through this tool chain and it should automate, it should ha-ha-ha, we all know that,

with three clicks, ha-ha-ha, make sure all this license information is correctly done. So ideally, if all your source code and all the dependencies, third-party libraries, if they're all SPDX'd and if they're all put through the system, you don't have to do any heavy lifting. It's done for you. The system actually collects that information, collects the license files,

puts it in software 360 and when you deliver, you know, to whoever it is you're delivering to, then that file is there and it's already done magically, automatically. So we're trying to do it as much as possible. Here's some interesting graph. I don't know what it means, but it looked pretty, so I put it in the presentation, okay? So you guys look at Quartermaster.

I think it's in version alpha 0.2 or something. Next year it'll probably come out. Okay? So this is a little bit what I was going to talk about, okay? All this, how do we put this together? So I don't expect you to see the professional. It's a French film. It's pretty good. It's got Ennio's music again. So OpenChain.

OpenChain is a cross-industry project initiated by me, among other people, so that it's for implementing best practices, the good, in software development, okay? So it's got about 13 lawyers, 13 engineers,

people from all types of backgrounds and industries trying to put together what we think is the best way of managing open source in enterprise or in a project or university or in the public administration, okay? So it has a set of processes, high-level stuff. Like, you know, you must have a policy.

You must do some training. If you deliver software, make sure you include all the right stuff, okay? So there's a specification, and we're asking the ISO to have a new sexy ISO number. It'll probably be 999 or 666 or something, something like that.

So it's a specification of the best practices in managing the legal aspects of open source projects. And there's a curriculum which basically means that there's about a stack of 150 totally indigestible slides that you can do some training on. And there's a checklist, the conformance checklist, which you can tick, and you can lie like Pinocchio

and say, yes, I do that. Yes, I do that. Yes, I do that. And you can say, yeah, I'm OpenChain compliant. It's all lie. But anyway, so it's pretty interesting, and we're getting there slowly to make this something that's usable and practical, okay? This is for a larger enterprise, the kind of process they're looking at, where one goes from the stage of identifying the inbound dependencies or inbound software.

You go through all sorts of approvals and verifications, and you're out, so it makes sure that your outbound stuff has the licensing information, complies with source code obligations, and is all digestible in a package. The next person in the chain can actually understand, okay?

So that's a little bit of an example of what we're trying to do with OpenChain, okay? Here's a couple of examples. Okay, so this is a quick summary of what we're actually working on in the legal open source community, is to help the development community make it have a better life and to reduce overheads in terms of legal terms.

I think we're getting there. We're probably another year or so, maybe a year and a half until we have something that's actually really usable, but a lot of it depends on you guys, because unless we get feedback from the users into what you actually want, then we can guess, we can work with some engineers,

but obviously it'd be better to have a wider community giving us some information about what you actually need and what's good for you, okay? So that's basically what I wanted to say. Thank you very much for your patience. Thank you very much for your active participation in raising your hand and saying that you have seen this film or not, and have a nice day.

Or make my day. Anyway, thank you very much. Thank you very much, Malcolm, for this very interesting presentation and for keeping us awake with all this interaction. The activity, actually, was a morning activity of your guests

to keep your hands going up. I think we have time for a few questions, so if someone wants to challenge Malcolm with some questions about... Okay, we have one.

That's a good question. Sorry, can we... Yeah, I'll repeat the question. Can you repeat? What do you do if you receive a pull request and you don't know if the person who's making that contribution has the right to make that contribution?

It's a good question. Next question, please. Nah, I'm joking. A lawyer's answer, it depends. Come and see me. Here's my phone number. Let's have a look. You've got... There's various scenarios here, okay? It also depends on your community, depends on your philosophy, on contributions, depends on how you organize the contributions,

which is one of the things that projects have to do, should do. You've got the more extreme control freaks who say every single contributor must sign a contribution license agreement or an assignment to the project where the contributor gives a warrant, a guarantee that I am the author of this code or I have the right to contribute this code.

This is more centralized, enterprise-facing projects, okay? Or you have the more, you know, shorts, long hair, chancletas, as they say, you know, type of communities. I'm not looking at you guys, don't worry.

Where you... Where they use something called the Developer's Certificate of Origin, DCO. The Linux community uses this. I'm not saying Linux community are all long-haired, shorts and whatever, but anyway, so this is basically on a good faith basis, but they do require each author or contributor,

committer, to sign off on a DCO which states that they are the author, although the code is committed under the license of the project, okay? So these are the more, in legal terms, these are the two extremes, okay? This doesn't mean to say that you don't have to do some form of diligence due diligence of what's happening, okay?

As always, it's good to know your sources, know who this person is. I don't think you let anybody into your community. You probably don't let anybody, or just anybody, do a pull request. Or maybe you do allow anybody to do a pull request, but you don't necessarily put that request into the branch or whatever it is you're working on, okay, into the release.

So know your source, I think, is the best thing. Some form of contributor guidelines on the wiki or on the repository, and some form of identification or authentication of the guys doing pull requests and committing the code, and some form of diligence checking out of that person is actually who it is.

The biggest problem we have is that often those people are working in companies, and the copyright law basically says that the, anybody working in a company here? Slaves to the machine? Yeah, okay. Do you own the code you write? Well, if you're the owner of the company, yes. But the answer is no, unless the company has said that you own that code.

The basic underlying rules, I'm not talking about Belgium, because apparently Belgium has different rules. The basic underlying copyright rule is that if you work in a company, or actually in a public administration, the copyright is owned by that company or by that administration, okay? So the person who has to sign off on the DCO or sign off on the thing

has to be the company, because that entity is the person, the legal person, authorized to commit the code, to submit the code. And many, many times we've had this issue of having to go around asking for all this documentation. And we suddenly find companies where people making commits from companies,

where the open source policy is you are not allowed to contribute to open source community projects. So we have this kind of huge conflict, which, as I said, is good business for lawyers, but bad for development. So you don't know. The answer is you don't know, so it's good to make some steps to check who they are, okay? The other question you may have

is people cutting and pasting from the web, incorporating into their pull request and sending it upstream. And that's even more difficult. You can use a scan code. You can use Google code to scan things or whatever all these scanners. They may be able to help you. Yeah. Okay, for those that didn't hear,

he said he's recommending to do geotools incubation because, in fact, you all go through the painful process of doing six months of legal verification. That's the only real reason to do the tools incubation, is that right? No, no, I'm joking, I'm joking. One question, of those 3,200 packages,

how much have got an SPDX declaration on it? No, none of them. Yeah, exactly. Now you've got another six months of pain to actually doing that, okay? Upstream it, guys, upstreaming. We all know that upstreaming is the best thing in this world. Upstream it. Yes.

That may have been a little bit ironic, but yes. No, no, no, no, it was actually, it was being a bonafide.

From a legal perspective, the answer is it depends. No, no, no. Well, the real answer really is it depends. It depends on you guys. It depends on who makes the best quality code.

Yeah, but I haven't answered yet, but yes. You make better code. And you comply with licenses. But it's a good question, actually. And there's lots of sub-questions, like what's the future of copyleft? Because people thought the copyleft was a, you know, the licensing system of the GPL

that you have to republish under the same license. And they thought this was like glue bringing a community together. And it works very well in some communities. But we're seeing that there are lots and lots of permissive licensed communities. Who lives in a permissive licensed community? MIT, BSD, Apache? We're finding there's as much glue in these communities,

i.e. there's lots of contributing back, there's lots of sharing, as there are in a copyleft community. So there's lots of questions being asked. Does copyleft really still have a meaning? So, but going back to your original question, from a legal perspective, I don't think there's a, it's not black and white. It's not, you know, proprietary here, open source there.

Especially if you see that probably 50% or 80% of proprietary software is open source, under the bonnet. It's permissively licensed open source packages. And you find that more and more open source projects like Hadoop or whatever, have a proprietary business, or at least a commercial business, like Cloudera,

you know, supporting, running, helping the community. So there's a lack of fusion, which is interesting from a community dynamics point of view. But, I mean, people said the software is eating the world. I think it was Ibrahim, what's his name, from Samsung.

And people said then open source is eating software. So, what's happening in my experience from a legal point of view, when I look at licensing, when I look at packages, is that open source is going up the stack. Okay, because more and more code is a commodity. Okay, so any economists in the room? Okay, well in economic, do I have two minutes?

In economic terms, when something becomes a commodity, it means that the marginal cost is nearly zero. So, when marginal cost is nearly zero, obviously open source is the only way. Because it's the only way to have any competitive advantage. It's because you can access the code, you can improve it. There's other value, rather than just the licensing cost. So, we see it obviously in the operating systems.

Today, Microsoft is giving away its operating system in a certain way. I know, yeah. It costs in support, it costs in pain and whatever, but because it has been commoditized. And the same thing is happening all the way up the stack. You're getting middleware, you're getting databases, you're getting everything which is becoming a commodity.

And therefore, the only competitive advantage is if you provide added value in other terms. And this is where open source has massive advantage. And so we're seeing, this is why MariaDB, or Mongo, or Hadoop, all in the database space. I mean, I don't want to say anything about established proprietary database companies,

but they have to find a new business model, because they are really losing weight. And I'm speaking from a licensing point of view. I'm saying that more and more proprietary packages, binaries, have more and more open source code in the commoditized stack.

And I hate to think what will happen when everything goes into artificial intelligence, and these systems get more and more complex, and we know less and less of what's in there. Anyway, I don't know if I answered the question, because I think things are merging together in a way, and obviously there's less tension between the two communities,

because we need money in the open source communities, so we do have businesses running on this, but we have open source businesses, and the proprietary also need to have competitive advantage or margin, and therefore they're using more and more open source. But there's always going to be some closed packages, where there's some added value, competitive advantage

that some inventor has, or writer has, specifically aimed at as the next best thing. The question is, how long will it stay that way? Two years? Three years, maybe? Maximum? Silence, gosh. Yes?

No, ETC is a very well-known studio in Hollywood. No, no, no, no, it's true, I've cut some corners here.

I've cut some corners. I hope no one's filming this, because I'm sure that I'm infringing lots of people's copyright in that. It's true, and it was a bit late last night when I found the last pictures, and I was just too tired to actually ... In Spanish we have an expression that says, in the ironworks, everybody has a wooden knife.

You know, because the ironmonger doesn't have his own tools. So, yeah, apologies. When we release this version, it'll have all the copyright and attribution notices. You're fired. Okay, so we thank you once more.

Thank you very much. Thank you very much.