 So, the topic of today, what should be allowed to call itself Debian? There's more and more pre-made images and similar things by various companies who obviously have a strong interest in their cloud product or whatever being called Debian for marketing reasons and we also have an interest in having useful things called Debian. On the other hand, if there is too many changes things or expected expectations might break. So, there should be a common baseline, a rule set, guidelines, common of you want, which help people what they can expect if a certain name is attached to a certain product or image or what have you. There may also be different variations of this is Debian, this is based on Debian, this is Debian by X. There are several possibilities which are floating around. Yeah, so that's basically the topic for this one. Does anyone want to start or? We discussed it yesterday. So, one thing that I'm curious about is that one of the really big performance of Debian is that we have our stable releases and they are really, really stable. We've tested everything, we've uninstalled, we've upgraded, we've done everything we can do. And I would think that for something to be allowed to call itself Debian it needs to have gone through the same level of testing. So, right now for example we have, you start with, you always install first the call system, right? And then after you've installed the call system, you run the installer or pre-search script or something like that, which gives you the next stage and then you can install packages and that has been tested really, really aggressively. If you do things in a different order, we don't actually know anything about whether it works or not. So, I think we should think about that. Think about do we want to be the recipient of public policy and do we want to be responsible for that system being stable when it's done in a different way that we don't actually understand most necessarily. So, maybe the answer is to get processes into the Debian project for how to build systems in different ways so we can test it, so we can know that it works. So, we can know that for some packages you can install them in a non-standard way. I think you have something to say. So, if we, if those cloud providers build images based on Debian stable and just use everything which is in Debian stable, we are fine to call that Debian? Do we agree on that? Not if it's, today I wouldn't say you are, but today there's a real example of the Google at the Amazon images yesterday. Google images very carefully say this is not an official Debian, this is modified. Yeah, but if those images are not modified, everything comes from Debian stable. But if it's installed in a non-standard order it might not work. What is the bootstrap? The bootstrap, if it's just the bootstrap and then made it... It's very easy with the bootstrap to make as it's the next drop. Even using the only standard package. So, yeah. So, what I see a problem with is the Amazon image which is made with everything that is in Debian, but it needs the Amazon infrastructure to be closed. And that bothers me because obviously the Amazon infrastructure is not free. And then we create, I mean, Gems is creating an image which is made of free software but built with something that we don't control and that is sort of the service, so completely non-free. And then shall we call that Debian? I'm not sure. In fact, I don't like it and I would... It's my opinion that we shouldn't call it Debian. Is there anyone that shares that opinion? Shouldn't call it Debian or just say that it's non-official image? That's different. It is Debian. Yeah, but I think what we care about is having that is called official Debian or not. The fact that it is based on Debian, I mean, we have many derivatives and such, right? I would put like two categories, one official Debian and the rest of. Officially. Officially. Okay, but go on. What's your definition now? I didn't mean to jump to one though. Go ahead. So, I've got adding a definition for something that's called Debian-based and then as to provide us to call this Debian-based image. What's that for? The point is to know which one we certify as Debian-based by the project, okay? The rest of, like, everybody can say it's Debian-based and we don't have to control that. I think we'll know what's next. We do have something which is very stable and we call it Debian-based. If anyone of you is running CID at the moment, you'll see that we are not quite as stable as all that. So I think it is perfectly fine for people to create images. This is stable Debian. This is testing Debian. This is bleeding edge, unstable Debian use at your own risk. And I do want to make a distinction again about official Debian images. I'll go stronger and say, official Debian images are created by Debian developers, maybe by the CD or the release team or whoever steps up to make cloud images, but it will be something delegated by the DPR. Based on Debian can be, as long as it gives you a Debian experience, I'm fine with that, even if it is made by property tools. But again, should it be just said it's official or because based, let's say, if I just use Debian and build it, it's not based on Debian. It is Debian. It's just non-official build. So it's not done. It's just based. No, based if I take the base and then build up and fall. That would be... But when we look at CD images, we have a long history of that. CD images which are labeled Debian official are not just take the base and build the top of it. We provide a set of images that can be burned on CD's. But anybody can take net install Debian and add things onto it. There are all kinds of rescue disks out there. They're based on Debian, but they're not official Debian. I don't see the cloud images being any different. I sort of view... Well, as far as based on Debian goes, I don't view that as something that we have the right to or script as long as it's accurate. I just view it as purely descriptive. I don't view it any differently than made after having a conversation with a Debian developer. If it's Windows 10, it's not based on Debian, that would be misleading. If you take Debian and then you add a lot of proprietary Oracle junk, it's still based on Debian. It's just not Debian. If you call it official Debian and Debian does not heavily in control of the build, release, certification, testing process. If it doesn't meet any Debian's ethical standards, et cetera, definitely not official Debian. I view there as being a wide middle ground called Debian. So, for example, if somebody takes the Debian installer source code, builds it on their personal machine, doesn't run through whatever validation the DI team does, and installs it, it's Debian. But it's not official Debian installer disk. And similarly, there's a lot of ways you can modify things without changing the essential nature or the supportability to a great degree. That was called the Debian. I was just going to say, I think, although we're talking about a lot of cloud images and so on here, some of the issues, and they're different from... If you imagine there were a lot more companies selling laptops with Debian pre-installed, there's exactly the same issues there. I don't think we can really stop someone saying, this is a laptop with Debian installed, even if they added, they installed Debian and then also installed Flash and random other proprietary junk. It's true to say it's a laptop with Debian installed. Yeah, well, indeed. But I agree on top of that, there may be some special status that we want to give people beyond that, that they say this is somehow a blessed, approved Debian installation setup. But that's a different thing. You can't stop people saying it's Debian if it is Debian. I mean, if they're being truthful, they installed Debian on this thing, whether it's a laptop or a cloud, it is a Debian system. Chris, I just wanted to say one thing which is for me the important difference. I agree with everything that's been said, by the way, no discussion about that. Note to self and to the bear. Importance, the current Amazon image has a percentage of their stable Debian official. And that's actually wrong. So that text has to be fixed. Somebody owns that and somebody needs to fix it. And so with regard to the Google images, I no longer work at Google, but I did when this conversation happened. Google consulted on the Debian cloud list with regard to whether to call it Debian. And I don't believe there was an official conversation with the trademark alias, because I think at that time that was operating in a more dormant and less formalized way than it is now. But I believe Brian did speak up as somebody who was involved in both categories. And the DPL at the time and the prior DPL, so Zach and Luca, were in the conversation as well. People were fine with calling it Debian, but not official Debian, because the deviations were justified, small, documented, and there was a desire to fix them and everything with free software. But my point was that that needs to be fixed for the Amazon. My point was that the important difference from using the cloud is the bug recording. So anything that's a Debian derivative, if we had this discussion with you once, all bug reports sent from that system should first go to them. So if Google has an image, all bug reports sent from any user of that system should first go to Google, and they can talk with Debian about it if it's... They don't currently make that change, but they will support it if there are more contract people calling them. I think we should state that somewhere, that if you're not really Debian, we really ask you kindly, please, if you want to be a good citizen, you should take all third bug reports through Google. Do we enable it easily that way? Do we want to force them all to patch report bug to say, don't use it? Because that kind of puts additional barrier, oh, don't do derivatives, because you have to... And when you change your documentation, then not always... It's difficult to enforce it, and it's difficult to detect it. But it's also really annoying that we get all the bug reports that we can't reproduce, because we don't have this system. We cannot reproduce it, but... That's not the normal case, even from that situation. Could we really forget the conversation about what we call Debian official, because I think that's what counts here. No, wait, I think we'll get to that. I just want to try and maintain your... One of you two... What about a unified script for building those cloud images? Like we already have that, called Bootstrap Reset, and have some sort of test suite. We can test those images, some sort of... I don't know, Jenkins or whatever test suite, so we can see those images comply to at least a certain amount of tests that the Debian project decides to be the official tests for those cloud images. Because that would give the project also a chance to call them official. So, I think it's... I think everyone sort of agreed that official Debian is something produced by the project, published on Debian.org, CD image, etc. There's then the description of based on Debian, it's descriptive, it's obvious that something's based on Debian. Ubuntu is based on Debian, but we wouldn't really want it called Debian, because it's not. But there is somewhere in between, which is essentially sort of a scratch and sniff test, so you sort of hold it up and put it up to the light and go, is this Debian? You go, yeah, it's obviously Debian. So if someone takes Debian and, for whatever reason, they need a new kernel, or they need to backport something, it's pretty obvious that it is Debian but it's been produced by someone else and it's had a slight flamethrower twist to it. So this is not theoretical. There's large organizations out there who have produced Debian derivatives and given it its own name because they don't want to foul our trademark usage. But they want to call it Debian because that's basically what it is. So there's no point in deploying this large distribution over here. They said, it's just Debian. They want to give us the credit of saying it's that. So a possibility around saying it's Debian from Oracle, for example. I mean, terrible example, but it is basically there. You get the idea. So there is clarity that it's Debian, but it's not produced by us. So it's not something that we, in the first instance, come across. So a way of being able to say, yes, you can use the Debian mark. If we have the clarity that these things are in place, you could say, please make sure you document some of the changes you've made or something like that. But people should be able to use the Debian mark when it's, to be honest, if Debian's used them a lot more widely than people recognize, partially because we don't wear a little scared of allowing things to be called Debian in that way. I don't know the name. So I just wanted to make a point. So it isn't in Debian's interest that derivatives are called out as a product of the community release. Because ultimately what happens is, as the market becomes more aware of Debian, more support gets given to Debian. Right now there's a situation where there's a lot of people who are producing derivatives calling them something different. That value is accruing to whatever they're calling that thing. Debian Oracle is called, let's say, Oracle Linux. The value that accrues to Oracle Linux doesn't accrue to Debian. Even though the work came from Debian. So it's in the community's interest that derivatives are associated with Debian. Because that way the community becomes aware of the broader community, not the developer community, but the broader community, the user community, the market becomes aware of where the work actually came from. So then they value those people who do that work. I agree with everything that was said before. I think there are stratifications. Certainly official Debian should come from Debian. Certainly based on Debian, components of Debian, artifacts of Debian. I don't know what the stratifications are. But there are clearly stratifications. Where you draw the lines, probably around the notion of non-proprietary release, a contrib-based release, only pre-software-based release. There's probably a line that you draw on there. There's probably a line that you draw on the testing as well. I really like the idea of having automated tests around the release to classify which part of the strategy you get thrown into. But wholesale saying Debian is a trademark and should only be associated with official Debian releases, causes a problem where people don't realize that people are essentially taking advantage of the community's effort and then accruing value to that thing outside of it, like Ubuntu. A tremendous amount of value is accrued to Ubuntu. It doesn't come from Ubuntu. It comes from Debian. I pretty much agree with everything that you just said. And from the most part, which everybody wanted. There is tremendous value in exposing the name of Debian more. I think there's maybe three or four views of Debian-lishness. There's official, that's obvious. There's derivatives, or based on, or call it a dog, or some Ubuntu, or Mint, or it doesn't matter. In between, I think we've got one or two areas. One where people are basically trying to stay as close as humanly possible to what the original Debian is, but they just have to make some decision. They say they may need a back port for it, or they may need a driver, or maybe they need to install some firmware. It doesn't matter, but when I really, really try to stay as close to the vanilla Debian as possible, and this should be something which should be honored, but also verified. And then on the other hand, you have someone who basically just tosses Debian on their laptop, installs, flash, or what have you, and basically is not a holy derivative like Ubuntu, but still it's quite far from what a vanilla Debian might be. So maybe we get in four different tiers, so to speak. Yes, I want to say, if you make a rule, you have to think about two things. The first is how to control the rule, and as easy as it is, it's better. And the second thing is what should be done if a person or company is uncompliant with the rule. So maybe you find some perfect rules for you, but you can't control them. They are worthless. I guess the ultimate assumption there is Debian with Jaws is, it's trademark ground. I mean, issues are press release. We do have the force of law if we need it. And the other thing is if we certify things, we can have a certified Debian page, but again, you can't qualify to certify unless you are Debian, which we can prove. I think Brian has been waiting for a while, right? Yes, but you are trying to know the balance of the rule. Okay. One thing that I might have been wanting to say is that with regard to testing, we shouldn't focus too much on the specifics of that during this session, except insofar if we want to make it a criteria for the name. I don't think... So I think most of the things that are built as Debian, except for the official CD releases, maybe it's slightly DI, and actually the Google images, mostly don't currently... Nothing except for those currently has a good test suite. More sharing of test suites and automation should happen, including from Google, right? But that's mostly a separate discussion, except for whether we want it as a criterion. Okay, so I just want to speak about this from the trademark. There's a couple of ways to go about what we're doing, but we're kind of limited to one way right now. There's certification marks and there's trademarks, and we have the trademark. Certification mark is kind of like what we want. We want to set a set of criteria that this is a product that meets this thing. But the different... Why we can't use certification mark is the person who owns the certification mark can't produce a product that's tested by that certification mark. So like, you might have like, this is tequila or something, and it's certified tequila or certified champagne, but the organization that owns that mark can't make champagne or tequila. So like SPI, what is... What is certified? No, SPI owns the trademark. SPI owns the trademark, yeah. But the mark will be different. It could be a different mark, you know? Like we could come up with a new mark. It would have to be a certification mark, saying Debian endorses this, and then it's just like unfair representation if you're not... Why I'm mentioning certification mark is that it sounds like that's what we want to create, but we really can't because we want to produce the product as well. So one of the risks I'm hearing about letting anybody go off and make Debian is if we don't kindly control the quality of the product that our licensees produce, we risk the mark becoming losing the mark and losing the ability to stop people from using the mark when we don't want to. We're not really risking the ability to... Someone's stopping us from losing the mark, but we're risking the ability to stop people who are doing something we really hate to use that mark. So I just want to make that clear. Like when we talk about official Debian, like in the ideal world from trademark law, when you say official Debian, that should be the only Debian. But that's, I mean, I know that's not the reality we live in, so we have to just be careful. I'm saying about letting people use it without adequate, you know, oversight. I don't know if that's true. It's true. About endorsing those who are staying very close to Debian and tweaking small features like a driver or something like that, we already have a name for that, and please don't invent new names that would just produce and even more is called Debian Blend. That means that means something different. No, it means exactly being very close to Debian. If you are within Debian, it's a Debian Pure Blend. I invented the word, so I really much know what I'm talking about. No company could want to use that marketing. Okay, fine. So you want to have a computer class? That's also a difference. One of your certifications is that something companies really want to have just a STEM UR guide. I think it was U of Mare? Or was it the other way around? No, I think it was U of Mare. But I'm not quite sure. So if you did, and I'm not an expert on trademark law by any stretch of the imagination, but I have been exposed to it a little bit, if you did a Powered by Debian, that would be perfectly okay. So I think that, I mean, I can't speak to all of the individuals concerned about this, right? But I think that getting sufficiently close to just having a relationship with Debian, right, to show value from where the value actually came from. Using a Powered by Debian would be sufficient for a derivative release that may have a smaller package came, or may have specialized drivers, maybe even some components that are proprietary. But it would be a licensing agreement to use our trademark. Maybe we would have a file for the trademark, a new trademark, Powered by Debian. Yes, I totally agree with that. Not in Europe. You could do that with the same trademark. I don't know about other countries. And I would even go as far as to say that, you know, automated testing, you know, some certification test would be a step that you would want to go through to make sure that the system was compliant in some way. I don't know the frequency of test. I don't know the extent of changes required to retest. Yeah, ideally there would be the test. I was just going to say, I think it's kind of too ambitious at this stage to say we're, imagine we're going to come up with a policy that can be implemented in a fully direct, like, automated level way. At the moment there's going to be something where there's human involvement in approvals in ongoing ways. So the advantage of that is it means we don't need to worry too much about every possible corner case. I think the case is where this is going to be easiest is actually working with other large organizations, whether that's HP, for example, where this is not their business. The case is actually a lot more complex is if you have someone who wants to make a fork of Debian, for example, I don't know, someone that wants to change Debian to use Upstart and delete all that in its systems. I mean, it's still true, it's based on Debian. We might even want them to be advertising that, but we might have more sensitivity about them labeling it as improved Debian or something. I mean, it's a more tricky thing. We actually had this issue, well, a similar issue with also even a long time ago with Debian, Corcoran Sultium was an attempt to use the Debian name in a way we weren't all together happy with. But I think, again, if we accept that it is case by case and that whatever agreement we need, we're going to need some ways to pull back from that. So, for example, even with some like HP, if HP decides tomorrow, actually they're going to make it fully required to install this thing to have tons of proprietary drivers and extra tools there. Maybe we stop them happy with them calling it Debian. But I think we can easily have some kind of agreements that would do this. I don't think it's... Again, I think it's going too far into the future or possibly something we would never want to have to imagine we're going to have a full set of rules that has every single case and we just go through and take boxes. It's not the right level for this. Do you think we ought to know? Sure. So, if we imagine a world where reproducible builds have all been done and everything is magic. So, what I do is I download also the source from Debian website. I rebuild it on my own infrastructure. So, I'm not using one build, still use that build or something like that. Produce it, package it, and I'll install it somewhere. Then it's... It is Debian, but it's not been produced by Debian if you see what I mean. So, it's still obviously Debian. So, it's working out how we can use that to... And enable some of these large companies who are producing derived distributions, but it's not really derived. It's just we don't have... They don't have permission to use our marks and they want to use the marks. So, some large organizations just, they say, we don't want to call it this. We want to call it Debian because that's what it is. We've changed the kernel, we've updated that. We've backported this graphics package or something over here, but that's it. I'm trying to keep that close and how we can... So, that's unofficial Debian then? Well, it's not official Debian because we haven't produced it. And then how about the Amazon image, which is non-modified Debian which is built on Amazon infrastructure, which to me makes it non-free. What's your point about this? It's not official Debian, and it's also not unmodified as the couple of things that they have, the AWS CLI interface which is proprietary packages inside. So, you know, it really... Somebody should look at that web page and just, you know, tell the web that it's responsible to clean it up because it's really bad. So, with regard to what Murray said, yeah, I agree it needs to have human involvement and I really think even if it is automated, so I think in order to use, like, certainly anything that's the unmodified trademark or close to it, I certainly think that humans should be involved in oversight or the right of oversight, the right to oversee, even if it is automated just because, you know, our opinion can also change as long as we give some reasonable notice to be fair to them. And I think, and as for, like, powered by Debian, I mean, unless we spend a lot of effort making that an appealing mark, I think it won't achieve some of the reasons so from the company perspective, the reasons they want to call it Debian are among those reasons would be their customers are requesting Debian and so something that's Debian-ish might not, like what's the ish part, right? You know, powered by Debian. If, let's say a vendor supports Debian as an operating system, if it's close enough to Debian that whatever the vendor is doing you know, they want, like, let's say, imagine, to use our favorite example of the session Oracle we're supporting Oracle DB on Debian, you know, just the fact that it's running in, I don't know, the great public cloud of China, for example, would not change that fact aside from firewall issues. But, so if it's, if the things that companies or their customers or relationships care about the Debian mark you know, would not be satisfied by an altered label we want them to be able to call it Debian maybe but not official Debian as long as we are involved enough to make sure they're not doing anything nasty and can say no if they change their nastiness. What did you raise your hand earlier? I did but it's been I don't know. I just want to mention the Amazon CLI is Apache 2 license and there are three implementations of the Amazon API, so it's not proprietary package. I don't know what definition I've seen proprietary is not proprietary. So there's many voices for making it available but then somehow regulating it. Not a single company would decide to use Debian as part of their product if later on we could just pull that carpet off their feet. They would. Let's say I as little company, I didn't want to go and establish my business for some name which later on could be taken away from me. Yeah, that happens all the time. I think the issue is that they don't want the conditions for use to chair. So as long as the conditions for use are known at the time that they agree to base their product on the next couple, right? That's a condition of use. They're getting some value, quite a lot. But is it feasible to establish those conditions in reasonable and human comprehensible by a regular mortal, not by some lawyer, because we're talking about small projects, some regular developers decided to pull off, right? If they go and do this, like, oh, we need to satisfy those main key regiments, like, I'll screw it. I'll just call it whatever, right? Because that's easier. There is this kind of entry point which makes it difficult. Even there is too much bureaucracy and lawyers involved. And kind of would it be concerning to not lose Devin trademark, right? But let's say if we could say that you could use Devin as part of your product name as long as you state that this is not an official Devin project. Product. Not an official product of Devin project. That's it. So they could use it. Then it's clear that it's not official. Period, right? There is no, like, fear. Okay, later on somebody will come and say, I need to rename it. I think that for our users, we do want them to get their Devin experience. Actually, we will take Windows 10 and say this is not a product of the Devin product. Project versus Devin. But see, there is, of course, range where people could go insane, right? Does it happen? I don't know. I didn't see any such case. So, you know, it's interesting to note that the CDT is unofficial Devin images. Right. Devin CD. Yeah, so if you take Devin, official Devin, and enable Contrib repo, that is no longer official Devin. Mm-hmm. Right, so we have something ourselves that if you have Contrib and if you have None Free in your sources. I'm running Devin unstable on my laptop. Now, I'm explicitly installing a package which FTP Master a week later decides to remove for whatever reason. Is that laptop still running Devin? I don't think so. It was in the archive when I installed the laptop. But it's not in the archive anymore. So is that still Devin or is it not? It's the official Devin. Power by Devin. Yeah. Power by Devin and Devin. And when I've been talking when I've been talking to some organizations there, I mean, some of the rules that we can put in place are fairly straightforward and very happy. So it's thinking we could do something along the lines of for it to be called Devin. It needs to have only free software. Well, Devin has free software. You could do things like you need to maintain a list of changes or where it's diverged from what official Devin is. We can review it once quarter or once a year. Everybody loves to mean data and change looks and here are my changes. No, it's literally come from a company who says we're doing this because we think it's a good idea. So would you like that? Would that be a way we could carry on looking at and review it? Very happy to do that. And we can put things around trying to beat things back in or keeping them more changes as well. So that's not necessarily a problem from a lot of the organizations I've talked to. In fact, people are legally replied to do that already because the social contract says that they must if you ask them, give you that source code. But give source code is different from documenting the changes. How do I ask you? I think you have to do that. Well, by GPL we can also list in every file. Do we do that? Oh yeah? Then you better fix those packages, pilebox. Try to figure it out. So if Devin would produce those images on CD image, Devin or wherever infrastructure and the cloud are downloading that exact image which has the exact same checksum into their repository for publishing that to their end users. That's called official dev. Could be a releasing of that. So what's happening on HP cloud because I wrote that OpenStack package to OpenStack Devin images that is now in the CD process release. So on every release we have a new release for that. That's a script for one exact cloud infrastructure. We have a bootstrap reset for doing several cloud infrastructure. So having one script for all of the... Currently, OpenStack Devin images script is used only for the OpenStack image but if you were running it on Amazon now that they do support mostly HVM, I think it would work as well but it wouldn't include the CLI. So one thing I wanted to talk about as well, before JC was released, I was doing these images. They were not produced by the CD team because I still wanted to have it only for JC, so it was testing at the time. And then for Wheezy, I was adding three backports. So Cloudy, Ramefestools and whatever. And then the question is, because I'm activating backports, is this really the Devin stable image? No. Probably not. Probably not. Okay. Well, but still the software that is installed is from the Devin archive. Yes, so that is fully Devin archive from backports and whatever. So it's fully official, but probably not Devin's stable. And now the JC image is obviously fully stable. So perhaps the way we deal with the way we officially deal with it on the hash Devin IRC channel is, have you installed from Devin media just using free and no backports and you don't have any other random sources in there or something else. And that is something that hash Devin will support if we get users coming along and we'll try and fix their problems. Then, oh, you've installed Mint. Please go talk to Mint or we don't support Ubuntu here because they changed it all so there's no way we can do that. But there's something in between that we do transport as well. So if you have installed backports or even if you have installed a third party repository we'll normally say go talk to them but if you installed say some, well tradition ones of the multimedia codec days, they installed that but they're having problems with Emacs. And it's still like, yeah, it's still going to be, oh I don't know if Max does video playing these days. Not only video editing in the Max case. So there is this area in between that it's a bit of a judgement call looking at it and going, yeah it's Devin, we know it's Devin. And it's not official. No, it's not, but we know it is because you look at it and it's obviously it's possibly, as Manuel said, using the Devin experience or something like that and you know what it is. You know it when you see it. Trying to codify that is tricky and trying to put something in law or some guidelines are saying we know it when we see it. Probably, I think a lawyer would describe it as inadvisable. Or it worked in the US. Yes. So yeah. If you are going to the non-free infrastructure stuff then you have to disregard almost all hardware anyway because it's non-free the hardware. And if it's software on the hardware it doesn't really change the way it's not certified hardware. Neither do we certify infrastructure. So we don't certify hardware. Do we certify infrastructure? I don't think we do. Our lovely folks at the Free Software Foundation can help certify hardware. But then that's another interesting topic that maybe we should do about having a certified logo of Debian or I do want to both agree and disagree with Toma different things you said. With regard to whether I guess it's a one-minute slide so we should feature it. So we do, I think we definitely want it to be possible if they're calling it even not official but just Debian without a lot of descriptors it should be possible yes for anybody whether they're employed by the company or not to use personal hardware not the company's services to do the build if they want to whether they can use the company's hardware it doesn't matter but it needs to be possible otherwise with public instructions and also as far as the back forth issue I agree with Neil that sometimes it's reasonable to call it still Debian stable if certain back forth are in not if it's heavily back forwarded but for example the common case of needing a new kernel for hardware driver support like let's say the back forth kernel a lot of custom proprietary modification things you know a lot of people would talk to their friends very legitimately say I'm running with Jesse oh yeah I happened to grab a new kernel to make my laptop run well but it's still Jesse that's that I came in late but I don't I think no one has mentioned I see and I think it's actually such a good comparison because we are on the other side so Firefox is such a strong brand and we are shipping it's Firefox but obviously we have to patch it right and I think that we had to rename it actually had both of the projects because for us it's a lot of confusion you know what is ice weasel and I think for Firefox it also doesn't have them because Debian is also a big issue and if they can say oh you know Firefox is the default in Debian I think that also helps them and so I definitely see the need again with Debian we have a strong brand so we need to protect it you know not everything can be called Debian but I think we need to be like open that obviously yeah they need to patch it like they probably going to change it