Re: Introduction

From: jmjonesat_private
Date: Mon Jun 25 2001 - 10:03:38 PDT

  • Next message: Steven M. Kramer: "Introduction"

    On Mon, 25 Jun 2001, Crispin Cowan wrote:
    
    > "Steven M. Kramer" wrote:
    
    ...
    
    >
    > >  (I'm not exactly sure what I get from the download because I want to wait
    > > until our lawyers sort out the license - based on J.M.Jones's concerns.)
    > 
    > With all due respect, JM Jones' concerns are ill-founded.  Non-paid use of
    > BK commits you to publishing your change logs, which makes it mostly
    > appropriate for open source projects.  Since LSM is an open source project,
    > this should not pose a problem.  If you are doing some other proprietary Linux
    > kernel work, then you should either not use BK for that work, or purchase
    > commercial copies of BK from the vendor  http://www.bitkeeper.com/
    > 
    > Remember, we're talking about hacking the Linux kernel here, which is already
    > thoroughly GPL'd, so just how scary can the BK license really be?
    > 
    > Usual caveat:  IANAL, consult the BK license and your attorney for specifics.
    > In that sense, JM Jones did precisely the right thing.
    > 
    
    For clarification, the license doesn't fit MY particular needs based on MY 
    particular business plan and technical configuration, at this time.
    Everything I've read about BitKeeper suggests it's an excellent product
    with fewer "technical issues" than most other systems of its kind.
    
    It certainly seems to be *an* appropriate choice for an Open Software
    project such as LSM, if not *the* choice I would prefer. "The needs of 
    the many outweigh the needs of the few, or the one." (Okay, I'm a Trekkie,
    I'm revealed.)
    
    I apologize for overstating my case.  IANAL either... I just share
    too much of my profit with them.  I'm just a bit frustrated by
    constraints imposed by the selection of BitKeeper and the particular
    "pothole" I fell through with regard to this specific project.  I'll 
    work around it, and support via patches for "stable" releases has been
    timely and adequate for most of my purposes.  There are many ways to skin
    a feline.
    
    I (always) suggest checking with an attorney/legal department... odds are
    good the "unusual" elements of BitKeeper's license won't be a problem to most
    interests (again, IANAL.)  Even without BitKeeper, though, the patches
    usually come often enough to keep projects "sync'd".
    
    > 
    > > 2. If after step 1 is solved, how do I submit changes?  It's my understanding
    > > that I send patch files to the list and consensus rules, and then Chris puts
    > > them in BitKeeper for all to extract.  Am I correct in this?
    > 
    > Yes, that's correct.  A few non-WireX people have write access to the
    > BK server, but this being a security project, we're tight about that.
    > 
    > 
    > > 3. Maybe I'm being presumptious in the last question, but is it true that
    > > anyone can join the group and contribute?
    > 
    > Within the bounds of the project, yes. Getting Linus to accept LSM into the
    > main goal of this project, so when ever something that someone wants conflicts
    > with what Linus is likely to accept, Linus wins:
    > 
    >    * All LSM kernel code is GPL'd (not the modules per se, but the stuff that
    >      goes into the LSM patch).
    >    * The patch is to remain as small as possible.
    >    * The technical objective is to support security-enhancing modules,
    >      particularly access control modules. As you have seen, Honeypots are a
    >      nice security thing, but outside the goals of LSM, so Honeypots get "best
    >      effort" support.
    >    * We're targeting the kernel, in the narrowest sense.  Hooks that are
    >      particular to some specific file system (e.g. Reiser, Ext3, etc.) are
    >      problematic.  At the moment, we're sinking hooks into the VFS layer, and
    >      hoping that's sufficient.  If an essential feature comes along where that
    >      is not sufficient (e.g. robust support for extended attributes) then some
    >      further architecting will be necessary.
    > 
    > So while we listen to consensus, just because you contributed something doesn't
    > mean we'll take it.  On the other hand, code speaks loudly, and if you
    > contribute something that works and is consistent with the project goals, it
    > likely will be accepted.  Like in the IETF:  rough consensus, and working code.
    
    I gotta say, the "system" has worked very well, so far.  I've always ended 
    up with what I need, if not always everything I want.  And even when I 
    spin off into a "rant", the consensus/coder filters seem to separate the
    wheat from the chaff very well.  It's a very well run project (imho),
    which works to everybody's advantage because it increases the odds that
    some or all of it will end up "accepted" to the kernel.  
    
    > 
    > Crispin
    > 
    > --
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc. http://wirex.com
    > Security Hardened Linux Distribution:       http://immunix.org
    > Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    > 
    
    J. Melvin Jones
    
    |>------------------------------------------------------
    ||  J. MELVIN JONES            jmjonesat_private 
    |>------------------------------------------------------
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    |>------------------------------------------------------
    ||  http://www.jmjones.com/
    |>------------------------------------------------------
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Mon Jun 25 2001 - 10:06:25 PDT