On 24/11/18 1:53 am, Szabolcs Nagy wrote:
On 23/11/18 14:11, David Newall wrote:
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose
On 24/11/18 1:53 am, Szabolcs Nagy wrote:
On 23/11/18 14:11, David Newall wrote:
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues. We need to abstract over these
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues. We need to abstract over these
Hi all,
First, I'm not subscribed to any of the mailing lists addressed. Please
copy me in replies.
I'm not sure if this is an LVM issue or a MM issue. I rather think it's
the latter, and I'll explain why, towards the end of this email.
I'm running a qemu virtual machine, 2 x i686 with
Hi all,
First, I'm not subscribed to any of the mailing lists addressed. Please
copy me in replies.
I'm not sure if this is an LVM issue or a MM issue. I rather think it's
the latter, and I'll explain why, towards the end of this email.
I'm running a qemu virtual machine, 2 x i686 with
On 20/05/14 14:25, valdis.kletni...@vt.edu wrote:
So yes, we*do* need to do something sensible there - either frag the packet
on the way out, or something.
I think the problem is that a bridge cannot be used across incompatible
media. That's the job of a router.
A bridge should act like a
On 20/05/14 14:25, valdis.kletni...@vt.edu wrote:
So yes, we*do* need to do something sensible there - either frag the packet
on the way out, or something.
I think the problem is that a bridge cannot be used across incompatible
media. That's the job of a router.
A bridge should act like a
Thanks for the reply. I've been hanging out for it!
On 19/05/14 23:31, Florian Westphal wrote:
Well, did you test what happens if we try to refrag a packet
containing ip options after the revert?
can happen e.g. when using netfilter conntrack on top of a bridge.
No. I expect it would
462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge :
Sanitize skb before it enters the IP stack)
Date: Sat, 17 May 2014 00:03:16 +0930
From: David Newall
To: Lukas Tribus , Eric Dumazet
, Netdev
CC: f...@strlen.de
We should revert commit 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge
: Sanitize
: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge :
Sanitize skb before it enters the IP stack)
Date: Sat, 17 May 2014 00:03:16 +0930
From: David Newall dav...@davidnewall.com
To: Lukas Tribus luky...@hotmail.com, Eric Dumazet
eric.duma...@gmail.com, Netdev net...@vger.kernel.org
CC
Thanks for the reply. I've been hanging out for it!
On 19/05/14 23:31, Florian Westphal wrote:
Well, did you test what happens if we try to refrag a packet
containing ip options after the revert?
can happen e.g. when using netfilter conntrack on top of a bridge.
No. I expect it would
David Brownell wrote:
> On Tuesday 26 February 2008, David Newall wrote:
>
>> Hardware can be inserted and removed while we're in a suspend state; and
>> there's nothing that we can do about it until we resume. Is it fair to
>> say, then, that having started suspend, we
David Brownell wrote:
> This "flaw" isn't a new thing, of course. I remember pointing out the rather
> annoying proclivity of the PM framework to deadlock when suspend() tried to
> remove USB devices ... back around 2.6.10 or so. Things have shuffled around
> a bit, and gotten better in some
David Brownell wrote:
This flaw isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases,
David Brownell wrote:
On Tuesday 26 February 2008, David Newall wrote:
Hardware can be inserted and removed while we're in a suspend state; and
there's nothing that we can do about it until we resume. Is it fair to
say, then, that having started suspend, we could reasonably ignore any
Linus Torvalds wrote:
> On Sat, 23 Feb 2008, David Newall wrote:
>
>> Do you actually get 80 columns wide on it?
>>
>
> Do people really care that deeply?
> ...
> And do I find lines longer than 80 charactes unreadable? Hell no.
>
I care, yes. I've
Jan Engelhardt wrote:
> static void blah(void)
> {
> if (foo) {
> bar;
> bar2;
> return;
> }
> if (this) {
> that;
> that2;
> return;
> }
> /* yay, got rid of two levels of indent! */
Pavel Machek wrote:
> On Sat 2008-02-23 23:08:58, David Newall wrote:
>
>> Pavel Machek wrote:
>>
>>> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
>>>
>>>
>>>> Pavel Machek <[EMAIL PROTECTED]> writes:
&
Matthew Wilcox wrote:
> On Sat, Feb 23, 2008 at 04:14:08PM +0800, WANG Cong wrote:
>
>> Use get_personality() macro instead of explicit reference
>> for parisc code.
>> -if (personality(current->personality) == PER_LINUX32
>> +if (personality(get_personality()) == PER_LINUX32
>>
>
Pavel Machek wrote:
> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
>
>> Pavel Machek <[EMAIL PROTECTED]> writes:
>>
>>
>>> Zaurus is one example, second is small screen where you need big font
>>> to keep it readable (x60 on desk).
>>>
>> Come on, are you doing Linux kernel
Pavel Machek wrote:
On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
Pavel Machek [EMAIL PROTECTED] writes:
Zaurus is one example, second is small screen where you need big font
to keep it readable (x60 on desk).
Come on, are you doing Linux kernel development on PDA?
Matthew Wilcox wrote:
On Sat, Feb 23, 2008 at 04:14:08PM +0800, WANG Cong wrote:
Use get_personality() macro instead of explicit reference
for parisc code.
-if (personality(current-personality) == PER_LINUX32
+if (personality(get_personality()) == PER_LINUX32
Hm. We have
Pavel Machek wrote:
On Sat 2008-02-23 23:08:58, David Newall wrote:
Pavel Machek wrote:
On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
Pavel Machek [EMAIL PROTECTED] writes:
Zaurus is one example, second is small screen where you need big font
Jan Engelhardt wrote:
static void blah(void)
{
if (foo) {
bar;
bar2;
return;
}
if (this) {
that;
that2;
return;
}
/* yay, got rid of two levels of indent! */
good
Linus Torvalds wrote:
On Sat, 23 Feb 2008, David Newall wrote:
Do you actually get 80 columns wide on it?
Do people really care that deeply?
...
And do I find lines longer than 80 charactes unreadable? Hell no.
I care, yes. I've found my code looks much prettier
Bart Van Assche wrote:
> There is a reason to limit line length: scientific research has shown
> that readability of regular texts is optimal for a line length between
> 55 and 65 characters.
Putting aside the point that we're talking code, not regular text, I've
heard that said before and I
Bart Van Assche wrote:
There is a reason to limit line length: scientific research has shown
that readability of regular texts is optimal for a line length between
55 and 65 characters.
Putting aside the point that we're talking code, not regular text, I've
heard that said before and I don't
Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>> I'm personally of the opinion that a lot of checkpatch "fixes" are
>> anything but. That mainly concerns fixing overlong lines
>>
>
> Perhaps we should increase line length limit, 132 should be fine.
> Especially useful
Greg KH wrote:
> On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote:
>
>> I too agree to merge, it especially since it fixed several problems
>> for David. However, I would like to know first if the same problems
>> also happen with the 2.6 driver or if it is OK. The risk is getting
Sorry, I forgot to include the changes to pl2303.h. Here's a second patch:
--- pl2303.h.orig 2008-01-01 22:36:40.0 +1030
+++ pl2303.h2008-02-22 06:11:19.0 +1030
@@ -9,7 +9,10 @@
*/
#define PL2303_VENDOR_ID 0x067b
#define PL2303_PRODUCT_ID 0x2303
-#define
Hi Willy,
Lacking hardware for a week, I've had a bit of a hiatus from PL2303, but
I've got it back again now, and finished my work back-porting the 2.6
driver to 2.4. Here's a new patch, which is more complete than my
previous one. It's based on the 2.6.24.1.
There's a lot of trivial
Alan Cox wrote:
>> developing is entirely wrong. Oh well. Mind you, providing a
>> write_room function is NOT a real solution; it merely reduces the
>> condition to a usually-winnable race. (Ironically, when I back-ported
>> the 2.6 driver, I excluded its new write_room function. Mistake.)
>>
Alan,
Alan Cox wrote:
>> That's a very good point. Even so: on the 2.4 driver, write_room isn't
>> implemented (refer to a previous message by Alan); and in 2.6, a 1k
>> buffer is built into the driver, with nothing to prevent it being sent
>> when the hardware buffer fills.
>>
[...]
>
Alan,
Alan Cox wrote:
That's a very good point. Even so: on the 2.4 driver, write_room isn't
implemented (refer to a previous message by Alan); and in 2.6, a 1k
buffer is built into the driver, with nothing to prevent it being sent
when the hardware buffer fills.
[...]
Careful - a
Alan Cox wrote:
developing is entirely wrong. Oh well. Mind you, providing a
write_room function is NOT a real solution; it merely reduces the
condition to a usually-winnable race. (Ironically, when I back-ported
the 2.6 driver, I excluded its new write_room function. Mistake.)
Hi Willy,
Lacking hardware for a week, I've had a bit of a hiatus from PL2303, but
I've got it back again now, and finished my work back-porting the 2.6
driver to 2.4. Here's a new patch, which is more complete than my
previous one. It's based on the 2.6.24.1.
There's a lot of trivial
Sorry, I forgot to include the changes to pl2303.h. Here's a second patch:
--- pl2303.h.orig 2008-01-01 22:36:40.0 +1030
+++ pl2303.h2008-02-22 06:11:19.0 +1030
@@ -9,7 +9,10 @@
*/
#define PL2303_VENDOR_ID 0x067b
#define PL2303_PRODUCT_ID 0x2303
-#define
Krzysztof Halasa wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm personally of the opinion that a lot of checkpatch fixes are
anything but. That mainly concerns fixing overlong lines
Perhaps we should increase line length limit, 132 should be fine.
Especially useful with long
Greg KH wrote:
On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote:
I too agree to merge, it especially since it fixed several problems
for David. However, I would like to know first if the same problems
also happen with the 2.6 driver or if it is OK. The risk is getting
2.4
Stephan,
Jiri Slaby wrote:
> On 02/14/2008 03:57 PM, Stephan Rose wrote:
>> I recently purchased a USB->Com Port serial cable from Radio Shack
>> (Model number 26-183) which did no seem to want to work. After looking
>> into it I discovered that it is based on the Prolific chipset using the
>>
Adrian Bunk wrote:
> Forks are allowed, so when you don't like the way some software is
> developed you can always release a version of the software that is in
> your eyes better.
>
What a silly thought. Nobody, I should hope, wants multiple Linuxes
competing and diluting the market. That's
Adrian Bunk wrote:
Forks are allowed, so when you don't like the way some software is
developed you can always release a version of the software that is in
your eyes better.
What a silly thought. Nobody, I should hope, wants multiple Linuxes
competing and diluting the market. That's
Stephan,
Jiri Slaby wrote:
On 02/14/2008 03:57 PM, Stephan Rose wrote:
I recently purchased a USB-Com Port serial cable from Radio Shack
(Model number 26-183) which did no seem to want to work. After looking
into it I discovered that it is based on the Prolific chipset using the
PL2303
Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>
>> The current 2.6 driver maintains it's own buffer. I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however it does s
Alan Cox wrote:
>> byte of a packet is being thrown away about .1% of the time for the pl2303,
>> but I'm not sure if the FTDI driver still suffers from a similar rash. I
>>
>
> A 20 byte low speed message is too small for flow control to account for
> it.
I agree. I've observed the
Arjan van de Ven wrote:
> Bill Davidsen wrote:
>> Note that because the hardware is old, it's highly likely that most
>> of it will be retired before that sk98lin driver needs a change. I
>> can't see anyone using sk98lin on a new system, so it would be less
>> contentious to let the hardware (or
Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of the URB on a stop-transmit
Greg KH wrote:
> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
>
>> Consider a USB-attached serial port that is set to do RTS/CTS (or
>> DSR/DTR) handshaking: What stops the kernel sending more data to it when
>> the remote end lowers CTS (or DTR)?
&
Greg KH wrote:
On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
The tty layer should look
Alan Cox wrote:
To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
a race: An in-flight write URB can fill all hardware buffers, making
unsafe what previously appeared to be a safe write. I think it's
essential to delay submission of the URB on a stop-transmit condition.
Arjan van de Ven wrote:
Bill Davidsen wrote:
Note that because the hardware is old, it's highly likely that most
of it will be retired before that sk98lin driver needs a change. I
can't see anyone using sk98lin on a new system, so it would be less
contentious to let the hardware (or users)
Alan Cox wrote:
byte of a packet is being thrown away about .1% of the time for the pl2303,
but I'm not sure if the FTDI driver still suffers from a similar rash. I
A 20 byte low speed message is too small for flow control to account for
it.
I agree. I've observed the first byte of
Greg KH wrote:
On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
The current 2.6 driver maintains it's own buffer. I think that's a bad
thing: usbserial already buffers writes, and the extra buffer copy seems
unnecessary, however it does solve the putchar problem. Buffered
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Greg KH wrote:
> A "driver" is not an "application" as you tried to reference in your
> prior quotes.
I think your treating what the learned Professors said to literally.
> It is a tiny portion of the whole kernel,
The Copyright Act draws no such a distinction.
> and as such,
> does fall
My, I am full of post scripts today. This one is a peace token for Alan.
David Newall wrote:
> there are more reliable and transparent sources [than Alan.] Don't take his
> word on it. Take the words of real experts in the law, because instead
> of a mere four word conclusion, the
I explained something poorly:
> Now, Alan has made a big issue over numerous legal opinions he has
> received, but he's been completely coy in the details.
The point I wanted to make is that a few people have said that lawyers
say that kernel modules are derivative, but I only remember Alan
Marcel Holtmann wrote:
> Anyway you are still under the impression that a Linux kernel module can
> be original work in the end. We keep telling you that could be a wrong
> assumption which is based on the view of many of the kernel developers
> and of most of the lawyers that looked at this
Alan Cox wrote:
> On Fri, 08 Feb 2008 13:25:33 +1030
> David Newall <[EMAIL PROTECTED]> wrote:
>
>
>> Alan Cox wrote:
>>
>>>> It would not be improper to say that "such and such a lawyer said this
>>>> an
Greg KH wrote:
A driver is not an application as you tried to reference in your
prior quotes.
I think your treating what the learned Professors said to literally.
It is a tiny portion of the whole kernel,
The Copyright Act draws no such a distinction.
and as such,
does fall under the
Marcel Holtmann wrote:
Anyway you are still under the impression that a Linux kernel module can
be original work in the end. We keep telling you that could be a wrong
assumption which is based on the view of many of the kernel developers
and of most of the lawyers that looked at this specific
I explained something poorly:
Now, Alan has made a big issue over numerous legal opinions he has
received, but he's been completely coy in the details.
The point I wanted to make is that a few people have said that lawyers
say that kernel modules are derivative, but I only remember Alan saying
My, I am full of post scripts today. This one is a peace token for Alan.
David Newall wrote:
there are more reliable and transparent sources [than Alan.] Don't take his
word on it. Take the words of real experts in the law, because instead
of a mere four word conclusion, they explain
Alan Cox wrote:
On Fri, 08 Feb 2008 13:25:33 +1030
David Newall [EMAIL PROTECTED] wrote:
Alan Cox wrote:
It would not be improper to say that such and such a lawyer said this
and that. I'm not proposing that you breach their copyright in their
It would be highly
Marcel Holtmann wrote:
> Hi David,
>
>
> I think you're missing my point: as long as the license stays the way
> it is now, you can never distribute proprietary code unless you've
> consulted a lawyer and even then you run the risk of being sued for
> infringement if the
Alan Cox wrote:
>> It would not be improper to say that "such and such a lawyer said this
>> and that." I'm not proposing that you breach their copyright in their
>>
>
> It would be highly improper given these were business discussions
> involving companies using Linux.
Then you should
Hans-Jürgen Koch wrote:
> The license says that derivative work has to be GPL. Naturally, every
> sensible and practically usable license has gray areas. We know that
> and we live with that. But if there's room for interpretation, it's
> perfectly OK and helpful, if the copyright holder states
Hans-Jürgen Koch wrote:
> Am Fri, 08 Feb 2008 01:01:24 +1030
> schrieb David Newall <[EMAIL PROTECTED]>:
>
>>> It is not legally meaningless if copyright holders publicly state
>>> how they interpret the license and what they consider a license
>>> v
Alan Cox wrote:
>> previous statements which seemed to say, "you've spoken to numerous
>>
>
> Please don't use "seemed to say" and then quote words I've never said.
> That's misleading, rude and also awful language style.
No, it's called, "paraphrasing," and it's quite normal in a
Alan Cox wrote:
>> No, I'm right. The word "proof" is appropriate in context. (I write in
>> plain English, not Legalese.) I certainly didn't intend "proof" to mean
>> "mathematically certain." Anybody who pretends that proof in court
>> means that must be ignorant or trying to deceive.
>>
Alan Cox wrote:
>> That's what you claim it says, but has any court, anywhere, agreed with
>> you? You claim the authority of others (i.e. numerous lawyers), but I
>> don't believe you have that authority. You're just starting hearsay.
>> You've never said what lawyers and you've never told us
Alan Cox wrote:
>> It's nonsense, it's a reasonable reading of the GPL. What I am doing is
>> telling you what the GPL says, not what you wish it said.
>>
>
> In which case for each statement please give the case at appeal or higher
> level which is the precedent for the interpretation.
>
Alan Cox wrote:
>> Again, I missed who wrote the above. I'm reminded of Apple computer,
>> who explaining some engineering decisions in the Apple ][ pointed out
>> that an additional 10c in components adds $10 to the retail price (or
>> something rather like that.) Cheap, cheap, cheap helps
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> That's naive, since requirements differ in different jurisdictions, as
>> I'm sure you are perfectly aware.
> Naive? Who thinks a limit can be enforced by sw is naive!
Of course. Naturally it's near impossible to prevent
Alan Cox wrote:
>>> IANAL, but when looking at the "But when you distribute the same
>>> sections as part of a whole which is a work based on the Program, the
>>> distribution of the whole must be on the terms of this License" of the
>>> GPLv2 I would still consult a lawyer before e.g. selling
Alan Cox wrote:
>> No. Holders of Linux copyrights would have to prove that the
>> proprietary code is derived from the kernel. They have the burden of
>> proof, and defence needs merely show that their arguments are wrong.
>>
>
> Wrong again. In civil law in the USA and most of europe the
Alan Cox wrote:
>> In Australia, devices require approval from a regulatory body. Such
>> approval is withheld if appropriate safeguards are not applied.
>>
>
> We were talking about the USA.
We most certainly were not. We are talking about Linux, and everybody
wants it be used globally.
Alan Cox wrote:
>> The contract (GPL) doesn't prevent me from using GPL work, in fact it
>> encourages me. Neither can it impose conditions upon original work
>> authored by a third party.
>>
>
> First mistake: The GPL is not a contract it is a license.
Mea culpa. It is indeed a licence,
Hans-Jürgen Koch wrote:
> Am Thu, 07 Feb 2008 23:49:42 +1030
> schrieb David Newall <[EMAIL PROTECTED]>:
>
>> Nobody is saying "I don't like your licence." The issue is a
>> technical restriction in Linux that attempts to restrict non-GPL
>> softwar
Alan Cox wrote:
>> I heard this all before and I don't buy it anymore. At some point the
>> companies in Asia will understand that the whole picture looks different
>> and that not always cheap, cheap, cheap is best for their margins.
Again, I missed who wrote the above. I'm reminded of Apple
Marcel Holtmann wrote:
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> Completely wrong. However if the driver is distributed as built-in, then it
>> would need to be licensed under GPL. This means that a driver can be
>> written and
Marcel Holtmann wrote:
> Hi David,
>
>
>>> I think you're missing my point: as long as the license stays the way
>>> it is now, you can never distribute proprietary code unless you've
>>> consulted a lawyer and even then you run the risk of being sued for
>>> infringement if the copyright
Greg KH wrote:
> On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote:
>
>> Marcel Holtmann writes:
>>
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> Completely wr
Chris Friesen wrote:
> Marcel Holtmann wrote:
>
>> If the developers say that this symbol can only be used in GPL code (and
>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
>> license or don't use this symbol at all.
>>
>> If you use that symbol inside non-GPL (meaning
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> "Of course", because in many parts of the world, a device who's
>> manufacturer fails to take reasonable steps to prevent it from being
>> used outside regulatory limits is illegal. Providing source code not
Pekka Enberg wrote:
> I have simply stated that (1) the problem boils down to what is
> derived work and what is no and (2) the developers use the
> EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not
> necessarily tested in court). The _logical conclusion_ of these two
> simple
Adrian Bunk wrote:
> On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote:
>
>> David Newall wrote:
>>
>>> That being said, a module can be written such that it only dynamically
>>> links with the kernel. Ndiswrapper is an exampl
Marcel Holtmann wrote:
> I disagree here. They either play by the roles or they really do pay
> Microsoft or go with BSD. I really couldn't care less.
Then you should keep away from the kernel. The last thing that Linux
needs is someone who doesn't care if Linux succeeds or fails. "I don't
care"
Hans-Jürgen Koch wrote:
> If somebody prefers an other OS for license reasons only, let them. You
> cannot have open source software without open source license. If a
> company chooses Linux, they do it for technical reasons, and because
> they're able to modify the sources to suit their needs.
Christer Weinigel wrote:
> I also think that my customers, that decided to keep their kernel
> modules binary only, made a big mistake and have told them so. But I
> still think it's better for the Linux community to be a bit soft on
> such companies for a while. It's better to let them get away
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
>
>> On Tue, 5 Feb 2008 12:34:18 -0800
>> Greg KH <[EMAIL PROTECTED]> wrote:
>>
>>
>>> In the end, it's up to the copyright holders to enforce the license.
>>> And as I have stated in the past, a number of
Chris Friesen wrote:
> if I were to write a new GPL shim and then a new closed-source module
> that uses the shim to access kernel symbols, it is entirely possible
> that a court could rule that my closed-source module is a derivative
> work of the linux kernel because it was written specifically
Alan Cox wrote:
>> "Of course", because in many parts of the world, a device who's manufacturer
>> fails to take reasonable steps to prevent it from being used outside
>> regulatory limits is illegal. Providing source code not only is a failure
>> to take those reasonable steps, but is quite
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote:
>
>> A kernel module is akin to a process. It uses services of the kernel
>> without being part of the kernel.
>>
>
> No Linux does not work like this at all.
> ...
> Als
Alan Cox wrote:
>> If we're still talking about whether a kernel module is required to be
>> released under GPL, then yes, this is not a gray area. This is something
>> that authors of original works can decide for themselves. They have no
>>
^^^
>
>
Marcel Holtmann wrote:
>>> If the developers say that this symbol can only be used in GPL code (and
>>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
>>> license or don't use this symbol at all.
>>>
Not sure who wrote the above, but it contains a glaring legal
Marcel Holtmann wrote:
If the developers say that this symbol can only be used in GPL code (and
with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
license or don't use this symbol at all.
Not sure who wrote the above, but it contains a glaring legal error:
Alan Cox wrote:
If we're still talking about whether a kernel module is required to be
released under GPL, then yes, this is not a gray area. This is something
that authors of original works can decide for themselves. They have no
^^^
Only if they
1 - 100 of 397 matches
Mail list logo
