Various Errors with recent GIT
In a recent (haven't tested the latest git, but I have tested one pulled down
1/29 - I think it's 24e1c13) I see the following errors when the AES crypto
module is loaded:
[ 27.786935] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.786984] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.787141] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.787187] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.787232] aes_x86_64: Unknown symbol crypto_ft_tab
[ 27.625672] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.625721] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.625793] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.625838] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.625883] aes_x86_64: Unknown symbol crypto_ft_tab
Another problem is one I wasn't able to find any kind of trigger for, other
than just running XChat. Every so often XChat would seem to freeze - but if
run from the command line, switching to that terminal window and
hitting "ctrl-c" would cause it to rapidly update and become responsive again.
The freeze would happen at a random time interval that I couldn't figure out.
The last two problems have different symptoms. With one the kernel would
sometimes spin unable to get a non-error return from the CD/DVD burner drive
in my laptop - it'd start at UDMA133 and rapidly devolve down to PIO0 and then
spin trying and retrying PIO0. The only part of the message I remember exactly
is { DRDY } on 90% of the messages once it switched to trying only the PIO
modes, although I have seen similar messages about this kind of error on the
list recently.
And the final error is one that I've been seeing since 2.6.24-rc6 and reported
as a secondary error in 2.6.24-rc7. The mac80211 system hits a warning when my
system initially brings my Wifi connection (iwlwifi is the driver) online. The
problem points to the following line:
WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
so it looks as though the initial packet from the device coming online and/or
registering with the network is corrupt. This does not happen when I boot
2.6.22 and load the pre-merge iwlwifi/mac80211 code and I do not have the time
or resources to bisect this problem at the moment or I would be trying to find
the cause. (This isn't a hardware problem like I initially thought, since the
code states that it's up to the driver to format the packet correctly - I
haven't been able to locate any changes to the iwlwifi code post import, (in
the recieve path that would have caused this, but the search was non
exhaustive) so I'm wondering if this might be a pre-existing bug...)
[ 49.960849] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 50.185438] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
[ 50.185446] Pid: 0, comm: swapper Not tainted 2.6.24-rc7-git #1
[ 50.185450]
[ 50.185451] Call Trace:
[ 50.185454][] :mac80211:__ieee80211_rx+0xc99/0xd60
[ 50.185509] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.185526] [] :iwl3945:iwl_rx_queue_restock+0xca/0x170
[ 50.185533] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.18] []
:mac80211:ieee80211_tasklet_handler+0xb8/0x120
[ 50.185570] [] tasklet_action+0x51/0xc0
[ 50.185576] [] _spin_unlock+0x14/0x40
[ 50.185583] [] __do_softirq+0x64/0xe0
[ 50.185592] [] call_softirq+0x1c/0x30
[ 50.185599] [] do_softirq+0x3d/0x90
[ 50.185605] [] irq_exit+0x88/0xa0
[ 50.185611] [] do_IRQ+0xc5/0x1b0
[ 50.185619] [] ret_from_intr+0x0/0xa
[ 50.185628][]
:processor:acpi_idle_enter_bm+0x273/0x2e3
[ 50.185647] [] :processor:acpi_idle_enter_bm+0x269/0x2e3
[ 50.185652] [] menu_select+0xad/0xe0
[ 50.185657] [] cpuidle_idle_call+0x95/0xd0
[ 50.185661] [] cpuidle_idle_call+0x0/0xd0
[ 50.185665] [] cpu_idle+0x73/0xe0
[ 50.185670] [] start_secondary+0x315/0x410
[ 50.185683]
(That's the complete warning from my 2.6.24-rc7 kernel... The following is the
complete warning from the 24e1c13 build)
[ 182.298665] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 182.359208] ppdev: user-space parallel port driver
[ 182.623816] [ cut here ]
[ 182.623826] WARNING: at net/mac80211/rx.c:1704
__ieee80211_rx_handle_packet+0x8e7/0x980 [mac80211]()
[ 182.623831] Modules linked in: ppdev acpi_cpufreq cpufreq_ondemand
cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats freq_t
able dock container sbs sbshc dm_crypt dm_mod ipv6 sbp2 parport_pc lp parport
arc4 ecb crypto_blkcipher iwl3945 mac80211 cfg80211 ata_generic snd_hda_intel
snd_hwdep snd_pcm_oss s
nd_pcm snd_page_alloc snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event sdhci serio_raw psmouse pcspkr iTCO_wdt
iTCO_vendor_support ricoh_mmc mmc
_core pata_acpi snd_seq snd_timer snd_seq_device video snd soundcore ac shpchp
pci_hotplug button battery intel_agp evdev ext3 jbd mbcache sg sd_mod ohci1394
ieee1394 ata_piix ahc
i tg3 libata scsi_mod ehci_hcd uhci_hcd usbcore therma
Re: Various Errors with recent GIT
On Friday 01 February 2008 23:42:47 Gabriel C wrote: > Daniel Hazelton wrote: > > Another problem is one I wasn't able to find any kind of trigger for, > > other than just running XChat. Every so often XChat would seem to freeze > > - but if run from the command line, switching to that terminal window and > > hitting "ctrl-c" would cause it to rapidly update and become responsive > > again. The freeze would happen at a random time interval that I couldn't > > figure out. > > I got that Xchat problem on i686 yesterday. > > I'm running 2.6.24-06481-gaa62999 right now with near 4h uptime and the > problem seems fixed. Hrm... I'll see about updating my local git tree and building a new kernel. With the x86 merger if it's fixed in 32bit it is probably also fixed in 64bit. The other problems are a bigger concern, though. I don't like seeing warnings in my logs - makes me worry about the long-term stability of my systems. And with the apparent problem in libata I'm not too sure I will be able to successfully boot into a new kernel - after all, the system just spins on trying and retrying the drive without any progress. (And it seems random, though it does appear that the trick to a successful boot is to get the hardware completely powered down - in other words, a completely cold boot) DRH > > DRH > > Gabriel -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [BUG] 2.6.24 refuses to boot - ATA problem?
On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
> Hi,
>
> I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
> PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer is
> failing to initialise:
>
> Driver 'sd' needs updating - please use bus_type methods
> scsi0 : ata_piix
> scsi1 : ata_piix
> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
> ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
> ata1.00: 39851760 sectors, multi 16: LBA
> ata1.00: configured for UDMA/66
> ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
> UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
> ata2.00: configured for UDMA/66
> ata2.01: configured for UDMA/33
> scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0 ANSI:
> 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
> (20404 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sda:<4>ehci_hcd :03:0d.2: Unlink after no-IRQ?
> Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for UDMA/66
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for UDMA/66
> ata1: EH complete
> SysRq : Emergency Sync
> Emergency Sync complete
> SysRq : Emergency Remount R/O
> Emergency Remount complete
> SysRq : Resetting
This error is what I mentioned in a post yesterday that mentioned several
errors I've seen with a recent kernel built from linus' git.
The only difference is that here the kernel starts at UDMA/133 and devolves
all the way down to PIO0 before spinning forever at that. A fully "cold" boot
(ie: removing all power from the system for a period of several minutes and
then powering it back on) seems to fix this problem.
I've got a kernel here built from git b036555adc but I haven't tested it yet.
If the problem still occurs with it, I'll try to get a copy of the output
posted here.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
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: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Saturday 02 February 2008 19:22:49 Greg KH wrote: > On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: > > @@ -145,6 +145,10 @@ as small as possible, and that all potential > > interfaces are tested as well as they can be (unused interfaces are > > pretty much impossible to test for validity.) > > > > +However, changing an interface can be delicate work and it can take > > +significant amount of developer effort. Therefore, an interface is > > +not changed unless the change is regarded as very important by the > > +developers. > > > > What to do > > -- > > I still don't understand why you want to add these sentances. Why are > they needed? Are people thinking that the kernel developers just > randomly change things just because they are bored and have nothing else > to do at the moment? Do people think that our changes are gratuitous? > > Even so, I don't think this needs to be added, we have already stated > many good reasons why changing apis are necessary and good. Do need to > add another one? > > thanks, > > greg k-h Actually, Greg, a hell of a lot of people that don't track linux kernel development do think that way. And there are always going to be people that think that way. As it stands the recommended paragraph does clarify that, while the interfaces aren't stable, can and will change as needed, there are some core interfaces that *WON'T* change without a very good reason. Having such a public statement that anyone can see and people can point to is another weapon to help people fight the FUD that exists around Linux. DRH (And yes, I do fight anti-linux FUD all the time. My parents have been using my laptops and can actually be quoted as saying that the next computer they buy will run Linux! My family mostly runs Windows - my brothers because their kids would complain about not being able to play their games and my sister because her husband is so computer illiterate I'm amazed he actually knows how to do a Google search) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Sunday 03 February 2008 00:03:10 Greg KH wrote: > On Sat, Feb 02, 2008 at 07:52:37PM -0500, Daniel Hazelton wrote: > > On Saturday 02 February 2008 19:22:49 Greg KH wrote: > > > On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: > > > > > > > > > > @@ -145,6 +145,10 @@ as small as possible, and that all potential > > > > interfaces are tested as well as they can be (unused interfaces are > > > > pretty much impossible to test for validity.) > > > > > > > > +However, changing an interface can be delicate work and it can take > > > > +significant amount of developer effort. Therefore, an interface is > > > > +not changed unless the change is regarded as very important by the > > > > +developers. > > > > > > > > What to do > > > > -- > > > > > > I still don't understand why you want to add these sentances. Why are > > > they needed? Are people thinking that the kernel developers just > > > randomly change things just because they are bored and have nothing > > > else to do at the moment? Do people think that our changes are > > > gratuitous? > > > > > > Even so, I don't think this needs to be added, we have already stated > > > many good reasons why changing apis are necessary and good. Do need to > > > add another one? > > > > Actually, Greg, a hell of a lot of people that don't track linux kernel > > development do think that way. And there are always going to be people > > that think that way. > > So why would to more sentances trying to say "see, we really do know > what we are doing, we aren't idiots" make things any better to these > people? (hint, it wouldn't...) I know this, because I've never needed to even read the document to understand why the API may have to change. But there are people that are very brain dead - I mean *EXTREMELY* brain dead who will start drooling and not understand the whole point of the document without a simple statement like the above. It is those people - and I've had a hell of a lot of contact with them (including people manning the phones in tech support departments!) - that wouldn't understand that the reason for the lack of a "fixed, stable API" is because of the various API changes that add capacity. (Instead they'd say "But MS does it with Windows" - ignoring the fact that the Windows API changed when NT3.51 was released, changed again when Win95 was released and has changed with *EVERY* release of Windows since - to the point that there are programs written for Win95 that can't/won't run on an XP machine.) > > As it stands the recommended paragraph does clarify that, while the > > interfaces aren't stable, can and will change as needed, there are some > > core interfaces that *WON'T* change without a very good reason. > > Again, do you think we kernel developers just randomly change core apis > because we are bored and want something to do late at night when we > can't sleep and are tired of playing Rock Band? No, I don't. Never have. But the fact is that there *ARE* people who do think that way. I've had a hell of a lot of contact with them. When I talk to people about using Linux (locally - I get "pinged" by someone every time I walk into a store to buy something, anymore) there is at least one person who complains that they can't run Linux because required hardware X isn't supported, and the manufacturer says its because there isn't a stable API to write the driver against. (though it's usually a lot coarser and less technical - I'm sure you understand) > > Having such a public statement that anyone can see and people can > > point to is another weapon to help people fight the FUD that exists > > around Linux. > > The whole article explains why apis are change for very good reasons > (evolution of hardware, security, we now know better, etc.) That's the > whole point of the document... Yes, it does, but you are making the mistake I used to make all the time and assuming that most people are going to actually have the ability to take the information in the document and comprehend that any *ONE* of the reasons that a stable API is bad is enough to not have one. Having such a paragraph to point to - or just having it there when those dead-brained people actually find and read the document - will definitely be a good thing. ... And now that I've re-iterated and explained the rather poor opinion I have of most people in the world and how it applies to this situation, I'm going to shut up and not say another word about this. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [BUG] 2.6.24 refuses to boot - ATA problem?
On Sunday 03 February 2008 12:36:33 Jeff Garzik wrote:
> Daniel Hazelton wrote:
> > On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
> >> Hi,
> >>
> >> I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
> >> PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer
> >> is failing to initialise:
> >
> >
> >
> >> Driver 'sd' needs updating - please use bus_type methods
> >> scsi0 : ata_piix
> >> scsi1 : ata_piix
> >> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
> >> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
> >> ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
> >> ata1.00: 39851760 sectors, multi 16: LBA
> >> ata1.00: configured for UDMA/66
> >> ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
> >> UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
> >> ata2.00: configured for UDMA/66
> >> ata2.01: configured for UDMA/33
> >> scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0
> >> ANSI: 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
> >> sd 0:0:0:0: [sda] Write Protect is off
> >> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> >> support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
> >> (20404 MB)
> >> sd 0:0:0:0: [sda] Write Protect is off
> >> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> >> support DPO or FUA sda:<4>ehci_hcd :03:0d.2: Unlink after no-IRQ?
> >> Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
> >> SAct 0x0 SErr 0x0 action 0x2 frozen
> >> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >> ata1.00: status: { DRDY }
> >> ata1: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> >> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >> ata1.00: status: { DRDY }
> >> ata1: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> SysRq : Emergency Sync
> >> Emergency Sync complete
> >> SysRq : Emergency Remount R/O
> >> Emergency Remount complete
> >> SysRq : Resetting
> >
> > This error is what I mentioned in a post yesterday that mentioned several
> > errors I've seen with a recent kernel built from linus' git.
> >
> > The only difference is that here the kernel starts at UDMA/133 and
> > devolves all the way down to PIO0 before spinning forever at that. A
> > fully "cold" boot (ie: removing all power from the system for a period of
> > several minutes and then powering it back on) seems to fix this problem.
> >
> > I've got a kernel here built from git b036555adc but I haven't tested it
> > yet. If the problem still occurs with it, I'll try to get a copy of the
> > output posted here.
>
> If its reproducible, please bisect... That will tell us precisely the
> problematic change.
>
> Jeff
It doesn't occur with 36555adc here - at least, it didn't the two times I've
booted a kernel built from that tree. With 36555adc I have other problems and
will be refreshing my copy of the code first. But I will start bisecting if
the problem persists.
I'm also going to make sure it wasn't caused by something strange, although,
IIRC, the only real differences in the configs from the kernel that booted
but had the somewhat random libata problem and the "strange xchat lockup"
problem is the CPA code and the "pre-emptible RCU" - so I'm going to turning
off one and then both of those options.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
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: [PATCH] UAPI: Fix tools/vm/page-types.c
On 10/23/12 09:20, David Howells wrote: Fix tools/vm/page-types.c to use the UAPI variant of linux/kernel-page-flags.h lest the following error appear: In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory Reported-by: Daniel Hazelton Signed-off-by: David Howells cc: Fengguang Wu --- tools/vm/page-types.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/vm/page-types.c b/tools/vm/page-types.c index cd1b03e..b76edf2 100644 --- a/tools/vm/page-types.c +++ b/tools/vm/page-types.c @@ -35,7 +35,7 @@ #include #include #include "../../include/uapi/linux/magic.h" -#include "../../include/linux/kernel-page-flags.h" +#include "../../include/uapi/linux/kernel-page-flags.h" #ifndef MAX_PATH FWIW: Tested-by: Daniel Hazelton -- 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/
tools/vm build fails
After doing any build in the kernel (last attempt was an allmodconfig) I've tried to build the 'vm' tool in tools/vm and the build fails - looks to be fallout from the uapi header work. [madman@localhost tools]$ make V=1 vm make -C vm/ make[1]: Entering directory `/home/madman/sources/linux-2.6/tools/vm' gcc -Wall -Wextra -o page-types page-types.c In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory compilation terminated. make[1]: *** [page-types] Error 1 make[1]: Leaving directory `/home/madman/sources/linux-2.6/tools/vm' make: *** [vm] Error 2 I'm not a kernel developer (I've tried and been unable to wrap my head around any part that I was going to try working on :( )and was just trying bits in tools/ at random to see what, exactly, they were and this kept happening, no matter the state of the tree. I updated my git tree about 3 hours ago to mirror the latest Linus from git.kernel.org after having run into this error yesterday and deciding I must have done something wrong. This looks like it might be a missing -I or similar since the file does exist and is at that exact path from the file that is directly including it. DRH -- 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] epoll: stop comparing pointers with 0 in self-test app
I don't see anything obviously wrong here...
Reviewed-By: Daniel Hazelton
On 12/20/2012 02:11 PM, Sasha Levin wrote:
Signed-off-by: Sasha Levin
---
tools/testing/selftests/epoll/test_epoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/epoll/test_epoll.c
b/tools/testing/selftests/epoll/test_epoll.c
index 4a14a7f..1034ed4 100644
--- a/tools/testing/selftests/epoll/test_epoll.c
+++ b/tools/testing/selftests/epoll/test_epoll.c
@@ -199,8 +199,8 @@ int main(int argc, char **argv)
epoll_items = malloc(n_epoll_items * sizeof(struct epoll_item_private));
- if (epoll_set < 0 || epoll_items == 0 || write_thread_data.fds == 0 ||
- read_thread_data == 0 || read_threads == 0)
+ if (epoll_set < 0 || !epoll_items || write_thread_data.fds == NULL ||
+ !read_thread_data || !read_threads)
goto error;
if (sysconf(_SC_NPROCESSORS_ONLN) < 2) {
--
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] USB: mark USB drivers as being GPL only
On Friday 08 February 2008 14:08:21 David Newall wrote: > 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 > that he had actually spoken with the lawyers. Therefore I infer that > this somewhat widely held opinion originates from him. My point was to > those people who have been taking him at his word, and was to point out > that there are more reliable and transparent sources. 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 everything. The one technically inclined lawyer that I asked about this said that the Lexmark decision meant that code using an API did not mean the work was a derivative of the API. However, in the case of the Linux Kernel, the code is meant to function inside a much larger framework and the API available to modules includes large amounts of "boilerplate code" buried behind handy chunks of code like "list_for_each". The problem, he said, was that, in the US, such code is included in the module in a mechanical and wholly automated process. Which means that the module doesn't automatically inherit the GPL license. But, he cautioned me, this does not mean that a court couldn't (and/or wouldn't) rule that a module written specifically for Linux is a derivative of the kernel. He also cautioned that, although the Bern Convention broadly controlled international copyright laws, specific countries do seem to have laws that cover the "kernel module" situation much better than the US laws and that those laws do apparently make a module a derivative of the kernel. His overall statement on it was that, in his opinion, whether a given module is a derivative or not would depend on the amount of "original" work contained in it compared to the number of places where linux specific code is used. He also stated that, while disagreeing with the idea that parts of an API could be "so deeply embedded that using them creates a derivative work", it would be a good idea to always pay attention to the beliefs of the developers of the code, because it is their opinion that will start the legal problems. In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", but people ignoring this and doing things that circumvent this will, eventually, have problems with the people who hold the copyright on the code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" bit might also be in violation of the DMCA, but he isn't sure if a court would see it in the same light as someone cracking the CSS key on a DVD expressly for the purpose of creating pirated copies) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [PATCH] USB: mark USB drivers as being GPL only
On Friday 08 February 2008 16:36:37 Alan Cox wrote: > > In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", > > but people ignoring this and doing things that circumvent this will, > > eventually, have problems with the people who hold the copyright on the > > code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" > > bit might also be in violation of the DMCA, but he isn't sure if a court > > would see it in the same light as someone cracking the CSS key on a DVD > > expressly for the purpose of creating pirated copies) > > There was a good analysis of that argument on the list some time ago. I > think the conclusion was fairly definitively no as the GPL explicitly > gives the right to modify GPL code. You are therefore aready "authorised" > to make such a change. > > It might have a significance in terms of intent but thats for lawyers to > argue over. > > Alan I think that's why he said he "Wasn't Sure" - as was pointed out in another post, the Lexmark ruling appears to apply for more than the "interface" portion of the ruling. And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said "I think this is so core to the kernel that anything using it is a derivative work" - is what he thought *MIGHT* be legally actionable under the DMCA. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [PATCH] USB: mark USB drivers as being GPL only
On Saturday 09 February 2008 23:50:17 Marcel Holtmann wrote: > > > It makes no difference if you > > > distribute the GPL library with it or not. > > > > If you do not distribute the GPL library, the library is simply being > > used in the intended, ordinary way. You do not need to agree to, nor can > > you violate, the GPL simply by using a work in its ordinary intended way. > > > > If the application contains insufficient copyrightable expression from > > the library to be considered a derivative work (and purely functional > > things do not count), then it cannot be a derivative work. The library is > > not being copied or distributed. So how can its copyright be infringed? > > go ahead and create an application that uses a GPL only library. Then > ask a lawyer if it is okay to distribute your application in binary only > form without making the source code available (according to the GPL). > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL > > Regards > > Marcel In the US, at least, the belief that "Linking", in *ANY* form, with a GPL library creates a derivative work, is fallacious. Were I to create an application that uses, say, GTK for the interface the protected expression is my "unique and creative" use of the GTK API for creating the specific interface and any other code I have written using the API. I hold sole license to the copyright on that code and am able to license said code under the specific license of my choice. Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and hence the output is not able to be separately copyrighted - if it could be, then the copyright would be held by the *COMPILER*, and I am *NOT* bound by the license on that code. The same applies if GPL'd code is included in my application during the linking process. QED: The "Linking" argument used by most people is wholly fallacious in at least one major country - and if I'm not mistaken, the output from an automated process is similarly not considered as carrying a separate copyright in all nations that are signatories of or follow the Bern Convention. (And yes, this also applies to some GPL'd tools that RMS extended "GPL Exemptions" to - such as "Bison". There is, generally, no need for such an exemption, because the process by which the GPL'd code is included in the final binary is wholly mechanical.) DRH PS: The above information is a very condensed form of the result of several past conversations on this list about copyright law and the GPL as well as my own, private discussions with lawyers. I'm being lazy here and not searching various archives of LKML to give pointers to the past discussions. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 00:43:49 Marcel Holtmann wrote: > Hi Daniel, > > > > > > It makes no difference if you > > > > > distribute the GPL library with it or not. > > > > > > > > If you do not distribute the GPL library, the library is simply being > > > > used in the intended, ordinary way. You do not need to agree to, nor > > > > can you violate, the GPL simply by using a work in its ordinary > > > > intended way. > > > > > > > > If the application contains insufficient copyrightable expression > > > > from the library to be considered a derivative work (and purely > > > > functional things do not count), then it cannot be a derivative work. > > > > The library is not being copied or distributed. So how can its > > > > copyright be infringed? > > > > > > go ahead and create an application that uses a GPL only library. Then > > > ask a lawyer if it is okay to distribute your application in binary > > > only form without making the source code available (according to the > > > GPL). > > > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGP > > >L > > > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGP > > >L > > > > In the US, at least, the belief that "Linking", in *ANY* form, with a GPL > > library creates a derivative work, is fallacious. > > that is how FSF states it and it seems that most legal departments of > big companies (US and EU based) are not taking any risk on this. So it > seems that someone actually has to prove in court that these assumptions > for the GPL case are wrong. The FSF is making a claim that can be traced back to the beliefs of one person - RMS - and that propagate their views. As I stated in the original, this is not just my opinion, but that of two different lawyers I've spoken to and also the stated belief of numerous people on LKML. The fact is that the GPL only affects a "derivative work" in a viral manner. Merely using a GPL'd libraries API is not enough to make a program a "derivative work". > > Were I to create an > > application that uses, say, GTK for the interface the protected > > expression is my "unique and creative" use of the GTK API for creating > > the specific interface and any other code I have written using the API. I > > hold sole license to the copyright on that code and am able to license > > said code under the specific license of my choice. > > Not even getting into this one since GTK+ is a LGPL based library. Get > your examples straight. And the LGPL was created because of the FSF propagated belief that using a GPL'd library means your application is automatically a "derivative work" and hence must be released under the GPL. So the LGPL was created with the "automatic" 'linking' exemption. It is not necessary and never has been. This is why, even if the FSF claims what I've said above (that linking code with the GPL doesn't propagate the GPL into the non-GPL code) most companies won't risk it... Because the FSF has taken actions that are the exact opposite of their words. > > Why? Because the pre-processor is what is including any GPL'd code in my > > application and expanding any macros. That is a purely mechanical process > > and hence the output is not able to be separately copyrighted - if it > > could be, then the copyright would be held by the *COMPILER*, and I am > > *NOT* bound by the license on that code. The same applies if GPL'd code > > is included in my application during the linking process. QED: The > > "Linking" argument used by most people is wholly fallacious in at least > > one major country - and if I'm not mistaken, the output from an automated > > process is similarly not considered as carrying a separate copyright in > > all nations that are signatories of or follow the Bern Convention. > > The GPL is a license. Nobody is talking about the copyright of your code > here. You always have the copyright on your code. The point is that you > have to license your code under GPL (when using a GPL library) and you > are distributing your code. Yes, It is "my" code and "my" copyright. However, by the absolutely *common* belief that "linking to GPL libraries makes a program a derivative work" it would mean that I no longer have the freedom to license my code under the license of my choosing, because the *mechanical* process of linking has caused the GPL's "viral" clause to spread to cover my code. And you're absolutely wrong. It doesn't matter that the library is GPL'd at all. My code *cannot*, under any circumstances, be affected by the GPL license on the library. Because the libraries API *cannot* be copyrighted and any GPL'd code which winds up in the final binary got there via a "mechanical process" and doesn't affect my right to release the code under a license of my choosing. Any other belief is fallacious. Claiming otherwise would mean that any program that uses any library on a windows system makes an application a derivative work of that li
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 06:20:45 Alan Cox wrote: > > Why? Because the pre-processor is what is including any GPL'd code in my > > application and expanding any macros. That is a purely mechanical process > > and > > And its not pirating Windows because Norton Ghost put Microsoft copyright > material in your hard disk either - thats a mechanical process too. Right > - no. Nor can the gcc compiler hold the copyright as you suggest as it is > not a legal person. It takes someone telling the program to do it. The act of instructing the program is the actual "criminal" act. This is a 'Straw Man'. Next ? > The compiler might perform a process which combines your creative work > with another and thus creates a derivative work. It might do that with > libgcc. In many cases the FSF is being careful when it makes sure > specific things don't happen just as Linus did with the kernel. Sometimes > it is best to make sure no judge got a bit carried away and instead to > create certainty in advance. Yes, of course, and I'll never argue otherwise. However, what I was saying is that it is the claim of the FSF that, in no uncertain terms, a C program that uses the standard C library interface and is linked to glibc instead of, say, the old Borland libc, is automatically GPL because it's been linked to GPL code. And in the case of the "Bison Exception", lets think of it this way... A company writes a configuration file parser and is selling the software to other companies for use on their Solaris and SysV machines. The board decides to sell the software for linux and the employee in charge of the linux build uses the standard GNU tools for the entire process, including Bison. Even without the exception it wouldn't make the program a derivative of Bison or even come close to putting the code under the GPL. > If you really think what you claim then I'll #include your entire work, > flog it binary only and assure you it can't be derivative as you said so. > That's entirely mechanical - in fact I can clain a defence of 'estoppel' > given your previous statement, so you probably wouldn't be able to sue me > for it even if it was otherwise a violation. Straw man. Again. But... You'd have fallen afoul of the "intent". Action follows intent, and so does the law. (At least in the US) > There is btw lots of possibly useful caselaw in the area of books. People > have spent time litigating and thus established some clearer answers to > questions like whether you need copyright owners permission for And I've actually read almost all the court cases that have a bearing on this. (I don't step into a discussion unprepared) If the process of linking could create a derivative work, the *EVERY* program that runs on *ANY* OS would be a derivative of that OS, because the program is linked to the OS at run-time. DRH PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I tend to get very combative and come off like a troll. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?
On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
> On Mon, 25 Feb 2008, Jan Kara wrote:
> > Yes, exactly two of them. One is non-trivial to get rid of - it's
> > used for encoding of filename before we write it,
>
> Why can't we do just
>
>
>
> UDF: Optimize stack usage
>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 112a5fb..706a2b5 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -336,7 +336,7 @@ static struct fileIdentDesc *udf_add_entry(struct inode
> *dir, {
> struct super_block *sb = dir->i_sb;
> struct fileIdentDesc *fi = NULL;
> - char name[UDF_NAME_LEN], fname[UDF_NAME_LEN];
> + char *name, *fname;
> int namelen;
> loff_t f_pos;
> int flen;
> @@ -352,6 +352,14 @@ static struct fileIdentDesc *udf_add_entry(struct
> inode *dir, struct extent_position epos = {};
> struct udf_inode_info *dinfo;
>
> + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> +
> + if (!name || !fname) {
> + *err = -ENOMEM;
> + return NULL;
> + }
> +
Wouldn't it be better to check each individually, so you do wind up leaking a
buffer here if one gets allocated and the other doesn't ?
> if (dentry) {
> if (!dentry->d_name.len) {
> *err = -EINVAL;
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index f3ac4ab..42e3ba8 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -1345,7 +1345,7 @@ static void udf_load_logicalvolint(struct super_block
> *sb, kernel_extent_ad loc) * July 1, 1997 - Andrew E. Mileski
> * Written, tested, and released.
> */
> -static int udf_process_sequence(struct super_block *sb, long block,
> +static int noinline udf_process_sequence(struct super_block *sb, long
> block, long lastblock, kernel_lb_addr *fileset)
> {
> struct buffer_head *bh = NULL;
> --
> 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/
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
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: [PATCH 6/6] staging: ccg: print MAC addresses via %pM
On 07/06/2012 11:32 AM, Kyungmin Park wrote:
> Acked-by: Kyungmin Park
>
> On Sat, Jul 7, 2012 at 12:28 AM, Andy Shevchenko
> wrote:
>> Signed-off-by: Andy Shevchenko
>> Cc: Kyungmin Park
>> ---
>> drivers/staging/ccg/ccg.c |8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/ccg/ccg.c b/drivers/staging/ccg/ccg.c
>> index a5b36a9..62f5d92 100644
>> --- a/drivers/staging/ccg/ccg.c
>> +++ b/drivers/staging/ccg/ccg.c
>> @@ -564,9 +564,7 @@ static int rndis_function_bind_config(struct
>> ccg_usb_function *f,
>> return -1;
>> }
>>
>> - pr_info("%s MAC: %02X:%02X:%02X:%02X:%02X:%02X\n", __func__,
>> - rndis->ethaddr[0], rndis->ethaddr[1], rndis->ethaddr[2],
>> - rndis->ethaddr[3], rndis->ethaddr[4], rndis->ethaddr[5]);
>> + pr_info("%s MAC: pM\n", __func__, rndis->ethaddr);
You lost a % there - it should be "%s MAC: %pM\n", no ?
DRH
>>
>> ret = gether_setup_name(c->cdev->gadget, rndis->ethaddr, "rndis");
>> if (ret) {
>> @@ -654,9 +652,7 @@ static ssize_t rndis_ethaddr_show(struct device *dev,
>> {
>> struct ccg_usb_function *f = dev_get_drvdata(dev);
>> struct rndis_function_config *rndis = f->config;
>> - return sprintf(buf, "%02x:%02x:%02x:%02x:%02x:%02x\n",
>> - rndis->ethaddr[0], rndis->ethaddr[1], rndis->ethaddr[2],
>> - rndis->ethaddr[3], rndis->ethaddr[4], rndis->ethaddr[5]);
>> + return sprintf(buf, "%pM\n", rndis->ethaddr);
>> }
>>
>> static ssize_t rndis_ethaddr_store(struct device *dev,
>> --
>> 1.7.10.4
>>
>> --
>> 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/
> --
> 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/
>
--
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: 2.6.24-rc8: iwl3945 gets stuck
On Tuesday 22 January 2008 17:15:42 John W. Linville wrote: > On Tue, Jan 22, 2008 at 09:54:11PM +0100, Harald Dunkel wrote: > > If I put some heavy load on the iwl3945, then the network connection > > gets stuck after a some time. To fix it I have to reload the module. > > Can you quantify this a bit more? What constitutes a "heavey load"? > What (if any) encryption are you using? Are you using any options > for iwl3945 in /etc/modprobe.conf? > > Could you include the output of dmesg and/or the contents of > /var/log/messages (trimmed for the most recent boot)? > > > AFAICS this problem was a topic on lkml almost 3 months ago. Any news > > about this? I would be glad to help to track this down, but I have > > no idea how to change the scaling algorithm to iwl-3945-rs . > > This should happen automatically now. > > John I've been getting a warning in the dmesg of my laptop with every boot since I started using 2.6.24-rc7 that might be related. This doesn't appear to cause any problems, but from looking at the source of the warning it appears that the ipw3945 hardware might be causing the problem. [ 31.460143] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 31.549722] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx() [ 31.549817] Pid: 4436, comm: amixer Not tainted 2.6.24-rc7-git2 #1 [ 31.549903] [ 31.549904] Call Trace: [ 31.550063][] :mac80211:__ieee80211_rx+0xc99/0xd60 [ 31.550236] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.550332] [] :iwl3945:iwl_rx_queue_restock+0xca/0x170 [ 31.550422] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.550520] [] :mac80211:ieee80211_tasklet_handler+0xb8/0x120 [ 31.550646] [] tasklet_action+0x51/0xc0 [ 31.550732] [] _spin_unlock+0x14/0x40 [ 31.550820] [] __do_softirq+0x64/0xe0 [ 31.550909] [] call_softirq+0x1c/0x30 [ 31.550995] [] do_softirq+0x3d/0x90 [ 31.551083] [] irq_exit+0x88/0xa0 [ 31.551169] [] do_IRQ+0xc5/0x1b0 [ 31.551257] [] ret_from_intr+0x0/0xa [ 31.551369][] get_page_from_freelist+0x30e/0x670 [ 31.551519] [] __alloc_pages+0x6e/0x3b0 [ 31.551608] [] generic_file_aio_read+0xd7/0x180 [ 31.551699] [] alloc_page_vma+0x9c/0xf0 [ 31.551788] [] handle_mm_fault+0x50e/0x780 [ 31.551874] [] _spin_unlock+0x14/0x40 [ 31.551962] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.552052] [] do_page_fault+0x228/0x970 [ 31.552146] [] _spin_unlock+0x14/0x40 [ 31.552251] [] vfs_read+0x13e/0x180 [ 31.552340] [] error_exit+0x0/0x51 [ 31.552436] The location of the warning is: hdrlen = ieee80211_get_hdrlen(rx.fc); line in question -->WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT) local->dot11ReceivedFragmentCount++; sta = rx.sta = sta_info_get(local, hdr->addr2); Now, the problem is that this might be nothing, and it might be the cause of the problem. (I don't think it is the cause, myself, because I've subjected my laptop to a lot of activity - to the point that the card was starting to drop packets - and have seen no problems) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > There is no udelay() in the reverted patch. If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. > > This is like fishing in the dark. We've got a working version. Why not > keep it? > > > Regards > > Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a "pop" from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote: > At Mon, 14 Jan 2008 16:03:22 -0500, > > Daniel Hazelton wrote: > > On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: > > > > > > > > Could this have anything to do with the following messages I've seen > > > > when trying -rc7 ? > > > > > > > > [7.760269] pnpacpi: exceeded the max number of mem resources: 12 > > > > > > Judging from Harald's report, it looks like a different problem. > > > The buggy patch (regarding HDA-intel) was, at least, already reverted > > > on Linus git tree. Could you give it a try? > > > > > > > > > Takashi > > > > Sorry, still no sound. Config, lspci and dmesg attached to help. System > > is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. > > Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? > > Anyway, try to change HZ=300. I got a report that HZ=1000 causes the > similar problem but HZ=300 not. > > > Takashi That did it. Looks like the hardware really is that sensitive to the timing. Strange, but I've seen worse. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: ndiswrapper and GPL-only symbols redux
On Tuesday 29 January 2008 19:46:06 Måns Rullgård wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > On Tue, Jan 29, 2008 at 11:25:22PM +, Måns Rullgård wrote: > >> Adrian Bunk <[EMAIL PROTECTED]> writes: > >> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote: > >> >> Hello! > >> >> > >> >> It have come to my attention that a patch has been committed to the > >> >> kernel with the explicit purpose of tainting ndiswrapper - the kernel > >> >> module allowing Windows NDIS drivers for Ethernet and Wireless cards > >> >> to be used by the kernel. > >> >>... > >> >> Just to reiterate some points from the old discussion: > >> >>... > >> >> - no copyright violation is involved, as Windows drivers are not > >> >> derived from Linux sources > >> >>... > >> > > >> > It is interesting that someone posting with an @gnu.org address claims > >> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was > >> > not a copyright violation. > >> > >> As long as you don't distribute /proc/kcore, I can't see how the GPL > >> would have any say in the matter. The Windows drivers are (unrelated > >> violations aside) clearly not derived from GPL code. Only because of the distribution of the windows driver. As I understand US and International copyright law, dynamic linking cannot create a new, derivative work and hence cannot carry its own license. (It's a "machine translation") What that means is that there is no violation of the GPL if GPL'd code is linked to proprietary code and then distributed. However, the GPLv3 does have language in it that would require the proprietary code to also be distributed. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- 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: Pata support for IDE Controller 82801G ICH7 in Linux 2.6.22
On Sunday 22 July 2007 18:03:06 Bartek wrote:
> 2007/7/22, Alan Cox <[EMAIL PROTECTED]>:
> > > > 00:1f.1 0101: 8086:27df (rev 02)
> > >
> > > Ok, this controller is supported.
> > > Did you forgot about CONFIG_PATA_MPIIX=y?
> >
> > MPIIX is for early Intel laptop (pentium era).
> >
> > If the chip is in AHCI mode then CONFIG_AHCI may be what is missing
>
> I made a few tests. First I booted my comp with Ubuntu Live Feisty
> Fawn, checked modules which are loaded, and interesting ones are:
> ata_piix, ata_generic, libata, scsi_mod, sg, sr_mod, sd_mod
> ls /dev/sda* showed:
> /dev/sda{1,2,3,4}.
> So I recompiled the kernel with these options (marking all these
> drivers as a modules, in the previous situation they were modules, as
> well as compiled directly), and tried to boot. Nothing worked. The
> same situation appeared: Waiting for root file system...
> Second, I installed a Debian distribution kernel
> (linux-image-2.6.22-1-686) and booted from it. It used an old IDE
> driver, not PATA. So again no success.
> According to AHCI, my chip is rather not that kind. Ubuntu does not
> load any AHCI modul. In my previous kernel compilations I tried that
> option as well. It did not work.
This sounds like a problem I ran into when I tried to boot a 2.6.21 kernel
using libata with Ubuntu Edgy installed. The init script on the initramfs
failed at the same point - not a problem with the drivers, but a problem with
what the scripts are looking for. I'd suggest looking at the scripts on the
initramfs - its been my experience that they are the culprit and not the
kernel itself.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: GPL weasels and the atheros stink
On Sunday 02 September 2007 22:01:17 David Schwartz wrote: > > Letting aside the legality of that change, why would such a change > > be needed ? The licensing is perfectly clear: the file is available > > under the ISC licence, OR the GPL licence. This doesn't cause any > > problem for the linux kernel. The ISC licence is perfectly compatible > > with the GPL (note to GPL trolls: this new licence does not have any > > advertizing clause, which was the ONLY issue with the old licence). And > > heck, they can use the code under the GPL licence. There is no > > incompatibility > > in there. > > Your entire argument is based on the false assumption that these licenses > are compatible. They are not. You cannot put code that was offered under > the GPLv2 into code that is licensed under the dual license and distribute > the result. Then go yell at Mr. Floeter. The code is dual-licensed and he put BSD-License only code in it. Because that's the *EXACT* *SAME* thing you're talking about. IANAL, but your argument is specious - if the code is dual-licensed and you are going to let one person add code to it that is only licensed under one of those licenses, you *CANNOT* complain when somebody else does it and chooses the other license. (Well, you can, but the complaint has no legal standing) > > The only possible issue is related to paranoia: if this file stays > > dual-licenced, some of its code may escape from the GPL shrine, and > > become available to the cuddly BSD people... but since their licence > > doesn't protect anything, it could used by the Evil Empire of Microsoft, > > or SCO, or whoever is the villain of the month. > > That's not the problem. The problem is that if the file stays > dual-licensed, everyone working on that file in the Linux kernel will have > to be careful not to put any GPLv2-only code into it. That's just > untenable. Any consistent license is better than different files being > under different licenses such that you can't cut and paste code between > files. Then why aren't you complaining about Mr. Floeters code ? His code doesn't maintain the dual-license. I think the reason is that you could care less about the "Dual License" and you just want the code - period. > > Let's extend the story a wee little bit. It seems that these days, some > > parts of the opensource community have gotten confident enough that they > > do not need the other part. We all know the situation is already fairly > > disymetric. The GPL is less free than the ISC licence for instance (for > > some definition of free), and practically, this makes it impossible to > > add GPL code to an ISC project without putting the project under the > > Aegis of the GPL licence. The reciprocal relationship does NOT hold. As > > you can see in various places, it is quite possible to put BSD code > > inside a GPL project without any issue (the FSF libiberty is a nice proof > > of that. And heck, the glibc as well... Read carefully past the COPYING > > file, you'll find numerous instances of BSD-like licences). > > If you embed protectable elements from GPLv2-only code into any of those > files, they are no longer dual-licensed. You wind up creating traps and > complexity that makes the code much harder to maintain. The same can be said of Floeters code. *ALL* of his code, IIRC, is *SINGLE-LICENSE*. ie: a complexity trap. But you aren't complaining about his code - you are complaining that somebody is doing the same thing, but is using the side of the dual-license you don't like. Nothing *LEGALLY* actionable there. > > Do you really think he's going to keep his work under a > > dual-licence, seeing > > how a bunch of rabid linux zealots are all but intent on stealing his > > code whenever they can. > > > > Nice going, GPL fan-boys... > > A dual-license is a compromise. One of the downsides is that you may force > large projects that are under one license or the other to fork the code. If > that bothers you, don't dual license. Exactly. If you want to only have your code available under a specific license but rely on dual-licensed code, you create a fork that contains the new code under that side of the license. For instance: Suppose I've written a new filesystem and released it with three licenses - CDDL, BSD/ISC and GPL(v2) - and a Linux developer decides to import my FS into Linux. But the code isn't optimal for Linux, so he fixes it - and only wants his code usable under the GPLv2 - he can do this - it just means that that fork isn't usable under the other two licenses. Note that the boundary of what a "work" consists of is complex - but as far as a computer program goes it is "the collection of source code needed to build the functional result" or "the functional result". This means that I can contribute as much code as I want to a project under whatever license I choose, but the project itself can have a different license. In the case of the code in question, that means that the second
Re: Fwd: That whole "Linux stealing our code" thing
(by the way, text in caps surrounded by *'s is meant to indicate vocal stress,
not volume)
On Sunday 02 September 2007 22:01:18 David Schwartz wrote:
> > So I appear to have a
> > right to convey the work under the GPL to a third party, who from me
> > receives no right to use it except under the GPL.
>
> Here's where your train goes off the rails. They do not receive any right
> to use it from you. They receive a license to use it under the GPL from the
> original author. Please read GPL section 6.
>
> " 6. Each time you redistribute the Program (or any work based on the
> Program), the recipient automatically receives a license from the
> original licensor to copy, distribute or modify the Program subject to
> these terms and conditions. You may not impose any further
> restrictions on the recipients' exercise of the rights granted herein.
> You are not responsible for enforcing compliance by third parties to
> this License."
>
> The GPL does not give you *any* right to extend anyone a license to code
> you did not author. (Nor can it as such an extension would have to be done
> in writing in most countries.) When you distribute a GPL'd work, the right
> to use every creative element in that work is licensed to the recipients
> directly from their respective authors. Under no circumstances does the GPL
> ever give you the ability to license someone else's work to a third party.
However, this is not what is happening here. Jiri has made changes that he has
licensed solely under the GPLv2. This means that he now becomes the
licensor - not Mr. Floeter or Mr. Leffler. *BUT* *ONLY* of the version of the
code containing his changes.
Mr. Floeter *CAN* request that his code be removed from said fork - his code
is solely licensed (AFAICT and IIRC) under the BSD/ISC license and was only
covered by the dual-license because it was integrated into a work that
carried said dual-license. (I'm not sure how well such a revocation would
work in reality, but it is Mr. Floeters right.)...
(Sam Leffler could do the same - but I'm not sure how well that would carry.)
> > * Alternatively, this software may be distributed under the terms of the
> > * GNU General Public License ("GPL") version 2 as published by the Free
> > * Software Foundation.
> >
> > The choice appears to be delegated to the recipient very clearly and
> > very specifically by the licencing on the file. It does not say that I
> > must convey the work under both licences. It quite specifically says I
> > may convey the work under whichever of the two I prefer (and probably
> > both if I wish). Clearly if that had not been the intent it would not
> > have included the clause giving the choice.
>
> Either license can grant you the right to distribute it, but how you get
> the rights to distribute has *NO* effect on the recipient. They receive a
> lawful copy and any rights the original author grants them under a license
> from that original author. You have no power to grant or modify rights to
> the original work.
Correct. Doesn't apply in the case of the code in question (unless the changes
that were made are so tiny as to not be copyrightable).
In this case the code is question is a modified version, which means that the
right to distribute said modified version now originates with the person
holding the copyright on the modifications. (Though their right to distribute
the code, in such a situation, is lessened quite a bit by the text of the
license they received the code under)
> This is a common misunderstanding.
No misunderstanding, really.
Alan seems to have given a bad example that doesn't apply to the situation
that is being discussed.
> Note that you may remove the text of either license from a dual-licensed
> file and redistribute under the other license because neither license
> requires you to retain the other license and both licenses give you the
> right otherwise to modify as you wish. But the removal of a license from a
> file has no effect on the grant of license. Your recipients still get a
> dual license to those protectable elements in the file that were placed
> under a dual license. You cannot stop the automatic grant.
Agreed. When re-distributing an un-modified copy of a work. When distributing
a modified work, the "work" has the license that the person who made the
modifications places on it. But individual files and pieces of code will
still retain their original license - this is how it works.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: GPL weasels and the atheros stink
(As noted before - I am surround all-caps text with *'s to indicate vocal stress, not volume) On Monday 03 September 2007 05:47:59 David Schwartz wrote: > Daniel Hazelton wrote: > > > Your entire argument is based on the false assumption that > > > these licenses > > > are compatible. They are not. You cannot put code that was offered > > > under the GPLv2 into code that is licensed under the dual license and > > > distribute > > > the result. > > > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > This is a completely irrelevent reply. For one thing, I'm not yelling at > anyone, so I don't see why you think I'm being inconsistent or something > because I'm not yelling at Mr. Floeter. > > Actually, it's perfectly fine to put BSD-only code in a dual-licensed file. > You just need to remove the dual license and make the file GPL-only. Huh? You're not making any sense. I think what you meant was "It's perfectly fine to put BSD-only code in a dual-licensed file. You just need to make the file *BSD* only." And you are correct - but you (and I may be wrongly interpreting your words) and a lot of other people have complained that Jiri made modifications to the Atheros code and only licensed his code under the GPL. What none of you have done is complained that Mr. Floeter did the same thing - made changes to the Atheros code and made his changes only available under *ONE* of the licenses. Apparently the reason why people that are complaining about Jiri doing such haven't complained about Floeter doing the same thing is that he used a license that you and the other people like. > > IANAL, but your argument is specious - if the code is > > dual-licensed and you > > are going to let one person add code to it that is only licensed > > under one of > > those licenses, you *CANNOT* complain when somebody else does it > > and chooses > > the other license. (Well, you can, but the complaint has no legal > > standing) > > What argument am I making that's specious? Perhaps you have me confused > with someone else? > > In any event, I utterly reject the argument that you make. Any argument > "you cannot complain about X unless you also complain about Y" is just > totally bogus. You can say "you cannot complain about X and *defend* Y > because X and Y are similar". But the fact that I don't complain about > something creates no inconsistency. I am under no obligation to complain > about everything that contradicts my principles, even things I don't know > about or don't have enough information to give an informed opinion. Wrong - I said "You can't complain about Person A doing X when you let Person B do X without complaint". To whit: you can't complain that Jiri has made changes to a dual-licensed "work" and only released his changes under one of the licenses on the work when somebody else - in this case Msr. Floeter - has done the same thing. > > > That's not the problem. The problem is that if the file stays > > > dual-licensed, everyone working on that file in the Linux > > > kernel will have > > > to be careful not to put any GPLv2-only code into it. That's just > > > untenable. Any consistent license is better than different files being > > > under different licenses such that you can't cut and paste code between > > > files. > > > > Then why aren't you complaining about Mr. Floeters code ? > > Because I am too busy answering nonsensical arguments like yours. Nonsense? Maybe in your little fantasy world. In the real world what I have proved by stating the facts is that you are complaining about something - and apparently claiming that its illegal - when somebody else has done the *EXACT* *SAME* *THING* and you have no problem with it. (And since you apparently keep forgetting, that "exact same thing" is 'making changes to a dual-licensed project and only releasing the changes under one of the licenses on the project) > I am > under no obligation to complain about everything I might disagree with if I > were informed about it. Huh? You are complaining about one person doing something and are not or do not see a need to complain about somebody else who has does the same thing. You either have a problem with the action or you don't - in this case it appears that you are complaining because the person in question made a choice you don't like. > Why aren't you complaining about starving kids in > Africa?
Re: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 05:48:00 David Schwartz wrote: > > Mr. Floeter *CAN* request that his code be removed from said fork > > - his code > > is solely licensed (AFAICT and IIRC) under the BSD/ISC license > > and was only > > covered by the dual-license because it was integrated into a work that > > carried said dual-license. (I'm not sure how well such a revocation would > > work in reality, but it is Mr. Floeters right.)... > > No. Neither the BSD license nor the GPL license permit you to revoke > rights. Mr. Floeter's code is still available under the BSD/ISC license. > The BSD license does not require you to make derived works available under > a BSD license. *His* code is still available under a BSD/ISC license, of > course, but the changed code is not. Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. The GPL codifies certain situations in which the person would not, personally, have to revoke the license, but does not limit the original copyright holders rights (in that regard) in any way. The BSD/ISC license has none of the automatic conditions of the GPL, but it also cannot remove the copyright holder(s) from exercising their rights. (And no, I haven't spoken to a lawyer about this - I did, however, ask a recently graduated law-school student where I could look for case-law and the text of the actual laws. What I got was some background on US copyright law itself and an agreement that a copyright license does not - and can not - affect the person holding the copyright) > Read the BSD license. It does not require changes to be made available > under a compatible license. This is the main difference between the BSD and > GPL licenses. Have done so. And that is the only part of the license that I actually don't like. > Note that it would be an error to remove the BSD license text, as the BSD > license requires you to keep it and you still need the BSD license to grant > you distribution rights to the original work. However, the license does not > apply to protectable aspects of the code not placed under the BSD license > by their original author, and it is important to add a note to that effect. Agreed, and I've never claimed otherwise. (Nor has anyone else. I believe the closest that anyone has come was Alan Cox saying (and I'm going to paraphrase it because I don't think he ever stated it well) "If you've made changes to a file that carries a dual BSD/GPL license and your changes are GPL only, the file can no longer be distributed under the BSD license at all. So it is safe to remove the headers from that individual file." There is no way that a license on a constituent file can alter or affect the license on the whole project (if it is different). It can "muddy the waters", but that is about as far as I can see it going. (I realize I may have said different, originally, but you'll have to forgive me. I was not in the best of moods (or the best state of mind) to be making a completely rational argument when I did such.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: GPL weasels and the atheros stink
On Monday 03 September 2007 13:18:35 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > Actually it is not. > > Dual BSD/GPL licence essentially means BSD, because rights given by > BSD are a superset of these by GPL. Actually, I was pointing out a logical fallacy. I'll spell it out long here so everyone can see the point I was trying to make. Person A writes a device driver and releases it under a dual license. Person B modifies said device driver and licenses his changes under only one of the licenses on the device driver. Nobody complains. Person C modifies the same device driver and licenses his changes under the other license on the device driver. People start complaining. In this case either the actions of both persons B and C are legal - in which case neither person B or person C is likely to lose a lawsuit (or even face one) - or they are illegal, in which case the second a lawsuit is brought against person C, the same lawsuit must be brought against person B. The exact nature of the licenses and whether one is a superset or subset of the other doesn't matter. Either the action of making modifications licensed solely under one or the other of the two licenses on the original code-base is illegal or it isn't. > The other thing is copyright notices. I think one can't legally > alter someone else's licence conditions (in his/her name), unless > something like that is explicitly permitted. Fully agreed. I've even said such myself. > However, we're talking about derivative works. A derivative > work may be, for example, GPL-licenced: > > "Copyright (C) 1234 Joe the GPL lover > licenced under the GPL as published" > > but could lawfully use code originally licenced under BSD: > > "Portions copyright (C) 1234 Bill the BSD lover > originally licenced under no-ad BSD" > > Thus his (Joe's) work is GPL only, but Bill's licence notice is > intact as required by it (BSD). I've suggested that such be done in the future - if just because it *IS* how it should be done. > > IANAL, maybe you (all of us) should consult one if required. Would cost me money to consult a lawyer over this, but I do have a few friends that have completed law school and are waiting on the results of the BAR. They have told me that they are not legally allowed to dispense legal advice - but I got around that by asking them to recount what the law actually says. Apparently the above suggestion would meet the letter of the law. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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
On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > The fact > > remains that the person making a work available under *ANY* form of > > copyright > > license has the right to revoke said grant of license to anyone. > > Not after the licence has been given and accepted (and there might be > restrictions), unless of course the licence contained such reservation. I hate to belabor the point, but you seem to be making the mistake of "The license applies to the copyright holder" that I've seen a lot of people make (and kept quiet about). The person holding the copyright has all the legal standing to revoke a license grant at any time. Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. If the license was of the "signed contract" type, or contained text stating that the copyright holder was giving up all rights of revocation (etc...) I could agree with you. As it stands, no "Open Source" license that I have seen used on a major project contains any part that does that. In fact, the GPL is the only license I can name (offhand) that even touches on the rights of the copyright holder - and then it is in the form of "If you do X, Y or Z all rights granted under this license are automatically revoked". That is an "automatic clause" - not a limitation stating that the copyright holder can only revoke under those conditions. The person holding the copyright has quite a few rights - more than people believe - and not even the most generous of Open Source licenses (except those that contain text like "granted in perpetuity" or similar) even come close to being exempt from the holder of the copyright not being able to summarily revoke a given persons license. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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
On Monday 03 September 2007 15:33:01 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > I hate to belabor the point, but you seem to be making the mistake of > > "The license applies to the copyright holder" > > Of course not. I'll take this at face value - I might have mis-parsed your earlier statements wrong. > > The person holding the copyright has all the legal standing to revoke a > > license grant at any time. > > Based on? US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) > > Licenses such as the GPL are not signed contracts, > > and that means there are limits to what effect they can have on the > > copyright > > holder. > > Perhaps that is your local laws, but I'd be surprised anyway. I wouldn't. The US Legal system is rather twisted. > Do you sign contracts when shopping, or are you (and the shop) > allowed to "revoke" the transaction after it's made (I'm not > talking about shop's return policy)? A purchase is separate from a grant of copyright under license. If I purchase a book I have the right to read the book and I have the right to sell the book to someone else, but I have no other rights to it. But if I purchase something, there are rights that go along with said purchase. Under a license such as the GPL (I can't say the same for the BSD/ISC license - I haven't spent enough time studying it to know for sure) no money need change hands for access to the program *and* source. All the rights that anyone *BESIDES* the copyright holder have to the program and/or source comes from license. But since money has not changed hands, there is no further set of rights or guarantees - the copyright holder has not, in general, sold a copy of the work or granted any guarantee that the license will not be revoked. > Is what you wrote only valid WRT licences? Yes. For contracts there is slightly different set of laws in play. > Which country has such laws BTW? The USA. > > In Poland, I can't just go and "revoke" a "statement of will" > if I haven't explicite reserved a right to do so. > Obviously I can act contrary to the statement, and be held liable. Ah, see - in the US the license(s) in question (and licenses in general) are grants of rights, not a "statements of will". If there are to be any limits on the rights of the copyright holder, under US law, they have to be explicitly stated in the license itself. (Truthfully, in the US a license should be read with an implicit "All rights reserved") DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: GPL weasels and the atheros stink
On Monday 03 September 2007 20:23:37 David Schwartz wrote: > > Wrong - I said "You can't complain about Person A doing X when > > you let Person > > B do X without complaint". > > Yes, I can. There is no inconsistency between acting in one case and > failing to act in another. We need not act in every possible case where we > could act to preserve our right to act in a particular case. Sorry, I should have said that you cannot prosecute one person for doing something without prosecuting everyone that is doing it. Otherwise you have lost the case before it has started - no judge would allow such a one sided application of the law. > > To whit: you can't complain that Jiri has made > > changes to a dual-licensed "work" and only released his changes > > under one of > > the licenses on the work when somebody else - in this case Msr. > > Floeter - has > > done the same thing. > > First of all, I haven't complained about Jiri's changes. Second, I most > certainly can. I can complain about one murder without complaining about > every murder. There is no inconsistency whatsoever with acting in one case > without having to act in every other conceivable case. Sorry, this ties back to the original statement and the implied threats of legal action by Theo and backed up by almost every OpenBSD developer that has participated in this discussion. It's a mis-statement of mine - see above. If you are going to prosecute one person for doing something, you have to prosecute everyone who does it. > We can complain about or work to fight whatever injustices we like. There > is no obligation to address every equal, or greater, injustice before > working on the injustice of one's choice. Yes, of course. > > No, no confusion. You could care less about the code being dual-licensed. > > Your > > > choice of subjects 'GPL weasels' speaks volumes. > > *My* choice of subjects?! You seem to have me confused with someone else > entirely. Potentially - I am terrible with names and had assumed that you were the person who had forked the "Stealing Our Code" thread with the "GPL weasels" subject. If my assumption is faulty, then I apologize and ask your forgiveness for my false accusation. > My sole points in this thread were to: > > 1) Correct some misunderstandings about how dual licenses actually work. This was, IIRC, already well understood by most of the people on the Linux Kernel side of things. (Alan Cox has given several quite lucid statements showing that he, at least, does understand this) > 2) Explain *why* a file cannot really remain dual-licensed if it's part of > the Linux kernel distribution. A file/files can have as many licenses on it as the developer wants, provided that at least one of them is the GPL(v2). That is because, for it to be legally distributed as part of the Linux Kernel it has to be done so under the auspices of the license on the Linux Kernel - the GPLv2. > While I generally prefer the BSD license to the GPL license and tend to be > a pretty vocal GPL critic, I have said many times that almost any > *consistent* license is better for a large project than different licenses, > even if they're compatible, on different files. I am critical of the GPL myself, as is Linus and a lot of people. (Linus himself has said, numerous times, that he is "no fan of the GPL, but it is the best that exists" (his words and opinion) - and I have heard similar sentiments from a lot of people.) I am not a fan of the BSD license because I'd like to be able to incorporate any changes someone might make back into the original code. There is no requirement in the BSD license for someone to make their changes to my code available to me - so I am not a fan of it. > > Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The > > fact remains that the person making a work available under *ANY* form of > > copyright > > > license has the right to revoke said grant of license to anyone. The GPL > > codifies certain situations in which the person would not, personally, > > have > > > to revoke the license, but does not limit the original copyright holders > > rights (in that regard) in any way. > > I'm not sure where you're getting this from, but it's not true. Linus > cannot decide tomorrow that nobody can distribute the Linux kernel anymore. In the US you have to explicitly waive rights for you to not have them (in regards to licenses). Although, considering what I have been informed of in regards to the law in Poland (and, seeing as how this has surprised a lot of people, likely a large number of other countries), to make sure those rights are "reserved" they should be explicitly spelled out in the text of the license. And the truth is that Linus could do that - if he required contributors to do a copyright assignment (which would make him the holder of the sole copyright on the Linux Kernel). Since Linus is *NOT* the sole copyright holder on Linux, he cannot do this. He could,
Re: Fwd: That whole "Linux stealing our code" thing
On Tuesday 04 September 2007 04:50:34 James Bruce wrote: > Daniel Hazelton wrote: > > On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: > >> Daniel Hazelton <[EMAIL PROTECTED]> writes: > >>> The fact > >>> remains that the person making a work available under *ANY* form of > >>> copyright > >>> license has the right to revoke said grant of license to anyone. > >> > >> Not after the licence has been given and accepted (and there might be > >> restrictions), unless of course the licence contained such reservation. > > > > I hate to belabor the point, but you seem to be making the mistake of > > "The license applies to the copyright holder" that I've seen a lot of > > people make (and kept quiet about). > > I believe you are making the mistake that the license on code has > anything to do with what the author chooses to do in the future. > Releasing something as BSD does not force the author to do anything in > the future with his code, and he/she could add and relicence as he/she > feels fit. HOWEVER, that particular code has already been released as > BSD, and the author no longer has control over that release. I may be mistaken, but it has always been my understanding that, unless you specifically waive your rights, they are automatically retained. (Under the law in the US, at least). Hence, a copyright holder can do such, where the license has not been acquired by money changing hands. (And actually, my above statement isn't rendered false by your rebuttal - it still appears that the person I replied to believes that a copyright license applies to the person holding the copyright in the same manner it applies to the person receiving the item under said license. Though I will admit it if I am wrong - publicly) > > The person holding the copyright has all the legal standing to revoke a > > license grant at any time. Licenses such as the GPL are not signed > > contracts, and that means there are limits to what effect they can have > > on the copyright holder. > > I believe you are confusing the fact that an author can decide to > release code under another license, with the existence of code under > that earlier license. The license grant comes from THE CODE (which > bears a license), not THE AUTHOR. I can use GPL code I get in the mail > because the license on the work says I can do so, not because I > contacted the author and got a specific grant. If such a grant were > only verbal, your theory might hold, but that doesn't apply to any OSS > software under discussion here. The license is a direct grant from the author. If the author so wished, he/she could pull the license - either entirely or in part. About the only caveat is that the author would have to publish and attempt to contact everyone who may have acquired the item under that license to inform them of such a change - this does make it difficult, hell, makes it nearly impossible, but it can be done. (IANAL, but this does appear to be what the law says) > If your legal theory were true, I could sell you a book and then later > demand that you destroy it. I could also release something as public > domain, and then later rescind that (I still hold the copyright on what > I produced), and charge money from anyone who used it. I think its safe > to say that this does not happen in practice. Please provide some > examples to the contrary or caselaw if you want to convince me otherwise. Actually, no. A purchase does automatically grant the rights inherent in ownership - but that is a *PURCHASE*. Mere transfer of an item with no exchange of money cannot convey those rights. As far as the 'public domain' argument goes... That smells of a straw-man and is as different from a grant of license as it is from a purchase. When you release something into the public domain you are waiving *ALL* of your rights as copyright holder. (Which, I am told, cannot be done in Germany and some other countries) > Furthermore, BSD/GPL software could not really exist under your legal > theory; A programmer who wrote 30 year old core BSD code could wake up > tomorrow and decide to require all BSD derivatives to remove his code or > pay him for it (and the next day he could change the price again). Open > source software would not exist if such a liability were true, and > companies like Sun could not be built up off of derivatives of it. > Linux 0.01 is still available under a pre-GPL license if you can find a > copy, and neither Linus (nor anyone else) can change that. He could, but AFAICT, thirty years ago BSD was still run entirely by UC Berkely and any copyrights that might be held are held entirely by UC Berkely and not the individuals that contributed to su
Re: Fwd: That whole "Linux stealing our code" thing
On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > US Copyright law. A copyright holder, regardless of what license he/she > > may have released the work under, can still revoke the license for a > > specific person or group of people. (There are some exceptions, but they > > do not apply to the situation that is being discussed) > > Oh come on, I thought some small country in maybe central Africa, > but certainly not USA. US Law is a twisted maze - you wouldn't believe the contradictions that exist between different sections of the US Federal Code. (And its worse as you move down to the State and the Local levels) > What you write would essentially mean GPL (and any other such licence) > is invalid in the USA. Nope. The GPL is an explicit grant of rights and is fully legal and active as it stands. > The licence is basically a promise not to sue. It wouldn't make any > sense to promise if you could revoke at will. If I was to revoke the license on something I held copyright to, I'd be forced to make an attempt to contact everyone that may have received a copy of the work under that license before I could ever begin filing lawsuits. This process will take at least a month - more if the various localities where someone might be living has laws about what constitutes an attempt to contact. (For instance, here in Pennsylvania an attempt to contact is taking out large format classified ad's in every newspaper in the area where the person is known to reside - or statewide if the region is not known. The ad's have to run for a minimum of one week) This means that it'd take no less than five weeks - and might take as much as six months - before I could begin filing lawsuits. (And even then I'd have to have proof that the person in question was violating my copyright at the time the lawsuit was filed) > > Ah, see - in the US the license(s) in question (and licenses in general) > > are grants of rights, not a "statements of will". > > Right here grants of rights are some sort of statements of will. Difference in terminology ? A "Grant of Rights" is where you say 'Normally only I could do this, but I am giving you the legal right to do it as well'. A "statement of will" is 'This is what I want to have happen, in perpetuity'. In the US, a "statement of will" can include or imply a "Grant of Rights" and vice-versa, but they are separate entities. > > (Truthfully, in the US a license > > should be read with an implicit "All rights reserved") > > Actually (and I think it's the same in the USA), a copyrighted work > has an implicit "all rights reserved". A licence is just exception. And? The fact remains that "All Rights Reserved" means "I am reserving all rights I do not specifically grant or waive". ie: If a license doesn't state 'The licenser hereby waives the right to revoke this license at any time' then that right hasn't been lost. (A license acquired through a purchase - as might apply to a novel - is a lot different. And contracts are a different beast entirely) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: GPL weasels and the atheros stink
On Tuesday 04 September 2007 11:10:52 [EMAIL PROTECTED] wrote: > On Mon, 03 Sep 2007 17:23:37 PDT, David Schwartz said: > > > Wrong - I said "You can't complain about Person A doing X when > > > you let Person > > > B do X without complaint". > > > > Yes, I can. There is no inconsistency between acting in one case and > > failing to act in another. We need not act in every possible case where > > we could act to preserve our right to act in a particular case. > > You *do* however need to be aware that in some cases, public inactivity > and/or statements that something will not be acted on may estoppel any > future attempts to enforce something. Exactly. However, inactivity can be construed as lack of knowledge that something is occurring. (ie: the RIAA didn't start acting on file-sharing until they became aware of Napster) But for said estoppel to not be a factor you will have to prosecute and/or file suit on all instances of the activity. (And filing a suit and then dropping it against some of the people that you filed suit against - ie: you file suit against persons A and B and then drop the suit against person A in its entirety - because you only wanted to prosecute person B for the action, you are leaving yourself open to lawsuits on a number of counts.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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
On Tuesday 04 September 2007 15:44:31 Michael Poole wrote: > Chris Friesen writes: > > Daniel Hazelton wrote: > >> On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: > >>>Daniel Hazelton <[EMAIL PROTECTED]> writes: > >>>>US Copyright law. A copyright holder, regardless of what license he/she > >>>>may have released the work under, can still revoke the license for a > >>>>specific person or group of people. (There are some exceptions, but > >>>> they do not apply to the situation that is being discussed) > > > > The OpenBSD policy page doesn't agree with you: > > > > "...That means that having granted a permission, the copyright holder > > can not retroactively say that an individual or class of individuals > > are no longer granted those permissions. Likewise should the copyright > > holder decide to "go commercial" he can not revoke permissions already > > granted for the use of the work as distributed, though he may impose > > more restrictive permissions in his future distributions of that work." > > > > http://www.openbsd.org/policy.html > > By my reading, this is supported by 17 USC 203(a)(3): > > (3) Termination of the grant may be effected at any time during a > period of five years beginning at the end of thirty-five years > from the date of execution of the grant; or, if the grant covers > the right of publication of the work, the period begins at the > end of thirty-five years from the date of publication of the > work under the grant or at the end of forty years from the date > of execution of the grant, whichever term ends earlier. > > (from > http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000- >.html ) Ah, I am both right and wrong, it seems. Apparently you have to wait anywhere form 35 to 40 years, and then you only have a five year window. Seems damned strange to me, but oh well. (I'd totally forgotten that part of the law - or my mind decided to play tricks on me.) DRH PS: See, I will admit it when I'm shown evidence that I'm wrong :) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > More sophisticated testing is needed - there's something in > > > ext3-tools which will mmap, page in and hold a file for you. > > > > So much for that theory. afaict mmapped, active pagecache is immune to > > updatedb activity. It just sits there while updatedb continues munching > > away at the slab and blockdev pagecache which it instantiated. I assume > > we're never getting the VM into enough trouble to tip it over the > > start-reclaiming-mapped-pages threshold (ie: /proc/sys/vm/swappiness). > > > > Start the updatedb on this 128MB machine with 80MB of mapped pagecache, > > it falls to 55MB fairly soon and then never changes. > > > > So hrm. Are we sure that updatedb is the problem? There are quite a few > > heavyweight things which happen in the wee small hours. > > The balance in _my_ world seems just fine. I don't let any of those > system maintenance things run while I'm using the system, and it doesn't > bother me if my working set has to be reconstructed after heavy-weight > maintenance things are allowed to run. I'm not seeing anything I > wouldn't expect to see when running a job the size of updatedb. > > -Mike Do you realize you've totally missed the point? It isn't about what is fine in the Kernel Developers world, but what is fine in the *USERS* world. There are dozens of big businesses pushing Linux for Enterprise performance. Rather than discussing the merit of those patches - some of which just improve the performance of a specific application by 1 or 2 percent - they get a nod and go into the kernel. But when a group of users that don't represent one of those businesses says "Hey, this helps with problems I see on my system" there is a big discussion and ultimately those patches get rejected. Why? Because they'll give an example using a program that they see causing part of the problem and be told "Use program X - it does things differently and shouldn't cause the problem" or "But what causes the problem to happen? The patch treats a symptom of a larger problem". The fucked up part of that is that the (mass of) kernel developers will see a similar report saying "mySQL has a performance problem because of X, this fixes it" and not blink twice - even if it is "treating the symptom and not the cause". It's this attitude more than anything that caused Con to "retire" - at least that is the impression I got from the interviews he's given. (The exact impression was "I'm sick of the kernel developers doing everything they can to help enterprise users and ignoring the home users") So... The problem: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. Q) Why does it help? A) Because it pro-actively swaps stuff back-in when the memory pressure that caused it to be swapped out is gone. Q) What causes the problem? A) The VFS layer not keeping a limited cache. Instead the VFS will chew through available memory in the name of "increasing performance". Solution(s) to the problem: 1) Limit the amount of memory the pagecache and other VFS caches can consume 2) Implement swap prefetch If I had a (more) complete understanding of how the VFS cache(s) work I'd try to code a patch to do #1 myself. Patches to do #2 already exist and have been shown to work for the users that have tried it. My question is thus, simply: What is the reason that it is argued against?(**) DRH PS: Yes, I realize I've repeated some people from earlier in this thread, but it seems that people have been forgetting the point. (*) I've followed this thread and all of its splinters. The reports that are in them, where the person making the report has a system that has the limited memory needed for the problem to exhibit itself, all show that swap-prefetch helps. (**) No, I won't settle for "Its treating a symptom". The fact is that this isn't a *SYMPTOM* of anything. It treats the cause of the lag the users that have less than (for the sake of argument) 1G of memory are seeing. And no, changing userspace isn't a solution - updatedb may be the program that has been used as an example, but there are others. The proper fix is to change the kernel to either make the situation impossible (limit the VFS and other kernel caches) or make the situation as painless as possible (implement swap prefetch to alleviate the lag of swapping data back in). -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe f
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 14:16:32 Rene Herman wrote: > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > > Updatedb or another process that uses the FS heavily runs on a users > > 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory > > pressure that causes other applications to be swapped to disk. In the > > morning the user has to wait for the system to swap those applications > > back in. > > > > Questions about it: > > Q) Does swap-prefetch help with this? > > A) [From all reports I've seen (*)] Yes, it does. > > No it does not. If updatedb filled memory to the point of causing swapping > (which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch > hasn't any memory to prefetch into -- updatedb itself doesn't use any > significant memory. Check the attitude at the door then re-read what I actually said: > > Updatedb or another process that uses the FS heavily runs on a users > > 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory > > pressure that causes other applications to be swapped to disk. In the > > morning the user has to wait for the system to swap those applications > > back in. I never said that it was the *program* itself - or *any* specific program (I used "Updatedb" because it has been the big name in the discussion) - doing the filling of memory. I actually said that the problem is that the kernel's caches - VFS and others - will grow *WITHOUT* *LIMIT*, filling all available memory. Swap prefetch on its own will not alleviate *all* of the problem, but it appears to fix enough of it that the problem doesn't seem to bother people anymore. (As I noted later on there are things that can be changes that would also fix things. Those changes, however, are quite tricky and involve changes to the page faulting mechanism, the way the various caches work and a number of other things) In light of the fact that swap prefetch appears to solve the problem for the people that have been vocal about it, and because it is a less intrusive change than the other potential solutions, I'd like to know why all the complaints and arguments against it come down to "Its treating the symptom". I mean it - because I fail to see how it isn't getting at the root of the problem - which is, pretty much, that Swap has classically been and, in the case of most modern systems, still is damned slow. By prefetching those pages that have most recently been evicted the problem of "slow swap" is being directly addressed. You want to know what causes the problem? The current design of the caches. They will extend without much limit, to the point of actually pushing pages to disk so they can grow even more. > Here's swap-prefetch's author saying the same: > > http://lkml.org/lkml/2007/2/9/112 > > | It can't help the updatedb scenario. Updatedb leaves the ram full and > | swap prefetch wants to cost as little as possible so it will never > | move anything out of ram in preference for the pages it wants to swap > | back in. > > Now please finally either understand this, or tell us how we're wrong. > > Rene. I already did. You completely ignored it because I happened to use the magic words "updatedb" and "swap prefetch". Did I ever say it was about "updatedb" in particular? You've got the statement in the part of my post that you quoted. Nope, appears that I used the name as a specific example - and one that has been used previously in the thread. Now drop the damned attitude and start using your brain. Okay? DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 18:08:44 Mike Galbraith wrote: > On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote: > > On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > > > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > > > So hrm. Are we sure that updatedb is the problem? There are quite a > > > > few heavyweight things which happen in the wee small hours. > > > > > > The balance in _my_ world seems just fine. I don't let any of those > > > system maintenance things run while I'm using the system, and it > > > doesn't bother me if my working set has to be reconstructed after > > > heavy-weight maintenance things are allowed to run. I'm not seeing > > > anything I wouldn't expect to see when running a job the size of > > > updatedb. > > > > > > -Mike > > > > Do you realize you've totally missed the point? > > Did you notice that I didn't make one disparaging remark about the patch > or the concept behind it? Did you notice that I took _my time_ to > test, to actually look at the problem? No, you're too busy running > your mouth to appreciate the efforts of others. If you're done being an ass, take note of the fact that I never even said you were doing that. What I was commenting on was the fact that you (and a lot of the other developers) seem to keep saying "It doesn't happen here, so it doesn't matter!" - ie: If I don't see something happening, it doesn't matter. > > > Do yourself a favor, go dig into the VM source. Read it, understand it > (not terribly easy), _then_ come back and preach to me. I've been trying to do that since the thread started. Note that you snipped where I said (and I'm going to paraphrase myself) "There is another way to fix this, but I don't have the understanding necessary". Now, once more, I'm going to ask: What is so terribly wrong with swap prefetch? Why does it seem that everyone against it says "Its treating a symptom, so it can't go in"? Try coming up with an answer that isn't "I don't see the problem on my $10K system" or similar - try explaining it based on the *technical* merits. Does it cause the processor cache to get thrashed? Does it create locking problems? I stand by my statements, as vitriolic as you and Rene seem to want to get over it. So far in this thread I have not seen one bit of *technical* discussion over the merits, just the bits I've simplified and stated before. > Have a nice day. I am. You being nasty when somebody gets fed up with a line of BS doesn't stop me from having a nice day. Only thing that could make my life any better would be to have the questions I've asked answered, rather than having supposedly intelligent people act like trolls. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 19:29:19 Andi Kleen wrote: > > Any faults in that reasoning? > > GNU sort uses a merge sort with temporary files on disk. Not sure > how much it keeps in memory during that, but it's probably less > than 150MB. At some point the dirty limit should kick in and write back the > data of the temporary files; so it's not quite the same as anonymous > memory. But it's not that different given. Yes, this should occur. But how many programs use temporary files like that? >From what I can tell FireFox and OpenOffice both keep all their data in memory, only using a single file for some buffering purposes. When they get pushed out by a memory hog (either short term or long term) it takes several seconds for them to be swapped back in. (I'm on a P4-1.3GHz machine with 1G of ram and rarely run more than four programs (Mail Client, XChat, FireFox and a console window) and I've seen this lag in FireFox when switching to it after starting OOo. I've also seen the same sort of lag when exiting OOo. I'll see about getting some numbers about this) > It would be better to measure than to guess. At least Andrew's measurements > on 128MB actually didn't show updatedb being really that big a problem. I agree. As I've said previously, it isn't updatedb itself which causes the problem. It's the way the VFS cache seems to just expand and expand - to the point of evicting pages to make room for itself. However, I may be wrong about that - I haven't actually tested it for myself, just looked at the numbers and other information that has been posted in this thread. > Perhaps some people have much more files or simply a less efficient > updatedb implementation? Yes, it could be the proliferation of files. It could also be some other sort of problem that is exposing a corner-case in the VFS cache or the MM. I, personally, am of the opinion that it is likely the aforementioned corner case for people reporting the "updatedb" problem. If it is, then swap-prefetch is just papering over the problem. However I do not have the knowledge and understanding of the subsystems involved to be able to do much more than make a (probably wrong) guess. > I guess the people who complain here that loudly really need to supply > some real numbers. I've seen numerous "real numbers" posted about this. As was said earlier in the thread "every time numbers are posted they are claimed to be no good". But hey, nobodies perfect :) Anyway, the discussion seems to be turning to the technical merits of swap-prefetch... Now, a completely different question: During the research (and lots of thinking) I've been doing while this thread has been going on I've often wondered why swap prefetch wasn't already in the kernel. The problem of slow swap-in has long been known, and, given current hardware, the optimal solution would be some sort of data prefetch - similar to what is done to speed up normal disk reads. Swap prefetch looks like it does exactly that. The algo could be argued over and/or improved (to suggest ways to do that I'd have to give it more than a 10 minute look) but it does provide a speed-up. This speed increase will probably be enjoyed more by the home users, but the performance increase could also help on enterprise systems. Now I'll be the first one to admit that there is a trade-off there - it will cause more power to be used because the disk's don't get a chance to spin down (or go through a cycle every time the prefetch system starts) but that could, potentially, be alleviated by having "laptop mode" switch it off. (And no, I'm not claiming that it is perfect - but then, what is when its first merged into the kernel?) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 03:48:13 Mike Galbraith wrote: > On Fri, 2007-07-27 at 18:51 -0400, Daniel Hazelton wrote: > > Now, once more, I'm going to ask: What is so terribly wrong with swap > > prefetch? Why does it seem that everyone against it says "Its treating a > > symptom, so it can't go in"? > > And once again, I personally have nothing against swap-prefetch, or > something like it. I can see how it or something like it could be made > to improve the lives of people who get up in the morning to find their > apps sitting on disk due to memory pressure generated by over-night > system maintenance operations. > > The author himself however, says his implementation can't help with > updatedb (though people seem to be saying that it does), or anything > else that leaves memory full. That IMHO, makes it of questionable value > toward solving what people are saying they want swap-prefetch for in the > first place. Okay. I have to agree with the author that, in such a situation, it wouldn't help. However there are, without a doubt, other situations where it would help immensely. (memory hogs forcing everything to disk and quitting, one off tasks that don't balloon the cache (kernel compiles, et al) - in those situations swap prefetch would really shine.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Rene Herman wrote: > > On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >> On Fri, 27 Jul 2007, Rene Herman wrote: > >> > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > > Questions about it: > >> > > Q) Does swap-prefetch help with this? > >> > > A) [From all reports I've seen (*)] > >> > > Yes, it does. > >> > > >> > No it does not. If updatedb filled memory to the point of causing > >> > swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and > >> > swap-prefetch hasn't any memory to prefetch into -- updatedb itself > >> > doesn't use any significant memory. > >> > >> however there are other programs which are known to take up significant > >> amounts of memory and will cause the issue being described (openoffice > >> for example) > >> > >> please don't get hung up on the text 'updatedb' and accept that there > >> are programs that do run intermittently and do use a significant amount > >> of ram and then free it. > > > > Different issue. One that's worth pursueing perhaps, but a different > > issue from the VFS caches issue that people have been trying to track > > down. > > people are trying to track down the problem of their machine being slow > until enough data is swapped back in to operate normally. > > in at some situations swap prefetch can help becouse something that used > memory freed it so there is free memory that could be filled with data > (which is something that Linux does agressivly in most other situations) > > in some other situations swap prefetch cannot help becouse useless data is > getting cached at the expense of useful data. > > nobody is arguing that swap prefetch helps in the second cast. Actually, I made a mistake when tracking the thread and reading the code for the patch and started to argue just that. But I have to admit I made a mistake - the patches author has stated (as Rene was kind enough to point out) that swap prefetch can't help when memory is filled. > what people are arguing is that there are situations where it helps for > the first case. on some machines and version of updatedb the nighly run of > updatedb can cause both sets of problems. but the nightly updatedb run is > not the only thing that can cause problems Solving the cache filling memory case is difficult. There have been a number of discussions about it. The simplest solution, IMHO, would be to place a (configurable) hard limit on the maximum size any of the kernels caches can grow to. (The only solution that was discussed, however, is a complex beast) > > but let's talk about the concept here for a little bit > > the design is to use CPU and I/O capacity that's otherwise idle to fill > free memory with data from swap. > > pro: >more ram has potentially useful data in it > > con: >it takes a little extra effort to give this memory to another app (the > page must be removed from the list and zeroed at the time it's needed, I > assume that the data is left in swap so that it doesn't have to be written > out again) > >it adds some complexity to the kernel (~500 lines IIRC from this thread) > >by undoing recent swapouts it can potentially mask problems with swapout > > it looks to me like unless the code was really bad (and after 23 months in > -mm it doesn't sound like it is) that the only significant con left is the > potential to mask other problems. I'll second this. But with the swap system itself having seen as heavy testing as it has I don't know if it would be masking other problems. That is why I've been asking "What is so wrong with it?" - while it definately doesn't help with programs that cause caches to balloon (that problem does need another solution) it does help to speed things up when a memory hog has exited. (And since its a pretty safe assumption that swap is going to be noticeably slower than RAM this patch seems to me to be a rather visible and obvious solution to that problem) > however there are many legitimate cases where it is definantly dong the > right thing (swapout was correct in pushing out the pages, but now the > cause of that preasure is gone). the amount of benifit from this will vary > from situation to situation, but it's not reasonable to claim that this > provides no benifit (you have benchmark numbers that show it in synthetic > benchmarks, and you have user reports that show it in the real-worlk) Exactly. Though I have seen posts which (to
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 17:06:50 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Daniel Hazelton wrote: > > On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > >> On Sat, 28 Jul 2007, Rene Herman wrote: > >>> On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >>>> On Fri, 27 Jul 2007, Rene Herman wrote: > >>>>> On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > >> nobody is arguing that swap prefetch helps in the second cast. > > > > Actually, I made a mistake when tracking the thread and reading the code > > for the patch and started to argue just that. But I have to admit I made > > a mistake - the patches author has stated (as Rene was kind enough to > > point out) that swap prefetch can't help when memory is filled. > > I stand corrected, thaks for speaking up and correcting your position. If you had made the statement before I decided to speak up you would have been correct :) Anyway, I try to always admit when I've made a mistake - its part of my philosophy. (There have been times when I haven't done it, but I'm trying to make that stop entirely) > >> what people are arguing is that there are situations where it helps for > >> the first case. on some machines and version of updatedb the nighly run > >> of updatedb can cause both sets of problems. but the nightly updatedb > >> run is not the only thing that can cause problems > > > > Solving the cache filling memory case is difficult. There have been a > > number of discussions about it. The simplest solution, IMHO, would be to > > place a (configurable) hard limit on the maximum size any of the kernels > > caches can grow to. (The only solution that was discussed, however, is a > > complex beast) > > limiting the size of the cache is also the wrong thing to do in many > situations. it's only right if the cache pushes out other data you care > about, if you are trying to do one thing as fast as you can you really do > want the system to use all the memory it can for the cache. After thinking about this you are partially correct. There are those sorts of situations where you want the system to use all the memory it can for caches. OTOH, if those situations could be described in some sort of simple heuristic, then a soft-limit that uses those heuristics to determine when to let the cache expand could exploit the benefits of having both a limited and unlimited cache. (And, potentially, if the heuristic has allowed a cache to expand beyond the limit then, when the heuristic no longer shows the oversize cache is no longer necessary it could trigger and automatic reclaim of that memory.) (I'm willing to help write and test code to do this exactly. There is no guarantee that I'll be able to help with more than testing - I don't understand the parts of the code involved all that well) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Sunday 29 July 2007 16:00:22 Ray Lee wrote: > On 7/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote: > > If the problem is reading stuff back in from swap at the *same time* > > that the application is reading stuff from some user file system, and if > > that user file system is on the same drive as the swap partition > > (typical on laptops), then interleaving the user file system accesses > > with the swap partition accesses might overwhelm all other performance > > problems, due to the frequent long seeks between the two. > > Ah, so in a normal scenario where a working-set is getting faulted > back in, we have the swap storage as well as the file-backed stuff > that needs to be read as well. So even if swap is organized perfectly, > we're still seeking. Damn. That is one reason why I try to have swap on a device dedicated just for it. It helps keep the system from having to seek all over the drive for data. (I remember that this was recommended years ago with Windows - back when you could tell Windows where to put the swap file) > On the other hand, that explains another thing that swap prefetch > could be helping with -- if it preemptively faults the swap back in, > then the file-backed stuff can be faulted back more quickly, just by > the virtue of not needing to seek back and forth to swap for its > stuff. Hadn't thought of that. For it to really help swap-prefetch would have to be more aggressive. At the moment (if I'm reading the code correctly) the system has to have close to zero for it to kick in. A tunable knob controlling how much activity is too much for the prefetch to kick in would help with finding a sane default. IMHO it should be the one that provides the most benefit with the least hit to performance. > That also implies that people running with swap files rather than swap > partitions will see less of an issue. I should dig out my old compact > flash card and try putting swap on that for a week. Maybe. It all depends on how much seeking is needed to track down the pages in the swapfile and such. What would really help make the situation even better would be doing the log structured swap + cleaner. The log structured swap + cleaner should provide a performance boost by itself - add in the prefetch mechanism and the benefits are even more visible. Another way to improve performance would require making the page replacement mechanism more intelligent. There are bounds to what can be done in the kernel without negatively impacting performance, but, if I've read the code correctly, there might be a better way to decide which pages to evict. One way to do this would be to implement some mechanism that allows the system to choose a single group of contiguous pages (or, say, a large soft-page) over swapping out a single page at a time. (some form of memory defrag would also be nice, but I can't think of a way to do that without massively breaking everything) > > In case Andrew is so bored he read this far -- yes this wake-up sounds > > like user space code, with minimal kernel changes to support any > > particular lower level operation that we can't do already. > > He'd suggested using, uhm, ptrace_peek or somesuch for just such a > purpose. The second half of the issue is to know when and what to > target. The userspace suggestion that was thrown out earlier would have been as error-prone and problematic as FUSE. A solution like you suggest would be workable - its small and does a task that is best done in userspace (IMHO). (IIRC, the original suggestion involved merging maps2 and another patchset into mainline and using that, combined with PEEKTEXT to provide for a userspace swap daemon. Swap, IMHO, should never be handled outside the kernel) What might be useful is a userspace daemon that tracks memory pressure and uses a concise API to trigger various levels of prefetch and/or swap aggressiveness. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Ok, lets kill the 'PCI hidden behind bridge' message (was: pci=assign-busses)
On Monday 30 July 2007 14:35:13 Bernhard Kaindl wrote: > Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by > Yenta, so PCI does not have to warn about it. PCI could still warn about it > if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have > not seen a report where this would have been the case so I think we can > spare the kernel of that check (removes ~300 lines of asm) unless debugging > is done. > > History: The whole check was added in the days before we had the fixup > for this in Yenta and pci=assign-busses was the only way to get CardBus > cards detected on many (not all) of the machines which give this warning. The message triggers on systems without Cardbus at all. > In theory, there could be cases when this warning would be triggered and > it's not cardbus, then the warning should still apply, but I think this > should only be the case when working on a completely broken PCI setup, > but one may have already enabled the debug code in drivers/pci and the > patched check would then trigger. I wouldn't say totally broken. The last 5 computers I've owned have had this message. On only one could it even *remotely* be related to CardBus (my one year old laptop), and on one of them it does create problems for certain (NVidia) binary drivers. (and then pci=assign-busses doesn't do jack to clear the message) I'm not saying that binary drivers shouldn't be broken - but... DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: rt73usb: support for wireless in Kohjinsha subnotebook
On Monday 22 October 2007 17:52:57 Ivo van Doorn wrote:
> On Monday 22 October 2007, Pavel Machek wrote:
> > Hi!
> >
> > > > > This device is NOT a Ralink USB wifi adapter!
> > > > >
> > > > > Get the windows driver in this link and see for yourself.
> > > > > http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB
> > > > > (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver))
> > > >
> > > > Thanks a lot. With some patches, I got driver from conitech.it to
> > > > compile and partly work on 2.6.23. I can now transmit packets but not
> > > > yet receive them.
> > > >
> > > > (use Makefile.26 instead of Makefile)
> > >
> > > I couldn't find any license info immediately visible; are you sure it's
> > > GPL?
> >
> > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
>
> That doesn't say much, some manufacturers add that line to their driver
> just to prevent the module loader complaining about a non-GPL driver...
>
> There should be a copyright notice or a license file accompanied with
> the driver that clearly states the license of the driver.
Lacking an explicitly stated license it can be argued that, since the
MODULE_LICENSE() macro is meant to define the actual license on the code,
this code is GPL. No, it isn't an explicit definition, but lacking any other
signs of the license, the implicit declaration of it being GPL is (or should
be) enough to deflect charges of copyright infringement.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > >
> > > > That doesn't say much, some manufacturers add that line to their
> > > > driver just to prevent the module loader complaining about a non-GPL
> > > > driver...
> > > >
> > > > There should be a copyright notice or a license file accompanied with
> > > > the driver that clearly states the license of the driver.
> > >
> > > Lacking an explicitly stated license it can be argued that, since the
> > > MODULE_LICENSE() macro is meant to define the actual license on the
> > > code, this code is GPL. No, it isn't an explicit definition, but
> > > lacking any other signs of the license, the implicit declaration of it
> > > being GPL is (or should be) enough to deflect charges of copyright
> > > infringement.
> >
> > Yep, I believe this driver is GPLed. They published the source and
> > there's nothing to suggest otherwise, and there's explicit:
> >
> > #define DRIVER_AUTHOR "Jeff Lee<[EMAIL PROTECTED]>"
> > #define DRIVER_DESC "IS89C35 802.11bg WLAN
> > USB Driver" MODULE_LICENSE("GPL");
>
> If there isn't an explicit COPYING or LICENSE file or something
> distributed with the driver, and if there aren't copyright/license
> headers at the top of the files in question, I have a hard time agreeing
> that MODULE_LICENSE("GPL") _definitely_ means that the author has GPL-ed
> the driver intentionally. Of course that's the way it's supposed to
> work, but to me this doesn't pass sufficient muster to be definitely
> called GPL without additional clarification.
>
> Dan
Lacking any other indication MODULE_LICENSE is supposed to mark the license
that the code is being distributed under. If companies are intentionally
mis-using this to get around the "internal interfaces" limitations (where
some interfaces are not available unless the module is GPL'd) and the warning
message printed in the logs when the module is not GPL'd then they are
(technically) in violation of the law. (interfaces that are GPL only are
considered so internal to the kernel that using them makes your code GPL
because of the inclusion of GPL'd code. And no - I am not going to get into
that discussion - it's pointless)
In the end, using MODULE_LICENSE for any purpose other than declaring the
chosen license for the code is deceptive. So it is easily arguable that by
not including any license with the code other than the MODULE_LICENSE
statement and then trying to prosecute because MODULE_LICENSE doesn't
accurately state the license on the code is entrapment and illegal.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 14:54:54 Dan Williams wrote:
> On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote:
> > On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> > > On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > > > >
> > > > > > That doesn't say much, some manufacturers add that line to their
> > > > > > driver just to prevent the module loader complaining about a
> > > > > > non-GPL driver...
> > > > > >
> > > > > > There should be a copyright notice or a license file accompanied
> > > > > > with the driver that clearly states the license of the driver.
> > > > >
> > > > > Lacking an explicitly stated license it can be argued that, since
> > > > > the MODULE_LICENSE() macro is meant to define the actual license on
> > > > > the code, this code is GPL. No, it isn't an explicit definition,
> > > > > but lacking any other signs of the license, the implicit
> > > > > declaration of it being GPL is (or should be) enough to deflect
> > > > > charges of copyright infringement.
> > > >
> > > > Yep, I believe this driver is GPLed. They published the source and
> > > > there's nothing to suggest otherwise, and there's explicit:
> > > >
> > > > #define DRIVER_AUTHOR "Jeff
> > > > Lee<[EMAIL PROTECTED]>" #define DRIVER_DESC
> > > >"IS89C35 802.11bg WLAN USB Driver" MODULE_LICENSE("GPL");
> > >
> > > If there isn't an explicit COPYING or LICENSE file or something
> > > distributed with the driver, and if there aren't copyright/license
> > > headers at the top of the files in question, I have a hard time
> > > agreeing that MODULE_LICENSE("GPL") _definitely_ means that the author
> > > has GPL-ed the driver intentionally. Of course that's the way it's
> > > supposed to work, but to me this doesn't pass sufficient muster to be
> > > definitely called GPL without additional clarification.
> > >
> > > Dan
> >
> > Lacking any other indication MODULE_LICENSE is supposed to mark the
> > license that the code is being distributed under. If companies are
> > intentionally
>
> Step 1: Ask the author.
Agreed. This should have been done before this discussion even started.
> Step 2: if the author doesn't reply, then we can have this discussion
>
> MODULE_LICENSE is just a random string that could have been added by
> anybody, not necessarily the author. Unless you can determine the
> intent of the author explicitly, a single MODULE_LICENSE is not
> sufficient to concretely determine the license of the code. It's only
> in one file. There is nothing to explicitly state the overall license
> of the whole work unless each file has a header referring to the license
> or unless there is a license document distributed with the code as a
> whole.
>
> In the absence of any other indication, MODULE_LICENSE doesn't not
> concretely determine the license of the code. You can assume it does,
> but that's your gun to put to your own head.
The intent of MODULE_LICENSE is to mark the license on the code. This is
clearly stated in several places in Documentation/ (if my memory serves).
> > mis-using this to get around the "internal interfaces" limitations (where
> > some interfaces are not available unless the module is GPL'd) and the
> > warning message printed in the logs when the module is not GPL'd then
> > they are (technically) in violation of the law. (interfaces that are GPL
> > only are considered so internal to the kernel that using them makes your
> > code GPL because of the inclusion of GPL'd code. And no - I am not going
> > to get into that discussion - it's pointless)
>
> Just because the module may be loading illegally says _nothing_ about
> the license of the code.
No, but it is a mis-use of MODULE_LICENSE, which is supposed to state the
correct license on the code.
> > In the end, using MODULE_LICENSE for any purpose other than declaring the
> > chosen license for the code is deceptive. So it is easily arguable that
> > by
>
> "deceptive" is also not "this code code is definitely GPL". Doesn't
> matter whether it's deceptive or not. We do not know th
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 17:27:07 Dan Williams wrote:
> On Tue, 2007-10-23 at 15:41 -0400, Daniel Hazelton wrote:
> > On Tuesday 23 October 2007 14:54:54 Dan Williams wrote:
> > > On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote:
> > > > On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> > > > > On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > > > > > Hi!
> > > > > >
> > > > > > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > > > > > >
> > > > > > > > That doesn't say much, some manufacturers add that line to
> > > > > > > > their driver just to prevent the module loader complaining
> > > > > > > > about a non-GPL driver...
> > > > > > > >
> > > > > > > > There should be a copyright notice or a license file
> > > > > > > > accompanied with the driver that clearly states the license
> > > > > > > > of the driver.
> > > > > > >
> > > > > > > Lacking an explicitly stated license it can be argued that,
> > > > > > > since the MODULE_LICENSE() macro is meant to define the actual
> > > > > > > license on the code, this code is GPL. No, it isn't an explicit
> > > > > > > definition, but lacking any other signs of the license, the
> > > > > > > implicit declaration of it being GPL is (or should be) enough
> > > > > > > to deflect charges of copyright infringement.
> > > > > >
> > > > > > Yep, I believe this driver is GPLed. They published the source
> > > > > > and there's nothing to suggest otherwise, and there's explicit:
> > > > > >
> > > > > > #define DRIVER_AUTHOR "Jeff
> > > > > > Lee<[EMAIL PROTECTED]>" #define DRIVER_DESC
> > > > > >"IS89C35 802.11bg WLAN USB Driver" MODULE_LICENSE("GPL");
> > > > >
> > > > > If there isn't an explicit COPYING or LICENSE file or something
> > > > > distributed with the driver, and if there aren't copyright/license
> > > > > headers at the top of the files in question, I have a hard time
> > > > > agreeing that MODULE_LICENSE("GPL") _definitely_ means that the
> > > > > author has GPL-ed the driver intentionally. Of course that's the
> > > > > way it's supposed to work, but to me this doesn't pass sufficient
> > > > > muster to be definitely called GPL without additional
> > > > > clarification.
> > > > >
> > > > > Dan
> > > >
> > > > Lacking any other indication MODULE_LICENSE is supposed to mark the
> > > > license that the code is being distributed under. If companies are
> > > > intentionally
> > >
> > > Step 1: Ask the author.
> >
> > Agreed. This should have been done before this discussion even started.
> >
> > > Step 2: if the author doesn't reply, then we can have this discussion
> > >
> > > MODULE_LICENSE is just a random string that could have been added by
> > > anybody, not necessarily the author. Unless you can determine the
> > > intent of the author explicitly, a single MODULE_LICENSE is not
> > > sufficient to concretely determine the license of the code. It's only
> > > in one file. There is nothing to explicitly state the overall license
> > > of the whole work unless each file has a header referring to the
> > > license or unless there is a license document distributed with the code
> > > as a whole.
> > >
> > > In the absence of any other indication, MODULE_LICENSE doesn't not
> > > concretely determine the license of the code. You can assume it does,
> > > but that's your gun to put to your own head.
> >
> > The intent of MODULE_LICENSE is to mark the license on the code. This is
> > clearly stated in several places in Documentation/ (if my memory serves).
> >
> > > > mis-using this to get around the "internal interfaces" limitations
> > > > (where some interfaces are not available unless the module is GPL'd)
> > > > and the warning message printed in the logs when the module is not
> > > > GPL'd then they are (technically) in
Re: mea culpa on the meaning of Tivoization (was: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3)
On Sunday 17 June 2007 19:11:13 Alexandre Oliva wrote: > On Jun 17, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: > >> > That accurately describes the FCC wireless rules. > >> > >> AFAIK the FCC mandates not permitting the user to tinker. It doesn't > >> mandate the vendor to retain this ability to itself. > > > > In practical terms it does since a recall/replacement in the event of > > rule changes is a bit impractical > > Indeed. But that's not a legal requirement, it's an economic reason. > > "But I need to make a profit" or "But I need to reduce costs" is no > excluse to disrespect the GPL. > > >> Therefore, per the above, FCC doesn't mandate tivoization. > > > > I'm sure you can find a definition to sort your goals whatever. > > Are you per chance implying that I'm twisting the definition of > tivoization? > > > You know... I now believe that would be correct. I have indeed > twisted the definition of tivoization, and I'm sorry about that. > Which is not to say that I agree that the FCC or any other law > mandates tivoization, or that tivozation is a good thing or that it is > permitted by GPLv2. Please read on. > > > After long conversations with RMS about the section on poisoned apples > and tivoization in my draft article about GPLv3 (Corresponding Sources > is the name of the section in > http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite) I had come > to the conclusion that Tivoization amounted to: > > denying the user of the computer the freedom to run modified > versions of the Free Software in it, while retain this ability to > oneself. > > This understanding of mine had been strengthened by my understanding > of the wording and the rationale of GPLv3dd3, the wording about > technical restrictions in the rationales published along with > GPLv2dd2, and the various speeches in which the term was presented. > > Nevertheless, I consulted with him and others highly involved in the > development of GPLv3 about some of the discussions going on here, and > got responses over the past few hours that surprised me. A lot. > > So I've just went back to that discussion about my article, and to > various other cases in which RMS, Eben Moglen and others presented > Tivoization, the rationales, and so on, and I came to the conclusion > that I had experienced a subtle but very significant misunderstanding. > > I'm now convinced that a more appropriate definition would be: > > denying the user of the computer the freedom to run modified > versions of the Free Software in it, by not sharing information as > to how it could be accomplished. > > > This difference is very significant, and even more so for this > discusion, because it contradicts some of what I claimed before about > forms to use GPLed software where regulations require the user to be > unable to modify the software. > > > Let me start with an example: I bought a wireless router some time > ago, and it had a GNU+Linux distribution installed in it. No source > code or written offer for source code, though. Just want to point out that, when I read this, my reaction was "But... That is a direct violation of the GPLv2. No specific reading of the license needed." > Now, if I called the vendor next day and asked for the source code, > and they responded "sorry, I can't give you that. I threw it all > away, such that I wouldn't be able to give it to you.", they would > still be disrespecting my freedoms, as well as the license, right? Yes, they would. They are distributing a modification - in the words of the GPLv2 "a work based on the work" - without complying with the terms of the license. > You see where I'm going? Now, if they gave me the source code, but I > still couldn't install modified versions, because they introduced > technical measures with the purpose of denying me this possibility, > then the inability to modify the program wouldn't be caused by > something like a physical impossibility (something like ROM), but > rather by an active measure to trample my ability to adapt the program > and run it for any purpose. > > So, if I called them to ask how to install and run modified versions > of the GPLed programs, and they responded "sorry, I can't give you > that. I threw it all away, such that I wouldn't be able to give it to > you.", they would still be disrespecting my freedoms, as well as the > license. Not even the GPLv3dd4 - because they don't have the information anymore either. If, however, they still retained the information - in any form - they would be violating the GPLv3dd4. The GPLv2 doesn't make the actions described above - "how to install and run" - a license violation. > The reasons as to why they'd want to disrespect the freedoms don't > matter. It could be "making a profit", "complying with the law", > "abiding by contractual restrictions", anything. Imposing > restrictions to the exercise of the freedoms is not in line with the > spirit of the GPL, as such restrictions render the Softwar
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Monday 18 June 2007 04:49:56 Anders Larsen wrote: > On Sat, 16 Jun 2007 22:54:56 -0300, Alexandre Oliva wrote: > > I don't know any law that requires tivoization. > > Not exactly laws, but pretty close: > > Credit-card payment terminals are subject to strict security > certification, where it has to be ensured that > > a) the user cannot tinker with the device without rendering it unusable > for its original purpose (electronic payments), and > > b) the manufacturer is able to update the device _in_ _the_ _field_. > > Those are hard requirements imposed by the banks and credit-card companies. > > We _are_ allowed to disclose the source code (and we do, of course) so > that it can be used for other purposes, and of course the user can modify > it. But there's just no way she would be (legally) able to run the > modified software in the same device for the original purpose. And with the current laws it wouldn't just be the user that is charged with a crime, but the company. For "Facilitating the commission of a crime". (btw, that is how, in the US, companies that provide "Full Automatic" conversion kits are prosecuted. (You can't be touched for providing instructions on how to do it - "Freedom of Speech" and all that, but...) DRH > With the (current draft of) GPLv3 we could not legally use Linux on such > devices. > > Cheers > Anders -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: mea culpa on the meaning of Tivoization
On Monday 18 June 2007 15:09:47 Alexandre Oliva wrote: > On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Sunday 17 June 2007 19:11:13 Alexandre Oliva wrote: > >> Let me start with an example: I bought a wireless router some time > >> ago, and it had a GNU+Linux distribution installed in it. No source > >> code or written offer for source code, though. > > > > Just want to point out that, when I read this, my reaction was > > "But... That is a direct violation of the GPLv2. No specific reading > > of the license needed." > > Yes. Anyone feels like enforcing the GPLv2 in Brazil? I can even > recommend lawyers that speak English reasonably well and are somewhat > familiar with the GPL, and I've already tracked the distribution chain > back to the initial infringer. Harald is aware of the issue, but > AFAIK he's decided not to pursue that yet. I don't know if I have the right. None of the code is mine - the fact that they are in violation of the license is not in question (I trust your word on this), but it is the licensor who has the right to press charges. (I will check with the lawyers and law professionals I know, because the GPL makes no statements about the legal jurisdiction under which violations will be tried. It might be that I actually can file suit under Brazillian law) > >> Now, if I called the vendor next day and asked for the source code, > >> and they responded "sorry, I can't give you that. I threw it all > >> away, such that I wouldn't be able to give it to you.", they would > >> still be disrespecting my freedoms, as well as the license, right? > > > > Yes, they would. They are distributing a modification > > There's no reason to assume it's a modification. They're distributing > a copy, and that's enough. Bad word choice on my part. Of course you are correct. > >> So, if I called them to ask how to install and run modified versions > >> of the GPLed programs, and they responded "sorry, I can't give you > >> that. I threw it all away, such that I wouldn't be able to give it to > >> you.", they would still be disrespecting my freedoms, as well as the > >> license. > > > > Not even the GPLv3dd4 - because they don't have the information > > anymore either. If, however, they still retained the information - > > in any form - they would be violating the GPLv3dd4. > > I'm told by the authors of GPLv3dd4 that this case is not meant to be > permitted. I suppose they're going to change the wording, or at least > the rationale for it. Okay. So its possible to change whats running on the hardware - but even though nobody has the information needed to do it, it's a violation. Hrm... I can see some valid reasoning behind this, but it'll take creative legalese to make sure that things like (EE)PROMS are properly covered. > > The GPLv2 doesn't make the actions described above - "how to install and > > run" - a license violation. > > This is true. They didn't have any such duty, under the GPLv2. > > However, if I figured that out by myself, but found that I was unable > to run a modified version because something in there checks for a hash > computed over the program I'd like to modify, and refuses to run it > because of the hash, then the hash is effectively part of the program, > and they haven't provided me with the corresponding sources of that > portion of the program. "Effectively" - yes, that is the perfect way to describe it. And even though it isn't directly part, a situation like that should be covered. (In other words, if this was the way the "tivoization" section was written to make this "effectively part of the work" bit the focus a lot of my objections to it would be nullified. Give me a few hours to work on some solid and unambiguous language and I'll send something your way for review) > I know you don't want that to be true, and a court might actually > decide your way some day. But until then, your claim that this is > permitted by the GPL is just as good as mine that it's not. And I > really mean "just as good", since my claim is in line with the stated > purpose of the authors of the GPL, and yours is in line with their > opinion (according to others, I don't think I've got this straight > from them) as to whether the license effectively prohibits this > practice. Agreed. As Linus pointed out, we've been arguing over opinions and that's pointless. The only thing to do when someone states an opinion is to nod and accept it. > > T
Re: mea culpa on the meaning of Tivoization
On Monday 18 June 2007 17:31:47 Alexandre Oliva wrote: > On Jun 18, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Monday 18 June 2007 15:09:47 Alexandre Oliva wrote: > >> Yes. Anyone feels like enforcing the GPLv2 in Brazil? > > > > I don't know if I have the right. None of the code is mine > > It would have to be some major copyright holder of core Linux code, or > the mips port (IIRC it's mips hardware), or some other driver they're > using. That's what I thought. Anyone here feel like pursuing that? It is, directly, a license violation. :) > > Okay. So its possible to change whats running on the hardware - but > > even though nobody has the information needed to do it, it's a > > violation. Hrm... I can see some valid reasoning behind this, > > Yup. Same reasoning as "I threw the source code away", really. Not really. "I threw the source away" violates the license in a very clear manner - they are distributing a "work based on the work" without complying with the terms of the license under which they gained access to the work. However, as I said, I can see some valid reasoning. But its more a part of the "Hey, I paid good money for this thing and I can't use it how I want!" type of reasoning. > > "Effectively" - yes, that is the perfect way to describe it. And > > even though it isn't directly part, a situation like that should be > > covered. > > And if you look at GPLv3dd1 or dd2 IIRC, that's how it started. For > some reason, the FSF turned it into the more lax (in some senses) > installation information for user products in dd3. Maybe they decided > that the argument about the signature being effectively part of the > executable, and therefore the key being effectively part of the source > code, was less likely to be upheld in a court of law than this > alternate phrasing. All in all, the effect is the same AFAICT, and > the spirit is being complied with. But the change has some massive problems. If dd1 or dd2 was clearly and concisely written such that the conditions were not open to a different interpretation without creative re-definition of words then changes would not be needed. (I'm still working on the version I mentioned - give me a bit, writing english in such a way that a lawyer can't twist it to mean whatever they are paid to make it mean is difficult.) > >> > What the GPLv3 has done is take away options they might otherwise > >> > have had. > >> > >> It doesn't. Authors can always grant these options separately if they > >> want to. Authors can always choose GPLv2 if they want to. > > > > Okay. I think that someone pointed out a problem with the "optional > > grant" idea, but I can't remember the specifics and don't feel like > > digging through the 500 or so posts that make up this discussion. > > Linus claimed he would then have to refrain from accepting > contributions from anyone who removed this additional permission. > > I don't see how this is different from refraining from accepting > contributions under any other license, except that you can't use > license incompatibility to reason it out as an impossibility you > established for yourself in just the very same way. I think there was more to it than that, but the point doesn't matter. If the license used on contributed code *isn't* completely compatible with the license on the project it can't be used anyway. (doesn't the GPLv3 cover situations like that?) > >> > If one of the goals of the FSF is to force proprietary software into > >> > a minority then its just done damage to that goal. > >> > >> That's not the goal. > > > > I didn't say it was "the goal", I said "one of the goals". > > I stand corrected. Sorry. It's been a long thread and a long week. Understandable. > My objection was mainly about the "forcing". FSF's stance is about > educating users as to the moral and ethical reasons, such that they > reject non-Free Software, while at the same time providing software > authors with means to stop others from hurting users, by depriving > them of the freedoms they're morally entitled to have. Hrm... When I first hit the end of this massive sentence I was really confused. Took about five minutes for me to remember that "morally entitled" is based on the morals promoted by the FSF. > Others often perceive FSF's tactics as forceful, and I don't deny that > this may be justified, based on past interactions with the FSF. That > said, I think they've im
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Monday 18 June 2007 19:31:30 Alexandre Oliva wrote: > On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > With the GPLv2, you need to give your software modifications back, but > > the > BZZT! > > GPLv2 never *ever* makes any technical limitations on the end result. > > Actually, just think of how many times you've heard the argument "I > can't give you the source code for this driver/firmware/etc under the > GPLv2 because the law says so." Sorry to tell you this, but anyone that makes a modification to GPLv2 covered code and distributes that modification is bound by the license. If a law makes following the license illegal, then they can't use any rights granted by the license. They are breaking the law by refusing to follow the license. > > The GPLv2 requires that you give source code out. > BZZT ;-) > > But if you want to make your hardware in a way that it only runs > > signed versions, because of some reason like an FCC rule, or banking > > rule, or just because you damn well want, the GPLv2 doesn't stop > > that. > > And then, the user is stopped from making appropriate technical > decisions. You marked the "requires" as an error. Technically it is. Practically, however, it is rare for a modification to not fall under the "distribution" part of the license, making the "release the source" requirement active almost all the time. > > b) I think you're simply wrong in your math. I think more people > > like the middle-ground and not-frothing-at-the-mouth spirit of "open > > source" over the religious dogma of "free software". > > It looks like the math you're talking about is in no way related with > anything I've argued about. You seem to be thinking about the number > of people who claim to be on the "free software" or "open source" > sides, but I can't fathom in what way this is related with whether you > get more or less contributions from users as a consequence of users' > being permitted to tinker with the free software in their own devices. "More Developers" (either "Free Software" or "Open Source") == "More Contributions" That equation is very simple to understand - claiming its wrong is impossible. > > See? Those are three totally different reasons why I think the GPLv2 is > > the right license for me, and for the kernel. > > Ok, the only one that stands is the moral reason. Apparently because you can't admit that a good reason *IS* a good reason when it conflicts with your belief that the FSF is correct. (The same as the "Science can't be right because it conflicts with the bible" I hear from all kinds of Xtians these days) DRH PS: I know I've said I'm done with this conversation, but this is like a bad habit. I just couldn't help myself. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Monday 18 June 2007 22:06:57 Alexandre Oliva wrote: > On Jun 18, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Monday 18 June 2007 19:31:30 Alexandre Oliva wrote: > >> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> > >> Actually, just think of how many times you've heard the argument "I > >> can't give you the source code for this driver/firmware/etc under the > >> GPLv2 because the law says so." > > > > Sorry to tell you this, but anyone that makes a modification to GPLv2 > > covered code and distributes that modification is bound by the license. > > Of course I know that. I'm not the one making those arguments. > And then, not all of those pieces of code are indeed moficiations of > GPLv2-covered code, so your objection is off target. I had a parsing error with your statement. My mind made the jump to "they are doing it with GPLv2 code" - meaculpa. > >> > b) I think you're simply wrong in your math. I think more people > >> > like the middle-ground and not-frothing-at-the-mouth spirit of "open > >> > source" over the religious dogma of "free software". > >> > >> It looks like the math you're talking about is in no way related with > >> anything I've argued about. You seem to be thinking about the number > >> of people who claim to be on the "free software" or "open source" > >> sides, but I can't fathom in what way this is related with whether you > >> get more or less contributions from users as a consequence of users' > >> being permitted to tinker with the free software in their own devices. > > > > "More Developers" (either "Free Software" or "Open Source") == "More > > Contributions" > > > > That equation is very simple to understand - claiming its wrong is > > impossible. > > YES! Thank you! This is exactly the point I'm trying to make. > > Now can you please explain this to Linus in terms that his brain won't > dismiss as "coming from a fundamentalist"? No need. Linus already understands the equation, and also the secondary fact that most home users are not developers. However, companies like TiVO do employ developers. This is why the equation works. > > Apparently because you can't admit that a good reason *IS* a good reason > > when it conflicts with your belief that the FSF is correct. > > No, seriously. Linus is disputing the equation above, dismissing my > various attempts to show it to him, whenever it appears in teh context > of tivoization, apparently because it doesn't match his moral belief > that tivoization ought to be permitted on his moral grounds. Actually you are in error here. You are saying "More home users == More Developers" when the ratio of home users to developers isn't all that high. (small set of facts: "Hacker" == "Developer" (in most cases, where the term, as defined in the Jargon File, can actually be applied), "Home User" * 0.10 (ie: 10%) == "Developer" (approximately, and the correlation may be lower). "TiVO" == "Developers" (note the plural - they do employ more than one person for development)) So "TiVO", even though they are walking all over the freedoms you love, means more *guaranteed* developers than the potential pool from the users of their boxes. (the pool of potential developers among the millions of TiVO users is actually miniscule, despite the size of the sample) However, you do make a good argument. But when you look at the statistics[1] they don't hold water. > > PS: I know I've said I'm done with this conversation, but this is like a > > bad habit. I just couldn't help myself. > > You've helped me a lot while at that. Thanks! > > I hope this helps others fundamentalist anti-fundamentalists :-) see > reason too. I love that phrase! But seriously, all I did was stop trying to give fully reasoned counters (complete with examples) and state the simple truth. DRH [1] "There are three types of lies - lies, damn lies and statistics" - Attribution uncertain (Benjamin Disraeli, Mark Twain and Alfred Marshal are all said to have issued this famous quotation) PS: I've beaten the addiction! This post was to clarify some things that were either misunderstood or stood a chance of being twisted to mean something other than what I intended. (not that anyone did the latter) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: mea culpa on the meaning of Tivoization
On Monday 18 June 2007 22:57:20 Alexandre Oliva wrote: > On Jun 18, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Monday 18 June 2007 17:31:47 Alexandre Oliva wrote: > >> And if you look at GPLv3dd1 or dd2 IIRC, that's how it started. For > >> some reason, the FSF turned it into the more lax (in some senses) > >> installation information for user products in dd3. Maybe they decided > >> that the argument about the signature being effectively part of the > >> executable, and therefore the key being effectively part of the source > >> code, was less likely to be upheld in a court of law than this > >> alternate phrasing. All in all, the effect is the same AFAICT, and > >> the spirit is being complied with. > > > > But the change has some massive problems. > > Such as? Is the effect really any different? I haven't looked at it, in depth, today but one of the problems I saw was the apparent loopholes in the text. No specifics, but I remember thinking "a lawyer would have a field day with this - dozens of ways they could sidestep these issues" > > If dd1 or dd2 was clearly and concisely written such that the > > conditions were not open to a different interpretation without > > creative re-definition of words then changes would not be > > needed. (I'm still working on the version I mentioned - give me a > > bit, writing english in such a way that a lawyer can't twist it to > > mean whatever they are paid to make it mean is difficult.) > > It's very difficult and, worse, it might turn out to be unenforceable. > You'd have to count on signing keys being copyrightable, and they are > unlikely to be, and on signatures being derived works of both, which > is a tough call. The whole idea resonates very well with the spirit > of the license, but we need more than that, we need it to be very > likely to work. I suspect this is why the FSF has decided to take > another route to achieve the same (AFAICT) effect. Agreed. I'm still stuck trying to keep the language concise and understandable without delving into the descriptive flights of fancy I enjoy. (I write a lot more fiction than I do code, even though I started writing code a long time before I started on fiction) > >> I don't see how this is different from refraining from accepting > >> contributions under any other license, except that you can't use > >> license incompatibility to reason it out as an impossibility you > >> established for yourself in just the very same way. > > > > I think there was more to it than that, but the point doesn't > > matter. If the license used on contributed code *isn't* completely > > compatible with the license on the project it can't be used > > anyway. (doesn't the GPLv3 cover situations like that?) > > I'm not sure what you're asking. GPLv3 covers additional permissions, > that are really no different from dual-licensing, so anyone can choose > to drop them when combining with works (including their own) that > don't offer such additional permissions. What I was getting at, here, is that the GPLv3 isn't backwards compatible with GPLv2, because you aren't allowed to remove rights from the GPLv3. Remember, there are rights encoded in the GPLv3 that don't appear in v2. In fact, if you want to use GPLv3 code in a GPLv2 project you have to use GPLv3. For some projects, like the Linux Kernel, the upgrade is impossible to accomplish. > >> My objection was mainly about the "forcing". FSF's stance is about > >> educating users as to the moral and ethical reasons, such that they > >> reject non-Free Software, while at the same time providing software > >> authors with means to stop others from hurting users, by depriving > >> them of the freedoms they're morally entitled to have. > > > > Hrm... When I first hit the end of this massive sentence I was really > > confused. Took about five minutes for me to remember that "morally > > entitled" is based on the morals promoted by the FSF. > > Yes. And the 'them' after the last comma refers to the users, not the > authors (although they can be users too), in case it's not clear ;-) > > :-D Yes. I almost replied "-ENOPARSE" because, when I first read it, I parsed it as "by depriving [the authors] of the freedoms they're morally entitled to have". When my brain finally rebooted after that bought of idiocy I was able to parse it properly. DRH > > Everyone that has been part of this discussion - my personal code of > > morals will not let me get a
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 01:51:19 Alexandre Oliva wrote: > On Jun 19, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > The GPLv2 is the one that allows more developers. > > > > The GPLv2 is the one that is acceptable to more people. > > Based on my understanding that the anti-tivoization provisions are > *the* objectionable issue about GPLv3 for those of you who dislike > GPLv3, this is circular reasoning: > > anti-tivoization is bad > => we reject licenses with it > => there are fewer developers willing to develop with such licenses > => anti-tivoization is bad The logic is close to: => License forbids X => developer has requirement for X in license, can't add to project => License forbidding X is bad When it comes to TiVO the reason the developers "required" the "tivoization" was because the company itself demanded it. The reason: providers of the content their device works with demanded it. > > Face it, the "open source" crowd is the *bigger* crowd. > > I really don't know about that. I can believe it may be so in LKML. Actually, it is. Every "Free Software" developer that I personally know could care less about the FSF's motives - until they impact them. Since they don't care what the FSF does, publishes, etc... they cannot be termed "Free Software" developers (using the definition of the term "Free Software" provided by the FSF). In fact, almost all of them will state either: "I work on Open Source software" or "I develop FOSS stuff". > > I haven't really seen a single one. Last I did the statistic, I asked the > > top ~25-30 kernel developers about their opinion. NOT A SINGLE ONE > > preferred the GPLv3. > > Wow, that's a really big sample among all Free Software and Open > Source developers out there. And not even a little bit biased at > that. Yes, the sample could be considered "biased" - jst as a sample taken among the GCC developers could be considered "biased" towards the other end of the spectrum. > > So I have actual *numbers* on my side. What do you have, except for a > > history of not actually understanding my arguments? > > Which is worse, not understanding or repeatedly snipping out and > addressing unrelated points? It's time to quote a very ancient source: "Don't point out the speck in your neighbors eye when you cannot see the log in your own" In other words - you've done the same and more. > > Let's please try again. > > I'll try to keep it simple, since you can't seem to be able to grasp > the entire argument, and keep disregarding essential parts, disputing > unrelated points and jumping to the conclusions that you've disputed > the point I was trying to make. > > I'll present it in parts, as an attempt to stop you from making this > mistake, that I'm sure is not intentional. > > The first part is in this e-mail. > > > Dispute this: > > non-tivoized hardware => users can scratch their itches => more > contributions from these users > > tivoized hardware => users can't scratch their itches => fewer > contributions from these users Linus doesn't have to. Statistically the number of people that will even think of modifying the code running on a "tivoized" device is minute - at most 5% of the users of such a device. Of those people the ones with the skill to actually do the work is an even smaller number - figure 2.5 to 3% of them. Of those with the skill, probably about 10% of them are actually *good* enough at it for their changes to be useful. Of that number, figure that only 25%, at most, will contribute the changes back. Apply that to a sample case: "tivoized" device total users: 1,000,000 people that think about modifying: 50,000 (5%) people with skill: 1500 (3%) people who are good enough for the changes to be useful: 150 (10%) those who will contribute them back: 38 (25%) Now a normal companies software department is anywhere from 10 to 50 people. Large companies can employ more - IBM employs hundreds. What you are arguing is that people should abandon a firm set of developers that is proven to be large for the potential at adding, at most, 38 developers per million users of the device. If that number was more than 1000 per device I'd agree. The numbers don't support your argument. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: mea culpa on the meaning of Tivoization
On Tuesday 19 June 2007 02:10:02 Alexandre Oliva wrote: > On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > I haven't looked at it, in depth, today but one of the problems I > > saw was the apparent loopholes in the text. No specifics, but I > > remember thinking "a lawyer would have a field day with this - > > dozens of ways they could sidestep these issues" > > *Pretty* *please* file comments about the apparent loopholes at > gplv3.fsf.org/comments To do that I'd have to go back, take the time to re-read the GPLv3 *in* *depth*, think about each paragraph of each section individually... Like I said, I just got a general impression that a lawyer would have a field-day with it. > > What I was getting at, here, is that the GPLv3 isn't backwards > > compatible with GPLv2, > > It couldn't possibly be. The whole point of upgrading the GPL is such > that it complies better with its spirit of defending the freedoms, so > as to keep free software free. This can only be accomplished with > additional restrictions that stop practices that deny users' > freedoms. > > Relaxing the provisions, a necessary condition for compatibility, > wouldn't make for better defenses. > > > because you aren't allowed to remove rights from the GPLv3. Remember, > > there are rights encoded in the GPLv3 that don't appear in v2. > > I'm not sure what you mean by "rights" in the two sentences above. > You know you can grant additional permissions, so I assume that's not > what you mean, even more so because you *can* indeed take them out. > Is it "conditions", "restrictions" or some such, that in turn > translate into freedoms for downstream users, or is it about the > granted rights per se? Sorry, bad choice of words. There are "guarantees" encoded into every license. There are some encoded into the GPLv3 that aren't encoded into the GPLv2. You can't remove or restrict those guarantees without violating the license. And removing those guarantees would be the only way to make the GPLv3 fully compatible with the GPLv2. > > In fact, if you want to use GPLv3 code in a GPLv2 project you have > > to use GPLv3. For some projects, like the Linux Kernel, the upgrade > > is impossible to accomplish. > > Impossible is a bit too strong. I understand it would take a huge > amount of work though, so I sympathize with "it wouldn't be worth it", > even if, in my scale of moral values, I'd disagree. In this case I wasn't speaking literally. I should have been a lot more specific there - it should say "practically impossible". DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote: > On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 June 2007 01:51:19 Alexandre Oliva wrote: > >> On Jun 19, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> > The GPLv2 is the one that allows more developers. > >> > > >> > The GPLv2 is the one that is acceptable to more people. > >> > >> Based on my understanding that the anti-tivoization provisions are > >> *the* objectionable issue about GPLv3 for those of you who dislike > >> GPLv3, this is circular reasoning: > >> > >> anti-tivoization is bad > >> => we reject licenses with it > >> => there are fewer developers willing to develop with such licenses > >> => anti-tivoization is bad > > > > The logic is close to: > > > >=> License forbids X > >=> developer has requirement for X in license, can't add to project > >=> License forbidding X is bad > > I'm not sure it was clear that '=>' was meant as logical implication. > Read it as "therefore". > > It's actually funny that what your inference sequence (in spite of the > missing initial operand) rings so true about my impressions about some > of the reactions I'm getting here. > > GPLv3 forbids tivoization, therefore developer has requirement for > tivoization in the license, therefore GPLv3 forbidding tivoization > is bad. > > :-) However, my argument is straight logic, nothing "circular" about it. :) Replacing "X" in my logic path above with "tivoization" and "license" with "GPLv3", as you've done, does produce a valid chain of logic. > >> > I haven't really seen a single one. Last I did the statistic, I asked > >> > the top ~25-30 kernel developers about their opinion. NOT A SINGLE ONE > >> > preferred the GPLv3. > >> > >> Wow, that's a really big sample among all Free Software and Open > >> Source developers out there. And not even a little bit biased at > >> that. > > Sorry that I missed the markers. > > > Yes, the sample could be considered "biased" - jst as a sample taken > > among the GCC developers could be considered "biased" towards the > > other end of the spectrum. > > FWIW, I haven't taken such a sample, because I know my network of > contacts would likely make it statistically useless. I'd not try to > make an argument based on that. FWIW the Linux Kernel shouldn't be as homogeneous a population as it is. I'd expect it with an FSF run project, because they require copyright assignment in order to participate, but with a project like Linux, where everyone maintains the copyright to their contributions, should be a hell of a lot less homogeneous than Linus' numbers make it seem. > > Statistically the number of people that will even think of modifying > > the code running on a "tivoized" device is minute > > Wait a minute, these figures you made up are for the tivoized hardware > (no changes allowed to the GPLed software in it), or for the > non-tivoized hardware (changes allowed to the GPLed software in it)? Actually, any generic "TiVO"-like hardware - whether it is tivoized or not. Admittedly the numbers are significantly different for PC's (and other types of general purpose computing devices). > > those who will contribute them back: 38 (25%) > > Regardless of what you meant, this is 38 developers *on top* of > however many the company pays to work on that, unless you're jumping > the gun and spoiling the multi-part argument. 38ppm is a fairly small amount, regardless. > > What you are arguing is that people should abandon > > I'm not arguing any such thing. Where's any such argument above? > > At this point, I'm only comparing a tivoized device with a > non-tivoized device. Nothing but it. You've been making the argument the entire time you've been arguing that the "anti-tivoization" language in the GPLv3 is necessary. I think I'd rather see a guaranteed increase of developers - even if it is only 10 - rather than hoping that the potential pool of 38 actually follows through. Wouldn't you? DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote: > On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote: > >> GPLv3 forbids tivoization, therefore developer has requirement for > >> tivoization in the license, therefore GPLv3 forbidding tivoization > >> is bad. > > > > However, my argument is straight logic, nothing "circular" about it. :) > > Replacing "X" in my logic path above with "tivoization" and "license" > > with "GPLv3", as you've done, does produce a valid chain of logic. > > Yes. Isn't it funny though that tivoization became necessary as a > consequence of GPLv3 forbidding it? -ELOGIC It didn't become necessary as a result of the GPLv3 forbidding it. As I pointed out in text that was cut to keep the post short, there could be any number of reasons why "tivoization" is needed by the manufacturer. Other people have also pointed that out. This whole bit was to point out that you were inferring circular logic where none existed. > >> Wait a minute, these figures you made up are for the tivoized hardware > >> (no changes allowed to the GPLed software in it), or for the > >> non-tivoized hardware (changes allowed to the GPLed software in it)? > > > > Actually, any generic "TiVO"-like hardware - whether it is tivoized or > > not. > > So your claim is that a user's possibility to scratch her own itches > makes no difference whatsoever as to their amount of contributions she > is likely to make? Exactly. > Am I the only one who thinks this is utter nonsense? > > >> > those who will contribute them back: 38 (25%) > >> > >> Regardless of what you meant, this is 38 developers *on top* of > >> however many the company pays to work on that, unless you're jumping > >> the gun and spoiling the multi-part argument. > > > > 38ppm is a fairly small amount, regardless. > > Yes. And your estimates are way too low too, FWIW. Any reason why > you changed your mind as to the 10% before? That 10% was, IIRC, a reference to the potential number of "Hackers" that would own a TiVO. On thinking about it I realized that the number of hackers owning a TiVO would be vanishingly small because of "tivoization". So in this new set of numbers I dropped it entirely. ... crap I am tempted to respond to nastily has been cut ... > > I think I'd rather see a guaranteed increase of developers - even if > > it is only 10 - rather than hoping that the potential pool of 38 > > actually follows through. Wouldn't you? > > Yes. How does this relate with the piece of the argument I've > proposed so far, or the whole argument I've posted before? > > Answer: It doesn't. At all. You're just showing you didn't > understand the argument. Which shows why I have to explain it piece > by piece. Which suggests you shouldn't try to jump to conclusions. Wrong. Nobody here needs a "piece by piece" explanation. So, in the belief that you were intelligent enough to understand that, I was providing proof that refutes your argument entirely. With a situation as complex as what exists you can't split the argument into two and claim that, since "Argument A" is true in the "split" argument that it is true when the argument isn't split. This holds true for almost all real-world situations. Now, I am not enjoying the discussion anymore. I've asked once before - remove me from the CC list. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 13:06:17 Alexandre Oliva wrote: > On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote: > >> On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >> > On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote: > >> >> GPLv3 forbids tivoization, therefore developer has requirement for > >> >> tivoization in the license, therefore GPLv3 forbidding tivoization > >> >> is bad. > >> > > >> > However, my argument is straight logic, nothing "circular" about it. > >> > :) Replacing "X" in my logic path above with "tivoization" and > >> > "license" with "GPLv3", as you've done, does produce a valid chain of > >> > logic. > >> > >> Yes. Isn't it funny though that tivoization became necessary as a > >> consequence of GPLv3 forbidding it? > > > > -ELOGIC > > I see. Try 'modprobe logic', it worked for me years ago ;-) :-D Try using real logic rather than the logic of your religion. > > It didn't become necessary as a result of the GPLv3 forbidding it. > > Which is why I said it was funny, because your inference chain stated > *exactly* (with an implied "for the developers") that it did. > > Do you understand what an inference chain is? A => B, as in A implies > B, which can also be read as A therefore B if A is known to hold. Okay, since you want it in a specific language rather than as a set of bullet points (which is what I used the => for) Company X has requirement for restriction Y => License on product Z disallows restriction Y => Product Z loses Company X and the exposure use in their product gives => License on product Z is bad for the product Understandable now? > > there could be any number of reasons why "tivoization" is needed by > > the manufacturer. > > This claim is false. > > Tivoization is when hardware manufacturer takes copyleft software and > blocks updates by the user of the hardware. By that definition you are correct. > No single law so far has shown an example that even resembled to > mandate copyleft software, and no contract could possibly establish a > condition like this. No argument here. What I was stating is that are legal (and other reasons) why a company might have to lock down their software in a process similar to "Tivoization". > Therefore, this claim is false. Only when you define a term as specifically as you have done for "Tivoization". I should, perhaps, have used a different term - it would then have been patently true. Though, at that point, you would likely have argued that it wasn't "tivoization" > > This whole bit was to point out that you were inferring circular > > logic where none existed. > > There *is* circular logic is in place. > > The initial premise of this fallacy is that anti-tivoization is bad > for the project. > > This is used to conclude that licenses with such provisions should be > rejected. > > This is then used to conclude that there are fewer developers who > would develop under such licenses. > > Which is then used to conclude that anti-tivozation is bad for the > project. Your view of the logic is, in this case, flawed. It's more along the lines of what I've detailed above. Now, please, go away. You aren't doing your "religion" any good. In fact, you are damaging it - repeatedly. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 19:49:24 [EMAIL PROTECTED] wrote: > On Tue, 19 Jun 2007, Alexandre Oliva wrote: > > On Jun 19, 2007, [EMAIL PROTECTED] wrote: > >> remember, not all tivo models are locked down, > > > > Only the earliest that you can't find for sale any more, right? > > > >> as a result of watching the hacker groups I can safely say that the > >> lockdown has not blocked many users. it has slowed modification of the > >> hacks to new types of hardware, but not for very long. > > > > Well, then... What's the point *for* tivoization, again? To slow > > down the contributions? And that's good because...? > > no, the point is that while tivoization is not nessasarily the best thing > it's far better then the company useing propriatary code. > > delayed contributions are better then no contributions. > > David Lang This logic has been proven already. Apple used KHTML and KJS as the backend systems for Safari. While Safari was in development they held onto all their changes and modifications. When they released Safari, they contributed it all back, making both things better. Fact: KHTML and KJS are also the core of Apples "WebKit" and "WebCore" technologies - both KHTML and KJS are Open Source projects, making up a part of KDE. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Patch related with Fork Bobmbing Attack
On Wednesday 13 June 2007 07:34:09 Simon Arlott wrote:
> On Tue, June 12, 2007 18:32, Jan Engelhardt wrote:
> > On Jun 12 2007 10:04, Roland Dreier wrote:
> >> > +/*
> >> > + * following code does not allow Non Root User to cross its
> >> > process + * limit. it alerts administrator about fork bombing
> >> > attack and prevents + * it.
> >> > + */
> >> > if (atomic_read(&p->user->processes) >=
> >> > p->signal->rlim[RLIMIT_NPROC].rlim_cur) if (!capable(CAP_SYS_ADMIN) &&
> >> > !capable(CAP_SYS_RESOURCE) && - p->user !=
> >> > &root_user)
> >> > -
> >> > +p->user != &root_user) {
> >> > +if (printk_ratelimit())
> >> > +printk(KERN_CRIT"User with uid %d is
> >> > crossing its process
> >>
> >> limit\n",p->user->uid);
> >>
> >> > goto bad_fork_free;
> >> > +}
>
> Why does this need to be KERN_CRIT? You can't assume that every time a
> process limit is reached that it's a fork bomb.
I think the reasoning here is to alert the administrator(s) to the possibility
that somebody has just tried a fork-bomb. A better test, IMHO, would be to
check how fast the processes are being spawned and whether a large percentage
share the same parent. (Those two taken together would better spot most
fork-bombs, including the very simple types that are just a simple one-liner)
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote: > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Wed, 13 Jun 2007, Alan Cox wrote: > >> > find offensive, so I don't choose to use it. It's offensive because > >> > Tivo never did anything wrong, and the FSF even acknowledged that. The > >> > fact > >> > >> Not all of us agree with this for the benefit of future legal > >> interpretation. > > > > Well, even the FSF lawyers did, > > Or rather they didn't think an attempt to enforce that in the US would > prevail (or so I'm told). That's not saying what TiVo did was right, > and that's not saying that what TiVo did was permitted by the license. > Only courts of law can do that. Wrong! Anyone with half a brain can make the distinction. What TiVO did is entirely legal - they fully complied with the GPLv2. Note that what they *DON'T* allow people to do is run whatever version of whatever software they want on their hardware. They have that right - its the "Free Software Foundation" and the GPL - regardless of version - is a *SOFTWARE* license. TiVO never stopped people from copying, modifying or distributing the code - what they did was say "The code is GPL'd, the hardware is restricted" - ie: "You can do what you want with the code, but you can only run compiled version of it that we provide on our hardware". Why is that legal? Because TiVO produces the hardware and sells it to you with a certain *LICENSE* - because it does contain hardware covered under any number of patents. That license grants you the right to use the patents - in this case algorithms - provided you comply with the terms of the license. (Just like the GPL gives you the right to copy, modify and distribute GPL'd code as long as you comply with its terms) If you believe otherwise then you are sadly mistaken. Now stop parroting the FSF's worn and tired tripe. DRH PS: Looking at your .sig I guess maybe you can't do that without getting kicked out of the FSF-LA -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 19:35:41 Jörn Engel wrote: > On Wed, 13 June 2007 14:33:07 -0700, Linus Torvalds wrote: > > The beauty of the GPLv2 is exactly that it's a "tit-for-tat" license, and > > you can use it without having to drink the kool-aid. > > One could even add that "tit-for-tat" appears to be the best strategy > in game theory for continuous runs of the prisoners dilemma. At times I > wonder why game theory isn't taught in schools yet - it might shorten > discussions like these. > > Jörn With the sheer amount of sheeple[1] in the world (and on this list), I doubt anything could make these discussions any shorter. (While I hate thinking that sheeple are on this list, it is an unavoidable fact. (I had hoped I wouldn't find any sheeple here, as my favorite theory is that they are all "Fundamentalist Christians" like the "Creationist" fools)) DRH 1: Sheeple (n): People that act like sheep - ie: they cannot think or form opinions for themselves and always look to someone else for their thoughts and parrot the opinions of some "trusted" figure. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote: > > The fact is, Tivo didn't take those rights away from you, yet the FSF > > says that what Tivo did was "against the spirit". That's *bullshit*. > > Oh, good, let's take this one. > > if you distribute copies of such a program, [...] > you must give the recipients all the rights that you have > > So, TiVo includes a copy of Linux in its DVR. > > TiVo retains the right to modify that copy of Linux as it sees fit. > > It doesn't give the recipients the same right. > > Oops. > > Sounds like a violation of the spirit to me. > > Sounds like plugging this hole would retain the same spirit. Are you an idiot, or do you just choose to ignore all proof that doesn't fit your preconceived beliefs? TiVO gives you every right to the Linux kernel that they recieved. What they don't give you the right to do is use modified versions on their *HARDWARE* - which they have *NEVER* given you any rights to, except for "normal use". (And no, it isn't legal to put those 200G hard drives in your TiVO no matter what you think) > > In other words, GPLv3 restricts rights that do not need to be restricted, > > That's correct. They don't need to be restricted. The whole idea of > copyleft, implemented through the GPL, is not based on needs, but > rather on the wish to defend the freedoms established in the preamble > from those who would rather not respect them. > > Do you deny that TiVo prevents you (or at least a random customer) > from modifying the copy of Linux that they ship in their DVR? Exactly. They don't. What TiVO prevents is using that modified version on their hardware. And they have that right, because the Hardware *ISN'T* covered by the GPL. Do you understand that, or do I need to break out the finger-puppets next ? > Do you deny that they can still do it themselves? > > > Think of it this way: what if the GPLv3 had an addition saying "You can > > not use this software to make a weapon". > > This would make GPLv3 a non-Free Software license. > > But the GPLv3 last call draft doesn't say anything along these lines. > > You can use the software as much as you like, even in DVRs, and even > to implement DRM in them, as long as you respect the users' freedoms > to change and share the software. Per the GPLv3 (paraphrased), if it > is possible to install modified versions of the covered program in the > device, you must tell the recipient how to do it. Otherwise, the > freedom to modify the program is being too severely limited. And this unnaturally restricts the freedom of hardware manufacturers. If they add a custom, internal connector so a repair shop can restore the hardware to its *FACTORY* state then it is "possible to install modified versions", provided the person doing it has the specialized hardware needed. And this is what the FSF, RMS and yes, *YOU*, Alexandre, fail to realize - the GPL covers *ONLY* the software. It has *ZERO* legal standing when applied to hardware. Not even the most draconian of MS EULA's tries to apply itself to the hardware. In the case of 99% of the hardware targeted by the clause of the GPLv3 you elucidate on, the "ability to install modified versions of the software" was *NOT* intended for that use, nor was it intended for *ANYONE* *EXCEPT* trained service personell to have *ACCESS* to that functionality. Arguing otherwise is just idiotic - I have never found a piece of "high tech" hardware (like a TiVO) that was designed for the end-user to modify. (yes, installing a new version of the linux kernel is "modifying" the system) > And, in the particular case of TiVo, it's a case of distributing > incomplete source code, of refraining from including functional > portions of the source code. And? They distribute the kernel source - as they recieved it - in compliance with the GPL. Their additions - whether they be "modules" or just the UI - do not, necessarily, fall under the GPL. (Yes, there have been discussions about whether a kernel module is a derived work, but most of the time those discussions ended "Legally they aren't, even though I feel they should be") > > In other words, GPLv3 *restricts* peoples freedoms more than it > > protects them. > > While you look at it from the point of view of TiVo, who wants to be > free to prohibit people from modifying the workings of the device it > sells while it can still modify it itself, and it does that in order > to prohibit people from removing locks that stop them from doing > things they're legally entitled to do, I see a lot more prohibitions > than freedoms in what TiVo does. I don't understand why you'd stand > up for it. Is it more important that a single company be allowed to > impose prohibitions on others in order for its business model to work, > than to maintain the spirit of hacking and sharing that enabled Free > Software and Linux to flourish? What "Legally Entitled" things? And... You do realize that almost every difference
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 20:14:47 Neil Brown wrote: > On Wednesday June 13, [EMAIL PROTECTED] wrote: > > 1: Sheeple (n): People that act like sheep - ie: they cannot think or > > form opinions for themselves and always look to someone else for their > > thoughts and parrot the opinions of some "trusted" figure. > > I recommend that you avoid definitions like this. Using them simply > makes you appear to have a very poor understanding of your fellow > humans. > > "cannot" and "always" are absolutes that never apply (well, hardly > ever). In this case I gave a very hasty definition of the term, though it does fit very well. > In my experience, most people do think for themselves and do form > opinions about areas where they have an interest/ability, and tend to > follow trusted others in areas where they have less interest or > ability. Agreed. But those *aren't* "Sheeple". > The problem that I think you see is particularly the "parrot the > opinions" bit. When a person tries to argue a case based largely on > the opinion of someone else with little personal understanding, they > are in very risky territory. This is akin to 'fundamentalism' that > you also mentioned in your post. > > Accusing people of arguing opinions that are not their own may well be > appropriate. Accusing them of not be able to think is not. I never accused any specific person of either. I was making an observation about the general nature of humanity as I've observed it. A better definition of "Sheeple" would be "Someone who continually parrots some "trusted" figures opinion even when presented with proof that that opinion is in error. They also, generally, do not "think deeply" on any topic." And while I won't apologize to anyone that may have felt the "Sheeple" remark was directed at them, I will apologize for not taking more time to choose a better definition for the term originally. DRH > NeilBrown > - > 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/ -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote: > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote: > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote: > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > On Wed, 13 Jun 2007, Alan Cox wrote: > > > >> > find offensive, so I don't choose to use it. It's offensive > > > >> > because Tivo never did anything wrong, and the FSF even > > > >> > acknowledged that. The fact > > > >> > > > >> Not all of us agree with this for the benefit of future legal > > > >> interpretation. > > > > > > > > Well, even the FSF lawyers did, > > > > > > Or rather they didn't think an attempt to enforce that in the US would > > > prevail (or so I'm told). That's not saying what TiVo did was right, > > > and that's not saying that what TiVo did was permitted by the license. > > > Only courts of law can do that. > > > > Wrong! Anyone with half a brain can make the distinction. What TiVO did > > is entirely legal - they fully complied with the GPLv2. Note that what > > they *DON'T* allow people to do is run whatever version of whatever > > software they want on their hardware. They have that right - its the > > "Free Software Foundation" and the GPL - regardless of version - is a > > *SOFTWARE* license. ... > > The GPLv2 says: > > "For an executable work, complete source code means all the source code > for all modules it contains, plus any associated interface definition > files, plus the scripts used to control compilation and installation of > the executable." > > The question is whether this includes private keys. > Different people have different opinions regarding this issue. > > If "the complete source code" includes private keys, the GPLv2 requires > them to give any costumer the private keys. > > Fact is that Harald Welte did in several cases successfully convince > vendors that private keys are part of the source code if they are > required for running the compiled binary on some hardware. If the hardware was designed for the end-user to change the software running on it - including running software that it was never meant to run (ie: a complete webserver on cell phone) - then yes, the signing keys are a part of the source, as the software running on the device is designed to be updated by the user using the provided system. If, on the other hand, the only "software updates" the user is expected to perform are the installation of newer versions of the existing code for "Security" or "Bug Fix" reasons then the signing keys aren't part of the source. I haven't looked into what Harald Welte did, but I'd be surprised if someone tried following suit in America and had as much success. > > AFAIK there haven't been any court rulings on this issue, and it could > even be that courts in different countries will decide differently. Agreed. DRH > > cu > Adrian -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 20:55:52 Alexandre Oliva wrote: > On Jun 13, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote: > >> if you distribute copies of such a program, [...] > >> you must give the recipients all the rights that you have > >> > >> So, TiVo includes a copy of Linux in its DVR. > > > > And they give you the same right that they had, which is obtain free > > software that you can modify and redistribute. There's nothing in there > > that says they should give you the tools they used after they received > > the software, which is what you seem to be looking for. > > Can they modify the software in their device? > > Do they pass this right on? But this *ISN'T* a right that the GPLv2 *REQUIRES* be passed on. > >> TiVo retains the right to modify that copy of Linux as it sees fit. > >> > >> It doesn't give the recipients the same right. > > > > It does, can't you modify their kernel source? > > It's not the kernel source. That's not where the TiVo anti-tampering > machinery blocks modifications. > > It's about that copy of the kernel that ships in the device in object > code. That's the one that TiVo customers ought to be entitled to > modify, if TiVo can modify it itself. The GPLv2 makes no real provision for *DIRECTLY* modifying object code. What provisions the GPLv2 has apply to the source code. And no, the end user *SHOULD* *NOT* be entitled to run whatever kernel they like on a TiVO. It was designed with the "install new kernel" functionality so that the TiVO corporation could update the kernel running on the hardware when security problems came up, when bugs were fixed or even when the new version gives better performance. > > Where does it say you should be able to run you modifications on the > > same hardware? > > Where it says that you should pass on all the rights that you have. > > While TiVo retains the ability to replace, upgrade, fix, break or make > any other change in the GPLed software in the device, it ought to pass > it on to its customers. It *DOES* *NOT* say "All rights that you have". It says "All rights that are granted you by this license". If every piece of software released under the GPL had *ALL* rights passed on, then *ANYONE* could do the "I'm granting company X the right to use this software outside the GPL for $50,000USD." instead of just the *creator* of the software. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 21:04:42 Alexandre Oliva wrote: > On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > Now stop parroting the FSF's worn and tired tripe. > > Are you playing Linus' sheeple and parroting his lines just to make a > point, or are you like that all the time? ;-) Nope. I'm just tired of giving proof after proof that you're wrong and having you restate the same tripe. > > PS: Looking at your .sig I guess maybe you can't do that without getting > > kicked out of the FSF-LA > > Don't worry, I'm not speaking even for FSFLA, and I'm entitled to my > own opinion. Certainly. I never said otherwise. What I stated and then *implied* was that you are repeating the same false logic over and over again trying to make people believe that it isn't borked and that that false logic is exactly the same crap I've seen from the FSF numerous times. > I haven't consulted other FSFLA members about this. This is all my > own personal opinion. Where I am examining the facts and drawing a logical conclusion. That it happens to form an opinion is secondary to the truth. > It just so happens that I'm very closely involved in the process, I've > spent a lot of time thinking about it, and I happen to share a similar > moral and ethical background with others involved in the process, so I > arrive at similar conclusions. Okay. Still doesn't explain why you have argued that the GPLv3 doesn't attempt to cover hardware and then provide proof that it does. > And then, I influence the process myself, so it's not like some of the > arguments I brought up here weren't taken into account while creating > the GPLv3, and adopted by its other proponents. This is no surprise - I had a feeling this was the truth. Not that it changes my opinion at all. As I've said, I have never liked the GPL at all, but v2 is the best that exists - even though I've put together custom licenses myself, none of them have had the number of lawyers look at them that the GPLv2 has had. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 21:16:19 Alan Cox wrote: > > > Only courts of law can do that. > > > > Wrong! Anyone with half a brain can make the distinction. What TiVO did > > is > > Maybe half a brain can, but anyone with a whole brain can assure you its > a bit more complex and you are wrong.. > > > version of it that we provide on our hardware". Why is that legal? > > Because TiVO produces the hardware and sells it to you with a certain > > *LICENSE* - > > The keys required to make the code run with the hardware are part of the > software. The license requires the software and relevant scripts etc are > included. Thus there is a very good argument that the keys are part of > the software. Good argument, but I'll stand by my interpretation of the law, the GPL and the situation until there is solid proof that a signing-key is part of the source code. Doubly so because the language of the GPLv2 makes it clear that "all relevant scripts, etc" are only needed to build and run the "covered work" - not for proper installation of it. (and, in the case of a TiVO, the signing keys are part of the installation, not the running or building. Besides needing the proper signing key, the kernel in a TiVO is run the same as any other Linux kernel) > And since there is no court ruling to high enough level in the USA, UK or > any other jurisdiction on that it remains a matter of opinion. > > Tivo may control the hardware but the authors control the software (via > the GPL), and subject to the limits of what may be specified by a > copyright license (as opposed to contract) can make such demands as they > see fit about their software and anything derivative of it. Agreed. However, AFAICT, TiVO meets the provisions of the GPLv2 - they make the source of the GPL'd part of their system available. (And I'm not going to get into arguments over whether kernel modules are "derivative works" or not, since those invariably end up with "They aren't, even though we think they should be") > > because it does contain hardware covered under any number of patents. > > That license grants you the right to use the patents - in this case > > algorithms - > > You can't patent algorithms either Then explain the patents on the MP3 algorithm, the LZW algorithm, etc... Those patents are real and while the LZW one may have lapsed, still relevant. DRH > Alan -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote: > On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote: > > On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote: > > > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote: > > > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote: > > > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 13 Jun 2007, Alan Cox wrote: > > > > > >> > find offensive, so I don't choose to use it. It's offensive > > > > > >> > because Tivo never did anything wrong, and the FSF even > > > > > >> > acknowledged that. The fact > > > > > >> > > > > > >> Not all of us agree with this for the benefit of future legal > > > > > >> interpretation. > > > > > > > > > > > > Well, even the FSF lawyers did, > > > > > > > > > > Or rather they didn't think an attempt to enforce that in the US > > > > > would prevail (or so I'm told). That's not saying what TiVo did > > > > > was right, and that's not saying that what TiVo did was permitted > > > > > by the license. Only courts of law can do that. > > > > > > > > Wrong! Anyone with half a brain can make the distinction. What TiVO > > > > did is entirely legal - they fully complied with the GPLv2. Note that > > > > what they *DON'T* allow people to do is run whatever version of > > > > whatever software they want on their hardware. They have that right - > > > > its the "Free Software Foundation" and the GPL - regardless of > > > > version - is a *SOFTWARE* license. ... > > > > > > The GPLv2 says: > > > > > > "For an executable work, complete source code means all the source code > > > for all modules it contains, plus any associated interface definition > > > files, plus the scripts used to control compilation and installation of > > > the executable." > > > > > > The question is whether this includes private keys. > > > Different people have different opinions regarding this issue. > > > > > > If "the complete source code" includes private keys, the GPLv2 requires > > > them to give any costumer the private keys. > > > > > > Fact is that Harald Welte did in several cases successfully convince > > > vendors that private keys are part of the source code if they are > > > required for running the compiled binary on some hardware. > > > > If the hardware was designed for the end-user to change the software > > running on it - including running software that it was never meant to run > > (ie: a complete webserver on cell phone) - then yes, the signing keys are > > a part of the source, as the software running on the device is designed > > to be updated by the user using the provided system. > > > > If, on the other hand, the only "software updates" the user is expected > > to perform are the installation of newer versions of the existing code > > for "Security" or "Bug Fix" reasons then the signing keys aren't part of > > the source. > > Are you an idiot, or do you just choose to ignore all proof that doesn't > fit your preconceived beliefs? Nope. Merely stating a distinction. Either a device is distributed, like the common PC, that is designed for the user to change and update the software on, or, like the PS2 it isn't designed for that. If I find a way to update my PS2 to run Linux and find that it doesn't want to start the "Linux Firmware" because I'm lacking a signing key... In the case of a device that internally runs Linux (or any other GPL'd software) and wasn't designed for the end-user to change the software running on it then the signing keys aren't part of the source. OTOH, if I sell a PC running Linux that requires the kernel be signed then the signing keys *are* part of the source, since a PC is designed for the end-user to change the software running on it. BTW, nice use of irony with that line. Makes me regret letting my fingers get ahead of my brain. > The GPL doesn't give someone distributing the software the choice of how > much to limit the freedom of the user. Never claimed it did. I just wasn't as specific as I should have been when giving my examples. > Either private keys required to run the kernel on the hardware are > always considered part of "the complete
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 22:08:27 Adrian Bunk wrote: > On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote: > > On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote: > > > On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote: > > > > On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote: > > > > > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote: > > > > > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote: > > > > > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > On Wed, 13 Jun 2007, Alan Cox wrote: > > > > > > > >> > find offensive, so I don't choose to use it. It's > > > > > > > >> > offensive because Tivo never did anything wrong, and the > > > > > > > >> > FSF even acknowledged that. The fact > > > > > > > >> > > > > > > > >> Not all of us agree with this for the benefit of future > > > > > > > >> legal interpretation. > > > > > > > > > > > > > > > > Well, even the FSF lawyers did, > > > > > > > > > > > > > > Or rather they didn't think an attempt to enforce that in the > > > > > > > US would prevail (or so I'm told). That's not saying what TiVo > > > > > > > did was right, and that's not saying that what TiVo did was > > > > > > > permitted by the license. Only courts of law can do that. > > > > > > > > > > > > Wrong! Anyone with half a brain can make the distinction. What > > > > > > TiVO did is entirely legal - they fully complied with the GPLv2. > > > > > > Note that what they *DON'T* allow people to do is run whatever > > > > > > version of whatever software they want on their hardware. They > > > > > > have that right - its the "Free Software Foundation" and the GPL > > > > > > - regardless of version - is a *SOFTWARE* license. ... > > > > > > > > > > The GPLv2 says: > > > > > > > > > > "For an executable work, complete source code means all the source > > > > > code for all modules it contains, plus any associated interface > > > > > definition files, plus the scripts used to control compilation and > > > > > installation of the executable." > > > > > > > > > > The question is whether this includes private keys. > > > > > Different people have different opinions regarding this issue. > > > > > > > > > > If "the complete source code" includes private keys, the GPLv2 > > > > > requires them to give any costumer the private keys. > > > > > > > > > > Fact is that Harald Welte did in several cases successfully > > > > > convince vendors that private keys are part of the source code if > > > > > they are required for running the compiled binary on some hardware. > > > > > > > > If the hardware was designed for the end-user to change the software > > > > running on it - including running software that it was never meant to > > > > run (ie: a complete webserver on cell phone) - then yes, the signing > > > > keys are a part of the source, as the software running on the device > > > > is designed to be updated by the user using the provided system. > > > > > > > > If, on the other hand, the only "software updates" the user is > > > > expected to perform are the installation of newer versions of the > > > > existing code for "Security" or "Bug Fix" reasons then the signing > > > > keys aren't part of the source. > > > > > > Are you an idiot, or do you just choose to ignore all proof that > > > doesn't fit your preconceived beliefs? > > > > Nope. Merely stating a distinction. Either a device is distributed, like > > the common PC, that is designed for the user to change and update the > > software on, or, like the PS2 it isn't designed for that. If I find a way > > to update my PS2 to run Linux and find that it doesn't want to start the > > "Linux Firmware" because I'm lacking a signing key... > > > > In the case of a device that internally runs Linux (or any other
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 22:04:04 Alexandre Oliva wrote: > On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > Still doesn't explain why you have argued that the GPLv3 doesn't > > attempt to cover hardware and then provide proof that it does. > > It doesn't cover hardware, in the same way that it doesn't cover > patents, and it doesn't cover pro-DRM laws. It merely arranges, as > best as we've managed a copyright license to do, that they can't be > used as excuses (or tools) to disrespect the freedoms that the GPL > demands all licensees to respect for other users. Consider this scenario: Small company A is manufacturing a new WiFi router. They decide to have it run HURD as the OS. In complying with the GPLv3 they supply the signing keys and everything else needed to install a new kernel on the hardware. User B buys the router and modifies the kernel so it drives the WiFi to an output power twice that which it is licensed to carry. FCC finds out and prosecutes User B for violating the regulations. FCC then pulls the small companies license until they change their hardware so the driver can't push it to transmit at a higher power level and levies a fine. Small company A loses the money paid on the fine, has to recall all the devices that can be modified (through software) to break the law at a massive cost *AND* has to redesign their hardware. The total cost drives the company into bankruptcy. Small companies C,D and E, in order to avoid the fate of small company A, purchases a license for proprietary OS "F" to drive their new hardware. Net loss: A lot of the users and publicity that "Free Software" used to get, because GPLv3 contains language that opens the companies to lawsuits that they wouldn't otherwise face. Which is better: Growing the base of installed GPL covered software, or "ethics and morals" that demand the language that has been added to the GPLv3 ? Personally I'd like to see proprietary software driven into a very small "niche" market or entirely out of existence. However much I want this to happen, I cannot be anything *BUT* scared of the GPLv3 simply because I see it creating massive problems - and all because of a *small* portion of the new language it contains. It has taken almost 15 years for "Free Software" to make a dent in the market, and, IMHO, a lot of that is both Linux and the "holes" in GPLv2. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: > On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote: > > > > Exactly. They don't. What TiVO prevents is using that modified version on > > their hardware. And they have that right, because the Hardware *ISN'T* > > covered by the GPL. > > Indeed, TiVO has this legal right. But then they must not use > software under the GPLv3 in it. And, arguably, they must not use > software under the GPLv2 either. Yes. It can be argued. But I cannot find *ANYTHING* in the GPLv2 that stops anyone from doing that, unless you add extra meaning to one specific clause. (And I am willing to admit that *MOST* people do give it that extra meaning) > > In the case of 99% of the hardware targeted by the clause of the GPLv3 > > you elucidate on, the "ability to install modified versions of the > > software" was *NOT* intended for that use, nor was it intended for > > *ANYONE* *EXCEPT* trained service personell to have *ACCESS* to that > > functionality. Arguing otherwise is just idiotic - I have never found a > > piece of "high tech" hardware (like a TiVO) that was designed for the > > end-user to modify. (yes, installing a new version of the linux kernel is > > "modifying" the system) > > It's about time for a change for better, wouldn't you think? I've never had a reason to want to change the way any device like a TiVO works. So I can't comment on this. > In 95% of the desktop computers, you can't make changes to the OS that > runs on it. Whom is this good for? Faulty logic. I have yet to find a computer that I couldn't change the OS on. I have run Linux on 3 different Mac's, every x86 machine I've ever owned and even had it running on my Palm. Whats more is that I have *never* heard of a person that knows what they are doing not being able to change the OS on a desktop computer. > > And? They distribute the kernel source - as they recieved it - in > > compliance with the GPL. > > This makes it seem like you think that passing on the source code is > enough to comply with the GPL. Check your assumptions. It's not. Hrm. Strange, but thats what most companies think. Hell, it even says that you have to do just that in the GPL. If you're talking about the fact that it can be argued that they are "distributing" Linux by selling their boxes and its a modified version then I'll agree with you. > >> to prohibit people from removing locks that stop them from doing > >> things they're legally entitled to do > > > > What "Legally Entitled" things? > > Time shifting of any shows, creating copies of shows for personal use, > letting others do so. Think fair use, and how TiVO software and DRM > in general gets in the way. I thought that time shifting and creating personal copies was what the TiVO did already. Or do you mean "transferring the recorded copies off the TiVO and on to a different medium"? If that is what you mean by "Creating Copies" then, IIRC, you're wrong. DRM, I do agree, gets in the way of "Fair Use". > > And... You do realize that almost every difference between the GPLv2 > > and the GPLv3 is going to cause a hell of a lot of problems? > > For those who are not willing to abide by the spirit of the license, > yes. Does it look like I'm concerned about them? If they're willing > to look for and maybe even find holes in the license to disrespect > users' freedoms, why should I worry about the problems that plugging > these holes is going to cause them? If they'd taken the spirit of the > GPL for what it is, instead of looking for loopholes, this improved > wording wouldn't be causing them any problems whatsoever. Okay. So you're not concerned that you're potentially pushing companies that would otherwise be major consumers of GPL'd software away? That doesn't make sense to me. > > The fact that the GPLv3 is designed to prevent things that RMS > > *PERSONALLY* finds distasteful - DRM and the like - is a big > > turn-off for a *LOT* of people. > > This is a pretty sad accusation. 2/3s of the Free Software packages > use the GPL with its existing spirit, and you still haven't shown that > any changes proposed in GPLv3 fail to abide by the same spirit. That > some (many?) people misunderstood or disregarded the spirit is an > unfortunate fact, but trying to pose the patching that's going into > GPLv3 as if it was a matter of personal taste, rather than improved > compliance with the spirit, is unfair and uncal
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wednesday 13 June 2007 22:56:40 Adrian Bunk wrote: > On Wed, Jun 13, 2007 at 10:43:14PM -0400, Daniel Hazelton wrote: > > On Wednesday 13 June 2007 22:08:27 Adrian Bunk wrote: > > > On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote: > > > > On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote: > > > >... > > > > > > > Either private keys required to run the kernel on the hardware are > > > > > always considered part of "the complete source code" or they are > > > > > never part of it. > > > > > > > > No. It all depends on the use-case. If the hardware is designed for > > > > the user to install their own, custom versions of the code on then > > > > the signing keys are part of the source as defined by the GPLv2. > > > > > > > > If, OTOH, the hardware was never meant for the end-user to install > > > > custom versions of the software on, then while the signing keys are > > > > still *technically* part of the source, in practice they are not. > > > > Why? Because in most of those cases the end-user isn't granted the > > > > right to install and run custom binaries on the hardware. If the > > > > manufacturer provided the signing keys they'd be facilitating the > > > > commission of a crime. (call it "Breach of Contract") > > > >... > > > > > > Repetition doesn't let wrong things become true. > > > > > > Where does the GPLv2 talk about the distinction you are trying to make > > > based on distributor intentions? > > > > > > We are talking about the GPLv2 licence text, not about what you would > > > personally prefer. > > > > The GPLv2 doesn't have to cover this distinction to make it a reality. > > This distinction is *EXACTLY* the type of distinction a lawyer will make > > when arguing the point. > >... > > Reality check: > > Harald convinced companies that they have to provide the private keys > required to run the Linux kernel they ship on their hardware. In Germany, not America. I should have qualified my statement to make it clear I mean "In America". Sorry about the confusion. DRH > > cu > Adrian -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:51:13 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > I've never had a reason to want to change the way any device like a TiVO > > works. So I can't comment on this. > > Have you never wanted to improve any aspect of the software in your > cell phone? In your TV, VCR, DVD player, anything? In the microwave > oven, maybe? Nope. I've been tempted several times, but decided that the extra bits I'd thought about wouldn't add anything to the device. > > On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: > >> In 95% of the desktop computers, you can't make changes to the OS that > >> runs on it. Whom is this good for? > > > > Faulty logic. I have yet to find a computer that I couldn't change the OS > > on. > > I was not talking about installing another OS, I was talking about > making changes to the OS. As in, improving one particular driver, > avoiding a blue screen, stuff like that. Ah, well... In the case of "Windos" and other proprietary OS's I try to educate people and get them to switch. I don't, personally, have any computers that run Windows (and I switched my Palm back to PalmOS because it wasn't getting the same performance under Linux - which rather surprised me. And rather than fight with it I just switched it back. > > Or do you mean "transferring the recorded copies off the TiVO > > and on to a different medium"? > > Sure. Such that I can watch shows while wasting time in public > transportation, in an airplane, whatever. Under the US Copyright law I'm not sure that making a "second copy" like that is legal. IIRC, "Fair Use" only allows for one copy. > > DRM, I do agree, gets in the way of "Fair Use". > > And the fact that TiVO can be, and has been modified remotely to add > restrictions on what users could do, means nothing you do with it is > safe. You, and everything you've recorded with the TiVO, are at the > mercy of this one company. As has been noted in their TOS and the licenses for the hardware from the start. The FSF itself explicitly reserves the right to change the GPL at any time - which is no different. (when you remove all the bits explaining the purpose of the license) > > So you're not concerned that you're potentially pushing companies > > that would otherwise be major consumers of GPL'd software away? That > > doesn't make sense to me. > > What would their consuming GPL software buy us, if they won't respect > users' freedoms, which is the very reason behind the GPL? I'm not referring to companies that are embedding GPL'd software in their products. The companies I'm referring to are the ones that would like to use GPL'd software internally. A lot of them would probably have private modifications that would never be distributed - and under the GPLv2 it is clear that you can keep modifications private as long as you don't distribute them. "Pushing them away" means that they'd not do that because they would be concerned that the license will change under them in such a way that even those private modifications need to be released to the public. (and don't try to argue that even though those modifications are truly private (to the company) they should be released anyway to comply with the "spirit" of the license. It is made clear that it isn't by the text of the license itself) > Heck, if they don't want to play by the rules, that's up to them. But > then they shouldn't use the software at all. > > Yeah, I wish they'd rather play by the rules, but if they don't want > to, too bad, for us and for them. > > > Why should I repeat Linus' explanation of the ways that GPLv3 violates > > the spirit of GPLv2? > > Don't worry about parrotting here, he hasn't provided that explanation > yet ;-) Please give it a try. But he has. Whether you have accepted that his explanations are valid or not doesn't change the fact. > BTW, what license is Linux licensed under? It's GPLv2 plus userland > exception, right? (There's some additional module exception, right?) The kernel itself is GPLv2 (only). Individual components - even individual files - have other licenses or retain the "any later version" clause. (Someone pointed out, earlier in this thread, that there is GPLv1.1 code in the kernel) > > And why shouldn't I pose it as a matter of "Personal Taste"? The > > biggest and most powerful voice in the FSF says "I don't like > > Tivoization" and "I don't like DR
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:39:13 Michael Gerdau wrote: > > In Germany, not America. I should have qualified my statement to make it > > clear I mean "In America". Sorry about the confusion. > > You shouldn't say "America" when you mean the "US". Sorry, I slipped. I'm still trying to rid myself of the uniquely "US" belief that "America" == "USA". Thanks for the reminder. DRH > > Best wishes, > Michael -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 02:36:12 Alexandre Oliva wrote: > On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Thu, 14 Jun 2007, Adrian Bunk wrote: > >> "For an executable work, complete source code means all the source code > >> for all modules it contains, plus any associated interface definition > >> files, plus the scripts used to control compilation and installation of > >> the executable." > >> > >> The question is whether this includes private keys. > > > > No. That's the question as the FSF would like to frame it. > > No. The FSF actually does *not* want to take this position. That's > why it chose the formulation of Installation Instructions. It doesn't > share my view that the keys needed to sign a binary in order for it to > work are part of the source code. > > > And you could actually replace their copy of Linux with another one. It > > would have to have the same SHA1 to actually start _running_, but that's > > the hardware's choice. > > That's the hardware imposing a restriction on modification of the > software. It doesn't matter how elaborate the excuse is to justify > denying users' freedoms: it's against the spirit of the GPL, and the > GPL will be amended as needed to plug such holes. And? There is *absolutely* *nothing* in any version of the GPL *prior* to 3 that says that hardware cannot impose restrictions. What the GPL *does* say is that you can't "add additional restrictions to the license" - (IMHO) a piece of hardware having a restriction isn't an "additional restriction added to the license". As well, as Linus stated, there is nothing *anywhere* - AFAICT, not even in GPLv3 - that says that you have to be able to run the software "in place" or "on the same hardware". If a hardware manufacturer - like TiVO - uses GPL'd code in their product - and complies with the terms of the license - they aren't required to allow you to run modified code on that hardware. Without it mentioned anywhere in the GPL *OR* the assorted writings of RMS (who founded the FSF and wrote the original GPL) that "modified software must be able to run on the same hardware" then it cannot be in the "spirit" of the license to allow this. > > So take another example: I obviously distribute code that is copyrighted > > by others under the GPLv2. Do I follow the GPLv2? I sure as hell do! But > > do I give you the same rights as I have to modify the copy on > > master.kernel.org as I have? I sure as hell DO NOT! > > That's an interesting argument. > > People don't get your copy, so they're not entitled to anything about > it. > > When they download the software, they get another copy, and they have > a right to modify that copy. But you get the TiVO corporations copy of the software? I smell a logical fallacy here, but can't remember the name for it. > > And here's a big clue for people: anybody who thinks that I'm violating > > the GPLv2 by not giving out my private SSH key to master.kernel.org is a > > f*cking moron! > > Agreed, except I'd probably use a lighter term. > > > See any parallels here? Any parallel to a CD-ROM distribution, or a Tivo > > distribution? > > Yes. You see how TiVO is different? It is modifyable, and I actually > receive the copy that TiVO can still modify, but I can't. I don't. You don't get the TiVO corporations copy of the software. You get your own copy, with all the rights that TiVO had when receiving the software. The right to install and run the kernel in the TiVO device is independent of the rights to copy, modify, distribute and run the software. (because the GPL never guarantees you the right to run the software on a particular piece of hardware.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 03:11:45 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 01:51:13 Alexandre Oliva wrote: > >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >> > On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote: > >> >> In 95% of the desktop computers, you can't make changes to the OS > >> >> that runs on it. Whom is this good for? > >> > > >> > Faulty logic. I have yet to find a computer that I couldn't change the > >> > OS on. > >> > >> I was not talking about installing another OS, I was talking about > >> making changes to the OS. As in, improving one particular driver, > >> avoiding a blue screen, stuff like that. > > > > Ah, well... In the case of "Windos" and other proprietary OS's I try to > > educate people and get them to switch. > > Good. So I presume you'd tell them to switch away from a > turned-proprietary GNU/Linux operating system as well, right? If that happened I'd be lost. I've tried the various BSD's and found they had problems with hardware support and getting a new version of the BSD kernel to compile and boot is something of a black art. The point is moot, though. It can never happen. > So, again, what do we gain if companies abuse the GPL and disrespect > users' rights that we meant them to respect? > > >> > Or do you mean "transferring the recorded copies off the TiVO > >> > and on to a different medium"? > >> > >> Sure. Such that I can watch shows while wasting time in public > >> transportation, in an airplane, whatever. > > > > Under the US Copyright law I'm not sure that making a "second copy" > > like that is legal. IIRC, "Fair Use" only allows for one copy. > > Even if you delete the "first copy"? > > Actually, I thought fair use in US entitled you to make a backup copy. > So the copy in your TiVO would be your original, and the external copy > would be your fair-use backup. Hrm... Perhaps. > > As has been noted in their TOS and the licenses for the hardware from the > > start. > > If it is used to disrespect the inalienable freedoms associated with > the GPL software in the device, it seems like a license violation to > me. As much as the US "Declaration of Independence" and other sources want people to believe otherwise there is no such thing as "inalienable rights" or "inalienable freedoms". In this case I have been unable to find this "inalienable freedom" to run custom versions of software "on the same machine" that you received the original copy on anywhere before the GPLv3 - and even then it isn't explicitly clear. There is no restriction on your right to modify, copy, distribute or run the software as provided by versions of the GPL prior to version 3. If this "run modified copies on the same hardware you received the original on" *IS* the "spirit" of the license, then why isn't it stated anywhere before GPLv3? (After all, the FSF has have 20+ years to mention it) > > The FSF itself explicitly reserves the right to change the GPL at any > > time - which is no different. > > Actually, it's completely different. > > If the FSF revises the GPL, the old version remains available for > anyone to use for any new software, and all software released under > the old version remains available under that old version. I'll grant you that. But, at this point, where can I find a copy of the GPLv1 without having to dig around the net ? > In contrast, your TiVO may get a software upgrade without your > permission that will take your rights away from that point on, and > there's very little you can do about it, other than unplugging it from > the network to avoid the upgrade if it's not too late already. And because its a device that connects to their network - and TiVO isn't a telecommunications company - they have the right to upgrade and configure the software inside however they want. (In the US at least) > > A lot of them would probably have private modifications that would > > never be distributed - and under the GPLv2 it is clear that you can > > keep modifications private as long as you don't distribute them. > > Likewise with GPLv3. I can see this, but will a company see this? > > "Pushing them away" means that they'd not do that because they would > > be concerned that the license will change under them in such a way > > that even those private modifications n
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 04:37:55 Bernd Petrovitsch wrote: > On Wed, 2007-06-13 at 23:38 -0300, Alexandre Oliva wrote: > > On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > > On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote: > > > > > > Exactly. They don't. What TiVO prevents is using that modified version > > > on their hardware. And they have that right, because the Hardware > > > *ISN'T* > >^^ > BTW as soon as I bought that thing, it is *my* hardware and no longer > *theirs* (whoever "theirs" was). eh. Perhaps I should have said that differently. And TiVO could handle it differently. I'm not going to argue about it anymore. It's pointless. > > > covered by the GPL. > > > > Indeed, TiVO has this legal right. But then they must not use > > Do they? At least in .at, it is usually impossible to (legally) limit > the rights of the *owner* a (tangible) thing (and if I bought it, I *am* > the owner and no one else) - even if you put it in the sales contract > since this is discussion about/within sales law. > > One usual example is "you buy a car and neither the car producer nor the > (re)seller can restrict the brands of the tires you may use or the brand > of the fuel etc.". No argument there. However, that is not to say that "you bought it, now you're free to do with it whatever you please" is always what the law says (at least in the US) In the TiVO case there may be restrictions placed on the manufacturer for legal reasons or contractual reasons. Seeing as I'm not privy to the contracts between TiVO and the various production and broadcasting companies I can't comment on what contracts they have. As to the legal side there are restrictions in copyright law. > And the same holds for pretty much everything. No one can forbid you to > open a TV set and fix it (or let it fix by whoever I choose to). I know of at least one company that will sell you the parts to repair your TV if its out of warranty. DRH > Yes, there are exceptions in several laws for specific things (e.g. for > really dangerous ones like airbags in cars) but in general, you are > allowed to do almost anything (including the simple destruction of it). > > And yes, if you *rent* the thing, you are not the owner and this is a > totally different thing. > > > software under the GPLv3 in it. And, arguably, they must not use > > software under the GPLv2 either. > > Bernd -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 11:20:34 Adrian Bunk wrote: > On Thu, Jun 14, 2007 at 12:00:17AM -0400, [EMAIL PROTECTED] wrote: > > On Thu, 14 Jun 2007 04:56:40 +0200, Adrian Bunk said: > > > Reality check: > > > > > > Harald convinced companies that they have to provide the private keys > > > required to run the Linux kernel they ship on their hardware. > > > > No, the *real* reality check: > > > > The operative words here are "convinced companies" - as opposed to > > "convinced a judge to rule that private keys are required to be > > disclosed". (I just checked around on gpl-violations.org, and I don't see > > any news items that say they actually generated citable case law on the > > topic of keys...) > > > > Harald convinced companies that it was easier/cheaper/faster to provide > > the private keys than to continue in a long legal battle with an > > uncertain outcome. If the company estimates the total loss due to keys > > being released is US$100K, but the costs of taking it to court are > > estimated at US$200K, it's obviously a win (lesser loss, actually) for > > the company to just fold. > >... > > Here in Germany, the rules at court are roughly "the loser pays > everything including the costs of the winner", so if a big company is > sure they will win at court there's no reason not to go there. > > And if they did the effort of using private keys to only allow running > an official firmware, they must have seen an advantage from doing so. > > I'm not saying it legally clear the other way round, my statement was > an answer to Daniel's emails claiming it was clear what such companies > do was legal. I'm sorry if I gave anyone that impression. My point was that it would be pointless to argue the case in the US because here it really is, usually , "buy the best justice for the money". DRH > cu > Adrian -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 12:06:31 Kevin Fox wrote: > On Wed, 2007-06-13 at 20:42 -0400, Daniel Hazelton wrote: > > > > > Do you deny that TiVo prevents you (or at least a random customer) > > > from modifying the copy of Linux that they ship in their DVR? > > > > Exactly. They don't. What TiVO prevents is using that modified version on > > their hardware. And they have that right, because the Hardware *ISN'T* > > covered by the GPL. > > The hardware isn't directly covered by the GPL, correct. But, if they > want to use the software on the hardware, they have to comply with the > GPL. The software license can then influence hardware IF they want to > use it badly enough. Until GPLv3 there was no requirement that the modified code be able to operate on any given device - even the one its designed for. Claiming otherwise seems stupid to me, almost ridiculous. > For example, the hardware is perfectly capable of being used to break > the terms of the GPL by being used to distribute a modified binary > without releasing the source. But the hardware's behavior is restricted > by the software for the betterment of all. But this can be done *NOW* - has been done by at least one company, IIRC. (and, IIRC again, they didn't so much as "not release the modified version" as "not release all tools/scripts/installation/build instructions") > This whole argument is about the spirit of the GPL. Linus and others > think the spirit is one thing, the FSF guys think its something else. > Since the license is clearly owned by the FSF, I think they get the > final vote on what they "intended" it to be when they wrote it, no? If > they say they intended it to not allow Tivoization then believe them, > because they are the only ones that know what they were thinking when > they wrote it! The GPLv2 seems to allow it though. If Linus and friends > want to allow it, then they can stay with the GPLv2. For those who want > to disallow Tivoization, choose v3. No worries guys. > > > Do you understand that, or do I need to break out the finger-puppets next > > ? > > Guys, we are all friends here. No reason to be so insulting. Its just a > difference of opinion. People seem to be talking past each other instead > of to one another. This usually happens when people are basing their > underlying assumptions on different things and not listening to the > other. Please take a step back and think about it. I noticed that ten or twenty messages after I made that comment. In truth, the reason I made it was, and is, because I am tired of explaining the fact that there is no "one" interpretation of the GPLv2 - or any license - *UNLESS* it has been ruled on by a court. And even then, the courts ruling only applies to the parts of the license that were in contention before it. DRH > -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 13:26:30 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 03:11:45 Alexandre Oliva wrote: > >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >> > Ah, well... In the case of "Windos" and other proprietary OS's I try > >> > to educate people and get them to switch. > >> > >> Good. So I presume you'd tell them to switch away from a > >> turned-proprietary GNU/Linux operating system as well, right? > > > > If that happened I'd be lost. I've tried the various BSD's and found they > > had problems with hardware support and getting a new version of the BSD > > kernel to compile and boot is something of a black art. > > > > The point is moot, though. It can never happen. > > Look again, it's already happened in the TiVO and other devices. > > The software that ships in them is no longer Free Software. > In *YOUR* opinion and by *YOUR* definition of the term. Yes, I have seen some evidence that TiVO hasn't made some of the modifications they made public - doesn't mean that they won't, just it hasn't *YET* been done. (Not that I'm so omniscient I can say, definitively, whether they will or won't - or even that they haven't done it already). By my own definition replacement != modification. > > Consider a new microprocessor. > > Consider that Linux is ported to it by the microprocessor > manufacturer. > > Consider that the manufacturer only sells devices with that > microprocessor with TiVO-like locks. > > How exactly can you enjoy the freedoms WRT the GPLed software you got > from the manufacturer? The same as I would with a TiVO. I have the right to copy, modify, distribute and run the code - even if I can't do any of those things on the hardware the original binary operates on. > > > Now consider that you have a single computer, and that's built by TiVO. > > How exactly can you enjoy the freedoms the author meant you to have, > if the TiVO box won't run the program after you modify it? Simple: I don't buy it. Each and every piece of hardware I buy has a rather laborious research process before I actually spend the money on it. This makes it a certainty that I can use the hardware in the manner I want without problems like your hypothetical. Whats worse - forcing your morals and ideals on someone or giving them the same freedom of choice you had? Before you answer remember that that is *EXACTLY* what is being done with GPLv3. With GPLv2 and prior there was a simple guarantee that every "Licensee" had exactly the same rights. With GPLv3 you are forcing your ethics and morals on people - and isn't this exactly what the Roman Catholic church did during the Spanish Inquisition? > > If this "run modified copies on the same hardware you received the > > original on" *IS* the "spirit" of the license, then why isn't it > > stated anywhere before GPLv3? > > For the same reasons that the pro-DRM laws weren't mentioned before, > and the patent retaliation clauses weren't mention before: these > specific cases hadn't been studied, only the general idea of > respecting users' freedoms was. Bzzt! Wrong! The reason is that it wasn't necessary - at all. It still isn't, but a group that feels modification == replacement wants it to be, so it has suddenly become necessary. (Note that anti-DRM stuff *IS* good - DRM is part of an attempt by failing business models to stop the failure) > > I'll grant you that. But, at this point, where can I find a copy of > > the GPLv1 without having to dig around the net ? > > In the program you received under GPLv1. > > Hey, you said there was code under GPLv1.1 in the Linux tree. Then, > there should be a copy of GPLv1.1 in there, otherwise AFAICT the > distribution of that code is copyright infringement. IANAL. Ah, but I never said I had a GPLv1 program. If GPLv1 is still valid and available I should be able to find a copy of it *RIGHT* *NOW* to license a new project if I want to use GPLv1 as its license. So your logic is again flawed. > >> In contrast, your TiVO may get a software upgrade without your > >> permission that will take your rights away from that point on, and > >> there's very little you can do about it, other than unplugging it from > >> the network to avoid the upgrade if it's not too late already. > > > > And because its a device that connects to their network - and TiVO > > isn't a telecommunications company - they have the right to upgrade > > and co
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 14:53:47 Linus Torvalds wrote: > On Thu, 14 Jun 2007, Lennart Sorensen wrote: > > So now the copy of the GPL v2 isn't good enough for the GPLv1.1 code? > > Maybe that code said 'or later' in the license and hence someone added > > it to a GPL v2 project since that sounds perfectly OK. > > Where did that GPLv1.1 nonsense come from? > > There is no GPLv1.1 code in the tree. By the time I selected the GPL for > the kernel license, the GPLv1.1 had long since been discontinued. The > kernel was *never* GPLv1.1-only compatible. That's just total nonsense. > > There was indeed a kernel license before the GPLv2, but it wasn't the GPL > at all, it was my own made-up thing. Appended here, for those who are too > lazy to actually look up and check the original Linux-0.01 announcement. > A hundred or so messages back someone stated that the parport driver in Linux is GPLv1.1 - however, on checking on this statement for myself I've found that there is no statement about it being v1.1 and, in fact, given that Linux itself is GPLv2 there is no possible way any code covered by GPLv1.1 can exist. DRH > Linus > > --- > This kernel is (C) 1991 Linus Torvalds, but all or part of it may be > redistributed provided you do the following: > > - Full source must be available (and free), if not with the > distribution then at least on asking for it. > > - Copyright notices must be intact. (In fact, if you distribute > only parts of it you may have to add copyrights, as there aren't > (C)'s in all files.) Small partial excerpts may be copied > without bothering with copyrights. > > - You may not distibute this for a fee, not even "handling" > costs. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 15:13:31 Alexandre Oliva wrote: > On Jun 14, 2007, "Chris Friesen" <[EMAIL PROTECTED]> wrote: > > Alexandre Oliva wrote: > >> But see, I'm not talking about getting permission to hack the > >> hardware. I'm only talking about getting permission to hack the Free > >> Software in it. > > > > No you're not...you're talking about being able to hack the software > > *and load it back onto the original hardware*. > > Yes. You wouldn't impose restrictions on modifying the software like > that, now would you? Even though the GPL says you can't impose > further restrictions on modification and distribution. replace != modify > > >> It's your position that mingles the issues and permits people to use > >> the hardware to deprive users of freedom over the software that > >> they're entitled to have. > > > > The software license controls the software. If the hardware has > > restrictions on it that limit what software it will run, then that is > > unrelated to the software license. > > As in, the license controls the software. If a patent creates > restrictions that limit what you can do with the software, then that > is unrelated to the software license. No - because this case is covered in GPLv2. Lose the straw-men. > As in, the license controls the software. If a discriminatory > contract limits what you can do with the software, then that is > unrelated to the software license. Incorrect. This is, again, covered by the GPLv2. Straw-man argument. > As in, the license controls the software. If I send you the source > code, but it happens to be protected by a key that only the hardware > can decode, and it won't decode for you, then that is unrelated to the > software license. Straw-man. Situation covered by the GPLv2. > Is that so, really? > > > There is nothing stopping you from taking the code for the tivo, > > modifying it, distributing it, or even running it on other hardware. > > True. But TiVO is still imposing further restrictions on how I can > modify the software stored in their device, while reserving that > ability to itself. This is wrong. This is not "in kind". This is > not "tit-for-tat". Tit-for-tat is: if they can, then I can too, and > if I can't, then they can't either. But that right has never been guaranteed by the GPL. It might have been the *intent* of RMS when he wrote GPLv1 and the *intent* of the FSF when they wrote GPLv2, but intent is worth exactly *NOTHING* in the law *UNLESS* that intent is spelled out. Anyway, as I've pointed out before: replace != modify You can *replace* parts of a program and it will be a modification, you can *replace* components of a piece of Hardware and it will be a modification but replacing one software component of a device with another is *NOT* a modification. Why? Because the hardware hasn't changed at all - the hardware is merely there so the software can perform its job. And since you are *replacing* the *ENTIRE* piece of software, it isn't a modification of the software. > > Suppose I had some machine that will only run microsoft-signed > > binaries. Would it be at all related to any software license that this > > machine won't let me run linux? > > That would be an unfortunate machine to have, but if Linux or some > other GPLed software was not shipped in it, then I don't see how this > is relevant to this discussion. It's not about the hardware, it's > about the software in it, and about passing on the freedoms related > with it. Exactly. However, you are making it about the hardware by making the claim that "replacing a program, in its entirety, with another is a modification". It isn't. A modification is when you replace or change a *portion* of a program. By your logic I could write an operating system that is 100% binary compatible with Linux and I'd be *required* to release it under the GPL, because, even though it *replaces* Linux, it's still a "modification". DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 14:35:29 Alexandre Oliva wrote: > > So let's look at that "section 6" that you talk about, and quote the > > relevant parts, will we: > > > > You may not impose any further restrictions on the recipients' > > exercise of the rights granted herein. > > > > and then let's look at Red Hat sending me a CD-ROM or a DVD. > > > > Now, Red Hat clearly *did* "further restrict" my rights as it pertains TO > > THAT COPY ON THE CD-ROM! I cannot change it! Waa waa waa! I'll sue your > > sorry ass off! > > Red Hat is not stopping you from making changes. The media is, and > that's not something Red Hat can control. TiVO isn't stopping you from making changes - the *media* is. (in this case the "Media" isn't even doing as much as a CD-ROM does. The only thing a TiVO box restricts is which binaries it will execute as the operating system) > > Compare this with the TiVO. TiVO *designs* the thing such that it can > still make changes, but customers can't. > > That's the difference. No, it isn't. Look at any motherboard. The Bios on the last three or four motherboards I've purchased check for a digital signature on the Bios updates. The motherboard manufacturer can make changes, but the customer can't. Is there any difference? Nope. > TiVO is using hardware to "impose further restrictions on the > recipients' exercise of the rights granted herein", and this violates > section 6 of GPLv2. No, they don't. The GPLv2 makes no provisions for you being able to execute a modified copy of the code on the same media or hardware that you received it on. The fact is that claiming it was "the spirit" doesn't matter at all - this isn't philosophy you're arguing, its *LAW*, and in law, if it isn't clearly spelled out, it doesn't exist. > > See the issue? You are continually making the mistake of thinking that > > the GPLv2 talks about individual copies of software. > > It does. You're making the mistake of thinking that it doens't. And > even in the legal terms that you claimed to have understood so > thoroughly. > > > The rights granted are the rights to "distribute and modify the > > software". > > More specifically, some of the rights are: > > copy and distribute verbatim copies of the Program's source code as > you receive it > > modify your copy or copies of the Program or any portion of it, thus > forming a work based on the Program, and copy and distribute such > modifications or work And where does it say that you even have the right to run the "work based on the Program", or even a self-compiled copy of the "verbatim copy of the code" on any given piece of hardware? > > But by "the software", the license is not talking about a particular > > *copy* of the software, it's talking about the software IN THE ABSTRACT. > > Please read it again. Done. Section 3 of GPLv2 covers the right to distribute "object code" forms of a licensed work. At no point does it even *mention* that, if the object code form comes on a device capable of executing it, you have to give the right to execute a modified form of the work on the same platform. If this has been the "intent and spirit" of the license from the beginning, it should be there somewhere. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 15:46:36 Alexandre Oliva wrote: > On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Thu, 14 Jun 2007, Alexandre Oliva wrote: > >> Is there anything other than TiVOization to justify these statements? > > > > Do you need anything else? > > No, I'm quite happy that this is all. So am I, actually :) > > > But if by the question you mean "would you think the GPLv3 is fine > > without the new language in section 6 about the 'consumer devices'", then > > the answer is that yes, I think that the current GPLv3 draft looks fine > > apart from that. > > Then would you consider relicensing Linux under GPLv3 + additional > permission for Tivoization? With Al Viro, at least, specifying that his code has been released *strictly* under GPLv2, this is impossible. > >> Also, can you elaborate on what you mean about 'giving back in kind'? > >> (I suspect this is related with the tit-for-tat reasoning, that you've > >> failed to elaborate on before) > > > > I've *not* failed to elaborate on that before. Not at all. > > > > Just google for > > > > torvalds tit-for-tat > > > > and you'll see a lot of my previous postings. Trying to claim that this > > is somehow "new" is ludicrous. > > I didn't. But I've provided evidence that your prior musings on this > topic were wrong. I wanted to give you an opportunity to review your > position under this new light. I see you haven't changed it at all. It is wrong when you look at the text of the GPLv2 only. When you look at how the "Open Source" community works it is clear that the "tit-for-tat" nature is a reality. No, it isn't mandated by GPLv2, but that is the "spirit" of the GPLv2 that most people who work on Open Source projects follow. If you want a *REAL* and *CONTINUING* violation of the GPL just look at Herr Schillings "cdrecord", in which he places additional restrictions on peoples ability to modify the code with statements in the same such as "You must leave this check in place" or "You have to leave this comment in place" - even when the comment isn't part of the "licensing statement" mandated by the GPLv2. (if you want specifics I'll go download the source and pull them out) > > Giving back "in kind" is obvious. I give you source code to do with as > > you see fit. I just expect you to give back in kind: source code for me > > to do with as I see fit, under the same license I gave you source code. > > > > How hard is that to accept? > > Forgive me if I find this a bit hard, because that's *not* what the > GPL says. > > Where do you think the GPL say that you get the source code back? It doesn't. But that it doesn't *MAKES* *NO* *DIFFERENCE* because, in practice, that is *EXACTLY* what happens anyway. > > I don't call Linux "Free Software". I haven't called it that for close to > > ten years! Because I think the term "Open Source" is a lot better. > > I can appreciate that you think it's better, but unfortunately it > appears to be playing a significant role in confusing your > interpretation of the GPL. The GPL is not just about making the > source code visible, or even modifyable by others. It's about > respecting others' freedoms. No matter how badly you prefer Open > Source over Free Software, how badly you'd rather disregard the > freedoms in the spirit and in the legal terms of the GPL, you chose a > license designed to protect those freedoms, not only the ability to > see and modify source code. Which is not in question here. The objections Linus (and others) have to the GPLv3 may share some specifics with my own objections, but my own are that GPLv2 respects my freedoms in their entirety. GPLv3 restricts my freedoms because one (or more) of the people behind it have a political agenda. (No, that term isn't entirely accurate, but its the best one I have found for the situation. Explanation: We don't like the way the law of one or more munincipalities/political divisions/countries is written and rather than trying to get it changed through other channels, we are going to enforce the way we think it should be by using a related set of laws and the text of a license) > >> The only thing the GPL demands is respect for others' freedoms, as in, > >> "I, the author, respect your freedoms, so you, the licensee, must > >> respect others' freedoms as well". Is this the "in kind" you're > >> talking about? Or are you mistaken about the actual meaning of even > >> GPLv2? > > > > I just ask that you give the software back in a usable form. That's > > all I ask for. > > I'm afraid that's not what the GPLv2 says. There's no provision > whatsoever about giving anything back. Not in the spirit, not in the > legal terms. But it does. If you are going to distribute your own, modified version - in any way - you have to make the source available as well. No, it doesn't require that you give back a version if you aren't distributing it, but in that case it hardly matters. DRH -- Dialup is like piss
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 16:42:44 Alexandre Oliva wrote: > On Jun 14, 2007, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 14, 2007 at 04:46:36PM -0300, Alexandre Oliva wrote: > >> > Giving back "in kind" is obvious. I give you source code to do with as > >> > you see fit. I just expect you to give back in kind: source code for > >> > me to do with as I see fit, under the same license I gave you source > >> > code. > >> > > >> > How hard is that to accept? > >> > >> Forgive me if I find this a bit hard, because that's *not* what the > >> GPL says. > > > > What part of the word "expect" did you not understand? > > http://lkml.org/lkml/2006/9/24/246 > > It asks everybody - regardless of circumstance - for the same thing. > It asks for the effort that was put into improving the software to > be given back to the common good. You can use the end result any > way you want (and if you want to use it for "bad" things, be my > guest), but we ask the same exact thing of everybody - give your > modifications back. > > > And whats your point here anyway? > > The the GPL doesn't do that. It encourages that. But what it asks > for is respect for the freedoms it defends WRT the software licensed > under it. Logical fallacy. The two statements are semantically equivalent, and the draw and allure of "Open Source" is that the software continually gets better at doing its job, grows more features, etc... *ALL* because the modifications *DO* get "given back". Because it is *VERY* hard to keep a modification *PRIVATE* and avoid the "distribution" clauses of the GPL the belief that it "doesn't require giving changes back" is technically and literally true, but is false in practice. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 17:19:51 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > With GPLv2 and prior there was a simple guarantee that every > > "Licensee" had exactly the same rights. With GPLv3 you are forcing > > your ethics and morals on people - and isn't this exactly what the > > Roman Catholic church did during the Spanish Inquisition? > > I fail to see the distinction you're making between GPLv2 and GPLv3. > AFAICT, with GPLv3, there still is a simple guarantee that every > licensee has exactly the same rights. > > Sure, GPLv3 follows the spirit of the GPLs more strictly than GPLv2 > possibly could. How is that "forcing ethics and morals" any more than > GPLv2 was? Because GPLv2 doesn't enforce limitations on the hardware a GPL'd work can be put on. It doesn't make artificial distinctions between "Commercial", "Industrial" and "User". What it does is *ATTEMPT* to ensure that nobody receiving a copy of a GPL'd work has the same rights as any other person that gets a copy. GPLv3 gives people *additional* rights beyond those. In the "TiVO" case it forces somebody releasing a HW platform to grant *additional* rights if they are going to use software covered by the GPLv3. The reason for forcing the giving of those additional rights is "the FSF and GPLv3 committees think that what TiVO did is 'morally and ethically' wrong, so were are enforcing our morals and ethics". Note that these are the rights that TiVO got from the GPLv2: 1) The ability to make copies of Linux 2) The ability to modify Linux 3) The ability to distribute Linux *NOTE* that those are the rights *GUARANTEED* by the GPL - despite what anyone *WISHES* it to say, or what the "Intent" or "Spirit" of the license may be, those are the only guaranteed rights. In shipping their devices with an "object code" version of Linux on them they exercised their right to perform such a distribution, granted under section 3 of the GPLv2. They made modifications to the Linux so it functioned properly on their devices, as allowed by the GPL. They have made numerous copies of Linux, as allowed by the GPL. And, as required by the GPLv2, they made the source code form of their changes available. In fact, they went beyond the requirements of the GPL (which only requires you make the source available to people you have given an "object code" version to) in making it fully available to the public *AND* in contributing those changes back to Linux. What rights did they give to "downstream" recipients of the "object code" version? *EXACTLY* those they received from the GPLv2. What rights do they have as creators of a *PROPRIETARY* hardware platform: 1) The right to restrict what programs it will run 2) The right to update it as they choose, even if it makes it incompatible with earlier versions Does the GPL *require* them to give up those rights? Version 3 does, but not any earlier version. Why does version 3 do this? Because one or more of the people behind its design and language feel that executing a piece of software on any given hardware platform automatically entitles them to all rights to the hardware that the creator of the hardware has. > > Ah, but I never said I had a GPLv1 program. > > I thought you had a copy of Linux and, per what you'd said before, > there was GPLv1 code in it. I was just trying to make it easy for > you. > > > If GPLv1 is still valid and available I should be able to find a > > copy of it *RIGHT* *NOW* to license a new project if I want to use > > GPLv1 as its license. > > http://www.gnu.org/copyleft/copying-1.0.html Ah, see, I didn't even know it was still there. I hadn't seen it in a complete form anywhere. > >> > And because its a device that connects to their network - and TiVO > >> > isn't a telecommunications company - they have the right to upgrade > >> > and configure the software inside however they want. (In the US at > >> > least) > >> > >> But do they have the right to not pass this right on, under the GPL? > > > > Yes, they do. It isn't a right they have as "copyright holders" - in > > fact, it isn't a part of their rights under the copyright at all. It's a > > part of their rights as the owners of the network. > > How about the "no further restrictions" bit? As applies to the software. The rights that the GPL has (historically) granted are what I stated above. TiVO, and companies like them, are *NOT* imposing any restrictions on rights granted under GPLv2 and prior. Remember, because I'm getting tired of repeating my
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 17:27:27 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > > > And the companies that produce devices that come with Linux and/or > > other GPL'd software installed and place limits such that only > > people that have purchased that hardware have access to the > > "modified" source running on the device are following the letter, > > and the spirit, of the GPL. > > WAIT, WAIT, THAT'S... :-) > > > Before you start yelling I'm wrong, think about it this way: they > > make the source available to the people that they've given binary > > versions to, and there is nothing stopping one of those people from > > making the source available to the rest of the world. > > The *only* in your sentence betrayed you. > > If they place the limits such that nobody else can access the sources, > they're in violation of the license. Nope. There is *NO* requirement *ANYWHERE* in the GPL, no matter the version, that says you have to *DISTRIBUTE* the source to *ANYONE* except those that you have given a binary to. Go read the licenses. > > If they merely refrain from distributing the sources to others, but > still enable the recipients to do so, this is not a violation of the > license. Exactly what I said. "only the people that have purchased the hardware have access to the modified sources" That is *EXACTLY* what a number of companies have done - Acer (yes, the laptop company) has done that. They sell laptops running Linux, but unless you have purchased one of them you can't download the sources (or even replacement binaries) for the version of linux they put on their machines. (From Acer, that is) However, as I also said, there is nothing stopping one of those people from making those "modified sources" available to the rest of the world. (I have yet to find someone that has done that with the Acer specific stuff, but...) > But then IANAL. > > > *AND* the GPL has never been about making the source available to > > everyone - just to those that get the binaries. > > Exactly. Not even to the upstream distributor. That's where Linus' > theory of tit-for-tat falls apart. Yes, it does. However, the practicality is that there is nothing *stopping* the person upstream from getting a copy of the source and incorporating the modifications they contain in a new version. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 17:39:32 Alexandre Oliva wrote: > > And since the specific implementation involves creating a derived work > of the GPLed kernel (the signature, or the signed image, or what have > you) and refraining from providing the corresponding sources to that > derived work (the key and the signature "build scripts"), I still > think this specific case is a violation of the letter of the GPLv2, > even if the FSF doesn't take this position. Not entirely correct. If TiVO is making a change to the binary to include the signature, then it *could* be considered a derivative work. If the signature is stored in another place - say a bit of Flash or a separate file on the disc - then there is no way for it to be considered a derivative work. (Under US law, IIRC and I I've interpreted it (and the related cases) properly then the change would have to be to the source of the program for it to be considered a "derivative". But, as you say often and I should make clear myself, IANAL) > > > It seems pretty obvious that the only right Tivo is withholding is the > > right to install new versions on the device > > Actually, no. They withhold the right to run versions that they don't > authorize themselves. And this is relevant to a software license in which way? In particular how is this relevant to the GPL, which has always *only* guaranteed access to the source if you have access to the binary, the right to distribute your own versions and the right to modify the code. Since the "right to run code" was never guaranteed it *cannot* be a violation. It might be in conflict with what RMS intended when he wrote the first version of the GPL and in conflict with the intent of the people that contributed to GPLv2 but that doesn't matter. However, I will not use (or recommend) the GPLv3 in its current form because I feel it makes unnecessary restrictions. The fact that you have to "allow additional rights" to make it equal to the GPLv2 makes a functional (and spiritual) difference to me. (Why? Because I'm opposed to "In order to protect freedom X we have to restrict freedom Y. Its happening in the US *RIGHT* *NOW* and I have been doing what I can to fight that. Now the same faulty logic is being applied by the FSF with GPLv3) > Back when GPLv2 was written, the right to run was never considered an > issue. It was taken for granted, because copyright didn't control > that in the US (it does in Brazil), and nobody had thought of > technical measures to stop people from running modified copies of > software. At least nobody involved in GPLv2, AFAIK. Why isn't it in the US? Because the binary form of a program does not and cannot have a separate copyright than the source code. Since it is the *SOURCE* that is actually copyright (mechanical translation cannot create a new work, only a new form of an already copyrighted work) guaranteeing the "right to run" is pointless. And you are wrong about that "Nobody thought of it" thing - what you mean is that "Nobody that had a hand in drafting and ratifying the GPLv2 thought of it". The "NSA Guidelines for Trusted Systems" (aka "The Orange Book") talks about methods of preventing the execution of code. What you and the rest of the FSF is doing in response to "tivoization" is saying "we don't care if it wasn't designed to do X, we want to be able to make it do that anyway *AND* the manufacturer has to help us do it". There is no legal way for you to make that demand of a hardware manufacturer. Instead you've gone with the only legal recourse - saying "If you want to use my copyrighted work under license X, you have to do Y". I have no problem with that, and if the FSF wants that, it's fine by me. But, as I said, I could care less where and/or if something I release under the GPL is used. This makes the GPLv2 perfect for me. > The landscape has changed, and GPLv3 is meant to defend this freedom > that was taken for granted. > > > they never do (and really never could) "modify" the physical copy on > > your device (which is your main argument). > > Qualifying it as the main argument is a bit of an exaggeration. I > have a number of different arguments. The one about incomplete > sources is the most solid IMHO. Yes, it is. But your argument about the TiVO is "they can modify the copy on it but I can't". Hence it is your main argument. And remember, replace != modify. > >> What do you think you do when you save a modified source file in your > >> editor? > > > > Don't skip the part where the in-memory version started as an exact > > copy of the original being replaced. Notice the difference? ;) > > Sorry, I really don't follow. Both versions of the kernel binary also > started from a common source ancestor. Were you trying to make a > distinction on these grounds? No. He was making a distinction that I have seen made a number of times. That is, a copy of a copyright work in a computers RAM is a *distinct* copy, separate fro
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 18:24:55 David Woodhouse wrote: > On Wed, 2007-06-13 at 21:29 -0400, Daniel Hazelton wrote: > > Agreed. However, AFAICT, TiVO meets the provisions of the GPLv2 - they > > make the source of the GPL'd part of their system available. (And I'm not > > going to get into arguments over whether kernel modules are "derivative > > works" or not, since those invariably end up with "They aren't, even > > though we think they should be") > > Who cares about whether the module is a derivative work? That's only > relevant when you distribute the module as a separate work. When you > ship a combined work including both the kernel and the module in > question, it's a _whole_ lot easier to interpret the GPL. Agreed. I said I wasn't going to argue about it because there *ARE* distinctions that the law makes and the GPL ignores. You can't have it both ways. If the module is distributed *with* the kernel *SOURCE* then it doesn't matter if it's a derivative work or not, because it becomes covered by the kernels license. If it's distributed with the kernel *binaries* then it is covered by its own license. In that case the only reason you'd have a right to the source is if the module is considered a "derivative work". DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 18:35:01 Alexandre Oliva wrote: > On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > I want to be able to use other peoples improvements. If they release > > improved versions of the software I started, I want to be able to merge > > those improvements if I want to. > > Hmm... So, if someone takes one of the many GPLv2+ contributions and > makes improvements under GPLv3+, you're going to make an effort to > accept them, rather than rejecting them because they're under the > GPLv3? Doesn't matter at all. GPLv3 requires that any project incorporating GPLv3 code be licensed under the GPLv3. Linus is, as he has shown, intelligent enough to know this. The *second* he actually accepted GPLv3 code into the kernel it would either be "change the license or start getting lawsuits for breach of the terms of the GPLv3". > > Your *IDIOTIC* suggestion is explicitly against the whole POINT! By > > saying that I shouldn't accept contributions like that, you just > > INVALIDATED the whole point of the license in the first place! > > I understand. I assumed you had some trust that people would abide by > your wish to permit TiVOization, and that authors of modifications > were entitled to make "whatever restrictions they wanted" on their > code. > > Pardon me if I think your position is at least somewhat incoherent. > Can you help me make sense of it? You are making a distinction between "part" and "whole". When separate from the kernel the code can have whatever restrictions the creator pleases. If he has said "I want this in the "official" Linux Kernel" (ie: I want this in Linus' Linux Kernel source tree) then the creator of the code has stated a willingness to abide by Linus' decision about the whole work. It's a moot point, though. The Linux Kernel is licensed under GPLv2, which means that *all* code in it has to be under the same license *and* that no code in it can have any restrictions *NOT* in the GPLv2. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 18:45:07 Alexandre Oliva wrote: > On Jun 14, 2007, "Chris Friesen" <[EMAIL PROTECTED]> wrote: > > Alexandre Oliva wrote: > >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >>> *AND* the GPL has never been about making the source available to > >>> everyone - just to those that get the binaries. > >> > >> Exactly. Not even to the upstream distributor. That's where Linus' > >> theory of tit-for-tat falls apart. > > > > Nope. > > > > case 1: Upstream provides source, tivo modifies and distributes it > > (to their customers). > > > > case 2: tivo provides source, end user modifies and distributes it > > (possibly to their customers, maybe to friends, possibly even to > > upstream). > > > > See? Tit for tat. > > case 2': tivo provides source, end user tries to improve it, realizes > the hardware won't let him and gives up Faulty logic. The hardware doesn't *restrict* you from *MODIFYING* any fscking thing. DRH > > Where's the payback, or the payforward? > > And then, tit-for-tat is about equivalent retaliation, an eye for an > eye. Where's the retaliation here? > > If GPLv2 were tit-for-tat, if someone invents artifices to prevent the > user from making the changes the user wants on the software, wouldn't > it be "equivalent retaliation" to prevent the perpetrator from making > the changes it wants on the software? -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 21:43:07 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 14:35:29 Alexandre Oliva wrote: > > > > > >> > So let's look at that "section 6" that you talk about, and quote the > >> > relevant parts, will we: > >> > > >> > You may not impose any further restrictions on the recipients' > >> > exercise of the rights granted herein. > >> > > >> > and then let's look at Red Hat sending me a CD-ROM or a DVD. > >> > > >> > Now, Red Hat clearly *did* "further restrict" my rights as it pertains > >> > TO THAT COPY ON THE CD-ROM! I cannot change it! Waa waa waa! I'll sue > >> > your sorry ass off! > >> > >> Red Hat is not stopping you from making changes. The media is, and > >> that's not something Red Hat can control. > > > > TiVO isn't stopping you from making changes - the *media* is. > > TiVO made it so, that's the difference. > > I'll give you that it's not so much about making changes per se, or > even installing them, as it is about running the modified versions for > any purpose. Artificial distinction on your part. > >> Compare this with the TiVO. TiVO *designs* the thing such that it can > >> still make changes, but customers can't. > >> > >> That's the difference. > > > > No, it isn't. Look at any motherboard. The Bios on the last three or four > > motherboards I've purchased check for a digital signature on the Bios > > updates. The motherboard manufacturer can make changes, but the customer > > can't. Is there any difference? Nope. > > Is the BIOS code under the GPL? By your reasoning it doesn't even matter. I own the hardware, I should be able to change the BIOS to *any* chunk of code I want. Do you see the fallacy here? You're making an artificial distinction based on whether the *SOFTWARE* has a certain license or not. > > The fact is that claiming it was "the spirit" doesn't matter at all > > - this isn't philosophy you're arguing, its *LAW*, and in law, if it > > isn't clearly spelled out, it doesn't exist. > > That's exactly what makes for the difference between the spirit and > the precise legal terms, and why GPLv3 is fixing these divergences. And the reason behind this is all "ethics and morals". In other words, you are forcing those "ethics and morals" on others and hiding it by giving it a different name. Wasn't it Shakespear who said: "What is in a name? A Rose by any other name would smell as sweet" > > And where does it say that you even have the right to run the "work based > > on the Program", or even a self-compiled copy of the "verbatim copy of > > the code" on any given piece of hardware? > > It doesn't. The license can't demand the software, or modified > versions thereof, to run. The only thing it can demand is that > licensees don't impose restrictions on others' abilities to do so. No, it doesn't. There is no requirement in the license in question that makes a persons ability to run the program on any given piece of hardware. What it does say is you can't stop someone from *TRYING* to do that. > >> > But by "the software", the license is not talking about a particular > >> > *copy* of the software, it's talking about the software IN THE > >> > ABSTRACT. > >> > >> Please read it again. > > > > Done. > > 2. You may modify your copy or copies of the Program or any portion > of it > > > If this has been the "intent and spirit" of the license from the > > beginning, it should be there somewhere. > > I think you're missing what 'spirit' means. It's guidance, it's not > the legal terms. And it's precisely because the implementation (the > legal terms) failed to meet that design (the spirit, encoded in the > preamble) that the license needs patching. If the intent of a law (or license) is to do A but it doesn't say that, then how is the intent to be known? Your answer: Ask the author. Question: how can we be absolutely certain that the authors intent *hasn't* changed since the law (or license) was written? *ONLY* answer: It is impossible. Conclusion: Unless the intent is clearly spelled out at the time the law (or license) is written, or is available in other writings by the author of the law/license fr
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > Daniel Hazelton writes: > > What rights did they give to "downstream" recipients of the "object code" > > version? *EXACTLY* those they received from the GPLv2. > > Doing the e-mail equivalent of yelling about this will not change the Sorry, I wasn't trying to "yell" - just provide a note that at that point I would be providing verbal stress. > fact that people who think Tivo did something wrong -- legally and/or > morally -- consider DRM locks on a piece of software to be part of the > "work based on the Program" that is governed by the GPL. All I've done is get a little annoyed that, despite evidence that it isn't legally wrong - at least under the laws I am most familiar with - people continue repeat that it is. I can't argue that it isn't "morally" wrong. While it may not be against my morals, it could be against those of another person. It has never been my intent to try and convince people that their morals are wrong. > The fundamental reason for this is that neither the executable code > nor the digital signature serves the desired function alone. The user > received a copy of the executable for a particular purpose: to run the > program on a particular platform. With DRM signatures, only the > combination of program and signature will perform that function, and > separating the two based on strictly read legal definitions is risky. I agree. > The question of whether DRM signatures are covered by the license must > be resolved before one can determine whether Tivo gave "*EXACTLY*" the > same rights to object-code recipients as Tivo received. GPLv2 is > worded such that the answer to this does not depend on whether one is > in file A and the other in file B, or whether one is on hard drive C > and the other is in flash device D, as long as they are delivered as > part of one unit; it *might* matter if, say, one is received on > physical media and the other is downloaded on demand. I have read the GPLv2 at least three times since it was pointed out that I had forgotten part of it. At no point can I find a point where Tivo broke the GPLv2 requirement that they give the recipients of the object code the same rights they received when they acquired a copy of the object or source code. > (Linus likes to say that FSF counsel thinks that Tivo did not violate > GPLv2. I suspect the actual situation is that FSF counsel believes > that there is no case law on point, and that it could go either way, > making it improper to publicly claim that Tivo violated any copyright. > Until a court rules on a close-enough case, the question of whether > GPLv2 covers DRM signatures remains open. In the mean time, it makes > more sense for the FSF to issue a new license that squarely addresses > this -- such as the GPLv3 -- and persuade as many developers as > possible that using it is the best way to protect free software.) In examining the GPLv2 and the situation from a strictly factual basis I can believe Linus' statement fully. The facts are as I stated them in a previous mail. DRH > Michael Poole -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 22:21:59 Alexandre Oliva wrote: > On Jun 14, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > the GPLv2 license says no such thing, and you seem to be mighty confused > > about how software licenses work. > > > > the GPL applies to software. It is a software license. > > > > the Tivo box is a piece of hardware. > > > > a disk is put into it with software copied to it already: a bootloader, > > a Linux kernel plus a handful of applications. The free software bits > > are available for download. > > > > the Tivo box is another (copyrighted) work, a piece of hardware. > > > > so how can, in your opinion, the hardware that Tivo produces, "take > > away" some right that the user has to the GPL-ed software? > > Consider egg yolk and egg shells. > > I produce egg yolk. I give it to you under terms that say "if you > pass this on, you must do so in such a way that doesn't stop anyone > from eating it" > > > You produce egg shells. You carefully construct your shell around the > egg yolk and some white you got from a liberal third party. > > > Then you sell the egg shells, with white and yolk inside, under > contracts that specify "the shell must be kept intact, it can't be > broken or otherwise perforated". > > > Are you or are you not disrespecting the terms that apply to the yolk? Bad analogy. I've already provided all the proof needed to prove that, while "tivoization" may be against the "intent" or "spirit" of the GPLv2 it is not in violation of it. > > by your argument, the user has some "right to modify the software", on > > that piece of hardware it bought which had free software on it, correct? > > Yes. This means the hardware distributor who put the software in > there must not place roadblocks that impede the user to get where she > wants with the software, not that the vendor must offer the user a > sport car to take her there. Okay. That means that if I ship Linux on a ROM chip I have to somehow make it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter of the GPLv2. And no claiming that I'm missing the point - I'm drawing a logical conclusion from your statement above. > The goal is not to burden the vendor. The goal is to stop the vendor > from artificially burdening the user. I have no objection to this. What I object to is the manner in which it is being done. However, I must admit that, at this point, I do not know of a better method to achieve this goal. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 23:22:48 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > Faulty logic. The hardware doesn't *restrict* you from *MODIFYING* > > any fscking thing. > > Ok, lemme try again: > > case 2'': tivo provides source, end user tries to improve it, realizes > the hardware won't let him use the result of his efforts, and gives up And there is nothing in the license that says that this has to be done. Claiming that it is a requirement because of the "spirit" of the license or that such was the "intent" of the license does not make it any less legal than it is. And, as I've taken the time to explain to you, lacking any clear statement, written at the exact same time as the license, a statement of intent or spirit cannot have any real legal weight when the text of a license is finally decided upon. The reason, in case you missed the mail in which I gave it, is that the author *cannot*, no matter the belief anyone may have in their honesty or the oaths they may swear, be trusted to have *not* changed his/her mind as to the intent and/or spirit of the license at any time after the license goes into use. DRH > > On Thursday 14 June 2007 18:45:07 Alexandre Oliva wrote: > >> Where's the payback, or the payforward? > >> > >> And then, tit-for-tat is about equivalent retaliation, an eye for an > >> eye. Where's the retaliation here? > >> > >> If GPLv2 were tit-for-tat, if someone invents artifices to prevent the > >> user from making the changes the user wants on the software, wouldn't > >> it be "equivalent retaliation" to prevent the perpetrator from making > >> the changes it wants on the software? -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 23:39:50 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > You're making an artificial distinction based on whether the > > *SOFTWARE* has a certain license or not. > > What matters to me is that, when the GPL says you can't impose further > restrictions, then you can't, no matter how convoluted your argument > is Convoluted? Not in the least. Every example I have given has been an example of the application of your logic. If my examples are convoluted, then, QED, so is your logic. > >> That's exactly what makes for the difference between the spirit and > >> the precise legal terms, and why GPLv3 is fixing these divergences. > > > > And the reason behind this is all "ethics and morals". > > There was never any attempt to hide that this was what the Free > Software movement was about, and that the GPL was about defending > these freedoms. > > Sure, it has other advantages. But the goal has always been the same, > and it's not going to change. I'm not trying to change that. My point in making that statement is to prove that the FSF is doing exactly what the Spanish Inquisition did, what every "Communist Revolution" has done and what Hitler did. Saying "My ethics and morals are better than everyone else, so I'm going to force everyone else to have my morals and ethics". That the FSF isn't doing this through force of arms or threat of violence just shows how sophisticated people have really become in the sixty years that have passed since Hitler - they now use threat of legal action. > > If the intent of a law (or license) is to do A but it doesn't say > > that, then how is the intent to be known? Your answer: Ask the > > author. > > No, you interpret based on what the author wrote then. Really? Well I must say I'm surprised at the sudden change of heart. I have several mails here in which you have either said "You ask the author" or that line has been quoted. > You read the preamble, and any other rationales associated with the > license or law. I don't know how it's elsewhere, but in Brazil every > law has a rationale, and that's often used to guide its interpretation > in courts, even though the rationale is not part of the law. Show me where in the preamble that this issue of "it must run on any given piece of hardware" or even less generally, "it must run on the hardware it came on" is even *hinted* at. You wont find it. Nor will you find any mention of anything of the sort in the publicly available writings of RMS. But let me go re-read the GPLv2 preamble again and see if it even hints at this issue... oh, wait, I read it earlier and didn't see anything that hinted at this. So I can safely conclude that no lawyer or judge would find it when interpreting the license. QED: The Tivo clause of GPLv3 causes it to break spirit with the GPLv2. (And, by the way, if the FSF decided to release a GPLv4 that had an active section that said "You must turn over all copyright rights to a work released under this license to the FSF" it wouldn't "break spirit" with the GPL (v2 or v3). Why? Because *both* contain the following paragraph: "We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." By your logic it is the *intent* of the FSF to hold copyright on all software released under the GPL *and* only give the rights detailed in the license to other people - including the person who has placed the work under the GPL. Can you see the problem with your logic ? > > If the author realizes what he wrote was not enough, or it got > misinterpreted, author his text, and then whoever feels like it and is > entitled to adopts the revised version. > > > In the GPLv2=>v3 case, all that needed revision was the legalese. The > preamble has barely changed. This is a strong indication that the > spirit remains the same, is it not? If "tivoization" was against the spirit, then all that would have been needed was one extra clause clearly explaining that. Instead there are more than 6 extra sections in the GPLv3. If "DRM" was against the license then an extra section clearly explaining that could have been added. (in the DRM case I actually understand the reasoning and agree with it.) > > Unless the intent is clearly spelled out at the time the law (or > > license) is written, or is available in other writings by the author > > of the law/license from the same time period as the law/license then > > it is impossible. > > Is there anything not
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 23:04:37 Michael Poole wrote: > Daniel Hazelton writes: > > On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > >> The fundamental reason for this is that neither the executable code > >> nor the digital signature serves the desired function alone. The user > >> received a copy of the executable for a particular purpose: to run the > >> program on a particular platform. With DRM signatures, only the > >> combination of program and signature will perform that function, and > >> separating the two based on strictly read legal definitions is risky. > > > > I agree. > > > >> The question of whether DRM signatures are covered by the license must > >> be resolved before one can determine whether Tivo gave "*EXACTLY*" the > >> same rights to object-code recipients as Tivo received. GPLv2 is > >> worded such that the answer to this does not depend on whether one is > >> in file A and the other in file B, or whether one is on hard drive C > >> and the other is in flash device D, as long as they are delivered as > >> part of one unit; it *might* matter if, say, one is received on > >> physical media and the other is downloaded on demand. > > > > I have read the GPLv2 at least three times since it was pointed out that > > I had forgotten part of it. At no point can I find a point where Tivo > > broke the GPLv2 requirement that they give the recipients of the object > > code the same rights they received when they acquired a copy of the > > object or source code. > > I am trying to reconcile your responses to those two paragraphs. > > If the DRM signature and program executable are coupled such that they > are not useful when separated, the implication to me is that they form > one work that is based on the original Program. This is beyond the > GPL's permission for "mere aggregation". > > If they are one work, and the original Program was licensed under the > GPLv2, the combined work must also be licensed under the terms of the > GPLv2. > > The input files required to generate a DRM-valid digital signature are > part the preferred form for modifying that work. > > If those bits are not distributed along with the rest of the GPL'ed > work, the distributor is either not giving the same rights to the end > user, not distributing the source code for the work, or both. Which > is it? Following your logic it would be a "failure to distribute the source code for a work". However, since the signing is an automated process it cannot generate a "new" work - at least, not under the laws of the US - so the signature itself cannot have a copyright at all. DRH PS: This is the exact same reason that the GPL cannot apply to a Bison generated parser in the US. The "input" file that causes Bison to generate the output can have a copyright, but not the output - no matter what RMS or anyone else wants, and no matter what the GPL says about it. > > Michael Poole -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 23:54:31 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 22:21:59 Alexandre Oliva wrote: > >> Consider egg yolk and egg shells. > >> > >> I produce egg yolk. I give it to you under terms that say "if you > >> pass this on, you must do so in such a way that doesn't stop anyone > >> from eating it" > >> > >> You produce egg shells. You carefully construct your shell around the > >> egg yolk and some white you got from a liberal third party. > >> > >> Then you sell the egg shells, with white and yolk inside, under > >> contracts that specify "the shell must be kept intact, it can't be > >> broken or otherwise perforated". > >> > >> Are you or are you not disrespecting the terms that apply to the yolk? > > > > Bad analogy. > > It's just a very simple case in which an enclosure is being used to > disrespect the terms of something enclosed in it. > > It's meant to show that the argument that "it's a software license, it > can't affect the hardware" is nonsense. > > It's not meant to show whether TiVO is right or wrong. This would > depend on agreement that the GPL requirements are similar to the > requirements of the egg yolk manufacturer. > > >> > by your argument, the user has some "right to modify the > >> > software", on that piece of hardware it bought which had free > >> > software on it, correct? > >> > >> Yes. This means the hardware distributor who put the software in > >> there must not place roadblocks that impede the user to get where she > >> wants with the software, not that the vendor must offer the user a > >> sport car to take her there. > > > > Okay. That means that if I ship Linux on a ROM chip I have to > > somehow make it so that the person purchasing the chip can modify > > the copy of Linux installed on the chip *if* I want to follow both > > the spirit and the letter of the GPLv2. > > I thought we'd already cleared up the issue about ROMs, and why > they're different. Do I have to quote it again? Must I allude to > "passing on the rights" every time I mention "imposing further > restrictions"? :-( I wasn't referring to anything that had already been "cleared up". I was applying the logic of the statement of yours I quoted. The "cleared up" things all were in reference to the GPLv3 - my example was in reference to the "spirit" of the GPLv2 that you were stating. By simple extension of the logic you provided I came to the conclusion stated above. The fact that you've claimed I'm wrong shows how flawed your logic is. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Friday 15 June 2007 00:14:49 Alexandre Oliva wrote:
> On Jun 15, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Fri, 15 Jun 2007, Alexandre Oliva wrote:
> >> case 2'': tivo provides source, end user tries to improve it, realizes
> >> the hardware won't let him use the result of his efforts, and gives up
> >
> > So you're blaming Tivo for the fact that your end user was a lazy bum and
> > wanted to take advantage of somebody elses hard work without permission?
>
> -ENONSEQUITUR
>
> > Quite frankly, I know who the bad guy in that scenario is, and it ain't
> > Tivo. It's your lazy bum, that thought he would just take what Tivo did,
> > sign the contract, and then not follow it. And just because the box
> > _contained_ some piece of free software, that lazy bum suddenly has all
> > those rights?
>
> Yes, because the software license that TiVo signed up for says that
> TiVo must pass on certain rights and not impose any further
> restrictions.
They don't add any restrictions that don't already exist. As stated in section
0 of the GPLv2 the scope of the license is "copying, distributing and
modification".
> And all that because TiVo wanted to use kernel and userland that were
> readily available, and at no cost other than respecting others'
> freedoms, while at that?
>
> Who's the lazy bum, again?
Still the same one that Linus pointed out. No amount of faulty logic can
change that.
> > And you seem to argue that it's perfectly fine to ignore the people who
> > design hardware and the services around them,
>
> Just like they seem to think it's perfectly fine to ignore a number of
> people who design and maintain the software they decided to use in
> their hardware.
Huh? They have complied with the terms - and, IMHO, the spirit - of the
license under which that software was released.
> > Guys, you should be ashamed of calling yourself "free software" people.
> >
> > You sound more like the RIAA/MPAA ("we own all the rights! We _own_ your
> > sorry asses for even listening to our music") and a bunch of whiners that
> > think that just because you have touched a piece of hardware you
> > automatically can do anythign you want to it, and nobody elses rights
> > matter in the least!
> >
> > Guys, in fighting for "your rights", you should look a bit at *other*
> > peoples rights too. Including the rights of hw manufacturers, and the
> > service providers. Because this is all an eco-system, where in order to
> > actually succeed, you need to make _everybody_ succeed.
>
> Good. How about thinking of the users, the customers of your dear
> friends too? The ones who might be contributing much more to your
> project.
If they are *CONTRIBUTING* then they are not just simple users anymore.
> Then look how what you said in the paragraph before about RIAA/MPAA
> applies to what TiVO is doing to the software, and realize that you're
> accusing us of doing what the party you support does.
>
> I'm not trying to impose anything. I'm not pushing anything. I'm
> defending the GPLv3 from accusations that it's departing from the GPL
> spirit, and I'm trying to find out in what way Tivoization promotes
> the goals you perceive as good for Linux, that make GPLv2
> advantageous. So far, you haven't given any single reason about this.
> You talked about tit-for-tat, you said anti-Tivoization in GPLv3 was
> bad, but you don't connect the dots. Forgive if I get the impression
> that you're just fooling yourself, and misguiding a *lot* of people
> out there in the process.
And failing. You say that the intent and spirit of the GPLv2 is clear if you
read it. I read it and I feel its pretty clear that the only things that the
GPLv2 sought to protect are *EXACTLY* "copying, distribution and
modification".
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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/
