 This is how to get your release through the Incubator. I'm Justin McLean. I've been a freelance developer for about 25 years. I'm on the Incubator PMC, which is why I'm giving this talk. I'm also on the Flex PMC and a few others as well. I'm an Apache member and I'm also a mentor for several incubating projects and I can see a couple people in the audience who are part of those groups so that's good. I have reviewed more than 200 releases at the Apache. Some of them quite thoroughly. I also happen to run an IoT Meetup in Sydney and you may have come to some of my other IoT talks that I've given at this conference. Now, first off, I am not a lawyer. I have not been trained in law and I think legally I'm not supposed to give legal advice. So I am mentioning licensing and a few other things in this talk. So just be aware that I am not a lawyer. Occasionally I do get things wrong. My understanding about licensing at Apache has changed over time as well and policy does change over time as well. Sometimes it's complex and there's more than one right answer. Sometimes one project will do one thing in one way and that's good for them but that may not be the right answer for another project. This is why this is sometimes confusing. I'm also a volunteer and I'm not paid to do this so and this talk is my own views and may not represent the incubator as a whole. The incubator is quite large, has lots of people on it and they have lots of different opinions about things. If you hang out at the incubator mailing list I'm sure you might have noticed that by now. So the whole process about incubation is to make sure that a project coming to Apache follows a couple of things. The first thing is that the project must comply with the Apache 2.0 license. It must follow the AF structure of contributors, committers and PMC and have the right checks and balances in place so that it operates like other Apache projects. There's a bit of freedom in there. PMCs are mostly left alone to do whatever they want but there are a few things that they do have to follow. They have to vote on releases. They've got to vote committers and PMC members in. They have to grant more responsibility via metriocracy. That means if they see someone who is contributing to the project they should vote them in as a committer. They have to ensure that decision making is done in the open. If it's not on the mailing list it's not on the mailing list. You may have heard that or if it's not in the mailing list it didn't happen. So and also have to ensure that people act as individuals not companies. So when you're on an Apache list you are not representing your company you are yourself. Your job may change. That means that you may not be involved in this project anymore. Well you may do. I don't know. But companies are not members of Apache. Individuals are. And all of this sort of comes under a thing called the Apache way. And most of that is some of it is documented. Some of it isn't documented. Some of it is tribal knowledge. And we just hope that by going through the incubation process we show you enough that you can come to the same point that other top level projects have. So the vote process. Who here has made an incubating a vote under the incubator? One, two, three. Hi, welcome. Have a seat. Who here is going to make a vote? Right. That's what I expect people to come along to this talk. Right. You want to make the process as smooth as possible for you? I'm going to tell you where I've seen other podlings have some issues and how to fix those issues. So anyway the process is that the podling creates a release candidate. They have a vote on the mailing list. Generally open for 72 hours. And they have to have three plus one votes and more plus one than minus one. If that vote fails you make another release candidate. Fix the error. Make another release candidate. And then repeat. Vote on the dev list again. Then once you've got to vote the passes you need the incubator PMC to vote on that. And exactly the same again. You need three plus one votes and more plus one than minus one. But they have to be by incubator PMC members. Now quite often you'll get incubator PMC members voting on the dev list as well. And those votes can be carried over. It's a good idea to mention that in the vote email that goes to the incubator list. Then if the vote fails on the incubator you have to go all the way back to the dev list and go through the whole process again. So you may not get this right all the time. And it used to be that the incubator was harsh I think is the word on poddling releases. In more recent time there's been a bit more forgiving. If you've got some a few mistakes in there your vote was still likely to be passed but you'll be asked to fix it up next time. Yes. Can the mentors vote on a release? Yes the mentors are considered part of the PMC so their vote counts. Yes that is correct. And you can either vote in both places or carry them. Yeah we'll just say you've carried the vote over. So yeah so stay to play. We have 60 plus projects in the incubator. We have about 250 incubator PMC members. Not all of those are active. I would guess I don't know. A dozen people are very active. 50 people occasionally pop up on the mailing list and argue about something. So there's about a dozen releases a month and about 70 percent of those releases pass the incubator. These are stats from the last few years. A little recently in the last few months I noticed that some of the releases haven't been voted on as quickly as they have been. That's mostly because I haven't been voting on things I think. But there are other people who vote. It's not thankfully it's not just me. So yeah if you need help these are the places to go to. If you need help with dependencies and licensing then go have a look at the legal previously asked questions. That gets updated on a regular basis so if you haven't looked at it for a while please look at it again. There is an incubator release process which is continually in draft and continually updated but it has a lot of very good information in there. And these are the two links there that you should go and read. And probably the best one to have a look at in terms of getting you on the license and notice together is the licensing how-to which is at that link there. So please read these. These will answer most of your questions. If you're unclear about anything on this documentation please send an email to the incubator list and hopefully we'll fix the documentation for you. There's also the Apache maturity model. This is not policy but it's a nice idea and you may want to look at that to see how your project is along the line to graduation by seeing how it fits in with this. A few incubating projects do this but it's certainly not required. There is also the legal mailing list archive. Often searching through that will give you answers to questions like if you have can I include this license in my project you might find that that has already been answered it's not in the FAQ but it's on the mailing list and the same with the legal JIRA that is another place where you can you can find sometimes fine answers. This is roughly how I voted on more than 200 releases so 180 of them good 54 of them no sorry do it again I try not to be harsh and I and again I definitely do so in most cases you know try and fix it up next time but there are certain things that we look for that really you know you've got to do better so here's why I voted minus one. Number one reason is binaries in source code. The Apache foundation makes source code. We need source to not have compiled code in it so that's the most common issue. Licenses are classified by category A, category B and category X. Category A are licenses that are compatible with the Apache license. Category B are ones that you can include in binary distributions generally and category X is you can't include them or depend on them. GPL is one of the category X ones and so on 10 occasions I've had to vote minus one. Now I do know of one occasion where a release was passed with GPL software in it because they got permission from VP legal to do so and they said they were going to get rid of it the next one so even if you think that your vote may not pass if you say we have these issues and we're going to fix them in the next release then that's a good way to go rather than saying oh no we're not going to do anything about this at all well we didn't know that was there so quite often if you explain things it's more likely that your vote will pass than not. Eight of them include category B license software in the source release which again is not allowed and the rest of them are a few things licensing and notices issues generally they're not so severe but just in some cases you know if it's like nah sorry you need to do a bit better than that. Copyright issues have come up a few times so it's included code that Apache couldn't distribute or didn't own the IP to. I'll come to some examples of those later. Missing headers were header issues if you're missing just a single header or so forth your vote's going to pass but if you've got a hundred files missing headers where it's very unclear what is Apache licensed and what isn't Apache licensed then your vote is probably not going to pass and there's also some restrictions on encryption software thanks to the US government so you've got to be careful about including encryption software in your in your code as well. Yes okay so the question was what type of encryption software counts as encryption software and the answer is I'm not 100% sure. I believe if it's a like a public private key type encryption thing and it's more than 256 bit encryption you've got to apply for a license an export license for it but the rules I know have changed recently I'm so I'm not a US citizen and I'm not a up on exactly what's there. The information that we do have on the incubator is definitely out of date but I don't know if we've got anyone who actually authoritatively knows what the current legal situation is or not so the best thing to do is if in doubt just go through the process of registering it and that is documented so if you're using an md5 hash that's fine you know there's no problem with that if you're using decrypt yeah you need to do something about it if you're using if you have ssl code you'll have to do something about it. Do you know what the particular example is that you have? I use uh yeah in some cases it counts in some cases it doesn't I think that's what it comes down to it's not that clear cut sorry yeah it can be complicated and it's a complicated legal situation so but there will be people who can help and there's a fallback is that you just say yeah I'm using it and then you're covered basically so um a minus one vote is not a veto so just because you get a minus one vote on a release doesn't mean you have to do it again um it may be that I'm feeling particularly grumpy that day and it's like nah don't like that um if someone votes minus one you can try to change their mind uh you can say all right I'll try and fix this up in the next release uh well you might say well it's not so much of a problem because of whatever um so don't be discouraged if you get your release put it up there and you immediately get a minus one um people will also put up conditional votes they'll say okay minus one unless you fix this in the next release and if you say I'm going to fix this in the next release and here's the juror then good I'll change by vote so um that being said if generally if someone votes minus one there's probably a good reason why they did so uh so there probably is something that needs to be fixed there um and you should look into it and try and fix it in the next release but it doesn't have to be perfect the whole point of an incubating project is that you don't have to get it right first go you're trying to learn this process and go through it and you may not be familiar with asf policy or licensing rules or everything at the start um our policy certainly has gaps in it it doesn't cover everything there are odd situations that come up around licensing all the time so um just point it out in the release candidate if you have something odd in there and you're not too sure what to do with it just say okay we've done this this is what we thought was the best idea to do this um if it has no surprises inside it that's a good thing all right make it easy to review um people on the incubator PMC are volunteers their time is limited um don't make them think too hard about it all right provide well-named artifacts don't try to be clever with licensing or headers uh include compile instructions in the actual release don't point them to a web page and make it easy to compile if you can all right all of those things will make it means it's much more likely that someone will have a look at your release and vote plus one on it now i our incubator PMC documentation can sometimes be confusing can sometimes be out of date uh in recent times it's actually improved uh significantly i think but there is still a lot of cultural knowledge that isn't well documented um and the PMC is large and has a lot of differing opinions on on what is correct i think there's mostly consensus about around most things but occasionally there's a few edge cases uh like in terms of binaries inside source releases there are some exceptions for build tools and there's sort of a bit of a debate that's been going on recently about what you can include in a source release and not if it's a build tool um often there's multiple ways to solve the same issue um so i think the right answer here is if there's any doubt like should i should i leave this header alone well should i include this header on this file just do so it it makes it easy and it's it's often by including a header that you don't need say an mit license for example um you're not making a licensing error it's just a documentation error but if you leave that license out it is a licensing error uh and it needs to be in there so often there's a a path that you can go down that while it may not be 100 correct it's okay so um some of the problems i see come from copying what top level projects have done um just i'm not saying that any top level projects have done the wrong thing because that's not part of the incubator's responsibility uh but policy does change it over time and there may be historical reasons for why a project is doing something in a certain way uh it may not be immediately obvious why you know that's happening so just take care when looking at top level projects and the examples and don't just blindly copy what they've done um yeah in particular a couple of big data projects but i won't mention any names it's a better idea to have a look at projects that have recently graduated so um one of the other things is that in order to pass a vote releases must be signed um it's a good idea to use an apache.org email address rather than a hotmail address as i've seen on one occasion you know randomperson27athotmail.com i don't know who you are i'm not sure i trust this release so use your apache release to to sign it um make sure you have a disclaimer in your release uh it's not required to actually put it in a file called disclaimer it can actually be on the website i look through the documentation that's what it says um most common though it's actually put in a file called disclaimer sometimes the disclaimer is also put in the readme and and both of those those are fine yes yeah yeah the disclaimer just says this is an incubator project um i can't remember the exact wording but yeah it's almost every single project has one and you just take another one and just copy the name so um good idea to tag releases not essential but it's a good idea that means you can recreate the the release at a later date and um it also means that you can easily compare what is actually in the source release to what is tagged in github uh well subversion if you're using subversion um so um just one word of caution is that git tags can be edited and changed so make sure you provide the hash in the vote email so that at at some future point in time if we ever had to go back and recreate the software from scratch from from version control we could double check that uh licensing this is where a lot of issues seem to occur um and i think some of it is that most of us are just developers and don't really want to understand licensing it's just like why do i need to know that it's all too hard and complex and you know um and it's certainly a language barrier as well even for people who speak english it's it can sometimes be hard to understand what something actually means uh and it can certainly be complex and policy can change over time as well so um you do need to keep up to date with this um i i have to say though that we're not the only people who have difficult with licensing if you look at open source projects in general apache tends to be a lot better much much better on average than some random project on github um and that can cause some problems if you start using stuff on github in your own project or from elsewhere um external projects often have unclear licenses they often include code under different licenses and don't mention that um sometimes they're incompatible so you will see a project that is licensed mit but it contains gpl code in it it's like ah that's not good if they are apache licensed they generally are missing a license a notice file which is is required by asf policy but it's not required by the apache 2.0 license but that causes problems if you want to try and include it in your own own project um some of them try to be funny don't do that um here's one trying to be funny um this is from uh android um it has 33 copies of bsd in it yeah it's got uh i think most of them are the same but there are a couple of variations in there yeah but it's just like why would you do that um here's a check in for a license that i don't know if you can read that uh but it is uh they've changed the license from um um w uh um yeah i'm gonna say that what the fuck public license to uh or let's do whatever the what you want license basically um which is actually a permissive license under the apache license um there was some debate about it whether it was actually too permissive and doing what you want could mean you could ignore patents and copyright and ip and all sorts of other things but it was decided that it was okay um so they had to change the license from that to i think it's mit no isc um and yeah because of lintel uh intel lawyers complained about the the license it's like ah whatever uh yeah and that that's the that's the get the tag on it um this is a nice license uh have i got this um yeah only dead people can use code well sorry only living people can be used to code it's it's like yeah don't do this this file is good up the top of it we have a gpl at the bottom of it we have a bsd how is it licensed i've got no idea so yeah as i was saying just try and err on the side of caution so it's better to say if if you're including something and it's mit license but you know for whatever reason you may not be 100 percent sure whether you should include an mit header or include the license information just do so anyway um worst case it you didn't have to include it but that's okay oh sorry best case is you didn't have to include it and that's okay and you know it's a minor issue but nothing that can be fixed in a future release but not having that mit license there is actually not agreeing with the terms of the mit license um so basically the whole principle behind this is the concept of a universal donor which gives anyone confidence that they can use our software without any legal issues um and that's a big thing um it means that all software with inside a release is compatible with the apache 2.0 license and it means it can be used for any commercial and non-commercial purposes uh so most large companies are going to get their lawyers to go over everything and you know check it but that's them but it it it means that you can have confidence in using the software without having legal risk uh which is a big thing so when you're assembling a release there's a guiding principle um and that is that the license and notice files must represent the contents of the distribution that they're that they're in so don't mention stuff that's not bundled uh if you have an external dependency that you link to um but it's not actually included in the source release it doesn't have to be in the license as long as it's compatible with the apache license so and this applies to both source and binary artifacts so your source and binary artifacts may actually have different license and notice files so that is a common mistake yeah question look back there uh you can make a dependency file and put it in that well you could put it in your readme that's yeah either was fine there's no there's no asf policy on on doing that so it's up to the pmc to do that however they want not that i'm aware of anyway um yeah so when you're bundling stuff have a look to see what's actually inside it um sometimes you may get some surprises um particular look for category b and category x software again that those categories are listed in the legal faq um look for photos or fonts or other resources that you may not have permission to um distribute um no it doesn't mean you have to go through every single file and look at it with a magnifying glass um you know you have to make some assumptions at some point in time and quite often you know you don't know if someone's copied two lines off stack overflow and pasted it in into your code so it's but you know just have a look to see what's actually in there um and you may find some surprises um one good way to check for those surprises is to use rat who here's heard of rat well uses rat yeah cool okay um it's a good tool for finding binaries and licenses in your source release it's not perfect uh it only understands about a few licenses and it doesn't find odd things like double headers if you've got that issue that i showed you before with the bsd and the gpl license in it it won't detect that um another question up the back there yeah yeah you may when when you're making making a source release you may exclude some things from the source bundle that you put in you may put them in there or you rat may complain about things and you put a rat exclusion file in there so it doesn't complain about them um just so you know i generally run rat manually without exclusion files so i can have a good look at everything because that's sometimes a common issue is that the exclusion files are too wide and they they miss things they get put in there um yeah so you just be a little bit careful with the exclusions so um this is what the rat output looks like um it's sort of quite nice so that's just showing you you know what files have unimproved licenses in there and whether or not has a license or a notice file and that sort of thing and whether or not you've got any binary files in there and you can see some mit license files there as well um there's also this website compliance rocks um it's like rat but gives slightly different results good idea to run both hello goodbye so all right and this is what the output of that looks so you are basically upload a zip file it compiles it tells you what's there what's not there uh all the rest um this is what i generally do though i actually use the command line quite a lot um if i'm trying to find licenses i use this little script here this nice little grip script and i generally pipe it to um to uh sort unique so um i i get things so you just search for common license names like gpl bsd mit and that'll generally pick them up straight away um also search for copyright and and see what that gives as well so it's not perfect but you know it it it it's a nice way of doing it that gives you a hey come on in um javascript javascript files are a pain i'll just say that again because the door closed javascript files are a pain often because they're minified and they're missing license headers so you often have to then find out what the javascript files are go find out where they're hosted find what the license is um and a lot of them are not under under licenses that are not compatible with the Apache license so you have to be a little careful with that um also a lot of javascript files the licensing has changed between versions so you have to know what version you're including as well to make it doubly sure so you may have to look very clear carefully and they also may include other javascript files either embedded inside them or whatever so um you need to to to look at that jQuery and Bootstrap are two that bundle other stuff inside them as well um i had to vote minus one on a release once because it had a cat photo in it um it was a professional photographer's cat photo they just wanted a big photo that they could put in there and they like the picture of the cat um i'm sorry you can't do that i didn't want to vote minus one on it but you know you can't take something that you don't have permission to distribute um and include it in a release uh so generally what i do is i say you know let's have a look at all the images copy them into a folder and then just view those as icons and see what's there um and then if anything jumps out at me i'll i'll try and find out what um that may have come from and generally a google reverse image search will find it for you straight away and it's like oh yeah let's copyright this guy ah sorry so um fonts licensing around fonts can be very very complex uh it's changed a little bit in recent years with google providing a whole lot of fonts under the Apache license uh but if you do have fonts in your release look at the font metadata um make sure you have permission to distribute them um and fonts are binary files and it may not be immediately obvious how they are licensed to someone who's reviewing your release so it may be a good idea to put that in the license file you don't have to uh but that that at least that way you've documented it and no one people don't have to keep double checking the what is the license of this font um now the licenses that i've been talking about so far there's there's certain legal obligations you need to comply with like the MIT license says you must include the text of this license that's about the only restriction that it that it has um Apache policy adds a little bit more um and as that is that you must have a notice file and all the licenses must be listed in license probably even if they're not required that's it's not set in stone but it's it's it's a good idea to do that again from a review point of view um so the license file is in the root directory and it's either called license will license dot text and it contains the list of license of the it contains the Apache license and then a list of all the licenses of the bundled software now notice it's only the bundled software not what you depend on um and there's two ways that you can do this you can either take the full text of the license and stick it in there or you can put a short form that just has a pointer to the text of the license now that pointer is not a url it's actually to a physical file uh the reason that you don't want to put it to a url is that urls change over time or may disappear or may die or whatever um license again may be different for source and binary files because they have different contents so you need to be aware of that question out the back um i i have seen that in one or two projects it's probably okay but it's it's a little confusing unless it's clearly marked so sorry the question was could i could i just have one license file that included all the licenses for the source and binary but clearly mark that one section is for source and one section is binary and yes that is okay so here's a example license file well and then we have the notice file now that contains the asf copyright i believe and it has a year in there and you need to keep the year up to date um and it only should have what's needed in there the reason for that is that anyone who uses your software must take the contents of their notice file and add it to theirs um so generally what is only required is relocated copyright notices so things that have been removed from source code that are not no longer clear any required notices from other included apache software and anything else now the documentation we currently have isn't really clear 100 on what goes into a notice file it says all required notices other than these things except if this it's like makes no sense whatsoever but not much at all needs to go in a notice file that's what it comes down to you don't need to list all the copyrights of all the software in the notice file only ones that the headers have been relocated from um anything that's a licensing information should go in the licensing file it shouldn't go in the notice file so it's generally fairly minimal but it's often where where mistakes are well here's a very very minimal uh notice file here so yeah as i was saying with the required notices there's some confusion to what a required notice is um about the only thing i can think of is advertising clauses um but the issue with that is most things that have advertising clauses are actually category x so you'll never see them in a notice file so um but if there is a required notice uh you must include a link to the original source uh oh sorry some category b software requires you to have a link to the original source and how to get the original as a requirement that should go in the notice file and some licenses require that you must state any changes have been made um so that would probably go in the notice file as well so but there's not much that needs to go in there and there's certainly a bit of relay about what gets included and what doesn't get included yeah some some people have very strong opinions on it though so if you yeah so i mentioned the the license categories uh before so there's category a which you can bundle in your software and you can depend on and will link to or you know whatever it is um basically they don't add any restrictions above and beyond what the Apache license 2.0 does so common licenses uh lichens that's a good one common licenses include it's sort of like licenses just grow on you common licenses include the Apache 2.0 license Apache 1.1 uh two clause with three clause bsd without the advertising clause uh mit or x11 is originally known w3c unicode cc copyright only and the w2f public license um so you can include all of those and as long as that you mention them in license you're generally good category b licenses you can't include in a source release because they contain some restriction of use generally there's they vary a little bit um by including them in a binary form it means that limiters the chance of the license corrupting the Apache license and that's generally good so the common ones you'd run into there uh the cdl the eclipse license and the mozilla license and creative commons attribution as well um that's only for uh media i believe the creative commons one you can't have code that's under creative commons attribution so there's there's some some restrictions around that and then there's the things that you cannot include and cannot depend on and that generally is gpl lgpl any sort of non-commercial license um jason jason has been recently added uh because of the uh do good not evil clause which is uh open to interpretation uh there's the four clause bsd license and possibly the Apache 1.0 license uh which is sort of a bit odd um i yeah it's come up a couple of times and people have just said uh we don't want to go there but it my reading and understanding of it is that you couldn't actually include Apache 1.0 in an Apache 2.0 product um yeah we don't want any unexpected binary files in the source release um so that's no executables drls jars or class files please you can include images you can include fonts you can include stuff that is binary but not uh source code there's a few exceptions i've seen releases pass that have um like fake jars for a test like the jar is actually empty it's not really a real jar it doesn't really contain code but often there's a way around this and that is just to take the code and compile it as part of the compile it into the jar as part of the test anyway so just this is generally the number one reason that the releases get voted minus one on you need to have all the license source file must have an asf header um be careful about that because the asf header has changed a little bit over time from the 1.1 to 2.0 and occasionally i still run into asf headers that have copyright lines in them you should not have a copyright line unless yes yeah the uh the question there well the clarification i guess uh was that the apache license itself has a header that says you should use in your code don't use that one that's what we want other people to use uh asf has their own policy and they have their own header that you must put on all of your code um that's very clearly documented though on those links that i've pointed to you before um make sure that people can compile the source um have clear instructions on how to do it if it doesn't work on a certain platform note that all right um you don't want to have someone spend half an hour trying to get it to work on osx when it never was supposed to work on osx um if you need to some setup or you need to download third party components to get it to compile write that down make it make it easy for someone to be able to review your release and you're much more likely to get a plus one vote um one of the things i've done um i'm hoping to do a few more of these but i haven't really found the time so far is that i've made an affictional apache project called apache wombat um and i've uh put it up in github and i have step by step text and explanation showing how i would make the license and notice files and i've also made a short video of five minutes showing how i did that so it's fairly clear and straightforward um you might want to go have a look at that um and this is basically the steps so it's using bootstrap um and what i do is i get boilerplate license and notice files i update the notice file to have the right copyright year copy correct copyright in year now we're including bootstrap that's mit licensed note that different versions of bootstrap have had different licenses so you've got to be careful with that and i think bootstrap four has new license as well i'll have to double check that but it does in bundle other things as well now so that this will change if you were using bootstrap four versus bootstrap three um if you have a look at the the contents of the file you'll notice the html shiv is being used that's dual licensed mit gpl if something is dual licensed you take the most compatible license so in this case i think well we we know gpl's category x we don't want to use that mit is a compatible license with the apache license so we use that and we add that to the license file um there's also respond.js and query in there so it uses those things but they're not actually bundled so we don't have to mention them so you don't have to add anything to the license file or notice file for that um if you look inside the bootstrap code at some point in there it uses normalized.js so because that is bundled we do need to add that to the license file and that's mit licensed again mit is a compatible license so there's there's no problems there and lastly we have some font files which are glyph icon now try to find how these fonts are licensed is a little tricky because if you look at the metadata it actually is incorrect but if you go back to the source of where they came from and bootstrap it actually says they're licensed under the bootstrap license which is mit licensed so um glyph icon was a commercial product and they made some deal with bootstrap to allow for use of their fonts so sometimes you're going to run into complexities like that even with well known software like bootstrap um there's a few nice to have as well these are not required but they just make things easy having an up-to-date read me so we know what has changed from one release to the next release always helps uh for example if you if you have a complex licensing situation uh and your last release pasts and you note in the read me that there's been no third party files added uh the licensing is going to be exactly the same so you know we basically don't have to check that um list all the changes and make sure you have a keys file published so that people can actually verify the signatures on on your release um common mistakes as i said unexpected binary files in source releases contents of license and notice files the source and binary have the same files when they should be different not putting the release in the correct place um less common recently uh but for a while people were sticking them in home directories and sticking them up and maven and not sticking them in the the the proper release area um missing disclaimer is happens quite a bit too surprisingly um and missing headers as well that's not so common but just be careful with the rat exclusions and make sure that they're not too wide and you're you know uh just because it's testing code and it's you know it still has to be licensed correctly you you need you need to make sure of that uh the other issue with binary releases is that they have to comply in the same way as source distributions but the contents could be different and so you may need a different license and notice file best way to do this is to actually look inside all the jars that you have in your binary release and you can just do that with with like text editor uh because generally they're just a compressed file and you can see all the path names there and if you look at all the path names you can generally work out what's bundled and what licenses they're there they're they're under um if you make some mistakes with the binary distribution uh people are probably not going to vote minus one on it unless it's really major um because they're not actually official releases um so they're provided for convenience only it's the source release that that is that is the more important one so where to ask for help um ask on your mailing lists ask your project mentors ask if you don't get any luck with either of those ask incubator and for legal questions ask legal discuss um every few years this crops up um the incubator is broken i don't think it is i think it works pretty well actually um there's room for improvement that's for sure um and it adds a lot of value for a small amount of work for those involved uh it it's quite what i said we had 60 plus incubating projects we get through a dozen releases a month something along those lines um that's for a group of volunteers we don't do too badly but um if you want to see if another good way to to to work out whether you might run into problems or not is just follow the list a little bit i'm not saying read every single email on it um and just see have a look at other releases and why people voted minus one on those and you'll see that that that that may be some issues that you may have to run into um and we can certainly do with more help get involved i think one of the one thing we are doing wrong is that we put puddlings through this incubating process and have the people that are making the releases uh they then become top-level projects but we don't see them again those people who went through the release projects are the perfect people to review other releases in the incubator um and currently how it's set up is that um generally you have to be a member to be asked to be included in the incubator pmc there are a few people who have done it the other way in that they've just turned up on the incubator list reviewed a few releases and so forth and have actually been voted in um i think myself and john uh two people who've done that um i don't know of any others um so yeah get involved yes yeah last one is something that if the people who do it should be thinking yeah if you vote on releases even though your vote is not binding eventually we'll probably vote you in so it is binding uh but it gives a good indication that someone else has looked at the release and if you find a problem then other people are likely to change their vote uh well if you say that it's a good thing then it's probably a good thing and it gives other people confidence that they're more likely to vote plus one um that doesn't mean that everyone who voted on the dev list like if you had 20 people vote plus one on it should jump on the incubator and vote plus one that's um another good idea is when you're voting on releases actually list out what you've checked uh rather than just say plus one like it's like okay i i don't know whether you just looked at it and said yep that's good or whether you actually you know got a magnifying glass out and had a bit more of a closer look so that's a good idea um so yeah any ideas on how we can prove contact us email us at the general incubator that Apache at all um we're happy to talk about it probably a little too much uh so yeah just um Apache rat is another tool um it's also Apache whisker which i haven't actually looked into but it looks like a really interesting idea and that it describes licenses via metadata uh so you might want to check that out um it could sort of automate the whole licensing thing um it's it seems like a lot of work i have to say and there's almost always exceptions but i like the concept um yeah okay so that's it from me do we have any questions yes uh so the uh exactly what you gave with the Apache long battery included bootstrap css and all that stuff um and validated licenses um is that just applied for um projects that are actually uh releasing bootstrap in the like the actual project versus just the website for the project like you have to do license validation stuff okay so the question was do you have to do license validations for the website uh if it's using bootstrap um the answer is no but it depends whether you include the bootstrap code in your source release or not if you had a website um and your source release didn't include the website then you wouldn't need to mention bootstrap in your source release yeah it is only if it's on the release you can put whatever you want on your on your website there's no no issues around that yeah yeah no no other people's cat photos please uh any other questions yes okay so signing of pjpks you mean actually signing a religious self or getting your key signed to become part of the web of trust uh yeah it's it's a little complex uh it is well documented though uh i can't remember the URL off the top of my head but there is a an Apache page that goes through step by step by step what you have to do um and ask your mentors for help they they will they will definitely help well what you can do a couple of things with your keys um you can publish them there's a um a public server that you can publish them to and it may that may have already happened and generally when you run pjp it will get look for the keys at that server um the other thing is you make a keys file and you put your your public key in that and you you distribute that with the release so as long as someone can get hold of the key um in one way or another you can also attach it to your Apache login in some way and it's recorded in LDAP but i can't remember exactly what the steps are to do that yes okay we are out of time so thank you very much for coming along