Crispin Cowan wrote: > > Greg KH wrote: > > >On Sun, Sep 23, 2001 at 09:10:14PM -0700, Crispin Cowan wrote: > > > >>Perhaps we should LGPL the security.h. Does that create problems? > >> > >I would object to this. That would be granting the explicit right > >for it to be used in closed source binaries. I do not want to grant > >that explicit right. > > > That is exactly what I always intended LSM to do. Really interesting discussion. Sice I didn't wrote any of the LSM code here are my personal thoughts about the issue: I think developer(s) should decide clearly if they do open source or closed source development. I do both kinds of software myself depending on client requirements and other factors. Yes, sometimes I want to keep my secrets. There's nothing wrong about that. But I *never* mix up closed and open source. Since the LGPL is somewhat in-between I definitely don't like it. Similar goes for BSD style licenses. It's a matter of principle. Therefore I never release closed source software for Linux. If I cannot GPL it I don't publish it at all - or use closed source software on Linux (if possible). I definitely do not like closed source kernel modules. Concerning security my requirements are far higher. While I don't have problems using closed source software in "normal" circumstances (I just don't like it), security is more important so I need access to the source to make my decision and to track down any problems. I do not trust any vendor, everyone including myself can make mistakes. Why would anyone keep security-related software a secret? I can think of three possible reasons. There might be more, please enlighten me! 1) Keep your secrets! I do this myself sometimes if I think I shouldn't tell all my tricks. However, when security is concerned I think it's a very Bad Idea (tm) See all the various Microsoft software exploits - even if you know about them you cannot fix them since you haven't the source! :-(( 2) It needs to be secret or the security will fail Very, very Bad Ides (tm)! If your solution depends on a secret algorithm you're in deep trouble. Just go and decompile it... I think we all agree on this issue. 3) Forced to by third-party software This one's the difficult one. For some software or algorithms like RSA you have to sign a non-disclosure agreement. It might be good to be able to use such third-party-software. I don't like this in security-related software, but if as much as possible of the module is open-sourced I can accept it. I doubt I'll ever use it, but I might be forced to... If I can avoid close-sourced software I'll use open-sourced counterparts, especially if security is concerned. I cannot trust any vendor getting out a patch quickly if an exploit becomes published so I need the source to defend myself. Using closed source software which uses open source software feels like stealing for me: The open source developer gave me free software so I should give them free software back in return. Lawyers might tell you otherwise (there are big differences between the appropriate laws in Germany and the USA, and IANAL), but that's the way I feel. Conclusion: I absolutely like the idea that only OSF-compliant software can use LSM. However I see one problem here (my point 3), and the fact this change (is it a change or not?) is introduced this late. I don't like it, but for now closed source LSM modules should be allowed. After further discussion this might hopefully change. But if the acceptance in the mainstream kernel really depends on this I'll prefer getting LSM into the kernel instead. Just my two Eurocents. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Registered Linux user #210635: http://counter.li.org/ _______________________________________________ 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 Sep 24 2001 - 17:30:51 PDT