Re: [PATCH -v4] random: introduce getrandom(2) system call
Pavel. I have bit 'ol enterprise daemon running with established file descriptors serving thousands of connections which periodically require entropy. Now I run out of descriptors. I can't establish new connections. but I should now halt all the other ones that require entropy? I should raise SIGKILL on my process serving these thousands of connetions? I don't think so. On Wed, Jul 30, 2014 at 6:26 AM, Pavel Machek wrote: > Hi! > >> The rationale of this system call is to provide resiliance against >> file descriptor exhaustion attacks, where the attacker consumes all >> available file descriptors, forcing the use of the fallback code where >> /dev/[u]random is not available. Since the fallback code is often not >> well-tested, it is better to eliminate this potential failure mode >> entirely. > > I'm not sure I understand the rationale; if someone can eat all your > file descriptors, he can make you stop working. So you can just stop > working when you can't open /dev/urandom, no? > > Fallback code is probably very bad idea to use... > >> The other feature provided by this new system call is the ability to >> request randomness from the /dev/urandom entropy pool, but to block >> until at least 128 bits of entropy has been accumulated in the >> /dev/urandom entropy pool. Historically, the emphasis in the >> /dev/urandom development has been to ensure that urandom pool is >> initialized as quickly as possible after system boot, and preferably >> before the init scripts start execution. > > Sounds like ioctl() for /dev/urandom for this behaviour would be nice? > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v4] random: introduce getrandom(2) system call
Pavel. I have bit 'ol enterprise daemon running with established file descriptors serving thousands of connections which periodically require entropy. Now I run out of descriptors. I can't establish new connections. but I should now halt all the other ones that require entropy? I should raise SIGKILL on my process serving these thousands of connetions? I don't think so. On Wed, Jul 30, 2014 at 6:26 AM, Pavel Machek pa...@ucw.cz wrote: Hi! The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely. I'm not sure I understand the rationale; if someone can eat all your file descriptors, he can make you stop working. So you can just stop working when you can't open /dev/urandom, no? Fallback code is probably very bad idea to use... The other feature provided by this new system call is the ability to request randomness from the /dev/urandom entropy pool, but to block until at least 128 bits of entropy has been accumulated in the /dev/urandom entropy pool. Historically, the emphasis in the /dev/urandom development has been to ensure that urandom pool is initialized as quickly as possible after system boot, and preferably before the init scripts start execution. Sounds like ioctl() for /dev/urandom for this behaviour would be nice? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hey Ted, one more nit. Yes, I have a bicycle too.. I see here we add a flag to make it block - whereas it seems most other system calls that can block the flag is added to make it not block (I.E. O_NONBLOCK, etc. etc.) Would it make more sense to invert this so it was more like the typical convention in other system calls? On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o wrote: > On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: >> Hi Ted, yeah I understand the reasoning, it would be good if there was >> a way to influence the various libc people to >> ensure they manage to provide a getentropy(). > > I don't anticipate that to be a problem. And before they do, and/or > if you are dealing with a system where the kernel has been upgraded, > but not libc, you have your choice of either sticking with the > binary_sysctl approach, or calling getrandom directly using the > syscall method; and in that case, whether we use getrandom() or > provide an exact getentropy() replacement system call isn't that much > difference, since you'd have to have Linux-specific workaround code > anyway > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Or perhaps to put that another way, since you don't do minherit - maybe a FORK_ZERO for madvise? or a similar way to do that? On Thu, Jul 17, 2014 at 11:46 AM, Bob Beck wrote: > And thanks btw. > > I don't suppose you guys know who we should talk to about possibly > getting MAP_INHERIT_ZERO minherit() support? > > On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck wrote: >> we have diffs pending that will do the syscall method until we start >> to see it in libc :) >> >> So basically we're going to put that in right away :) >> >> On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o wrote: >>> On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: >>>> Hi Ted, yeah I understand the reasoning, it would be good if there was >>>> a way to influence the various libc people to >>>> ensure they manage to provide a getentropy(). >>> >>> I don't anticipate that to be a problem. And before they do, and/or >>> if you are dealing with a system where the kernel has been upgraded, >>> but not libc, you have your choice of either sticking with the >>> binary_sysctl approach, or calling getrandom directly using the >>> syscall method; and in that case, whether we use getrandom() or >>> provide an exact getentropy() replacement system call isn't that much >>> difference, since you'd have to have Linux-specific workaround code >>> anyway >>> >>> - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
And thanks btw. I don't suppose you guys know who we should talk to about possibly getting MAP_INHERIT_ZERO minherit() support? On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck wrote: > we have diffs pending that will do the syscall method until we start > to see it in libc :) > > So basically we're going to put that in right away :) > > On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o wrote: >> On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: >>> Hi Ted, yeah I understand the reasoning, it would be good if there was >>> a way to influence the various libc people to >>> ensure they manage to provide a getentropy(). >> >> I don't anticipate that to be a problem. And before they do, and/or >> if you are dealing with a system where the kernel has been upgraded, >> but not libc, you have your choice of either sticking with the >> binary_sysctl approach, or calling getrandom directly using the >> syscall method; and in that case, whether we use getrandom() or >> provide an exact getentropy() replacement system call isn't that much >> difference, since you'd have to have Linux-specific workaround code >> anyway >> >> - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o wrote: > On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: >> Hi Ted, yeah I understand the reasoning, it would be good if there was >> a way to influence the various libc people to >> ensure they manage to provide a getentropy(). > > I don't anticipate that to be a problem. And before they do, and/or > if you are dealing with a system where the kernel has been upgraded, > but not libc, you have your choice of either sticking with the > binary_sysctl approach, or calling getrandom directly using the > syscall method; and in that case, whether we use getrandom() or > provide an exact getentropy() replacement system call isn't that much > difference, since you'd have to have Linux-specific workaround code > anyway > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hi Ted, yeah I understand the reasoning, it would be good if there was
a way to influence the various libc people to
ensure they manage to provide a getentropy().
On Thu, Jul 17, 2014 at 11:01 AM, Theodore Ts'o wrote:
> On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
>> On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
>> > The getrandom(2) system call was requested by the LibreSSL Portable
>> > developers. It is analoguous to the getentropy(2) system call in
>> > OpenBSD.
>>
>> What's the reason to not implement exactly the same system call OpenBSD
>> does? Having slightly different names and semantics for the same
>> functionality is highly annoying.
>
> The getrandom(2) system call is a superset of getentropy(2). When we
> add the support for this into glibc, it won't be terribly difficult
> nor annoying to drop the following in alongside the standard support
> needed for any new system call:
>
> int getentropy(void *buf, size_t buflen)
> {
> int ret;
>
> ret = getentropy(buf, buflen, 0);
> return (ret > 0) ? 0 : ret;
> }
>
> The reason for the additional flags is that I'm trying to solve more
> problems than just getentropy()'s raison d'etre. The discussion of
> this is in the commit description; let me know if there bits that I
> could make clearer.
>
> Cheers,
>
> - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hi Ted, yeah I understand the reasoning, it would be good if there was
a way to influence the various libc people to
ensure they manage to provide a getentropy().
On Thu, Jul 17, 2014 at 11:01 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Jul 17, 2014 at 09:12:15AM -0700, Christoph Hellwig wrote:
On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote:
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
What's the reason to not implement exactly the same system call OpenBSD
does? Having slightly different names and semantics for the same
functionality is highly annoying.
The getrandom(2) system call is a superset of getentropy(2). When we
add the support for this into glibc, it won't be terribly difficult
nor annoying to drop the following in alongside the standard support
needed for any new system call:
int getentropy(void *buf, size_t buflen)
{
int ret;
ret = getentropy(buf, buflen, 0);
return (ret 0) ? 0 : ret;
}
The reason for the additional flags is that I'm trying to solve more
problems than just getentropy()'s raison d'etre. The discussion of
this is in the commit description; let me know if there bits that I
could make clearer.
Cheers,
- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
And thanks btw. I don't suppose you guys know who we should talk to about possibly getting MAP_INHERIT_ZERO minherit() support? On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck b...@openbsd.org wrote: we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Or perhaps to put that another way, since you don't do minherit - maybe a FORK_ZERO for madvise? or a similar way to do that? On Thu, Jul 17, 2014 at 11:46 AM, Bob Beck b...@openbsd.org wrote: And thanks btw. I don't suppose you guys know who we should talk to about possibly getting MAP_INHERIT_ZERO minherit() support? On Thu, Jul 17, 2014 at 11:45 AM, Bob Beck b...@openbsd.org wrote: we have diffs pending that will do the syscall method until we start to see it in libc :) So basically we're going to put that in right away :) On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Hey Ted, one more nit. Yes, I have a bicycle too.. I see here we add a flag to make it block - whereas it seems most other system calls that can block the flag is added to make it not block (I.E. O_NONBLOCK, etc. etc.) Would it make more sense to invert this so it was more like the typical convention in other system calls? On Thu, Jul 17, 2014 at 11:34 AM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Jul 17, 2014 at 11:05:01AM -0600, Bob Beck wrote: Hi Ted, yeah I understand the reasoning, it would be good if there was a way to influence the various libc people to ensure they manage to provide a getentropy(). I don't anticipate that to be a problem. And before they do, and/or if you are dealing with a system where the kernel has been upgraded, but not libc, you have your choice of either sticking with the binary_sysctl approach, or calling getrandom directly using the syscall method; and in that case, whether we use getrandom() or provide an exact getentropy() replacement system call isn't that much difference, since you'd have to have Linux-specific workaround code anyway - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
r.kernel.org
>I urge developers to not bait into this and just leave this alone. >Those involved know what they are doing and have a strong team of >attorneys watching their backs. Any *necessary* discussions are be >done privately. > > Luis What? when we talk about the ethics of cooperating development and sharing code the response is "we have lawyers watching your backs" and "we know what we are doing and have a plan" What is this? a concerted attack by some organization on the BSD projects? Would that be the FSF? or freesoftware.org? What kind of crap is this? that Free Software developers can't respect each others project goals and work together, but instead should beware of organizations with hidden agendas to abscond with their work. What a crock. I urge any developers involved to decide if you really want to work in an environment of this sort of amoral baloney. I think you all should decide if you want to work in an environment where developers can cooperate on a handshake and respect each others differnet goals, or whether discoveries in each camp need to be hidden from each other and fought over by lawyers. You're all being talked to by a bunch of zealots who put zealotry above morals. -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
>As a free software user and developer, the question I have is how come >the Linux community feels that they can take the BSD code that was >reverse-engineered at OpenBSD, and put a more restrictive licence onto >it, such that there will be no possibility of the changes going back >to OpenBSD, given that the main work on the code has happened at >OpenBSD? (Obviously, such a scenario it is permitted by the licence, >but my question is an ethical one -- after all, most components of >OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.) > >You can see that Christoph Hellwig agrees with this ethical problem, >as in the message below. > >C. > > >>On 28/08/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: >> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote: >> > ath5k, license is GPLv2 >> > >> > The files are available only under GPLv2 since now. >> >> Is this really a good idea? Most of the reverse-engineering was >> done by the OpenBSD folks, and it would certainly be helpful to >> work together with them on new hardware revisions, etc.. I couldn't agree more. The point is, while we BSD license fans know and expect people from private industry to take our stuff and use it, at least private industry does not come to the table with "hey, let's cooperate" - we know who the corporate whores are, and we act accordingly. However, when a linux developer comes to us and say "hey lets cooperate" usually there is a thought of "this is a kindred spirit who understands what our mutual goals are and won't stab us in the back". My concern is that this situation will change if this is not rectified. I think the community needs to decide, should cooperation be based on morals and trust, or does the Linux community need to be regarded with less trust than a Corporation, something to be avoided, as while corporations can be counted on to act without morals, the knife is up front and visible. They do not come to you with one hand of cooperation extended and a knife kept behind their back. -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]
- Forwarded message from Bob Beck <[EMAIL PROTECTED]> - From: Bob Beck <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: I respect the GPL immensely, really I do - but I believe this type of action weakens us all. X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on bofh.cns.ualberta.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.8 Date: Sat, 1 Sep 2007 16:22:43 -0600 User-Agent: Mutt/1.5.12-2006-07-14 [ A copy of this is going to the linux kernel mailing list, regarding the recent license modifications to reyk's files] >Oh, and if you look at the OpenBSD CVS you see versions 4 months old >with dozens of contributions by Reyk and with: > >/* $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $ */ >/* $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/ >/*- > * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting > * All rights reserved. Of course you do! because some of reyk's work used some of Sam's work, and unlike what it seems a portion of the Linux community seems to be willing to do in their Zealotry for the GPL, reyk is not *removing and modifying* the licenses granted by the original authors. That's the point. He's not saying he wrote this piece, and he's not *changing* the conditions under which Sam distributed the code in the first place. However what scares me more is the seeming willingness to make the authors of a derivative work appear to be the primary authors of something, and a willingness to change an authors copyright statement (on reyk's code) without his permission. I have always immensely respected the GPL - it has very noble goals, they are very appropriate in some cases, they don't happen to be mine, but that's fine, I don't release my code under it - but that's fine, it's my choice. Just like many smart people who I know and respect do their work in GPL land, and this is great too. However, when it comes time to be looking at someone else's work above all we have to respect the various authors choice of how they want their hard work shared with the community. To me, this seems like a portion of the Linux community seems to be wanting to make their own rules, chosing to rewrite a license at any time they choose without the original author's agreement. This appalls and scares me. Why? not only does it show a huge lack of respect for someone who has worked very hard to produce something the whole community can use, but seriously undermines software freedom as a whole. This is a slippery slope. If one community starts modifying the others licenses for no purpose other than zealotry, I see only two consequences: 1) a hugh rift of mistrust between the developers of both camps, meaning no cooperating to make the world a better place. 2) A weakening of the respect for licensing on all sides of the community, which weakens the credibility of both BSD *AND* the GPL license when tested from the outside. Frankly, this scares the hell out of me and dismays me. I seriously hope that saner more mature and forward thinking heads inside the Linux community will stop bashing the things that Theo and the rest of our community is saying just because it's coming from Theo, and he's a great target to bash, and start thinking about what you are doing to free software as a whole. I think you are on the verge of doing irreparable damage that will seriously weaken the ability for all of our projects to move forward, and protect our rights as code authors in the future. -Bob - End forwarded message - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]
- Forwarded message from Bob Beck [EMAIL PROTECTED] - From: Bob Beck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: I respect the GPL immensely, really I do - but I believe this type of action weakens us all. X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on bofh.cns.ualberta.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.8 Date: Sat, 1 Sep 2007 16:22:43 -0600 User-Agent: Mutt/1.5.12-2006-07-14 [ A copy of this is going to the linux kernel mailing list, regarding the recent license modifications to reyk's files] Oh, and if you look at the OpenBSD CVS you see versions 4 months old with dozens of contributions by Reyk and with: /* $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $ */ /* $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/ /*- * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting * All rights reserved. Of course you do! because some of reyk's work used some of Sam's work, and unlike what it seems a portion of the Linux community seems to be willing to do in their Zealotry for the GPL, reyk is not *removing and modifying* the licenses granted by the original authors. That's the point. He's not saying he wrote this piece, and he's not *changing* the conditions under which Sam distributed the code in the first place. However what scares me more is the seeming willingness to make the authors of a derivative work appear to be the primary authors of something, and a willingness to change an authors copyright statement (on reyk's code) without his permission. I have always immensely respected the GPL - it has very noble goals, they are very appropriate in some cases, they don't happen to be mine, but that's fine, I don't release my code under it - but that's fine, it's my choice. Just like many smart people who I know and respect do their work in GPL land, and this is great too. However, when it comes time to be looking at someone else's work above all we have to respect the various authors choice of how they want their hard work shared with the community. To me, this seems like a portion of the Linux community seems to be wanting to make their own rules, chosing to rewrite a license at any time they choose without the original author's agreement. This appalls and scares me. Why? not only does it show a huge lack of respect for someone who has worked very hard to produce something the whole community can use, but seriously undermines software freedom as a whole. This is a slippery slope. If one community starts modifying the others licenses for no purpose other than zealotry, I see only two consequences: 1) a hugh rift of mistrust between the developers of both camps, meaning no cooperating to make the world a better place. 2) A weakening of the respect for licensing on all sides of the community, which weakens the credibility of both BSD *AND* the GPL license when tested from the outside. Frankly, this scares the hell out of me and dismays me. I seriously hope that saner more mature and forward thinking heads inside the Linux community will stop bashing the things that Theo and the rest of our community is saying just because it's coming from Theo, and he's a great target to bash, and start thinking about what you are doing to free software as a whole. I think you are on the verge of doing irreparable damage that will seriously weaken the ability for all of our projects to move forward, and protect our rights as code authors in the future. -Bob - End forwarded message - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole Linux stealing our code thing
As a free software user and developer, the question I have is how come the Linux community feels that they can take the BSD code that was reverse-engineered at OpenBSD, and put a more restrictive licence onto it, such that there will be no possibility of the changes going back to OpenBSD, given that the main work on the code has happened at OpenBSD? (Obviously, such a scenario it is permitted by the licence, but my question is an ethical one -- after all, most components of OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.) You can see that Christoph Hellwig agrees with this ethical problem, as in the message below. C. On 28/08/07, Christoph Hellwig [EMAIL PROTECTED] wrote: On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote: ath5k, license is GPLv2 The files are available only under GPLv2 since now. Is this really a good idea? Most of the reverse-engineering was done by the OpenBSD folks, and it would certainly be helpful to work together with them on new hardware revisions, etc.. I couldn't agree more. The point is, while we BSD license fans know and expect people from private industry to take our stuff and use it, at least private industry does not come to the table with hey, let's cooperate - we know who the corporate whores are, and we act accordingly. However, when a linux developer comes to us and say hey lets cooperate usually there is a thought of this is a kindred spirit who understands what our mutual goals are and won't stab us in the back. My concern is that this situation will change if this is not rectified. I think the community needs to decide, should cooperation be based on morals and trust, or does the Linux community need to be regarded with less trust than a Corporation, something to be avoided, as while corporations can be counted on to act without morals, the knife is up front and visible. They do not come to you with one hand of cooperation extended and a knife kept behind their back. -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
r.kernel.org
I urge developers to not bait into this and just leave this alone. Those involved know what they are doing and have a strong team of attorneys watching their backs. Any *necessary* discussions are be done privately. Luis What? when we talk about the ethics of cooperating development and sharing code the response is we have lawyers watching your backs and we know what we are doing and have a plan What is this? a concerted attack by some organization on the BSD projects? Would that be the FSF? or freesoftware.org? What kind of crap is this? that Free Software developers can't respect each others project goals and work together, but instead should beware of organizations with hidden agendas to abscond with their work. What a crock. I urge any developers involved to decide if you really want to work in an environment of this sort of amoral baloney. I think you all should decide if you want to work in an environment where developers can cooperate on a handshake and respect each others differnet goals, or whether discoveries in each camp need to be hidden from each other and fought over by lawyers. You're all being talked to by a bunch of zealots who put zealotry above morals. -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
