Hello Debian Users, Note: The quotation in previous threads was mis-attributed, my comments appear as "> >" Henning Makholm's as ">" :
> > Craig H. Rowland <[EMAIL PROTECTED]> > Henning Makholm <[EMAIL PROTECTED]> > > 1) I need to ensure code integrity because of the nature of the tool. If a > > person makes a change to the code that seriously hurts security it > > reflects poorly on me. > . . . > Even in a situation where your faculties are still yours, this is > a problem. Debian is takes security quite seriously does not want its > users to end up in a situation where a security fix is delayed because > the upstream author has to be contacted and respond before it can be > released. Presumably you go on vacations occasionally, or you might > end up in a job situation where your time budget and priorities are > different from what you can think of now. As the thread on BugTraq the last few weeks has shown with respect to the major FTP daemons, this is not always the case. Many times inappropriate patches and quick fixes have been introduced that exacerbate the problem. This is often the result of bypassing the controlling author. This is *not* to say that patches submitted by third parties are always like this, just that many times a small fix is only delaying discovery and exploitation of a larger issue. Typically these issues are best handled by the original author of the code on a controlled version that can serve as a stable reference. Nevertheless, I understand your point very well and it has crossed my mind on many occasions. To date however, I've felt it necessary to maintain strict revision control to prevent any problems that can impact the users of the tools. The intention is not to prevent fixes and updates from outside sources, it is strictly to mitigate risk with the ultimate goal of providing end-users with the most stable and secure software possible. > > I need to make sure nobody bundles all my tools together and sells > > them separately. > > This contradicts the needs of the DFSG quite directly. Free software > needs a distribution infrastructure, and we aren't going to get that > unless the distributors are allowed to charge money for their > services. (One might even imagine paranoid administrators that prefer > to buy CDs with security sources from multiple different vendors > rather than simply FTPing them via their possibly-tampered-with net > connection). Again I understand. I'm trying to prevent a situation where a person creates a product with my tools that directly competes against my employer. The license intention is not to prevent bundling with the OS, it is to prevent someone taking the tools by themselves and rolling them together into a separate product. RedHat packs the tools for use on their PowerTools CD. Indeed, they even listed the tool "Sentry" by name on the back of the box for PowerTools 5.2 CD in the "security" section. I don't mind this usage at all. That's why I wrote the tools. > > > My employment contract specifically excludes my tools to protect > > myself and my end users, but I don't want to stir up any problems > > where none exist. > > Could you get your employer to specifically agree to your work being > made free (something like the disclaimer templates at the end of the > GPL)? This is already agreed to -- in writing. My employer has no input on my tools, website, opinions, etc. and never will. Any attempt to exert such control would seriously impact my employment relationship with them. > > > Perhaps the person from Debian who is responsible for > > this decision can write me so we can chat? > > The entity responsible for the Debian Free Software Guidelines is > the developer consensus. I'm just a subscriber to debian-legal who > is volunteering my explanations of why it's a good thing they are > as they are. I have been a free software contributor since 1995 and an active Internet user since the 80's. I'm aware of the benefits of free software. I will have to think about the ramifications of altering the license and decide what to do from there. At this point I'm on the fence and am leaning towards liberalization of the license to meet the DFSG. I will review all the available guidelines and existing licenses and hopefully reach a conclusion that everyone can agree to. I'm sorry I don't have a better answer for the list, but I'm in an unusual position because of the nature of the tools and my employment status. In any event I intend to include links to Guido's Debian packages on my website in the next couple of days. Even if agreement cannot be reached with respect to my licensing (which I doubt), I sincerely hope the Debian community will find continued use for my tools. > > -- > Henning Makholm "The effect of a go to statement leading > into a conditional statement follows directly > from the above explanation of the effect of *else*." > Thanks for listening, -- Craig
