On Mon, Sep 24, 2001 at 10:55:29AM -0400, KRAMER,STEVEN (HP-USA,ex1) wrote: > I also cast my vote with Crispin and Sandy to exclude the new licensing > language. This is changing the rules in midstream, and does affect > companies that spent significant sums in LSM-targeted development already. Ah, so I am guessing that you are basing your HP Secure Linux development on the LSM patch? > My objections would not be as strong had the new verbage been put into place > from the beginning. For instance, we knew about the GPL license at that > time > and accepted what impact that would have on us from the start. I know for a > fact that the HP legal team has spent a large amount of time understanding > GPL and operating within its structure. Adding the new statement at this > time would mean significantly more legal work, with a possible negative > impact on work with, and acceptance of, LSM. All of the kernel programmers I have spoken with (admittedly a small sample) all like it. I think this will get our patch accepted even easier. > Fairness says to remove the new language, and furthermore, get agreement > that the license will remain GPL, with no new restrictive clauses. Um, the license will always remain GPL, and by stating that it _must_ be GPL, is not a "restrictive clause." I was just trying to state this fact up front, and not adding any more restrictions to the interface. If in userland, you generate a non-GPL program, using a GPL header file, you are violating the GPL. Why is the kernel any different? Can anyone point me to any wording in the current kernel license that grants this kind of exception just because we are in kernel space? thanks, greg k-h _______________________________________________ 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 - 08:59:54 PDT