Legal Review Process
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Kulow, Stephan
The Legal Review happening in the Factory development process is a black box for many, even though it's very important for keeping openSUSE away from danger. But many only know the downside of this requirement: if the review takes "too long". This presentation is trying to shed light into the black box and show the processes and applications used. Explaining the challenges and pitfalls - and the actions we took to speed up the process.
 Hi. I'm relieved that not so many people joined this call because the topic is quite complex and I, fortunately, I put the easy tech in the presentation and only realized while writing the talk that it's quite complex problem. About me, I'm Stefan Kuhler. I work for SUSE in the Enterprise Core Department. I used to be the release manager of Open SUSE until the release of Leap and I'm acting as an open QA tools architect and not as a lawyer. So most of the stuff I will tell you is actually bullshit, but take it as an advice from someone who doesn't know licenses to someone else who does not know licenses. And I asked Kirin to be around for overly bullshit stuff that he will correct then, no doubt. The topics of the talk is the whole background of open source licensing, what I describe as licensing hell and then how we actually handle it with an open SUSE, the actual process and I will briefly introduce you to the tool we used that we named computer-aided vicious licensing, short cable. So why are we actually doing legal reviews? Most of you who do packaging will have heard about licensing review, most of them with bad annotations. The problem is that open source comes in many, many flavors. There's no single this is open source, but we as a distribution or even for ST even as the product, we need to have the license to distribute the source and compile it, patch it to users. And with that, with this review, we're trying to protect the users and the customers from any dangers that would arise from not having correct licenses. So one prime example is if someone puts a license to his code not to be used with commercial offering, then actually SUSE does not have the right to distribute this and this would also not be open source. So there's no business for the software in factory because factory is open to the tumbleweed or leap is supposed to be open source only. So what is open source? As I already said, there is no single definition of open source. There are actually many definitions of what is open source. Most people have a feeling for that. There is for a long time, I don't know, the FSF propagating free software, which is more than just the source. It's also about the culture and the politics around free software. We had a great keynote on Friday about from the FSFE on how to, on what all these politics come down to. We have the open source initiative that propagates open source, which is different and there was quite some controversy about this than what free software is. So open source is more generic than free software is. And open SUSE as distribution follows that definition of open source from the open source initiative for code and for content like wallpapers, icon themes, you name it, there are different rules and they are listed in the packaging guidelines. They are mainly about that we know where it's coming from, that there are no trademarks on and no porn. The packaging guidelines even specify that there are better places to get porn. So the open source definition as of the open source initiative, it comes down to four basic points. There are even the actual rules as always with licenses much, much longer. But mainly it is about that it is free for everyone that as in no money, that the source code is available to modify. It also includes that the code is written as a developer would modify it, not some pre-processing or post-processing happen to the source. That the source allows the rivet works. That means you can just take it and do your own stuff with it. And that the source does not discriminate use cases, people, platforms. The discrimination part is actually the longest part of the open source definition because there are many ways you can discriminate and they are listed all of them in pretty great detail. So on the open source.org web page you also find a list of popular licenses that are used in the wild. They name the appuch, I guess this is alphabetically sorted. So we have the appuch license which is not only used for appuch but for a lot of Java packages for example. You have the BST3 and BST2 clause which is also very often used. You have the GPL from the FSF and you have the LGPL which is the Lesser or Library version of the GPL. You have the MIT license which is used for X11 and a lot of Ruby stuff also comes in MIT. And you have the Mozilla public license which is not so much used but it is very popular because the LibreOffice and Firefox are under this license. So as in use of users Mozilla license will be still be very relevant. So to illustrate the concept of licenses I find the icons used by Creative Commons quite nice. So this is actually from Wikipedia if you look up Creative Commons licenses. And at the bottom of the graph you have the all rights reserved license which is actually the default if you don't put the license under any, the code under any license. But on the left side of the colors is actually the rights that are added. And the first right that is added on Creative Commons is the right to share the content or the code in this case which creates then licenses they call CC by ND or NC for non-commercial. So you can actually for example music you can take a track from an artist and share it as long as you don't sample it or create something that you put your name on it or that you can share and use whenever there is no cost involved or no cost to the user involved. The next right there is remix and there you also get into the light green stuff but it is still not open source. Open source only starts when it gets really dark green because then you add even the right to use in commercial products and to modify in this case. The remix part is already there. And there they have a big difference and on the top there is public domain what they call CC0. So it is a pretty long license that says there is no license or there is no problem. You can do whatever you want. There are other licenses that express this but CC0 is the more polite form. But one of the big problems we are having as distribution is that we are not distributing source, we are actually distributing a distribution which contains big mixes of derived works from open source. So you will find the same implementation of an MD5 checksum in many, many packages and they this license the original author then picked the rives into each package using it but the licenses that come with these sources are actually mixed within this binary within our distribution and this mixing of licenses also means mixing of rules which is created which creates basically a new license with new set of rules. And not all open source projects are actually aware that you can't blindly mix open source licenses. Some you can, some you can't but not everyone knows. For example, the version 2 and version 3 of the GPL is actually not compatible but that was a big problem for KDE for example as we had KDE talks in front because KDE used to have GPL only version 2 and Zamba came along with only having version 3 and then there was a big problem and this was I think KDE resolved this by relicensing to version 2 or 3 and but very often licenses have explicit permissions to link certain libraries or certain licenses. One example of a licensing hell I wanted to show you but I'm not so sure about my time as this very, very liberal office I'm doing the presentation in. If you go to the web page it says it's free software. If you look deeper it says it is Mozilla public license but let's see if my monitor, I guess this. So this is the about licensing dialogue which says basically it's Mozilla but if you look the license of liberal office it's actually 189 pages and what Kiran or basically what our legal review process has to do is reviewing this to verify that there is nothing hidden that actually makes it illegal or impossible to redistribute, I'm still scrolling by the way, to make it impossible to redistribute liberal office in open source. So this is what I call licensing hell and I bet every one of you checked this before using liberal office. But fortunately you don't have to because you can trust my presentation skills. You can trust our licensing review and so let's skip the rest of this talk and slide. The one thing that came along some years ago is SPDX which is a common naming for licenses in open source. They have a big list of licenses and there is some committee deciding when there's a new license coming around, if what name it gets and what the official license text to this license is then so that as an open source project or as a distribution or as some vendor I can express my open source licensing in a way everyone understands because it is now clear. So before we had open source I called it the pearl license that pearl is under. Fedora still calls it GPL plus or artistic but the SPDX form that everyone then should have is artistic minus 1.0 or GPL 1.0 plus which means GPL version 1 or later. And this is just a brief example where you can already see that even the BSD version that some say okay I'm BSD comes in so many flavors that it needs more clarification on what exactly is required from the user or the redistributor. So this is some small statistics I created from the legal license database and most of our files in packages are GPL, public domain or BSD3 but you can see the list is quite long but it's dominated by only a couple of licenses. I already lost you I'm sure. So how do we handle this licensing hell? As part of the development process for basically every SUSE and open SUSE project there is something we call submit request you might know and legal auto is some small review bot that is part of this reviewing process and it reviews with help of some application the sources and the spec file of the package and if this combination of licenses is known for this package it will accept the review otherwise it will wait for a lawyer to review the combination and approve it and after that the bot will also approve it and what the lawyer is using is an external application also that the bot talks to and this I will at the remaining time introduce this to you. So we called it cavill after a long brainstorming session on what to name this because it had a very boring name before and the reason why I wanted to have a good name is we want to have this application open source we are not there yet but we are in the process of polishing it so we can actually show it to someone. This application is feeded by review requests from the bot and possibly developers directly and will unpack, will check out the sources from the build services, unpack it recursively and then does on the sources some multi pattern matching which means that it knows how a GPL 2 is marked in the source, it knows how a GPL 3 is marked, how a BSD is marked and it will do this pattern matching quite quick and it will then present the lawyer's summary on what files, what licenses were found and what files and how the combination looks like. The licenses within this tool have a risk associated to it so that they are grouped from more important to less important and each license has a different, a series of pattern associated to it. The reason why we need several I will explain soon enough. All the patterns are checked in parallel on the sources and the longest version wins. If the read me says it's licensed under the GPL we have a license that is called GPL unspecified which needs more research. If the text says licensed under the GPL version 2 then we name this GPL 2 0 and this means only version 2 but if it says licensed under the GPL version 2 or later then we add a plus to the license because then we can mix it with GPL 3. The patterns allow to have a magic key word called skip that allows to ignore an amount of words within the license or without the text. So this is how the legal queue would look like in Cavill. It has the link to the build service request to be reviewed when it was created, the package name and some summary on the license report as we call them but basically the combination. One of these reports for NASN would look like this. They have several licenses that you can see but the most prominent is the purple part, the low risk key words and all rights reserved are just noise in some sense. So the purple part is BSD 2 clause and that's also what the spec file says so the review would be rather quick but there's one GPL 2 0 file in there and the reviewer has to check how this file is actually used. If this is only a test case then this is okay because it's not shipped as part of the binary. If it's content it's also a different story but if it's part of the sources then the overall license changes so this has to be reviewed by someone who's really experienced with all these licenses mixing. Fortunately enough we have even more than one. So the main story is why is this taking so long? Some people complain that the legal review is taking too long or very long and as I try to explain the situation is quite complex and for every file in the source code we have to identify the license that this very file is under and then we have to find the combination of sources that create certain binaries and then determine from there the legal consequences that has. So very often part of the review is finding the build process and finding what library are used and what binary or if certain files or patches are applied or not and so this takes a long time for more complex packages than what I showed you and there's no one working full time on that and no human soul should work full time on this because this is really if you and trust me I tried it if you do this more often in a row you tend up to be really grumpy and reject more than you should reject because I just very annoying to see all this stupid upstream projects doing so many stupid things with licenses and one of the consequences this stupid things that upstream projects has is that we have to create repeatedly new patterns for the same license. The GPL each version has a very specific instruction what you should do if you want to release your source code under GPL you have to add some very just copy and paste some boilerplate to each of your sources and it should be formalized it should really be straight forward pattern matching unfortunately there are literally thousands of variants on how people write the code this markup. The skip variables already reduce the number of variants that we have but still it's insane what people do and this comes from real people really adding extra clauses to the licenses or to the sources people adding just random grammar changes that they felt necessary people that do global search and replace on their sources and unfortunately found a license with that people adding random typos while opening the editor and or trying to quit women I don't know. So for example this is a pretty standard BSD3 license it has three clauses and at the end says otherwise there are no warranties and no event show the copyright owner reliable and blah blah blah the typical licensing stuff you click away when you install software and then you have this which is basically the same conditions and I bet you did not even spot the difference but I blink for you so it's just its contributors or their contributors so it's just the same thing in English but for a machine trying to pattern match it's really sorry what's on video so this is another example of the same thing where people felt like removing stuff or adding stuff in pretty standard licensing so we have for this BSD3 we have I think a thousand five hundred different patterns that all look very much the same but are random iterations of this and it as I said when you do this more often it pisses you off and at some point you want to say to the package who is innocent get your upstream projects fixed or I will not review this. So there are some future plans for this application the most prominent is that we want to open source the application and release it on GitHub the actual underlying algorithm is already on GitHub we need to have these packages associated with a product or project so we can see actually the status of factory if every package has been reviewed and we another point why we need this association is so we can clean up stuff that is no longer relevant and currently the updates are reviewed as basically new packages so we have to have some diff view these are the short term plans and for longer term I am considering investing into machine learning things because the process of defining new patterns is quite boring and as you can see the patterns are very similar so the arriving one from the other sounds technically possible to teach to a machine and the next thing is that I would like to have some pre some support becoming more smart about what things he can approve on itself instead of waiting for someone because it looks very, very similar to another package for example all these not all but there are classes of Perl packages and classes of Haskell packages are basically the same thing so I am if we remove my Antonio's time and my technical problems we have five minutes left so if there is one question I could answer that otherwise I would leave you for lunch. Hi, I once was in a nice packaging workshop with my colleague Daryx and then I found out that the mosquito package that we packaged there is distributed under a license which is called Eclipse public license I think I filed a buck about it and the answer was look into the license it's a standard 3D 3 gloss BSD license but the thing is it's published on the Eclipse website as a copy of the BSD gloss under a new name so and it's also dual license under Eclipse distribution license which is findable in the SPDL format so what do I do there in such a case using the other license or? So the naming license is very common so if I write Cavill and released under GPL you will find several projects that name this license then the Cavill license so they in documentation so they can change the license later without changing the application and I guess this is one of these cases but case by case we have to review if this license actually adds or removes rights from that other license and this is actually what SPDX does and if I remember the case correctly SPDX even had a discussion about it if this is a new license or just a different name for the same license so it's case by case but they then add not the new name to the SPDX list if it's not just a copy okay only if it adds or removes rights or if it's really really really popular already the SPDX discussions are public. Albert what will you do if there's a license update to an existing package? Like if the files change but the package doesn't bother updating the fields. Here question and I have it prepared but I guess it's invisible because of my X render problems. So this is the latest XRDP update to factory and it is held to on legal review because it's really stupid now because the licenses did not really change but to the machinery there's a new combination and the reason being is that there is this is just to give you another example so this is already Apache NGPL in the spec file you can see Apache I'm not sure if you can see what I can see it you can see Apache NGPL and further below you can see LGPL and MIT which don't map to the overall result and there are several other licenses that are for random for random build tools so what happened in XRDP update is it is just a patch update but they updated the build system to latest autoconf macros which and the FSF puts their license in every file so what this brings now is no longer GPL 2 with autoconf exception but GPL 3 with autoconf exception so this is now a new combination to the tool and it waits for the lawyer to approve that the update is fine. That's what I mean we need a diff view quickly because this it's very hard to find a needle in this so what this is what we see we see the package is no longer having the same combination of licenses it used to have and then we held and then we all did for review and this unfortunately goes behind all the other updates. Yeah I'll make it short. You said to trust legal review process so you don't have to go. You've indicated that users should be trusting the legal review process instead of reading the licenses is that just like cross your fingers trust or is there any additional guarantees that the legal review is going to be actually correct. So if you have legal training you sure should read the liberal office license yourself but for everyone else the chances of finding the problems in that license text of liberal office is much much smaller than crossing your fingers. So trust me if I say trust the review process I mean we found we have we this this whole process is still not perfect and as you can see there's so much noise that you that it's not so hard to actually miss something and as no up as to my knowledge no upstream project is using such a process it is we are very likely to be the first to actually find it so but the good news is most open source developers have good intentions when they publish their code so even if they don't use a proper license but just put uploaded to GitHub for them it's already open source so these good intentions is something that the legal review has to take into account as well. So thank you. Thank you for having me patient.
 Hi.  I'm relieved that not so many people joined this call because the topic is quite complex  and I, fortunately, I put the easy tech in the presentation and only realized while writing  the talk that it's quite complex problem.  About me, I'm Stefan Kuhler.  I work for SUSE in the Enterprise Core Department.  I used to be the release manager of Open SUSE until the release of Leap and I'm acting as  an open QA tools architect and not as a lawyer.  So most of the stuff I will tell you is actually bullshit, but take it as an advice from someone  who doesn't know licenses to someone else who does not know licenses.  And I asked Kirin to be around for overly bullshit stuff that he will correct then, no  doubt.  The topics of the talk is the whole background of open source licensing, what I describe  as licensing hell and then how we actually handle it with an open SUSE, the actual process  and I will briefly introduce you to the tool we used that we named computer-aided vicious  licensing, short cable.  So why are we actually doing legal reviews?  Most of you who do packaging will have heard about licensing review, most of them with  bad annotations.  The problem is that open source comes in many, many flavors.  There's no single this is open source, but we as a distribution or even for ST even as  the product, we need to have the license to distribute the source and compile it, patch  it to users.  And with that, with this review, we're trying to protect the users and the customers from  any dangers that would arise from not having correct licenses.  So one prime example is if someone puts a license to his code not to be used with commercial  offering, then actually SUSE does not have the right to distribute this and this would  also not be open source.  So there's no business for the software in factory because factory is open to the tumbleweed  or leap is supposed to be open source only.  So what is open source?  As I already said, there is no single definition of open source.  There are actually many definitions of what is open source.  Most people have a feeling for that.  There is for a long time, I don't know, the FSF propagating free software, which is more  than just the source.  It's also about the culture and the politics around free software.  We had a great keynote on Friday about from the FSFE on how to, on what all these politics  come down to.  We have the open source initiative that propagates open source, which is different and there  was quite some controversy about this than what free software is.  So open source is more generic than free software is.  And open SUSE as distribution follows that definition of open source from the open source  initiative for code and for content like wallpapers, icon themes, you name it, there are different  rules and they are listed in the packaging guidelines.  They are mainly about that we know where it's coming from, that there are no trademarks  on and no porn.  The packaging guidelines even specify that there are better places to get porn.  So the open source definition as of the open source initiative, it comes down to four basic  points.  There are even the actual rules as always with licenses much, much longer.  But mainly it is about that it is free for everyone that as in no money, that the source  code is available to modify.  It also includes that the code is written as a developer would modify it, not some pre-processing  or post-processing happen to the source.  That the source allows the rivet works.  That means you can just take it and do your own stuff with it.  And that the source does not discriminate use cases, people, platforms.  The discrimination part is actually the longest part of the open source definition because  there are many ways you can discriminate and they are listed all of them in pretty great  detail.  So on the open source.org web page you also find a list of popular licenses that are used  in the wild.  They name the appuch, I guess this is alphabetically sorted.  So we have the appuch license which is not only used for appuch but for a lot of Java  packages for example.  You have the BST3 and BST2 clause which is also very often used.  You have the GPL from the FSF and you have the LGPL which is the Lesser or Library version  of the GPL.  You have the MIT license which is used for X11 and a lot of Ruby stuff also comes in  MIT.  And you have the Mozilla public license which is not so much used but it is very popular  because the LibreOffice and Firefox are under this license.  So as in use of users Mozilla license will be still be very relevant.  So to illustrate the concept of licenses I find the icons used by Creative Commons quite  nice.  So this is actually from Wikipedia if you look up Creative Commons licenses.  And at the bottom of the graph you have the all rights reserved license which is actually  the default if you don't put the license under any, the code under any license.  But on the left side of the colors is actually the rights that are added.  And the first right that is added on Creative Commons is the right to share the content  or the code in this case which creates then licenses they call CC by ND or NC for non-commercial.  So you can actually for example music you can take a track from an artist and share  it as long as you don't sample it or create something that you put your name on it or  that you can share and use whenever there is no cost involved or no cost to the user  involved.  The next right there is remix and there you also get into the light green stuff but it  is still not open source.  Open source only starts when it gets really dark green because then you add even the right  to use in commercial products and to modify in this case.  The remix part is already there.  And there they have a big difference and on the top there is public domain what they call  CC0.  So it is a pretty long license that says there is no license or there is no problem.  You can do whatever you want.  There are other licenses that express this but CC0 is the more polite form.  But one of the big problems we are having as distribution is that we are not distributing  source, we are actually distributing a distribution which contains big mixes of derived works  from open source.  So you will find the same implementation of an MD5 checksum in many, many packages and  they this license the original author then picked the rives into each package using  it but the licenses that come with these sources are actually mixed within this binary within  our distribution and this mixing of licenses also means mixing of rules which is created  which creates basically a new license with new set of rules.  And not all open source projects are actually aware that you can't blindly mix open source  licenses.  Some you can, some you can't but not everyone knows.  For example, the version 2 and version 3 of the GPL is actually not compatible but that  was a big problem for KDE for example as we had KDE talks in front because KDE used to  have GPL only version 2 and Zamba came along with only having version 3 and then there  was a big problem and this was I think KDE resolved this by relicensing to version 2  or 3 and but very often licenses have explicit permissions to link certain libraries or certain  licenses.  One example of a licensing hell I wanted to show you but I'm not so sure about my time  as this very, very liberal office I'm doing the presentation in.  If you go to the web page it says it's free software.  If you look deeper it says it is Mozilla public license but let's see if my monitor,  I guess this.  So this is the about licensing dialogue which says basically it's Mozilla but if you look  the license of liberal office it's actually 189 pages and what Kiran or basically what  our legal review process has to do is reviewing this to verify that there is nothing hidden  that actually makes it illegal or impossible to redistribute, I'm still scrolling by the  way, to make it impossible to redistribute liberal office in open source.  So this is what I call licensing hell and I bet every one of you checked this before  using liberal office.  But fortunately you don't have to because you can trust my presentation skills.  You can trust our licensing review and so let's skip the rest of this talk and slide.  The one thing that came along some years ago is SPDX which is a common naming for licenses  in open source.  They have a big list of licenses and there is some committee deciding when there's a  new license coming around, if what name it gets and what the official license text to  this license is then so that as an open source project or as a distribution or as some vendor  I can express my open source licensing in a way everyone understands because it is now  clear.  So before we had open source I called it the pearl license that pearl is under.  Fedora still calls it GPL plus or artistic but the SPDX form that everyone then should  have is artistic minus 1.0 or GPL 1.0 plus which means GPL version 1 or later.  And this is just a brief example where you can already see that even the BSD version  that some say okay I'm BSD comes in so many flavors that it needs more clarification on  what exactly is required from the user or the redistributor.  So this is some small statistics I created from the legal license database and most of  our files in packages are GPL, public domain or BSD3 but you can see the list is quite  long but it's dominated by only a couple of licenses.  I already lost you I'm sure.  So how do we handle this licensing hell?  As part of the development process for basically every SUSE and open SUSE project there is something  we call submit request you might know and legal auto is some small review bot that is  part of this reviewing process and it reviews with help of some application the sources  and the spec file of the package and if this combination of licenses is known for this  package it will accept the review otherwise it will wait for a lawyer to review the combination  and approve it and after that the bot will also approve it and what the lawyer is using  is an external application also that the bot talks to and this I will at the remaining  time introduce this to you.  So we called it cavill after a long brainstorming session on what to name this because it had  a very boring name before and the reason why I wanted to have a good name is we want to  have this application open source we are not there yet but we are in the process of polishing  it so we can actually show it to someone.  This application is feeded by review requests from the bot and possibly developers directly  and will unpack, will check out the sources from the build services, unpack it recursively  and then does on the sources some multi pattern matching which means that it knows how a GPL  2 is marked in the source, it knows how a GPL 3 is marked, how a BSD is marked and it  will do this pattern matching quite quick and it will then present the lawyer's summary  on what files, what licenses were found and what files and how the combination looks like.  The licenses within this tool have a risk associated to it so that they are grouped  from more important to less important and each license has a different, a series of  pattern associated to it.  The reason why we need several I will explain soon enough.  All the patterns are checked in parallel on the sources and the longest version wins.  If the read me says it's licensed under the GPL we have a license that is called GPL unspecified  which needs more research.  If the text says licensed under the GPL version 2 then we name this GPL 2 0 and this means  only version 2 but if it says licensed under the GPL version 2 or later then we add a plus  to the license because then we can mix it with GPL 3.  The patterns allow to have a magic key word called skip that allows to ignore an amount  of words within the license or without the text.  So this is how the legal queue would look like in Cavill.  It has the link to the build service request to be reviewed when it was created, the package  name and some summary on the license report as we call them but basically the combination.  One of these reports for NASN would look like this.  They have several licenses that you can see but the most prominent is the purple part,  the low risk key words and all rights reserved are just noise in some sense.  So the purple part is BSD 2 clause and that's also what the spec file says so the review  would be rather quick but there's one GPL 2 0 file in there and the reviewer has to  check how this file is actually used.  If this is only a test case then this is okay because it's not shipped as part of the binary.  If it's content it's also a different story but if it's part of the sources then the overall  license changes so this has to be reviewed by someone who's really experienced with all  these licenses mixing.  Fortunately enough we have even more than one.  So the main story is why is this taking so long?  Some people complain that the legal review is taking too long or very long and as I try  to explain the situation is quite complex and for every file in the source code we have  to identify the license that this very file is under and then we have to find the combination  of sources that create certain binaries and then determine from there the legal consequences  that has.  So very often part of the review is finding the build process and finding what library  are used and what binary or if certain files or patches are applied or not and so this takes  a long time for more complex packages than what I showed you and there's no one working  full time on that and no human soul should work full time on this because this is really  if you and trust me I tried it if you do this more often in a row you tend up to be really  grumpy and reject more than you should reject because I just very annoying to see all this  stupid upstream projects doing so many stupid things with licenses and one of the consequences  this stupid things that upstream projects has is that we have to create repeatedly new  patterns for the same license.  The GPL each version has a very specific instruction what you should do if you want to release your  source code under GPL you have to add some very just copy and paste some boilerplate  to each of your sources and it should be formalized it should really be straight forward pattern  matching unfortunately there are literally thousands of variants on how people write  the code this markup.  The skip variables already reduce the number of variants that we have but still it's insane  what people do and this comes from real people really adding extra clauses to the licenses  or to the sources people adding just random grammar changes that they felt necessary people  that do global search and replace on their sources and unfortunately found a license  with that people adding random typos while opening the editor and or trying to quit  women I don't know.  So for example this is a pretty standard BSD3 license it has three clauses and at the end  says otherwise there are no warranties and no event show the copyright owner reliable  and blah blah blah the typical licensing stuff you click away when you install software  and then you have this which is basically the same conditions and I bet you did not  even spot the difference but I blink for you so it's just its contributors or their contributors  so it's just the same thing in English but for a machine trying to pattern match it's  really sorry what's on video so this is another example of the same thing where people felt  like removing stuff or adding stuff in pretty standard licensing so we have for this BSD3  we have I think a thousand five hundred different patterns that all look very much the same  but are random iterations of this and it as I said when you do this more often it pisses  you off and at some point you want to say to the package who is innocent get your upstream  projects fixed or I will not review this.  So there are some future plans for this application the most prominent is that we want to open  source the application and release it on GitHub the actual underlying algorithm is already  on GitHub we need to have these packages associated with a product or project so we can see actually  the status of factory if every package has been reviewed and we another point why we  need this association is so we can clean up stuff that is no longer relevant and currently  the updates are reviewed as basically new packages so we have to have some diff view  these are the short term plans and for longer term I am considering investing into machine  learning things because the process of defining new patterns is quite boring and as you can  see the patterns are very similar so the arriving one from the other sounds technically possible  to teach to a machine and the next thing is that I would like to have some pre some  support becoming more smart about what things he can approve on itself instead of waiting  for someone because it looks very, very similar to another package for example all these not  all but there are classes of Perl packages and classes of Haskell packages are basically  the same thing so I am if we remove my Antonio's time and my technical problems we have five  minutes left so if there is one question I could answer that otherwise I would leave  you for lunch.  Hi, I once was in a nice packaging workshop with my colleague Daryx and then I found out  that the mosquito package that we packaged there is distributed under a license which  is called Eclipse public license I think I filed a buck about it and the answer was  look into the license it's a standard 3D 3 gloss BSD license but the thing is it's published  on the Eclipse website as a copy of the BSD gloss under a new name so and it's also dual  license under Eclipse distribution license which is findable in the SPDL format so what  do I do there in such a case using the other license or?  So the naming license is very common so if I write Cavill and released under GPL you  will find several projects that name this license then the Cavill license so they in  documentation so they can change the license later without changing the application and  I guess this is one of these cases but case by case we have to review if this license actually  adds or removes rights from that other license and this is actually what SPDX does and if  I remember the case correctly SPDX even had a discussion about it if this is a new license  or just a different name for the same license so it's case by case but they then add not  the new name to the SPDX list if it's not just a copy okay only if it adds or removes  rights or if it's really really really popular already the SPDX discussions are public.  Albert what will you do if there's a license update to an existing package?  Like if the files change but the package doesn't bother updating the fields.  Here question and I have it prepared but I guess it's invisible because of my X render  problems.  So this is the latest XRDP update to factory and it is held to on legal review because  it's really stupid now because the licenses did not really change but to the machinery  there's a new combination and the reason being is that there is this is just to give you  another example so this is already Apache NGPL in the spec file you can see Apache I'm  not sure if you can see what I can see it you can see Apache NGPL and further below  you can see LGPL and MIT which don't map to the overall result and there are several  other licenses that are for random for random build tools so what happened in XRDP update  is it is just a patch update but they updated the build system to latest autoconf macros  which and the FSF puts their license in every file so what this brings now is no longer  GPL 2 with autoconf exception but GPL 3 with autoconf exception so this is now a new combination  to the tool and it waits for the lawyer to approve that the update is fine.  That's what I mean we need a diff view quickly because this it's very hard to find a needle  in this so what this is what we see we see the package is no longer having the same combination  of licenses it used to have and then we held and then we all did for review and this unfortunately  goes behind all the other updates.  Yeah I'll make it short.  You said to trust legal review process so you don't have to go.  You've indicated that users should be trusting the legal review process instead of reading  the licenses is that just like cross your fingers trust or is there any additional guarantees  that the legal review is going to be actually correct.  So if you have legal training you sure should read the liberal office license yourself but  for everyone else the chances of finding the problems in that license text of liberal office  is much much smaller than crossing your fingers.  So trust me if I say trust the review process I mean we found we have we this this whole  process is still not perfect and as you can see there's so much noise that you that it's  not so hard to actually miss something and as no up as to my knowledge no upstream project  is using such a process it is we are very likely to be the first to actually find it  so but the good news is most open source developers have good intentions when they publish their  code so even if they don't use a proper license but just put uploaded to GitHub for them it's  already open source so these good intentions is something that the legal review has to  take into account as well.  So thank you.  Thank you for having me patient.
openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_0_203.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_204_323.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_324_659.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_660_4223.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_4224_17219.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_17220_17639.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_17640_18755.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_18756_18899.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_18900_18947.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_18948_19007.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_19008_21491.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_21492_23915.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_23916_24095.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_24096_24251.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_24252_24347.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_24348_25475.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_25476_25523.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_25524_25571.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_25572_26027.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_26028_27827.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_27828_28163.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_28164_28487.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_28488_30383.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_30384_35387.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_35388_37763.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_37764_37895.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_37896_40283.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_40284_43907.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_43908_44087.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_44088_44183.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_44184_44771.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_44772_44987.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_44988_45419.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_45420_45503.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_45504_45599.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_45600_45875.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_45876_45995.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_45996_46607.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_46608_46883.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_46884_47723.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_47724_47807.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_47808_47927.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_47928_48707.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_48708_48755.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_48756_49283.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_49284_49559.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_49560_49655.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_49656_49847.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_49848_49895.png openSUSE_Conference_2017_openSUSE_Legal_Review_Pro_5DAjSwKcVzI_49896_50010.png