The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
The patch extends to general case that prediction logic get
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
The patch extends to general case that prediction logic get
> Could I convince you to try out my variation on
> detect_repeating_intervals? :)
>
> http://people.redhat.com/riel/cstate/cstate-stddev-converge.patch
>
> I suspect that small change might help your code adapt to changed
> conditions even faster.
Yes. of course. your patch of
On 09/17/2012 09:53 PM, Youquan Song wrote:
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
The patch extends the patch to enhance the prediction
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu governor has a method to predict the repeat
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
The patch extends the patch to enhance the prediction
On 09/17/2012 09:53 PM, Youquan Song wrote:
The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.
cpuidle menu
Could I convince you to try out my variation on
detect_repeating_intervals? :)
http://people.redhat.com/riel/cstate/cstate-stddev-converge.patch
I suspect that small change might help your code adapt to changed
conditions even faster.
Yes. of course. your patch of cstate-stddev-converge is
On Thu, Jul 19, 2012 at 1:19 PM, Lance Ortiz wrote:
> When an AER event occurs not all of the print notifications are at the
> same log level. This can cause an incomplete AER log from the users
> point of view when monitoring the console output.
>
> The completion message in do_recovery() is
On Thu, Jul 19, 2012 at 1:19 PM, Lance Ortiz lance.or...@hp.com wrote:
When an AER event occurs not all of the print notifications are at the
same log level. This can cause an incomplete AER log from the users
point of view when monitoring the console output.
The completion message in
When an AER event occurs not all of the print notifications are at the
same log level. This can cause an incomplete AER log from the users
point of view when monitoring the console output.
The completion message in do_recovery() is currently set to KERN_DEBUG
(log level 7) while the starting
When an AER event occurs not all of the print notifications are at the
same log level. This can cause an incomplete AER log from the users
point of view when monitoring the console output.
The completion message in do_recovery() is currently set to KERN_DEBUG
(log level 7) while the starting
On Mon, 11 Feb 2008, Andi Kleen wrote:
>
> Not much left from the original code and I don't want my name
> on it because there is code in there I disagree with.
>
> I don't think any of the Ben inspired code is left in there
> either, but I left his name in for now.
>
> Signed-off-by: Andi
Not much left from the original code and I don't want my name
on it because there is code in there I disagree with.
I don't think any of the Ben inspired code is left in there
either, but I left his name in for now.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr.c |
On Mon, 11 Feb 2008, Andi Kleen wrote:
Not much left from the original code and I don't want my name
on it because there is code in there I disagree with.
I don't think any of the Ben inspired code is left in there
either, but I left his name in for now.
Signed-off-by: Andi Kleen
Not much left from the original code and I don't want my name
on it because there is code in there I disagree with.
I don't think any of the Ben inspired code is left in there
either, but I left his name in for now.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
arch/x86/mm/pageattr.c |
From: Mike Frysinger <[EMAIL PROTECTED]>
- thus clearing out the need for spin locks
- add a small optimization for reading of the rtc field
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/rtc/rtc-bfin.c | 249
From: Mike Frysinger [EMAIL PROTECTED]
- thus clearing out the need for spin locks
- add a small optimization for reading of the rtc field
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
drivers/rtc/rtc-bfin.c | 249
On Fri, 31 Aug 2007 13:56:10 -0500 Rob Landley wrote:
> On Friday 31 August 2007 7:10:00 am Satyam Sharma wrote:
> > Hi Rob,
> >
> > On Thu, 30 Aug 2007, Rob Landley wrote:
> > > On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
> > > > Please use the expected (canonical) patch format.
>
On Friday 31 August 2007 7:10:00 am Satyam Sharma wrote:
> Hi Rob,
>
> On Thu, 30 Aug 2007, Rob Landley wrote:
> > On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
> > > Please use the expected (canonical) patch format.
> > >
> > > See Documentation/SubmittingPatches:
> > > 14) The
Hi Rob,
On Thu, 30 Aug 2007, Rob Landley wrote:
> On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
> > Please use the expected (canonical) patch format.
> >
> > See Documentation/SubmittingPatches:
> > 14) The canonical patch format
>
> from Rob Landley <[EMAIL PROTECTED]>
>
On Friday 31 August 2007 7:10:00 am Satyam Sharma wrote:
Hi Rob,
On Thu, 30 Aug 2007, Rob Landley wrote:
On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
Please use the expected (canonical) patch format.
See Documentation/SubmittingPatches:
14) The canonical patch
On Fri, 31 Aug 2007 13:56:10 -0500 Rob Landley wrote:
On Friday 31 August 2007 7:10:00 am Satyam Sharma wrote:
Hi Rob,
On Thu, 30 Aug 2007, Rob Landley wrote:
On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
Please use the expected (canonical) patch format.
See
Hi Rob,
On Thu, 30 Aug 2007, Rob Landley wrote:
On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
Please use the expected (canonical) patch format.
See Documentation/SubmittingPatches:
14) The canonical patch format
from Rob Landley [EMAIL PROTECTED]
Signed-off-by: Rob
On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
> Please use the expected (canonical) patch format.
>
> See Documentation/SubmittingPatches:
> 14) The canonical patch format
from Rob Landley <[EMAIL PROTECTED]>
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
ecryptfs.txt moved into
On Thu, 30 Aug 2007 14:46:17 -0500 Rob Landley wrote:
> Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
>
> ecryptfs.txt moved into Documentation/filesystems, so move the 00-INDEX entry.
Please use the expected (canonical) patch format.
See Documentation/SubmittingPatches:
14) The canonical
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
ecryptfs.txt moved into Documentation/filesystems, so move the 00-INDEX entry.
--- linux-2.6.23-rc4/Documentation/00-INDEX 2007-08-27 20:32:35.0
-0500
+++ linux-new/Documentation/00-INDEX2007-08-30 14:43:15.0 -0500
@@ -134,8
Signed-off-by: Rob Landley [EMAIL PROTECTED]
ecryptfs.txt moved into Documentation/filesystems, so move the 00-INDEX entry.
--- linux-2.6.23-rc4/Documentation/00-INDEX 2007-08-27 20:32:35.0
-0500
+++ linux-new/Documentation/00-INDEX2007-08-30 14:43:15.0 -0500
@@ -134,8
On Thu, 30 Aug 2007 14:46:17 -0500 Rob Landley wrote:
Signed-off-by: Rob Landley [EMAIL PROTECTED]
ecryptfs.txt moved into Documentation/filesystems, so move the 00-INDEX entry.
Please use the expected (canonical) patch format.
See Documentation/SubmittingPatches:
14) The canonical patch
On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
Please use the expected (canonical) patch format.
See Documentation/SubmittingPatches:
14) The canonical patch format
from Rob Landley [EMAIL PROTECTED]
Signed-off-by: Rob Landley [EMAIL PROTECTED]
ecryptfs.txt moved into
Ingo Korb <[EMAIL PROTECTED]> writes:
> Loads find and seems to work with basic tests (and no character loss,
> yay!). I'll try 8-link bonded ppp when I've set up a second box.
Update: The driver now survives 7-link[1] bonded ppp without problems
with both UART types. IIRC it previously died
Jiri Slaby <[EMAIL PROTECTED]> writes:
> Okay, tty alloc after pci init, attached patch should fix it. Could you
> retest?
Loads find and seems to work with basic tests (and no character loss,
yay!). I'll try 8-link bonded ppp when I've set up a second box.
-ik
-
To unsubscribe from this list:
Ingo Korb wrote:
> > > Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller
> > > chip as PCI interface, the /64 uses a PLX PCI9050.
> >
> > I don't undestand this. IDE grabs the device? This is possible and if yes,
> > I'll fix the IDE driver.
>
> Yes, IDE (specifically:
Ingo Korb wrote:
Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller
chip as PCI interface, the /64 uses a PLX PCI9050.
I don't undestand this. IDE grabs the device? This is possible and if yes,
I'll fix the IDE driver.
Yes, IDE (specifically: generic IDE PCI
Jiri Slaby [EMAIL PROTECTED] writes:
Okay, tty alloc after pci init, attached patch should fix it. Could you
retest?
Loads find and seems to work with basic tests (and no character loss,
yay!). I'll try 8-link bonded ppp when I've set up a second box.
-ik
-
To unsubscribe from this list:
Ingo Korb [EMAIL PROTECTED] writes:
Loads find and seems to work with basic tests (and no character loss,
yay!). I'll try 8-link bonded ppp when I've set up a second box.
Update: The driver now survives 7-link[1] bonded ppp without problems
with both UART types. IIRC it previously died with
Ingo Korb napsal(a):
> Hi!
>
> The stallion driver in 2.6.21.3 put this little notice in my dmesg:
>
> === Cut ===
> Stallion Multiport Serial Driver: version 5.6.0
> stallion :00:0b.0: please, report this to LKML: 100b/d001/ff
> ACPI: PCI Interrupt :00:0b.0[
Hi!
The stallion driver in 2.6.21.3 put this little notice in my dmesg:
=== Cut ===
Stallion Multiport Serial Driver: version 5.6.0
stallion :00:0b.0: please, report this to LKML: 100b/d001/ff
ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 17
stallion: probe of 0
Ingo Korb napsal(a):
Hi!
The stallion driver in 2.6.21.3 put this little notice in my dmesg:
=== Cut ===
Stallion Multiport Serial Driver: version 5.6.0
stallion :00:0b.0: please, report this to LKML: 100b/d001/ff
ACPI: PCI Interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 17
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 4b0c3ad..b1ab0d5
From: Muli Ben-Yehuda [EMAIL PROTECTED]
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-calgary.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 4b0c3ad..b1ab0d5
If we can discover devices using PNP, we can skip some legacy probes.
This flag ("pnp_platform_devices") indicates that PNPBIOS or PNPACPI
is enabled and should tell us about builtin devices.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/pnp/core.c
If we can discover devices using PNP, we can skip some legacy probes.
This flag (pnp_platform_devices) indicates that PNPBIOS or PNPACPI
is enabled and should tell us about builtin devices.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: work/drivers/pnp/core.c
> > That is the point: the result is not a single work. It is a
> > collection or compilation of works, just like an anthology. If
> > there is any creativity involved, is in choosing and ordering
> > the parts. The creation of works that "can be linked together"
> > is not protected by copyright:
David Schwartz wrote:
>>That is the point: the result is not a single work. It is a
>>collection or compilation of works, just like an anthology.
>>If there is any creativity involved, is in choosing and
>>ordering the parts. The creation of works that "can be
>>linked together" is not protected
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote:
> On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
> > > > This is different. They are not giving the source at all. The licence
> > > > for those object files _has_ to be different. _They_ want it to be
> > > > different.
> > >
> That is the point: the result is not a single work. It is a
> collection or compilation of works, just like an anthology. If
> there is any creativity involved, is in choosing and ordering
> the parts. The creation of works that "can be linked together"
> is not protected by copyright: the
f the GPL)
>
>> >Wouldn't you agree that this is the normal form of use of
>> >a library? And doesn't first sale give you the right to
>> >normal use of a work you have legally acquired?
>>
>>Yes. And yes, if you buy a copy of the library, yes (but
to
normal use of a work you have legally acquired?
Yes. And yes, if you buy a copy of the library, yes (but
notice: not if you downloaded it for free from the Net).
There is no legal distinction.
Why do you think that? You can even be right on this, but your
argument below did not convince me.
Your
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote:
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
This is different. They are not giving the source at all. The licence
for those object files _has_ to be different. _They_ want it to be
different.
Sure, but in
That is the point: the result is not a single work. It is a
collection or compilation of works, just like an anthology. If
there is any creativity involved, is in choosing and ordering
the parts. The creation of works that can be linked together
is not protected by copyright: the literary
David Schwartz wrote:
That is the point: the result is not a single work. It is a
collection or compilation of works, just like an anthology.
If there is any creativity involved, is in choosing and
ordering the parts. The creation of works that can be
linked together is not protected by copyright:
That is the point: the result is not a single work. It is a
collection or compilation of works, just like an anthology. If
there is any creativity involved, is in choosing and ordering
the parts. The creation of works that can be linked together
is not protected by copyright: the
> > What compels you to agree with an EULA?
On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote:
> If you do not agree with the EULA, you cannot and do not acquire
> lawful possession of the work.
What about cases where you pay for the software before you're allowed
to see the
This thread should probably get moved off-list soon, it's like
beating the dead horse long after its flesh has decayed and its
bones disintegrated to dust.
On Apr 13, 2005, at 21:54, David Schwartz wrote:
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
Yes, the GPL can give you
> It seems to me, that to be consistent with the argument you seem to be
> presenting concerning binary data in GPLd code, that you also need to be
> demanding the "source" hardware design for binary register values.
>
> Why not consider the binary firmware in the same category as binary
>
> On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
> > Yes, the GPL can give you rights you wouldn't otherwise have. A
> > EULA can take away rights you would otherwise have.
> What compels you to agree with an EULA?
If you do not agree with the EULA, you cannot and do
of the individual works such that they can be linked together.
> >Wouldn't you agree that this is the normal form of use of a
> >library? And doesn't first sale give you the right to normal
> >use of a work you have legally acquired?
>
> Yes. And yes, if you buy a co
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
> > > This is different. They are not giving the source at all. The licence
> > > for those object files _has_ to be different. _They_ want it to be
> > > different.
> >
> > Sure, but in this case, the binary firmware blob is also a
the
> > > rest
> > > of it. gives permission to distribute said firmware blob as
> > > part of the linux kernel module driver for their hardware. The actual
> > > syntax
> > > of the inclusion of the code is still covered by the GPL, as is the rest
>
On Tue, Apr 12, 2005 at 11:28:59PM -0700, Sean Kellogg wrote:
> Failure to have a click-through license means that there is no acceptance,
> which is a fundamental part of contract law. No acceptance, no
> contract, no exceptions.
False.
For example, you can indicate acceptance of the GPL by
On Tue, 12 Apr 2005, David Schwartz wrote:
> > > > The EULA is irrelevant in germany and in many parts of the USA.
>
> > > Really? I was under the impression EULA's were routinely
> > > upheld in the USA.
> > > If you have any references for that, I'd love to hear them.
>
> >
On Tuesday 12 April 2005 10:46 pm, Raul Miller wrote:
> In essence, you're claiming that the difference between Davidson
> & Associates v. Internet Gateway Inc (2004) and other cases such as
> Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000)
> is that the presence of a
On Tuesday 12 April 2005 10:46 pm, Raul Miller wrote:
In essence, you're claiming that the difference between Davidson
Associates v. Internet Gateway Inc (2004) and other cases such as
Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000)
is that the presence of a
On Tue, 12 Apr 2005, David Schwartz wrote:
The EULA is irrelevant in germany and in many parts of the USA.
Really? I was under the impression EULA's were routinely
upheld in the USA.
If you have any references for that, I'd love to hear them.
On Tue, Apr 12, 2005 at 11:28:59PM -0700, Sean Kellogg wrote:
Failure to have a click-through license means that there is no acceptance,
which is a fundamental part of contract law. No acceptance, no
contract, no exceptions.
False.
For example, you can indicate acceptance of the GPL by
covered by the GPL, as is the rest
of
the driver code.
This is fine with me. It is the existance of legal threats versus
debian I don't agree upon.
Notice that debian can't afford to be sued even if they are right, so ...
So what? This is not the point. You can be sued any time
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
This is different. They are not giving the source at all. The licence
for those object files _has_ to be different. _They_ want it to be
different.
Sure, but in this case, the binary firmware blob is also a binary without
such that they can be linked together.
Wouldn't you agree that this is the normal form of use of a
library? And doesn't first sale give you the right to normal
use of a work you have legally acquired?
Yes. And yes, if you buy a copy of the library, yes (but
notice: not if you downloaded it for free
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
Yes, the GPL can give you rights you wouldn't otherwise have. A
EULA can take away rights you would otherwise have.
What compels you to agree with an EULA?
If you do not agree with the EULA, you cannot and do not
It seems to me, that to be consistent with the argument you seem to be
presenting concerning binary data in GPLd code, that you also need to be
demanding the source hardware design for binary register values.
Why not consider the binary firmware in the same category as binary
register
This thread should probably get moved off-list soon, it's like
beating the dead horse long after its flesh has decayed and its
bones disintegrated to dust.
On Apr 13, 2005, at 21:54, David Schwartz wrote:
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
Yes, the GPL can give you
What compels you to agree with an EULA?
On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote:
If you do not agree with the EULA, you cannot and do not acquire
lawful possession of the work.
What about cases where you pay for the software before you're allowed
to see the EULA?
On Tue, Apr 12, 2005 at 03:45:43PM -0700, David Schwartz wrote:
> This wasn't a copyright case. The court only refused to uphold the
> agreement because there was no oppurtunity to review the agreement before
> purchase. So it certainly wouldn't apply to a click-through type agreement.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote:
[snip]
> > A did put a GPL notice on it. He can't change his mind later.
> Then he should give us the source.
[snip]
> The fact remains that those firmware blob have no licence, and thus defacto
> fall under the GPL.
you the right to normal
>use of a work you have legally acquired?
Yes. And yes, if you buy a copy of the library, yes (but
notice: not if you downloaded it for free from the Net).
>
>There are many ways you can lawfully create a derivative work
>without explicit permission of the copyright hol
t; > rest
> > of it. gives permission to distribute said firmware blob as
> > part of the linux kernel module driver for their hardware. The actual
> > syntax
> > of the inclusion of the code is still covered by the GPL, as is the rest
> > of
> > the driver
> David Schwartz wrote:
>
> > This would, of course, only make sense if you *had* to agree to the
> > license to *create* the derivative work. If you were able to create
> > the derivative work under first sale or fair use rights, then the
> > restrictions in the contract would not apply to
On Tue, 12 Apr 2005, David Schwartz wrote:
> > If you buy a W*nd*ws install CD, you can create a derived work,
> > e.g. an image
> > of your installation, under the fair use rights (IANAL). Can you
> > distribute
> > that image freely?
>
> I would say that if not for the EULA, you could
> > > The EULA is irrelevant in germany and in many parts of the USA.
> > Really? I was under the impression EULA's were routinely
> > upheld in the USA.
> > If you have any references for that, I'd love to hear them.
> http://www.freibrunlaw.com/articles/articl22.htm
This wasn't a
> On Tue, Apr 12, 2005 at 09:44:29AM -0700, David Schwartz wrote:
> > I would say that if not for the EULA, you could transfer ownership
> > of the image to someone else. And if you legally acquired two copies of
> > Windows, you could install both of them and transfer them. Otherwise,
> >
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
> Yes, the GPL can give you rights you wouldn't otherwise have. A
> EULA can take away rights you would otherwise have.
What compels you to agree with an EULA?
> In the few court cases that have directly addresses
On Tue, Apr 12, 2005 at 12:01:15PM -0700, David Schwartz wrote:
> Would you agree that compiling and linking a program that uses
> a library creates a derivative work of that library?
No, I would not.
Creating a derivative work requires creativity, and a linker is not
creative.
The
On Tue, 12 Apr 2005, David Schwartz wrote:
> > The EULA is irrelevant in germany and in many parts of the USA.
>
> Really? I was under the impression EULA's were routinely upheld in the
> USA.
> If you have any references for that, I'd love to hear them.
> On Tue, 12 Apr 2005, David Schwartz wrote:
> > > If you buy a W*nd*ws install CD, you can create a derived work,
> > > e.g. an image
> > > of your installation, under the fair use rights (IANAL). Can you
> > > distribute
> > > that image freely?
> > I would say that if not for the EULA,
On Tue, Apr 12, 2005 at 09:44:29AM -0700, David Schwartz wrote:
> I would say that if not for the EULA, you could transfer ownership
> of the image to someone else. And if you legally acquired two copies of
> Windows, you could install both of them and transfer them. Otherwise,
> you could
David Schwartz wrote:
>>David Schwartz <[EMAIL PROTECTED]> wrote: If you buy a
>>W*nd*ws install CD, you can create a derived work, e.g. an
>>image of your installation, under the fair use rights
>>(IANAL). Can you distribute that image freely?
>>
>
>I would say that if not for the EULA, you
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> >>Copyright law only _explicitly_ grants a monopoly on preparation of
> >>derivative works. However, it is trivial, and overwhelmingly common,
> >>for a copyright owner to grant a license to create a derivative work
> >>that is conditional on how
so there's no other holders involved. We're talking
about the firmware case. A is one or two well identified subjects.
And A wrote it is GPL'ed. Whether you agree or not, that's the licence
A chose. A placed the copyright notice.
This is where i would need legal counsel, as to whether this means C
David Schwartz wrote:
This would, of course, only make sense if you *had* to agree to the
license to *create* the derivative work. If you were able to create
the derivative work under first sale or fair use rights, then the
restrictions in the contract would not apply to you.
The only way to
David Schwartz <[EMAIL PROTECTED]> wrote:
>>Copyright law only _explicitly_ grants a monopoly on preparation of
>>derivative works. However, it is trivial, and overwhelmingly common,
>>for a copyright owner to grant a license to create a derivative work
>>that is conditional on how the licensee
is included by mere
> aggregation, so there's no other holders involved. We're talking
> about the firmware case. A is one or two well identified subjects.
> And A wrote it is GPL'ed. Whether you agree or not, that's the licence
> A chose. A placed the copyright notice.
This is where i
the firmware case. A is one or two well identified subjects.
And A wrote it is GPL'ed. Whether you agree or not, that's the licence
A chose. A placed the copyright notice.
This is where i would need legal counsel, as to whether this means C or
someone else may stop you from distributing unless you
David Schwartz [EMAIL PROTECTED] wrote:
Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works. However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to
David Schwartz wrote:
This would, of course, only make sense if you *had* to agree to the
license to *create* the derivative work. If you were able to create
the derivative work under first sale or fair use rights, then the
restrictions in the contract would not apply to you.
The only way to
401 - 500 of 862 matches
Mail list logo
