Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Mar 8, 2019, "Maciej W. Rozycki" wrote: > Anyway I meant: does `war_io_reorder_wmb' expand to `wmb' on your system? No, it expands to `barrier' on the yeeloong: CONFIG_CPU_LOONGSON2F=y CONFIG_CPU_LOONGSON2F_WORKAROUNDS=y CONFIG_CPU_LOONGSON2=y CONFIG_SYS_HAS_CPU_LOONGSON2F=y I've finally managed to do the bisection on object files I mentioned I'd do to try to pinpoint where __BUILT_IOPORT_PFX with barrier rather than !barrier regressed. I found that forcing barrier off for drivers/irqchip/irq-i8259 was enough to avoid the problem. (I further narrowed it down to byte I/O, which is no surprise considering irq-i8259 doesn't seem to use any non-byte I/O.) Then I narrowed it down to output only. A Loongson2F kernel built with the patch below works at normal speed. I've also keyed the -1 barrier selector to compiling the irq-i8259 driver only, and that got me a functional kernel, but I'm not confident that the same issues that affect the interrupt controller, preventing it from initializing correctly, is not also affecting other drivers, just in less visible ways, so the patch conservatively reverts to the older barriers for all I/O (i.e., non-mem) out primitives. I've tested this on a yeeloong on top of v5.1.5. I'm tempted to start using this patch in my Freeloong builds of GNU Linux-libre for gnewsense/yeeloong of 5.0 and 5.1 stable releases, to try to make them usable. Can anyone suggest any reason why it might be risky to do so, moving on as much as I could to the new barriers, sticking to the 4.19-one only for non-mem out? As in, could mixing the barriers be riskier than reverting to the 4.19 barriers everywhere? Thanks in advance for any insights and recommendations, diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index 845fbbc7a2e3..04be4758d4ff 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -416,7 +416,7 @@ static inline void pfx##out##bwlq##p(type val, unsigned long port) \ volatile type *__addr; \ type __val; \ \ - if (barrier)\ + if (barrier > 0)\ iobarrier_rw(); \ else\ war_io_reorder_wmb(); \ @@ -467,13 +467,22 @@ BUILDIO_MEM(w, u16) BUILDIO_MEM(l, u32) BUILDIO_MEM(q, u64) -#define __BUILD_IOPORT_PFX(bus, bwlq, type)\ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p) +#define __BUILD_IOPORT_PFX(bus, bwlq, type, barrier) \ + __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0,) \ + __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0, _p) + +/* Choose the kind of barrier used for out in __BUILD_IOPORT_SINGLE in + non-__mem_ variants. On Loongson2F, irq-i8259 fails to initialize + when this is defined to 1. */ +#if defined(CONFIG_CPU_LOONGSON2) +#define USE_IO_BARRIER_FOR_NON_MEM_OUT -1 +#else +#define USE_IO_BARRIER_FOR_NON_MEM_OUT 1 +#endif #define BUILDIO_IOPORT(bwlq, type) \ - __BUILD_IOPORT_PFX(, bwlq, type)\ - __BUILD_IOPORT_PFX(__mem_, bwlq, type) + __BUILD_IOPORT_PFX(, bwlq, type, USE_IO_BARRIER_FOR_NON_MEM_OUT) \ + __BUILD_IOPORT_PFX(__mem_, bwlq, type, 2) BUILDIO_IOPORT(b, u8) BUILDIO_IOPORT(w, u16) -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Mar 7, 2019, "Maciej W. Rozycki" wrote: > So this seems backwards to me, port I/O is supposed to be strongly > ordered, so if removing the ordering guarantee "fixes" your problem, then > there must be a second bottom here. Well, it partially restores the earlier state, so the actual bug goes back to latent. We just have to find out what it is. My plan, in the next time slot I can devote to this investigation, is to try to bisect source files that use these interfaces to identify a minimal set that can switch to the new barriers without breaking anything, then report back after failing to make sense of it myself ;-) So, yeah, several more bottoms to dig through. > Does your platform use `war_io_reorder_wmb'? Err... I'm not sure I understand your question. It uses it in __BUILD_IOPORT_SINGLE within the expanded out function, given !barrier, but you already knew that. Did you mean to ask what war_io_reorder_wmb expand to, or whether there are other uses of war_io_reorder_wmb, or what? -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Mar 7, 2019, Aaro Koskinen wrote: > Hi, > On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote: >> On Feb 17, 2019, "Maciej W. Rozycki" wrote: >> >> > Is there an MMIO completion barrier missing there somewhere by any chance >> > causing an IRQ that has been handled already to be redelivered because an >> > MMIO write meant to clear the IRQ at its origin at handler's completion >> > has not reached its destination before interrupts have been reenabled in >> > the issuing CPU? Just a thought. >> >> I've finally got a chance to bisect the IRQ14 (nobody cared) regression >> on my yeeloong. It took me to MIPS: Enforce strong ordering for MMIO >> accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f). > This is interesting, thanks for the research, but I'm afraid it doesn't seem > to be the root cause. Oh, I didn't mean to offer anything definitive, just to report the findings of my investigation so far, since I had no clue when I'd find another significant time slot to get back onto it. > Could you check your /proc/interrupts counters after the boot with > your change? 16k to 18k interrupts after booting up into multi-user mode, including some idle time (and possibly anacron jobs) in the case that got more interrupts. That's not unlike what I get with 4.19.26-gnu. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 17, 2019, "Maciej W. Rozycki" wrote: > Is there an MMIO completion barrier missing there somewhere by any chance > causing an IRQ that has been handled already to be redelivered because an > MMIO write meant to clear the IRQ at its origin at handler's completion > has not reached its destination before interrupts have been reenabled in > the issuing CPU? Just a thought. I've finally got a chance to bisect the IRQ14 (nobody cared) regression on my yeeloong. It took me to MIPS: Enforce strong ordering for MMIO accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f). I've only just started trying to figure out what exactly in the change leads to problems. So far, I've determined that changing both uses of __BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1 removes the undesirable effects, both on top of that patch, and on top of v5.0: #define __BUILD_IOPORT_PFX(bus, bwlq, type)\ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p) + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,) \ + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p) Since the barriers didn't seem to be a problem for __BUILD_MEMORY_PFX, I figured I'd try to enable barriers in the __mem_ variants, but leave them alone for io, and that worked (without hitting the IRQ14 issue) at least on the yeeloong: diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index 845fbbc7a2e34..0a3a327d4e764 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -467,13 +467,13 @@ BUILDIO_MEM(w, u16) BUILDIO_MEM(l, u32) BUILDIO_MEM(q, u64) -#define __BUILD_IOPORT_PFX(bus, bwlq, type)\ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \ - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p) +#define __BUILD_IOPORT_PFX(bus, bwlq, type, barrier) \ + __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0,) \ + __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0, _p) #define BUILDIO_IOPORT(bwlq, type) \ - __BUILD_IOPORT_PFX(, bwlq, type)\ - __BUILD_IOPORT_PFX(__mem_, bwlq, type) + __BUILD_IOPORT_PFX(, bwlq, type, 0) \ + __BUILD_IOPORT_PFX(__mem_, bwlq, type, 1) BUILDIO_IOPORT(b, u8) BUILDIO_IOPORT(w, u16) -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 17, 2019, Aaro Koskinen wrote: > I tested few older kernels, and it seems that the spurious IRQ issue has > been always there after switching to libata (commit 7ff7a5b1bfff). It has > been unnoticed as the 10 irq limit wasn't reached during boot. I see, thanks. That would probably make it hard to bisect indeed. >> The kernel still disables irq14 early on, and then runs slow. > This hack works only for CONFIG_PATA_CS5536. You are probably using PATA_AMD. That's a reasonable guess, but I don't think so. I do have PATA_AMD enabled as a module indeed, but it's not even loaded, much as I can tell, whereas PATA_CS5536 is built into the kernel image, and dmesg says: [4.46] scsi host0: pata_cs5536 [4.464000] scsi host1: pata_cs5536 [4.464000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4c60 irq 14 [4.464000] ata2: DUMMY [4.464000] pcnet32: [...] [4.644000] random: [...] [5.908000] irq 14: nobody cared (try booting with the "irqpoll" option) Just to be sure, I added some printks to cs5536_noop_freeze, and here's what I got in dmesg instead: [4.452000] pata_cs5536: freeze: checking status... [4.452000] pata_cs5536: freeze: checked, clearing... [4.452000] pata_cs5536: freeze: cleared [4.46] scsi host0: pata_cs5536 [4.464000] scsi host1: pata_cs5536 [4.464000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4c60 irq 14 [4.464000] ata2: DUMMY [4.464000] pcnet32: [...] [4.468000] pata_cs5536: freeze: checking status... [4.468000] pata_cs5536: freeze: checked, clearing... [4.468000] pata_cs5536: freeze: cleared [4.652000] random: [...] [5.92] irq 14: nobody cared (try booting with the "irqpoll" option) now, maybe I just don't understand what effects the patch was supposed to have. The system still feels very slow, but I haven't timed anything; could it be that it had the effect of keeping the IRQ functional after all, but 5.0-rc6 is slower than earlier kernels for other reasons? Like, /proc/irq/14/pata_cs5536/ is there, but I haven't checked whether it was there before the patch. Do you suggest any way to tell whether it had the intended effect? -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 11, 2019, Aaro Koskinen wrote: > ATA (libata) CS5536 driver is having issues with spurious IRQs and often > disables IRQs completely during the boot. You should see a warning > in dmesg. This was the reason for slowness on my FuLoong mini-PC. A > workaround is to switch to old IDE driver. Thanks. I see a NIEN quirk in ide-iops.c that's enabled for the hard drive model I've got on my yeeloong, but that's not even compiled in my freeloong builds. I don't see any changes in libata between 4.19 and 4.20 that could explain the regression either. I'm afraid there's no observable change in behavior after installing the proposed patch at https://lore.kernel.org/linux-mips/20190106124607.gk27...@darkstar.musicnaut.iki.fi/ The kernel still disables irq14 early on, and then runs slow. Tom, why do you say bisecting this is impossible? I realize you wrote you did so for 24 hours non-stop, but... I'm curious as to what obstacles you ran into. It's such a reproducible problem for me that I can't see how bisecting it might be difficult. Or were by any chance you talking about the reboot/shutdown problem then? -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 11, 2019, Tom Li wrote: > We've just identified and confirmed the source of the shutdown problem a > few days ago on this mailing list. > You can pick up the patch from: > https://lore.kernel.org/lkml/20190207205812.ga11...@darkstar.musicnaut.iki.fi/ > A patch has been authored and submitted by Aaro Koskinen, but currently it > seems stuck in the mailing list because the maintainer worries about > regression > and asks for testing on more MIPS systems, although we believe it's a trivial > patch. Thanks. I've just brought it into my local copies of loongson-community branches for 4.4, 4.9, 4.14, 4.19, and 4.20, and master, after verifying that it enables at least 4.19, 4.20 and master to reboot without a power cycle, and I'll include it in upcoming freeloong builds, except for 3.16 and 3.18, where it doesn't apply. > In addition, I've discovered and fixed another bug preventing the machine from > shutting down, this patch has already merged into the Linus tree. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a96669d77897ff3613157bf43f875739205d66d Hmm, I don't think I've ever hit this one. Do you happen to know how far back it might be needed? > I'll continue working on upstreaming these out-of-tree drivers as my personal > project. I hope you'll be able to use a fully-functional machine with the > mainline > kernel soon, my current target is Linux 5.3. Thanks! -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 11, 2019, Aaro Koskinen wrote: > ATA (libata) CS5536 driver is having issues with spurious IRQs and often > disables IRQs completely during the boot. You should see a warning > in dmesg. Yup, thanks, it shows up first thing during boot. I hadn't seen that one in a while. Thanks. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 11, 2019, Tom Li wrote: > What is the current link to your repository? git://dev.lemote.com/linux-loongson-community.git I use a different git URL to push stuff, so I wouldn't have noticed if the above was gone, but I've just tried to git clone form the above and it seems to remain functional. > We've just identified and confirmed the source of the shutdown problem a > few days ago on this mailing list. It's related to a PREEMPT race condition > in the cpufreq framework that triggers a timing-dependent, probabilistic > lockup in the i8259 PIC driver. And it was first noticed by Ville Syrjälä > on a x86 system, my debugging rediscovered his findings. Oooh, thanks for the links. >> and, more recently, a very slow system overall, that's been present since >> 4.20. > The mainline framebuffer driver doesn't have any hardware drawing, printing > even a single line on the console is required a full screen redraw via memory- That doesn't seem to explain even a quiet boot up taking several times longer than 4.19, and package installation over an ethernet connection (thus not using the console) also taking several times longer. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
On Feb 8, 2019, Tom Li wrote: > found Alexandre Oliva has stopped maintaining his tree ?!? I still merge and tag every one of Torvalds' and Greg KH's releases into the loongson-community tree, resolving trivial conflicts and trying to verify that it at least builds and passes a smoke test on actual hardware (after Linux-libre deblobbing, but still). Occasionally I notice problems and I try to investigate through bisecting, but, not being a real Linux developer, I seldom get much further than that. Two issues that bother me a bit are frequent failure to reboot/poweroff, that's been around since around 4.10, and, more recently, a very slow system overall, that's been present since 4.20. I haven't checked whether they're caused by changes in the loongson-community tree that I still carry, or if they're already present in upstream releases. I've already tried to bisect the former, but since the issue is intermittent, that proved to be too tricky and time-consuming for me. I haven't tried to bisect the latter yet. I've considered leaving the loongson-community tree behind and using upstream releases, but every time I was about to do that, something else came up that led me to keep at it. I think the last such occurrence was the removal of the video driver (later reintroduced as a new driver). So I've kept at it ;-) -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [PATCH] cpufreq: loongson2_cpufreq: don't declare local variable as static
On Apr 3, 2014, Viresh Kumar wrote: > On 3 April 2014 18:10, Alexandre Oliva wrote: >> FWIW, the same mistake is present in at32. > I will check others as well now :) Thanks! >> Reverting all the changes to loongson2_cpufreq.c in 652ed95d5fa makes >> cpufreq work again, as opposed to printing nan% in all cpufreq stats in >> cpufreq-info's output, and freezing shortly thereafter. > You must have a look at this: > https://lkml.org/lkml/2014/4/2/426 : [PATCH] MIPS/loongson2_cpufreq: > fix CPU clock rate setting Thanks, I confirm that patch is enough to avoid the symptoms I'd described. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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] cpufreq: loongson2_cpufreq: don't declare local variable as static
On Apr 3, 2014, Viresh Kumar viresh.ku...@linaro.org wrote: On 3 April 2014 18:10, Alexandre Oliva ol...@gnu.org wrote: FWIW, the same mistake is present in at32. I will check others as well now :) Thanks! Reverting all the changes to loongson2_cpufreq.c in 652ed95d5fa makes cpufreq work again, as opposed to printing nan% in all cpufreq stats in cpufreq-info's output, and freezing shortly thereafter. You must have a look at this: https://lkml.org/lkml/2014/4/2/426 : [PATCH] MIPS/loongson2_cpufreq: fix CPU clock rate setting Thanks, I confirm that patch is enough to avoid the symptoms I'd described. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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] cpufreq: loongson2_cpufreq: don't declare local variable as static
On Apr 2, 2014, Viresh Kumar wrote: > did some changes to driver and by mistake made cpuclk as a 'static' local > variable, which wasn't actually required. Fix it. FWIW, the same mistake is present in at32. I've just finished bisecting the cpufreq regression on loongson2. Indeed, this s/static// patch does not fix it, but it was 652ed95d5fa, the patch that moved cpuclk into loongson2_cpufreq_cpu_init, that caused the regression. Reverting all the changes to loongson2_cpufreq.c in 652ed95d5fa makes cpufreq work again, as opposed to printing nan% in all cpufreq stats in cpufreq-info's output, and freezing shortly thereafter. > - static struct clk *cpuclk; > + struct clk *cpuclk; -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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] cpufreq: loongson2_cpufreq: don't declare local variable as static
On Apr 2, 2014, Viresh Kumar viresh.ku...@linaro.org wrote: did some changes to driver and by mistake made cpuclk as a 'static' local variable, which wasn't actually required. Fix it. FWIW, the same mistake is present in at32. I've just finished bisecting the cpufreq regression on loongson2. Indeed, this s/static// patch does not fix it, but it was 652ed95d5fa, the patch that moved cpuclk into loongson2_cpufreq_cpu_init, that caused the regression. Reverting all the changes to loongson2_cpufreq.c in 652ed95d5fa makes cpufreq work again, as opposed to printing nan% in all cpufreq stats in cpufreq-info's output, and freezing shortly thereafter. - static struct clk *cpuclk; + struct clk *cpuclk; -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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: [3.13-rc regression] Unbreak Loongson2 and r4k-generic flush icache range
On Jan 13, 2014, Sergei Shtylyov wrote: > Hello. >> Commit 14bd8c08, that replaced Loongson2-specific ifdefs with cpu tests, >> inverted the CPU test in local_r4k_flush_icache_range. Loongson2 won't >> boot up using the generic icache flush code. Presumably other CPUs >> might face other problems when presented with Loongson2-specific icache >> flush code too. This patch enabled my Yeeloong to boot up successfully >> a 3.13-rc kernel for the first time, after a long git bisect session. >> Signed-off-by: Alexandre Oliva >Fix for this issue has been posted long ago: > http://marc.info/?l=linux-mips=138575576803890 Thanks. As long ago as that was, I still don't see it in Torvalds's master branch. Was a pull request including this patch ever send his way? Such a trivial fix for such a show-stopper shouldn't find any difficulties making 3.13, I think. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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: [3.13-rc regression] Unbreak Loongson2 and r4k-generic flush icache range
On Jan 13, 2014, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. Commit 14bd8c08, that replaced Loongson2-specific ifdefs with cpu tests, inverted the CPU test in local_r4k_flush_icache_range. Loongson2 won't boot up using the generic icache flush code. Presumably other CPUs might face other problems when presented with Loongson2-specific icache flush code too. This patch enabled my Yeeloong to boot up successfully a 3.13-rc kernel for the first time, after a long git bisect session. Signed-off-by: Alexandre Oliva lxol...@fsfla.org Fix for this issue has been posted long ago: http://marc.info/?l=linux-mipsm=138575576803890 Thanks. As long ago as that was, I still don't see it in Torvalds's master branch. Was a pull request including this patch ever send his way? Such a trivial fix for such a show-stopper shouldn't find any difficulties making 3.13, I think. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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/
[3.13-rc regression] Unbreak Loongson2 and r4k-generic flush icache range
Commit 14bd8c08, that replaced Loongson2-specific ifdefs with cpu tests,
inverted the CPU test in local_r4k_flush_icache_range. Loongson2 won't
boot up using the generic icache flush code. Presumably other CPUs
might face other problems when presented with Loongson2-specific icache
flush code too. This patch enabled my Yeeloong to boot up successfully
a 3.13-rc kernel for the first time, after a long git bisect session.
Signed-off-by: Alexandre Oliva
---
arch/mips/mm/c-r4k.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 62ffd20..1c2029d 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -580,11 +580,11 @@ static inline void local_r4k_flush_icache_range(unsigned
long start, unsigned lo
else {
switch (boot_cpu_type()) {
case CPU_LOONGSON2:
- protected_blast_icache_range(start, end);
+ protected_loongson23_blast_icache_range(start, end);
break;
default:
- protected_loongson23_blast_icache_range(start, end);
+ protected_blast_icache_range(start, end);
break;
}
}
--
1.8.3.1
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
--
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/
[3.13-rc regression] Unbreak Loongson2 and r4k-generic flush icache range
Commit 14bd8c08, that replaced Loongson2-specific ifdefs with cpu tests,
inverted the CPU test in local_r4k_flush_icache_range. Loongson2 won't
boot up using the generic icache flush code. Presumably other CPUs
might face other problems when presented with Loongson2-specific icache
flush code too. This patch enabled my Yeeloong to boot up successfully
a 3.13-rc kernel for the first time, after a long git bisect session.
Signed-off-by: Alexandre Oliva lxol...@fsfla.org
---
arch/mips/mm/c-r4k.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 62ffd20..1c2029d 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -580,11 +580,11 @@ static inline void local_r4k_flush_icache_range(unsigned
long start, unsigned lo
else {
switch (boot_cpu_type()) {
case CPU_LOONGSON2:
- protected_blast_icache_range(start, end);
+ protected_loongson23_blast_icache_range(start, end);
break;
default:
- protected_loongson23_blast_icache_range(start, end);
+ protected_blast_icache_range(start, end);
break;
}
}
--
1.8.3.1
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
--
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: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Nov 3, 2013, Linus Torvalds wrote: > we'll have 4.0 follow 3.19 or something like that. > we could do a release with just stability and bug-fixes > the reason I mention "4.0" is that it would be a lovely time to do > that. That sounds backwards. .0s are known for instability and major new features that justify the major version number bump. A fixes-only release would make more sense as a last breath of the 3.* series, before (or even after?) 4.0 comes out. One way this might work is with a shorter release cycle after 3.19, with a fixes-only merge window, which would lead to a shorter stabilization cycle than usual, a rock-solid 3.20 release at the end of that cycle, during which new features would presumably have piled up for longer than usual, so as to make for more new features in the subsequent merge window, which would then justify a bump to 4.0. The shorter cycle towards 3.20, which would make the 2 cycles towards 4.0 shorter than two usual cycles, may help relieve some of the pressure to get features into 3.19, since the merge window for 4.0 won't be that far off. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Nov 3, 2013, Linus Torvalds torva...@linux-foundation.org wrote: we'll have 4.0 follow 3.19 or something like that. we could do a release with just stability and bug-fixes the reason I mention 4.0 is that it would be a lovely time to do that. That sounds backwards. .0s are known for instability and major new features that justify the major version number bump. A fixes-only release would make more sense as a last breath of the 3.* series, before (or even after?) 4.0 comes out. One way this might work is with a shorter release cycle after 3.19, with a fixes-only merge window, which would lead to a shorter stabilization cycle than usual, a rock-solid 3.20 release at the end of that cycle, during which new features would presumably have piled up for longer than usual, so as to make for more new features in the subsequent merge window, which would then justify a bump to 4.0. The shorter cycle towards 3.20, which would make the 2 cycles towards 4.0 shorter than two usual cycles, may help relieve some of the pressure to get features into 3.19, since the merge window for 4.0 won't be that far off. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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/
missing sources for generated files in drivers/gpu/drm/msm
Hi, Before getting to $SUBJECT, some context and a request for information: drivers/gpu/drm/msm/ got my attention while preparing the upcoming 3.12-gnu release of GNU Linux-libre. It names some firmware files that I couldn't locate to determine whether or not they're Free Software. I failed to find links to them in the documentation or even in comments, and the files don't seem to be present in the linux-firmware git repository either. I'd appreciate some information about a300_pm4.fw, a300_pfp.fw, a330_pm4.fw and a330_pfp.fw, such as where they can be obtained, how they're licensed, and whether their sources are available. While looking for the info above in the 3.12-rc7 source tree, I noticed a number of *.xml.h files in drivers/gpu/drm/msm/*/ that claim to be generated files (i.e., they're not sources per the GPL), and that point to a git repository that seems to have moved: This file was generated by the rules-ng-ng headergen tool in this git repository: http://0x04.net/cgit/index.cgi/rules-ng-ng git clone git://0x04.net/rules-ng-ng In the commit message, I could find a note pointing at https://github.com/freedreno/envytools I suppose that's where the repo mentioned in comments moved to. It would surely be desirable to adjust the links so that people who get the linux tarball can find the tool. AFAICT, rerunning the headergen program, as it is in the envytools repo above, will generated them with the updated URLs. However, the more serious concern in my mind is that, as the Linux tarballs stand, they are not compliant with the GPL, and they induce others to fail to comply with it in other ways, detailed below. The direct non-compliance is the lack of corresponding sources for these *.xml.h (because the links to them are broken) and of scripts to control the compilation of the original xml files into *.xml.h (I don't see them even after locating the moved repository; I'm not even sure it's headergen program that should be used to convert the .xml files into .xml.h). The inducement problem is that, because generated files are included in what most people presume to be the source tarball, without their corresponding sources, anyone who wishes to distribute binary versions of Linux under §3a of the GPL, so as to immediately satisfy all of their obligations under the GPL, will fail to do if they just accompany the binary with the Linux “source” tarball. In order to satisfy the requirements of GPLv2 under §3a, they'd have to distribute, along with the Linux “source” tree, the xml files from the envytool repository, as they were when the *.xml.h files were generated. Failure to do so could be quite inconvenient, or even construed as copyright infringement, should a distributor be unwilling or unable to satisfy their obligations under §3b or §3c of the GPL when prompted to provide the corresponding sources (the xml files and scripts used to turn them into xml.h files), for example, because the repository containing them moved again or became inaccessible. In order to avoid this problem, it would be ideal if the xml files, and a script that runs the conversion program to .xml.h, could be included in the Linux repository proper. I realize that neither the xml.h files nor the xml files they're generated from are licensed under the GPL, but rather under a far more permissive license. While this could alleviate some of the concern if the files were distributed separately, once the files are distributed as part of Linux, as they are, they are distributed under the GPL, and so distributors must satisfy the requirements of the GPL when redistributing them. I hope you'll agree these are real and serious problems, that they're trivial to fix, and so that they can be fixed in time for 3.12. Does anyone know of other such cases of generated files without corresponding sources in the Linux repository, aside from the various well-known blobs within the firmware/ subtree and the assorted blobs-disguised-as-sources that still often pop up in drivers/staging? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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/
missing sources for generated files in drivers/gpu/drm/msm
Hi, Before getting to $SUBJECT, some context and a request for information: drivers/gpu/drm/msm/ got my attention while preparing the upcoming 3.12-gnu release of GNU Linux-libre. It names some firmware files that I couldn't locate to determine whether or not they're Free Software. I failed to find links to them in the documentation or even in comments, and the files don't seem to be present in the linux-firmware git repository either. I'd appreciate some information about a300_pm4.fw, a300_pfp.fw, a330_pm4.fw and a330_pfp.fw, such as where they can be obtained, how they're licensed, and whether their sources are available. While looking for the info above in the 3.12-rc7 source tree, I noticed a number of *.xml.h files in drivers/gpu/drm/msm/*/ that claim to be generated files (i.e., they're not sources per the GPL), and that point to a git repository that seems to have moved: This file was generated by the rules-ng-ng headergen tool in this git repository: http://0x04.net/cgit/index.cgi/rules-ng-ng git clone git://0x04.net/rules-ng-ng In the commit message, I could find a note pointing at https://github.com/freedreno/envytools I suppose that's where the repo mentioned in comments moved to. It would surely be desirable to adjust the links so that people who get the linux tarball can find the tool. AFAICT, rerunning the headergen program, as it is in the envytools repo above, will generated them with the updated URLs. However, the more serious concern in my mind is that, as the Linux tarballs stand, they are not compliant with the GPL, and they induce others to fail to comply with it in other ways, detailed below. The direct non-compliance is the lack of corresponding sources for these *.xml.h (because the links to them are broken) and of scripts to control the compilation of the original xml files into *.xml.h (I don't see them even after locating the moved repository; I'm not even sure it's headergen program that should be used to convert the .xml files into .xml.h). The inducement problem is that, because generated files are included in what most people presume to be the source tarball, without their corresponding sources, anyone who wishes to distribute binary versions of Linux under §3a of the GPL, so as to immediately satisfy all of their obligations under the GPL, will fail to do if they just accompany the binary with the Linux “source” tarball. In order to satisfy the requirements of GPLv2 under §3a, they'd have to distribute, along with the Linux “source” tree, the xml files from the envytool repository, as they were when the *.xml.h files were generated. Failure to do so could be quite inconvenient, or even construed as copyright infringement, should a distributor be unwilling or unable to satisfy their obligations under §3b or §3c of the GPL when prompted to provide the corresponding sources (the xml files and scripts used to turn them into xml.h files), for example, because the repository containing them moved again or became inaccessible. In order to avoid this problem, it would be ideal if the xml files, and a script that runs the conversion program to .xml.h, could be included in the Linux repository proper. I realize that neither the xml.h files nor the xml files they're generated from are licensed under the GPL, but rather under a far more permissive license. While this could alleviate some of the concern if the files were distributed separately, once the files are distributed as part of Linux, as they are, they are distributed under the GPL, and so distributors must satisfy the requirements of the GPL when redistributing them. I hope you'll agree these are real and serious problems, that they're trivial to fix, and so that they can be fixed in time for 3.12. Does anyone know of other such cases of generated files without corresponding sources in the Linux repository, aside from the various well-known blobs within the firmware/ subtree and the assorted blobs-disguised-as-sources that still often pop up in drivers/staging? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> So, let's narrow the scenario to: tivoized machine downloads binary >> from protected site, refrains from downloading sources that it could >> download, user can still access and copy the binaries, but can't >> obtain the sources because the machine opted not to get them. >> Now, the user can't distribute the binaries, because doing so without >> being able to get the sources to pass them on would be copyright >> infringement. Would a court see this as a restriction on distribution >> imposed by the distributor? Or by the copyright holder? > I'm not sure my point was clear (not even to myself), so let me try to > clarify with a slightly different scenario. http://fsfla.org/svnwiki/blogs/lxo/2007-07-01-gplv3-tivo-and-linux.en -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 28, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote: So, let's narrow the scenario to: tivoized machine downloads binary from protected site, refrains from downloading sources that it could download, user can still access and copy the binaries, but can't obtain the sources because the machine opted not to get them. Now, the user can't distribute the binaries, because doing so without being able to get the sources to pass them on would be copyright infringement. Would a court see this as a restriction on distribution imposed by the distributor? Or by the copyright holder? I'm not sure my point was clear (not even to myself), so let me try to clarify with a slightly different scenario. http://fsfla.org/svnwiki/blogs/lxo/2007-07-01-gplv3-tivo-and-linux.en -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 30, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> But software is different. So different >> that it's governed by a separate law in Brazil, which could be >> qualified as a subclass of copyright law. And this law states that >> running programs requires permission from the copyright holder. > So do I have to buy a program and then negotiate the right to run it > separately? That seems very crazy. If you buy the program, then you become the copyright holder. I assume you meant buying a license. In this case, especially in the case of off-the-shelf non-Free Software, the license likely grants you permission to run the program, otherwise why would you pay for the license anyway? >> If you find that odd, you may have an idea of how ludicrous patents on >> software, business methods et al are. At least copyright regulation >> of execution saves us from a few abusive EULAs, created with the >> purpose of, let's see, regulating execution. > Quite the reverse. If execution is a copyright right, then I might need to > agree to a license or conract to get it. If execution is not a copyright > right, then I am safe from such craziness. Whoever gave you the copy you lawfully obtained is already subject to and/or able to offer a copyright license anyway. If the copyright holder wants to restrict your ability to run the software, whether copyright covers this case or not is absolutely irrelevant. And evidently some businesses have interests in restricting your ability to run software, not only to be able to sell you multiple licenses of non-Free Software, but also to turn Free Software into non-Free Software. > I am probably one of the stronger supporters of intellectual > property rights How do you reason about binary-only software fulfilling the goal of copyright? How does it deliver its part of the copyright deal with society if, even after it goes public domain, still nobody can create derived works from it because the source code remains unavailable? http://www.fsfla.org/?q=en/node/128#1 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 30, 2007, David Schwartz [EMAIL PROTECTED] wrote: But software is different. So different that it's governed by a separate law in Brazil, which could be qualified as a subclass of copyright law. And this law states that running programs requires permission from the copyright holder. So do I have to buy a program and then negotiate the right to run it separately? That seems very crazy. If you buy the program, then you become the copyright holder. I assume you meant buying a license. In this case, especially in the case of off-the-shelf non-Free Software, the license likely grants you permission to run the program, otherwise why would you pay for the license anyway? If you find that odd, you may have an idea of how ludicrous patents on software, business methods et al are. At least copyright regulation of execution saves us from a few abusive EULAs, created with the purpose of, let's see, regulating execution. Quite the reverse. If execution is a copyright right, then I might need to agree to a license or conract to get it. If execution is not a copyright right, then I am safe from such craziness. Whoever gave you the copy you lawfully obtained is already subject to and/or able to offer a copyright license anyway. If the copyright holder wants to restrict your ability to run the software, whether copyright covers this case or not is absolutely irrelevant. And evidently some businesses have interests in restricting your ability to run software, not only to be able to sell you multiple licenses of non-Free Software, but also to turn Free Software into non-Free Software. I am probably one of the stronger supporters of intellectual property rights How do you reason about binary-only software fulfilling the goal of copyright? How does it deliver its part of the copyright deal with society if, even after it goes public domain, still nobody can create derived works from it because the source code remains unavailable? http://www.fsfla.org/?q=en/node/128#1 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva write: >> > The GPL does sometimes use the word "may" where it's not clear >> > whether it >> > means you have permission or you must be able to. The general rule of >> > construction is that "may" means permission, unless there's some clear >> > indication to the contrary. The "may"s in sections one and two are >> > permisssion against a claim of copyright enfrocement. The "further >> > restriction" clause is, at it states, only on the exercise of *rights* >> > (which I think means those rights licensed to you under copyright law, >> > namely the right of distribution and copying). >> ... and modification and, depending on the jurisdiction, execution. > Modification, yes. Execution, well, if the rules of a jurisdiction are > insane, you will get insane results from almost any contract. > Fortunately, the GPL makes it clear that execution is unrestricted for GPL'd > works, but does not style this as a GPL right. Possible consequence: http://fsfla.org/svnwiki/blogs/lxo/2007-06-29-gplv3-tivo-and-linux.en > One would hope that jurisidictions that have such strange rules > would interpret the GPL to effect the same result under their laws > as was intended under the laws the GPL was written with respect to, > to the extent possible. Hopefully. But we know how justice is in the US, right? :-( > Treating ordinary use as a copyright privilege leads to nonsensical results > no matter what you do. For example, you get that I can drop copies of my > poem from an airplane and then sue anyone who reads it. Who was talking about reading? You can read programs as much as you can read poems. But since you (normally) can't run poems, copyright law doesn't talk about this, just like it doesn't distinguish source from object code of a poem. But software is different. So different that it's governed by a separate law in Brazil, which could be qualified as a subclass of copyright law. And this law states that running programs requires permission from the copyright holder. If you find that odd, you may have an idea of how ludicrous patents on software, business methods et al are. At least copyright regulation of execution saves us from a few abusive EULAs, created with the purpose of, let's see, regulating execution. And then, since it's already there, why not use it for other restrictions beneficial to the vendor that a copyright license couldn't establish? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, David Schwartz [EMAIL PROTECTED] wrote: Alexandre Oliva write: The GPL does sometimes use the word may where it's not clear whether it means you have permission or you must be able to. The general rule of construction is that may means permission, unless there's some clear indication to the contrary. The mays in sections one and two are permisssion against a claim of copyright enfrocement. The further restriction clause is, at it states, only on the exercise of *rights* (which I think means those rights licensed to you under copyright law, namely the right of distribution and copying). ... and modification and, depending on the jurisdiction, execution. Modification, yes. Execution, well, if the rules of a jurisdiction are insane, you will get insane results from almost any contract. Fortunately, the GPL makes it clear that execution is unrestricted for GPL'd works, but does not style this as a GPL right. Possible consequence: http://fsfla.org/svnwiki/blogs/lxo/2007-06-29-gplv3-tivo-and-linux.en One would hope that jurisidictions that have such strange rules would interpret the GPL to effect the same result under their laws as was intended under the laws the GPL was written with respect to, to the extent possible. Hopefully. But we know how justice is in the US, right? :-( Treating ordinary use as a copyright privilege leads to nonsensical results no matter what you do. For example, you get that I can drop copies of my poem from an airplane and then sue anyone who reads it. Who was talking about reading? You can read programs as much as you can read poems. But since you (normally) can't run poems, copyright law doesn't talk about this, just like it doesn't distinguish source from object code of a poem. But software is different. So different that it's governed by a separate law in Brazil, which could be qualified as a subclass of copyright law. And this law states that running programs requires permission from the copyright holder. If you find that odd, you may have an idea of how ludicrous patents on software, business methods et al are. At least copyright regulation of execution saves us from a few abusive EULAs, created with the purpose of, let's see, regulating execution. And then, since it's already there, why not use it for other restrictions beneficial to the vendor that a copyright license couldn't establish? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > So, let's narrow the scenario to: tivoized machine downloads binary > from protected site, refrains from downloading sources that it could > download, user can still access and copy the binaries, but can't > obtain the sources because the machine opted not to get them. > Now, the user can't distribute the binaries, because doing so without > being able to get the sources to pass them on would be copyright > infringement. Would a court see this as a restriction on distribution > imposed by the distributor? Or by the copyright holder? I'm not sure my point was clear (not even to myself), so let me try to clarify with a slightly different scenario. Software vendor places Free Software program for sale on a web site. Customers pay a fee and are granted access to a web page from which they can download both binaries and sources. The web page encourages them to download the sources first, because, one hour after the download of the binary completes, the password that grants access to the web page and to the downloadable bits is revoked. Sloppy customer downloads only the binaries. Days later, they decide they want to hire someone else to modify the software for them. Then they realize they don't have the sources, and that they declined the opportunity to have them. So they can't reasonably modify the software, or distribute the software for another party to do it for them. They got themselves into this situation by declining the source download. The software distributor is not imposing a restriction, it's the copyright holder that is, through the license. Now, compare this with the case quoted above, in which the computer, on behalf of the customer, declines the source download. Clearly the license stops the user from distributing the software in these circumstances, and practical matters pretty much stop the user from modifying the software for any other purpose, but how is this different from the unquoted case above? Can one actually claim that the tivoizing vendor is imposing a further restriction, even though the restrictions actually stems from a decision made by the user (or rather by the computer acting on the user's behalf), and from the copyright holder? How could this be phrased as a further restriction, if the license already restricts distribution without source code, and concedes that not having the source code makes it nearly impossible to make modifications? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> Let's hope courts see it this way. >> But then, why is it that I can't use hardware to stop someone from >> copying or modifying the source code, but I can use hardware to stop >> someone from copying or modifying the binary? Or is that not so? > You can use the hardware to stop someone from copying or modifying some > particular copy of the source code, so long as there is some copy of the > source code they can copy and modify. You are equivocating between a > particular copy and any copy at all. How do you reach this conclusion as to this kind of distinction? > I agree. You have the legal GPL right to modify any copy of a GPL'd work, > provided no technical or authorization obstacles stand in your way. Hey, why stop at these excuses to stop someone from modifying copies of the GPL? Why not list legal obstacles as well? > If the source code is on CDROM, you cannot modify that particular > copy even though you have the legal right to modify "the source > code". Yup. > The GPL does sometimes use the word "may" where it's not clear whether it > means you have permission or you must be able to. The general rule of > construction is that "may" means permission, unless there's some clear > indication to the contrary. The "may"s in sections one and two are > permisssion against a claim of copyright enfrocement. The "further > restriction" clause is, at it states, only on the exercise of *rights* > (which I think means those rights licensed to you under copyright law, > namely the right of distribution and copying). ... and modification and, depending on the jurisdiction, execution. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
distribute the binaries, because doing so without being able to get the sources to pass them on would be copyright infringement. Would a court see this as a restriction on distribution imposed by the distributor? Or by the copyright holder? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Jan Harkes [EMAIL PROTECTED] wrote: As for making modifications, I'd like to take this opportunity to withdraw, for purposes of interpretation, my earlier agreement that TiVo permits modification, even though it doesn't permit modification in place. I don't see any distinction in US copyright law between modification in place and modification by creating a separate work. In section 2 where it talks about modifications it at first doesn't seem to distinguish between source and binary, but it doesn't grant the right that the resulting modified program will actually work. And yes, you can still modify the kernel binary on the Tivo harddrive, it just won't boot with the standard bootloader. But there is an explicit no warranty clause in the GPLv2. Which I believe is a good thing. If the license tried to enforce usability, Yup. But will courts see this as a valid excuse for effectively denying users the ability to modify the copies of the GPLed programs they run on tivoized devices, even though the means to accomplish this are based on blocking the ability to run the modified executable, which happens to not require permission from the copyright holder in the US? Even more so when the modified binary provably works just fine on similar computers, and fails to work on the tivoizing device just because mechanisms were introduced to stop the user from modifying the behavior of the software that runs in the device? I.e., it fails because you changed it, rather than because you broke it. Couldn't this be understood by a court as an attempt to exploit a loophole in the letter of the license, rather than as an intentional permission to restrict the ability to run covered programs, an act that the license phrases as not restricted and outside its scope just because US copyright law doesn't demand permission from the copyright holder to run programs, which results in permission to run being outside the scope of a copyright license? Anyhow, I didn't mean to restart this debate, I just wanted (as stated above) to withdraw my earlier tentative agreement that modification in place was something that could be forbidden without infringing GPL. When you modify a sculpture, you're modifying it in place, and this requires as much copyright permission as creating a modified copy of it. Both count as modification. And when you scribble in the margin of a book you are also modifying it, so what. Maybe it's fair use, especially for a printed book, of which many copies presumably exist. I don't think you even need copyright permission, although you will probably get into trouble if the book was borrowed from a library. I don't see the relevance in the context of this discussion. Relevance was only to counter the argument that the right to modify in place, as some put it, was not covered by the GPL, because that's not how copyright law defines modification. I bought that argument at first, but then I referred back to US copyright law and not only failed to find supporting evidence for this argument, but actually found opposing evidence. So I brought it up to make sure my tentative agreement wouldn't be used in a court as an indication that the argument holds water. Here are variations of another scenario I proposed back then: - Tivoizing device ships with tivoized software, regardless of whether the corresponding sources are accessible to the end user or hidden inside the box, in a fully-encrypted disk that only that machine can read. I'm assuming no written offer for access to the software is included. Yup, that's the idea. Source are inaccessible, restricted the recipients rights to copy, distribute and modify the source code, GPLv2 violation. So, the same standards would apply to the binaries: if they were inaccessible, copyright holder could claim infringement under the same grounds, right? If it doesn't download the sources then the binary is not accompanied by the corresponding source code and since we assumed no written offer this is a violation of section 3. Except, perhaps, for this bit: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. So, let's narrow the scenario to: tivoized machine downloads binary from protected site, refrains from downloading sources that it could download, user can still access and copy the binaries, but can't obtain the sources because the machine opted not to get them. Now, the user can't distribute the binaries, because doing so without being able to get the sources to pass them on would be copyright infringement. Would a court see this as a restriction on distribution imposed by the distributor? Or by the copyright holder? -- Alexandre Oliva
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, David Schwartz [EMAIL PROTECTED] wrote: Let's hope courts see it this way. But then, why is it that I can't use hardware to stop someone from copying or modifying the source code, but I can use hardware to stop someone from copying or modifying the binary? Or is that not so? You can use the hardware to stop someone from copying or modifying some particular copy of the source code, so long as there is some copy of the source code they can copy and modify. You are equivocating between a particular copy and any copy at all. How do you reach this conclusion as to this kind of distinction? I agree. You have the legal GPL right to modify any copy of a GPL'd work, provided no technical or authorization obstacles stand in your way. Hey, why stop at these excuses to stop someone from modifying copies of the GPL? Why not list legal obstacles as well? If the source code is on CDROM, you cannot modify that particular copy even though you have the legal right to modify the source code. Yup. The GPL does sometimes use the word may where it's not clear whether it means you have permission or you must be able to. The general rule of construction is that may means permission, unless there's some clear indication to the contrary. The mays in sections one and two are permisssion against a claim of copyright enfrocement. The further restriction clause is, at it states, only on the exercise of *rights* (which I think means those rights licensed to you under copyright law, namely the right of distribution and copying). ... and modification and, depending on the jurisdiction, execution. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote: So, let's narrow the scenario to: tivoized machine downloads binary from protected site, refrains from downloading sources that it could download, user can still access and copy the binaries, but can't obtain the sources because the machine opted not to get them. Now, the user can't distribute the binaries, because doing so without being able to get the sources to pass them on would be copyright infringement. Would a court see this as a restriction on distribution imposed by the distributor? Or by the copyright holder? I'm not sure my point was clear (not even to myself), so let me try to clarify with a slightly different scenario. Software vendor places Free Software program for sale on a web site. Customers pay a fee and are granted access to a web page from which they can download both binaries and sources. The web page encourages them to download the sources first, because, one hour after the download of the binary completes, the password that grants access to the web page and to the downloadable bits is revoked. Sloppy customer downloads only the binaries. Days later, they decide they want to hire someone else to modify the software for them. Then they realize they don't have the sources, and that they declined the opportunity to have them. So they can't reasonably modify the software, or distribute the software for another party to do it for them. They got themselves into this situation by declining the source download. The software distributor is not imposing a restriction, it's the copyright holder that is, through the license. Now, compare this with the case quoted above, in which the computer, on behalf of the customer, declines the source download. Clearly the license stops the user from distributing the software in these circumstances, and practical matters pretty much stop the user from modifying the software for any other purpose, but how is this different from the unquoted case above? Can one actually claim that the tivoizing vendor is imposing a further restriction, even though the restrictions actually stems from a decision made by the user (or rather by the computer acting on the user's behalf), and from the copyright holder? How could this be phrased as a further restriction, if the license already restricts distribution without source code, and concedes that not having the source code makes it nearly impossible to make modifications? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Until someplace you can't actually access the software is customarily used > for software interchange, ... As in TiVo boxes? :-) :-) > This is a defect in the GPL. At least as I understood it, the intent > was to force distributors to remove any code for which there was a > patent claim that might threaten redistribution. Section 7 fails to > do that. It's not intended to do that. The existence of a patent doesn't render the Software non-Free. The patent holder's threats or willingness to enforce it doesn't render the Software non-Free. It's accepting a restrictive license, voluntarily or by means of a court order, that does. And the GPL is not about anything but doing as much as a copyright license can do to make sure the covered Free Software remains Free for all its users. So, requesting licensees to not use their patents to deny other users' freedoms is something a copyright license can do. But since it can't affect patent holders that are not copyright licensees, or any other legal mechanisms that non-licensees could use to restrict users' freedoms, it remains silent about this, rather than forcing licensees to comply with laws or avoid risks that might not even apply to themselves. > While you are granted rights under copyright, section 7 does not prevent > people from using other laws (so long as they don't impose the restrictions > or agree to them) to hamer your right to redistribute (or for those who > receive a distribution from you to lawfully use the work). I think that's correct, and IMHO that's how it's intended to be. > It is quite difficult to actually arrange this. You would need something > like a third party to indemnify your customers without your having to agree > to such indemnification. ... and without making you a party in this collusion. Basically, if you're involved in the process of denying users' freedoms, the GPL may have teeth for you. If you're not, and you're not a licensee of code present in that software, there's no way the GPL can stop you from imposing whatever restrictions that law permits you to impose, if you choose to do so. But the GPL won't impose restrictions on others just in case their downstream users might become your next target. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > Section 3 doesn't apply to this situation. However, other sections > do. They are distributing in line with the distribution requirement, > but not the "modification and copying" requirements. These are > granted early in the license and covered by the "no further > restrictions" clause. > You have to be able to copy and modify the source code for it to > comply with the GPL. Let's hope courts see it this way. But then, why is it that I can't use hardware to stop someone from copying or modifying the source code, but I can use hardware to stop someone from copying or modifying the binary? Or is that not so? Remember, section 2 talks about modifying *your* *copies* of the Program, without any reference whatsoever as to whether they're in source or object form. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
hts for the GPL to say you can't distribute the software. You must (voluntarily or not) accept a restrictive license before section 7 kicks in and stops you from distributing the software under the restrictions imposed on you. > We agreed that if anything prevented your recipients from exercising > your GPL rights, that means you cannot distribute. I didn't agree to that, and now I've explained why this would be a terribly stupid idea. That's just not how the GPL works. Draw satisfaction from the fact that you're not giving legal advice :-) FWIW, I'm not either, IANAL. > If the right/ability to modify a particular copy is a GPL right, > then you cannot distribute on CDROM. Who's stopping you from modifying the copy in a CDROM? Is it the distributor? Did it set things up such that you wouldn't be able to modify that CDROM? Or could it be just because nobody has found a way to overcome the natural (?) limitation of CDROMs (or rather of CDR drives?)? If you find it out, you're free to use it. In the mean time, you can still create other copies of the software in the CDROM and modify those. > If we were to read "may modify your copy or copies of the Program or > any portion of it" the way you suggest, that would mean that you > must be able to modify every single copy of the program that is > distributed to you. No, it only means that the distributor must not impose restrictions on my ability to modify those copies. The copyright holder says I can. Both nature and distributor might have means to stop me from doing it. Copyright holder can't override nature, but it can override the distributor. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva writes: >> Yes, but in the scenario I proposed, the source code *is* in the >> preferred form for making modifications, it just so happens to be >> behind a barrier you cannot trespass. This is not different from >> shipping binaries and sources in a CD inside a locked box that you >> can't open. You've received both, but how is the fact that you can't >> reach the source code (or the binaries) a violation of the GPL in this >> case? > Behind a barrier is not the preferred form for modification. Where does it state that there must not be a barrier? I see it saying the source must accompany the binary, under 3a. > Encrypted with a key you don't have is not the preferred form for > modification. Indeed, but why does it matter? In a CD is not the preferred form for making modifications either. In fact, in the CD, you can't modify it at all. What's *behind* encryption is the source code, along with the binary it accompanies. >> And, if it's not a violation, what is it that makes the case of >> shipping programs in a locked enclosure different from shipping them >> in a locked computing device? > I honestly don't see what relevance this could possibly > have. Getting access to the source is a fundamental GPL right. That's the spirit. But where does the *letter* of the GPL state it? > By this argument, shipping a GPL'd work in ROM would violate the GPL > because you cannot easily modify that particular copy. I've already explained that the inability to modify what's in the CD is not a restriction imposed by whoever recorded the bits in there as a means to stop you from making modifications. >> I ought to be entitled to modify any bit in the executable and >> expect that to have the same effect as modifying that bit on that >> executable on any other computer. > Nope, sorry. If this were true, you ought to be entitled to modify a bit in > the Linux kernel and have it have the same effect as modifying that Linux > kernel on my desktop. If your desktop is sufficiently similar, and the kernel binaries are identical, why should I not expect the same result to arise? > Again, nonsense view leads to nonsense conclusions. The fix is to > reject the nonsense view. There are no special GPL rights to > particular copies of works or particular hardware. 2. You may modify your copy or copies of the Program or any portion of it ^^ >> The fact that it stops >> working as a result of TiVo's design to prohibit modification, rather >> than by any other differences in the computer (e.g., the absence of >> the signature checks), just goes to show that there is intent to >> impose further restrictions on modification of the software. > Intent is not the issue. Imposing further restrictions is the issue. > If modifying software in this way is a GPL right, then anything that > prevents you from modifying software in this way is a GPL violation. If it is imposed by the licensee, yes, it is indeed. > If you can't distribute so as to give all GPL rights, you can't > distribute at all. Exactly. > If the GPL says I can modify my distributed copy, then distributing > on CDROM is a GPL violation. It doesn't state "you must distribute sources in modifyable media", it says "you may modify your copies, and the distributor must not have imposed restrictions on your exercise of this right" If you can't modify your copies because others get in the way, too bad. If you can't just because the distributor stops you, there's a GPL violation. > It is mind-bogglingly obvious that any sort of "right to modify one > particular copy" is *not* a GPL right. Please read the license instead of assuming you know what it says. You clearly don't. See above. > You are wasting an awful lot of time and effort analyzing things that have > *NO* GPL consequence at all. Let's just say I honestly hope you are right and I'm wrong. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > GPLv2 section 3. > The source code for a work means the preferred form of the work for > making modifications to it. > I believe this states that the source code has to be in the preferred > form for making modifications and not some other form that sucks rocks. Yes, but in the scenario I proposed, the source code *is* in the preferred form for making modifications, it just so happens to be behind a barrier you cannot trespass. This is not different from shipping binaries and sources in a CD inside a locked box that you can't open. You've received both, but how is the fact that you can't reach the source code (or the binaries) a violation of the GPL in this case? And, if it's not a violation, what is it that makes the case of shipping programs in a locked enclosure different from shipping them in a locked computing device? As for making modifications, I'd like to take this opportunity to withdraw, for purposes of interpretation, my earlier agreement that TiVo permits modification, even though it doesn't permit modification in place. I don't see any distinction in US copyright law between modification in place and modification by creating a separate work. This distinction makes sense for some cases of modification of software, but it doesn't make sense for other copyrightable works, such as sculptures, paintings, drawings, etc. When you modify a sculpture, you're modifying it in place, and this requires as much copyright permission as creating a modified copy of it. Both count as modification. And if TiVo creates artificial obstacles to your modifying the copy of GPLed programs that ships in its devices, then I believe it counts as a restriction on modification. I ought to be entitled to modify any bit in the executable and expect that to have the same effect as modifying that bit on that executable on any other computer. The fact that it stops working as a result of TiVo's design to prohibit modification, rather than by any other differences in the computer (e.g., the absence of the signature checks), just goes to show that there is intent to impose further restrictions on modification of the software. Saying that I can modify the sources and build another copy of the binary and then install that, but then it won't work, but that's fine because this is not modifying, while true, does not disqualify the claim that TiVo's design imposes artificial restrictions on my abilities to modify the copies of the program that I have received. > And yes, I do realize that you intentionally tried to come up with your > example to somehow bring tivoization to the source code. Actually, I first came up with this example long before GPLv3dd3 was published, and I know there have been changes to the draft in response to it. Here are variations of another scenario I proposed back then: - Tivoizing device ships with tivoized software, regardless of whether the corresponding sources are accessible to the end user or hidden inside the box, in a fully-encrypted disk that only that machine can read. - The software that ships is feature-limited. It's just barely enough to enable the device to connect to the network and download feature-complete software. - Network authenticates the device with help of the built-in crypto device, and device requests feature-complete binaries in encrypted network sessions. It's in the fature-complete binaries that the most valuable improvements made by the tivoizer are, that they don't want to share with anyone else. Sources *are* available behind the same authentication machinery you don't can't get past. Whether the device chooses to download them into the encrypted device you can't get to, to dispose of them right away or even leave them around, or it simply refrains from downloading the sources because it doesn't need them, the end result is the same: you've received the sources over the network, but you can't get to them. - Updates to the feature-complete software can be delivered over the same secure channel, and, as a result, derived versions of your software are distributed to third parties in ways that neither you nor the recipient can get to the sources. Here's another variation: - Vendor distributes device with feature-limited software in the fully-encrypted disk, with just enough software to download sources from the network, build the feature-complete software from sources, and install it. - Sources are behind network authentication, as above, so although your device receives them, you can't get to them because they're in the encrypted disk. Does it seem to you that GPLv2 blocks any of these means to distribute your code without granting its users access to the source code? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes [EMAIL PROTECTED] wrote: GPLv2 section 3. The source code for a work means the preferred form of the work for making modifications to it. I believe this states that the source code has to be in the preferred form for making modifications and not some other form that sucks rocks. Yes, but in the scenario I proposed, the source code *is* in the preferred form for making modifications, it just so happens to be behind a barrier you cannot trespass. This is not different from shipping binaries and sources in a CD inside a locked box that you can't open. You've received both, but how is the fact that you can't reach the source code (or the binaries) a violation of the GPL in this case? And, if it's not a violation, what is it that makes the case of shipping programs in a locked enclosure different from shipping them in a locked computing device? As for making modifications, I'd like to take this opportunity to withdraw, for purposes of interpretation, my earlier agreement that TiVo permits modification, even though it doesn't permit modification in place. I don't see any distinction in US copyright law between modification in place and modification by creating a separate work. This distinction makes sense for some cases of modification of software, but it doesn't make sense for other copyrightable works, such as sculptures, paintings, drawings, etc. When you modify a sculpture, you're modifying it in place, and this requires as much copyright permission as creating a modified copy of it. Both count as modification. And if TiVo creates artificial obstacles to your modifying the copy of GPLed programs that ships in its devices, then I believe it counts as a restriction on modification. I ought to be entitled to modify any bit in the executable and expect that to have the same effect as modifying that bit on that executable on any other computer. The fact that it stops working as a result of TiVo's design to prohibit modification, rather than by any other differences in the computer (e.g., the absence of the signature checks), just goes to show that there is intent to impose further restrictions on modification of the software. Saying that I can modify the sources and build another copy of the binary and then install that, but then it won't work, but that's fine because this is not modifying, while true, does not disqualify the claim that TiVo's design imposes artificial restrictions on my abilities to modify the copies of the program that I have received. And yes, I do realize that you intentionally tried to come up with your example to somehow bring tivoization to the source code. Actually, I first came up with this example long before GPLv3dd3 was published, and I know there have been changes to the draft in response to it. Here are variations of another scenario I proposed back then: - Tivoizing device ships with tivoized software, regardless of whether the corresponding sources are accessible to the end user or hidden inside the box, in a fully-encrypted disk that only that machine can read. - The software that ships is feature-limited. It's just barely enough to enable the device to connect to the network and download feature-complete software. - Network authenticates the device with help of the built-in crypto device, and device requests feature-complete binaries in encrypted network sessions. It's in the fature-complete binaries that the most valuable improvements made by the tivoizer are, that they don't want to share with anyone else. Sources *are* available behind the same authentication machinery you don't can't get past. Whether the device chooses to download them into the encrypted device you can't get to, to dispose of them right away or even leave them around, or it simply refrains from downloading the sources because it doesn't need them, the end result is the same: you've received the sources over the network, but you can't get to them. - Updates to the feature-complete software can be delivered over the same secure channel, and, as a result, derived versions of your software are distributed to third parties in ways that neither you nor the recipient can get to the sources. Here's another variation: - Vendor distributes device with feature-limited software in the fully-encrypted disk, with just enough software to download sources from the network, build the feature-complete software from sources, and install it. - Sources are behind network authentication, as above, so although your device receives them, you can't get to them because they're in the encrypted disk. Does it seem to you that GPLv2 blocks any of these means to distribute your code without granting its users access to the source code? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, David Schwartz [EMAIL PROTECTED] wrote: Alexandre Oliva writes: Yes, but in the scenario I proposed, the source code *is* in the preferred form for making modifications, it just so happens to be behind a barrier you cannot trespass. This is not different from shipping binaries and sources in a CD inside a locked box that you can't open. You've received both, but how is the fact that you can't reach the source code (or the binaries) a violation of the GPL in this case? Behind a barrier is not the preferred form for modification. Where does it state that there must not be a barrier? I see it saying the source must accompany the binary, under 3a. Encrypted with a key you don't have is not the preferred form for modification. Indeed, but why does it matter? In a CD is not the preferred form for making modifications either. In fact, in the CD, you can't modify it at all. What's *behind* encryption is the source code, along with the binary it accompanies. And, if it's not a violation, what is it that makes the case of shipping programs in a locked enclosure different from shipping them in a locked computing device? I honestly don't see what relevance this could possibly have. Getting access to the source is a fundamental GPL right. That's the spirit. But where does the *letter* of the GPL state it? By this argument, shipping a GPL'd work in ROM would violate the GPL because you cannot easily modify that particular copy. I've already explained that the inability to modify what's in the CD is not a restriction imposed by whoever recorded the bits in there as a means to stop you from making modifications. I ought to be entitled to modify any bit in the executable and expect that to have the same effect as modifying that bit on that executable on any other computer. Nope, sorry. If this were true, you ought to be entitled to modify a bit in the Linux kernel and have it have the same effect as modifying that Linux kernel on my desktop. If your desktop is sufficiently similar, and the kernel binaries are identical, why should I not expect the same result to arise? Again, nonsense view leads to nonsense conclusions. The fix is to reject the nonsense view. There are no special GPL rights to particular copies of works or particular hardware. 2. You may modify your copy or copies of the Program or any portion of it ^^ The fact that it stops working as a result of TiVo's design to prohibit modification, rather than by any other differences in the computer (e.g., the absence of the signature checks), just goes to show that there is intent to impose further restrictions on modification of the software. Intent is not the issue. Imposing further restrictions is the issue. If modifying software in this way is a GPL right, then anything that prevents you from modifying software in this way is a GPL violation. If it is imposed by the licensee, yes, it is indeed. If you can't distribute so as to give all GPL rights, you can't distribute at all. Exactly. If the GPL says I can modify my distributed copy, then distributing on CDROM is a GPL violation. It doesn't state you must distribute sources in modifyable media, it says you may modify your copies, and the distributor must not have imposed restrictions on your exercise of this right If you can't modify your copies because others get in the way, too bad. If you can't just because the distributor stops you, there's a GPL violation. It is mind-bogglingly obvious that any sort of right to modify one particular copy is *not* a GPL right. Please read the license instead of assuming you know what it says. You clearly don't. See above. You are wasting an awful lot of time and effort analyzing things that have *NO* GPL consequence at all. Let's just say I honestly hope you are right and I'm wrong. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
your recipients from exercising your GPL rights, that means you cannot distribute. I didn't agree to that, and now I've explained why this would be a terribly stupid idea. That's just not how the GPL works. Draw satisfaction from the fact that you're not giving legal advice :-) FWIW, I'm not either, IANAL. If the right/ability to modify a particular copy is a GPL right, then you cannot distribute on CDROM. Who's stopping you from modifying the copy in a CDROM? Is it the distributor? Did it set things up such that you wouldn't be able to modify that CDROM? Or could it be just because nobody has found a way to overcome the natural (?) limitation of CDROMs (or rather of CDR drives?)? If you find it out, you're free to use it. In the mean time, you can still create other copies of the software in the CDROM and modify those. If we were to read may modify your copy or copies of the Program or any portion of it the way you suggest, that would mean that you must be able to modify every single copy of the program that is distributed to you. No, it only means that the distributor must not impose restrictions on my ability to modify those copies. The copyright holder says I can. Both nature and distributor might have means to stop me from doing it. Copyright holder can't override nature, but it can override the distributor. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, Daniel Hazelton [EMAIL PROTECTED] wrote: Section 3 doesn't apply to this situation. However, other sections do. They are distributing in line with the distribution requirement, but not the modification and copying requirements. These are granted early in the license and covered by the no further restrictions clause. You have to be able to copy and modify the source code for it to comply with the GPL. Let's hope courts see it this way. But then, why is it that I can't use hardware to stop someone from copying or modifying the source code, but I can use hardware to stop someone from copying or modifying the binary? Or is that not so? Remember, section 2 talks about modifying *your* *copies* of the Program, without any reference whatsoever as to whether they're in source or object form. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, David Schwartz [EMAIL PROTECTED] wrote: Until someplace you can't actually access the software is customarily used for software interchange, ... As in TiVo boxes? :-) :-) This is a defect in the GPL. At least as I understood it, the intent was to force distributors to remove any code for which there was a patent claim that might threaten redistribution. Section 7 fails to do that. It's not intended to do that. The existence of a patent doesn't render the Software non-Free. The patent holder's threats or willingness to enforce it doesn't render the Software non-Free. It's accepting a restrictive license, voluntarily or by means of a court order, that does. And the GPL is not about anything but doing as much as a copyright license can do to make sure the covered Free Software remains Free for all its users. So, requesting licensees to not use their patents to deny other users' freedoms is something a copyright license can do. But since it can't affect patent holders that are not copyright licensees, or any other legal mechanisms that non-licensees could use to restrict users' freedoms, it remains silent about this, rather than forcing licensees to comply with laws or avoid risks that might not even apply to themselves. While you are granted rights under copyright, section 7 does not prevent people from using other laws (so long as they don't impose the restrictions or agree to them) to hamer your right to redistribute (or for those who receive a distribution from you to lawfully use the work). I think that's correct, and IMHO that's how it's intended to be. It is quite difficult to actually arrange this. You would need something like a third party to indemnify your customers without your having to agree to such indemnification. ... and without making you a party in this collusion. Basically, if you're involved in the process of denying users' freedoms, the GPL may have teeth for you. If you're not, and you're not a licensee of code present in that software, there's no way the GPL can stop you from imposing whatever restrictions that law permits you to impose, if you choose to do so. But the GPL won't impose restrictions on others just in case their downstream users might become your next target. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, [EMAIL PROTECTED] wrote: >> However, if the site takes the sources out, you're still responsible >> for providing sources to those who received the sources from you from >> that point on. Or something like that, IANAL ;-) > this sounds like a step backwards, you may not have the sources at > that point if you were relying on the other site to host them. You should have them. This provision is not an excuse from your obligations, it's just a pragmatic concession. > and by the way, internet access never was a barrier that could stop > someone from obtaining them Back when GPLv2 was written, it really was. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva: >> On Jun 26, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: >> > I read your scenario of the vendor not giving you the source to >> > mean: not directly; i.e. they could give you a third-party >> > download link. >> This has never been enough to comply with GPLv2. > A lot of people seem to say this, but I don't think it's true. http://www.gnu.org/licenses/gpl-faq.html#TOCUnchangedJustBinary and the 3 questions after that should be enlightening as to why people say this ;-) cost of physically performing source distribution, a complete ^^ Why would 'physically' be there if it didn't mean anything? When interpreting legal texts, that's one sort of question you should ask yourself. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, [EMAIL PROTECTED] wrote: > unless you are saying that the GPLv3 is saying that a third party link > now _is_ sufficiant. Yup. The improvement in GPLv3 is to relax the requirement of providing source code in physical medium if you choose to not distribute it along with the binaries. It's recognizing that internet access is no longer a barrier that could stop someone from obtaining the sources they're entitled to. Even someone who doesn't have regular or fast internet access can hire a third party who does to perform the download and record it. I.e., with GPLv3, you *can* point at the sources you used, even in a site that you don't control. However, if the site takes the sources out, you're still responsible for providing sources to those who received the sources from you from that point on. Or something like that, IANAL ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: > I read your scenario of the vendor not giving you the source to mean: not > directly; i.e. they could give you a third-party download link. This has never been enough to comply with GPLv2. FWIW, it is one of the improvements in GPLv3. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: >> You could argue that they do not restrict copying, distribution >> and modification of the sources in general, only of the specific copy >> they distribute. > "We don't oppose that you do any of these things, once you get the > source code. We just make it difficult (hopefully impossible) that > you'll get to the source code in the first place." Actually, they could even claim you don't need the source code to make modifications. The license even says the source code is the most convenient form to make modifications, not the only form. Now, that the others suck rocks is not their fault, is it? ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote: >> Consider this scenario: vendor tivoizes Linux in the device, and >> includes the corresponding sources only in a partition that is >> theoretically accessible using the shipped kernel, but that nothing in >> the software available in the machine will let you get to. Further, >> sources (like everything else on disk) are encrypted, and you can only > Interesting scenario, it seems to comply with GPLv2 on the surface. > If that kernel doesn't actually allow access and wipes the source > partition to use it as swap on first boot, then no machine is actually > capable of reading the source. Granted, that was just adding insult to the injury ;-) Assume the sources are kept in the encrypted disk. Or that the sources are shipped in an encrypted CD, that only the machine itself can read, using hardware-assisted decryption. > Another gripe is that encrypted media are not customarily used for > software interchange. That the whole disk is encrypted is "just a technical detail". And it's not the media that's encrypted, it's the data in it. Surely both hard disks and CDs are media customarily used for software interchange. And there is often compressed and encrypted data and software in them. > You also cannot interpret the encrypted partition as source code because > a bit further down in section 3, it defines source code as, > "The source code for a work means the preferred form of the work for > making modifications to it." The encrypted partition is not the source code. It contains the source code. Very much like the computer, or the disk, or the boot partition, is not the GPLed program, it contains the GPLed program. That it's encrypted, signed, or hardware-protected, have all been claimed as reasons why they're outside the scope of the GPL and can be used to escape its intent in this or other recent threads. > You could argue that they do not restrict copying, distribution > and modification of the sources in general, only of the specific copy > they distribute. "We don't oppose that you do any of these things, once you get the source code. We just make it difficult (hopefully impossible) that you'll get to the source code in the first place." > They get sued for copyright infringement because they are not in > compliance with section 3 and the sources are released as a result. I don't think a copyright lawsuit can be generally expected to obtain this result. A court can stop the distributor from distributing in an infringing manner, but I don't think a court could force the distributing party to shell out source code. The distributing party might not even *have* source code in the first place. And even if she had, she might have no right to distribute it. Or she might not want to, and then a court *might* require them to do so, but that would be quite unusual. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: >> Is it in the spirit of GPLv2? > No, but that's besides the point. Thanks for informing me about the point *I*'m trying to make ;-) > You can only hold people responsible for the letter, lest there be chaos. That's not *quite* how it works, but that's a general idea, yes. >> How are the sources passed on in this way going to benefit the user or the >> community? > They still have to provide the source by other GPL means of their choosing. This is contradictory. You said the scenario I described was permitted, and the scenario included the vendor's refusal to give customers other copies of the sources. Which is it? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, Al Boldi [EMAIL PROTECTED] wrote: Is it in the spirit of GPLv2? No, but that's besides the point. Thanks for informing me about the point *I*'m trying to make ;-) You can only hold people responsible for the letter, lest there be chaos. That's not *quite* how it works, but that's a general idea, yes. How are the sources passed on in this way going to benefit the user or the community? They still have to provide the source by other GPL means of their choosing. This is contradictory. You said the scenario I described was permitted, and the scenario included the vendor's refusal to give customers other copies of the sources. Which is it? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote: Consider this scenario: vendor tivoizes Linux in the device, and includes the corresponding sources only in a partition that is theoretically accessible using the shipped kernel, but that nothing in the software available in the machine will let you get to. Further, sources (like everything else on disk) are encrypted, and you can only Interesting scenario, it seems to comply with GPLv2 on the surface. If that kernel doesn't actually allow access and wipes the source partition to use it as swap on first boot, then no machine is actually capable of reading the source. Granted, that was just adding insult to the injury ;-) Assume the sources are kept in the encrypted disk. Or that the sources are shipped in an encrypted CD, that only the machine itself can read, using hardware-assisted decryption. Another gripe is that encrypted media are not customarily used for software interchange. That the whole disk is encrypted is just a technical detail. And it's not the media that's encrypted, it's the data in it. Surely both hard disks and CDs are media customarily used for software interchange. And there is often compressed and encrypted data and software in them. You also cannot interpret the encrypted partition as source code because a bit further down in section 3, it defines source code as, The source code for a work means the preferred form of the work for making modifications to it. The encrypted partition is not the source code. It contains the source code. Very much like the computer, or the disk, or the boot partition, is not the GPLed program, it contains the GPLed program. That it's encrypted, signed, or hardware-protected, have all been claimed as reasons why they're outside the scope of the GPL and can be used to escape its intent in this or other recent threads. You could argue that they do not restrict copying, distribution and modification of the sources in general, only of the specific copy they distribute. We don't oppose that you do any of these things, once you get the source code. We just make it difficult (hopefully impossible) that you'll get to the source code in the first place. They get sued for copyright infringement because they are not in compliance with section 3 and the sources are released as a result. I don't think a copyright lawsuit can be generally expected to obtain this result. A court can stop the distributor from distributing in an infringing manner, but I don't think a court could force the distributing party to shell out source code. The distributing party might not even *have* source code in the first place. And even if she had, she might have no right to distribute it. Or she might not want to, and then a court *might* require them to do so, but that would be quite unusual. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 26, 2007, Jan Harkes [EMAIL PROTECTED] wrote: You could argue that they do not restrict copying, distribution and modification of the sources in general, only of the specific copy they distribute. We don't oppose that you do any of these things, once you get the source code. We just make it difficult (hopefully impossible) that you'll get to the source code in the first place. Actually, they could even claim you don't need the source code to make modifications. The license even says the source code is the most convenient form to make modifications, not the only form. Now, that the others suck rocks is not their fault, is it? ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, Al Boldi [EMAIL PROTECTED] wrote: I read your scenario of the vendor not giving you the source to mean: not directly; i.e. they could give you a third-party download link. This has never been enough to comply with GPLv2. FWIW, it is one of the improvements in GPLv3. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, [EMAIL PROTECTED] wrote: unless you are saying that the GPLv3 is saying that a third party link now _is_ sufficiant. Yup. The improvement in GPLv3 is to relax the requirement of providing source code in physical medium if you choose to not distribute it along with the binaries. It's recognizing that internet access is no longer a barrier that could stop someone from obtaining the sources they're entitled to. Even someone who doesn't have regular or fast internet access can hire a third party who does to perform the download and record it. I.e., with GPLv3, you *can* point at the sources you used, even in a site that you don't control. However, if the site takes the sources out, you're still responsible for providing sources to those who received the sources from you from that point on. Or something like that, IANAL ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, David Schwartz [EMAIL PROTECTED] wrote: Alexandre Oliva: On Jun 26, 2007, Al Boldi [EMAIL PROTECTED] wrote: I read your scenario of the vendor not giving you the source to mean: not directly; i.e. they could give you a third-party download link. This has never been enough to comply with GPLv2. A lot of people seem to say this, but I don't think it's true. http://www.gnu.org/licenses/gpl-faq.html#TOCUnchangedJustBinary and the 3 questions after that should be enlightening as to why people say this ;-) cost of physically performing source distribution, a complete ^^ Why would 'physically' be there if it didn't mean anything? When interpreting legal texts, that's one sort of question you should ask yourself. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 26, 2007, [EMAIL PROTECTED] wrote: However, if the site takes the sources out, you're still responsible for providing sources to those who received the sources from you from that point on. Or something like that, IANAL ;-) this sounds like a step backwards, you may not have the sources at that point if you were relying on the other site to host them. You should have them. This provision is not an excuse from your obligations, it's just a pragmatic concession. and by the way, internet access never was a barrier that could stop someone from obtaining them Back when GPLv2 was written, it really was. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 25, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote: >> I was here to dispell the lies that were being spread about GPLv3, the >> spirit and the goals of the GPL, as far as I understood them. > Just because someone has a different opinion than you or the FSF does > not make what they say a lie. As a general statement, yours is absolutely correct. However, the situation at hand is quite different AFAICT. It's about people repeatedly making statements that misconstrued the intent of a third party, even after having been drawn attention to this. AFAICT, both elements needed to characterize lying are present: deviation from the truth, and intent to instill the incorrect statements on others as if they were true. Now, it might be that those making such statements hadn't fully realized what they were writing on was on others' intentions, rather than objective facts or their own opinions, and that they didn't realize they were misrepresenting those intentions before I brought this up here. In this case, if they confirm it, I'll be delighted to retract my assessment of such behavior as 'lying'. > Well what the spirit is, is certainly debateable, If you misunderstand what 'the spirit of a legal text' as something other than the intent of whoever wrote that document, then yes, it is debatable. You may want to take up the alleged inaccuracy to Wikipedia: http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law When one obeys the letter of the law but not the spirit, he is obeying the literal interpretation of the words (the "letter") of the law, but not the intent of those who wrote the law. Conversely, ^ when one obeys the spirit of the law but not the letter, he is doing what the authors of the law intended, though not adhering to the literal wording. > Any organization that claims anyone that doesn't agree with its view of > thw world and its interpretation of some written text is "confused" will > be treated like all other religigous fanatics, and not listened too. I suppose it thus follows that people will then take this perception further and selectively ignore portions of texts written by these parties. And then become frustrated and complain when their conclusions don't match those that are evidently encoded in the portions that were ignored by them. And then complain when they're misunderstanding the text, or when they're characterized as confused, or however else their selective attention and its misleading consequences are characterized. > Intelligent people know better than to listen to such groups. Ignoring facts that don't fit your ideology, or that support an ideology you reject, will mislead you, no matter what your fanaticism or anti-fanaticism is. > I think I know exactly as much about the GPL now as I did two weeks ago. Good for you (assuming you're not saying you've refused to learn anything just because I was the one passing on the knowledge, because, well, this would be unintelligent too, right? ;-) Consider this scenario: vendor tivoizes Linux in the device, and includes the corresponding sources only in a partition that is theoretically accessible using the shipped kernel, but that nothing in the software available in the machine will let you get to. Further, sources (like everything else on disk) are encrypted, and you can only decrypt it with hardware crypto that is disabled if the boot loader doesn't find a correct signature for the boot partition, or maybe the signature is irrelevant, given that everything on disk is encrypted in such a way that, if you don't have the keys, you can't update the kernel properly anyway. The vendor refuses to give customers other copies of the sources. To add insult to the injury, the vendor configures the computer to set up the encrypted disk partition containing the sources as a swap device, such that the shared-secret key used to access that entire filesystem is overwritten upon the first boot, rendering the entire previous contents of the partition holding the source code into an incomprehensible stream of bits. Does anyone think this is permitted by the letter of GPLv2? Is it in the spirit of GPLv2? How are the sources passed on in this way going to benefit the user or the community? Is this still desirable by the Linux developers? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 25, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote: I was here to dispell the lies that were being spread about GPLv3, the spirit and the goals of the GPL, as far as I understood them. Just because someone has a different opinion than you or the FSF does not make what they say a lie. As a general statement, yours is absolutely correct. However, the situation at hand is quite different AFAICT. It's about people repeatedly making statements that misconstrued the intent of a third party, even after having been drawn attention to this. AFAICT, both elements needed to characterize lying are present: deviation from the truth, and intent to instill the incorrect statements on others as if they were true. Now, it might be that those making such statements hadn't fully realized what they were writing on was on others' intentions, rather than objective facts or their own opinions, and that they didn't realize they were misrepresenting those intentions before I brought this up here. In this case, if they confirm it, I'll be delighted to retract my assessment of such behavior as 'lying'. Well what the spirit is, is certainly debateable, If you misunderstand what 'the spirit of a legal text' as something other than the intent of whoever wrote that document, then yes, it is debatable. You may want to take up the alleged inaccuracy to Wikipedia: http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law When one obeys the letter of the law but not the spirit, he is obeying the literal interpretation of the words (the letter) of the law, but not the intent of those who wrote the law. Conversely, ^ when one obeys the spirit of the law but not the letter, he is doing what the authors of the law intended, though not adhering to the literal wording. Any organization that claims anyone that doesn't agree with its view of thw world and its interpretation of some written text is confused will be treated like all other religigous fanatics, and not listened too. I suppose it thus follows that people will then take this perception further and selectively ignore portions of texts written by these parties. And then become frustrated and complain when their conclusions don't match those that are evidently encoded in the portions that were ignored by them. And then complain when they're misunderstanding the text, or when they're characterized as confused, or however else their selective attention and its misleading consequences are characterized. Intelligent people know better than to listen to such groups. Ignoring facts that don't fit your ideology, or that support an ideology you reject, will mislead you, no matter what your fanaticism or anti-fanaticism is. I think I know exactly as much about the GPL now as I did two weeks ago. Good for you (assuming you're not saying you've refused to learn anything just because I was the one passing on the knowledge, because, well, this would be unintelligent too, right? ;-) Consider this scenario: vendor tivoizes Linux in the device, and includes the corresponding sources only in a partition that is theoretically accessible using the shipped kernel, but that nothing in the software available in the machine will let you get to. Further, sources (like everything else on disk) are encrypted, and you can only decrypt it with hardware crypto that is disabled if the boot loader doesn't find a correct signature for the boot partition, or maybe the signature is irrelevant, given that everything on disk is encrypted in such a way that, if you don't have the keys, you can't update the kernel properly anyway. The vendor refuses to give customers other copies of the sources. To add insult to the injury, the vendor configures the computer to set up the encrypted disk partition containing the sources as a swap device, such that the shared-secret key used to access that entire filesystem is overwritten upon the first boot, rendering the entire previous contents of the partition holding the source code into an incomprehensible stream of bits. Does anyone think this is permitted by the letter of GPLv2? Is it in the spirit of GPLv2? How are the sources passed on in this way going to benefit the user or the community? Is this still desirable by the Linux developers? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 22, 2007, "Tomas Neme" <[EMAIL PROTECTED]> wrote: > The thing is, what matters in copyright and licencing matters is what > the author of the code understands, no the licence's author, if > ambiguous. And the kernel's rights holder is Linus. Since he didn't get copyright assignments, each contributor is the copyright holder of her/his own contribution. And this means each holder gets a say on how s/he understood GPLv2. IANAL, but I think if Linus' intended interpretation had been clarified all the way from the beginning, he could have grounds to claim that everyone else had implicitly accepted that reading by contributing to the project. But since it was a decision made many years later, his clarification on his reading of the license is in a way an additional permission that affects only his own contributions; other authors are still entitled to try to enforce their understanding of the legal terms of the license, and they would have the spirit of the GPL and its preamble on their side to guide the interpretation. Even if contract law states something like, in adhesion contracts, the party who writes the contract gives the other party the benefits of any ambiguity in the writing, the GPL is not a contract, it's a license, and per copyright law, licenses are to be interpreted restrictively. > Linus has the last word on it. In the sense that he can decide to remove all contributions from dissenting authors, yes, he does. But he can't impose his more lax interpretation upon other authors. Under copyright, it's the more restrictive reading that prevails, in that any holder who understands his rights are being trampled can enforce them. And since at least one such author is vocal in his dissent, not even estoppel defenses would apply. But IANAL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
ain such defenses, on the grounds that the complaining party might no longer get the full cooperation of the party who wanted more? If you're unhappy with GPLv3, why couldn't people who want better assurance that their code won't be used in ways they don't want be unhappy that GPLv2 doesn't guarantee these defenses for them? Don't you see that attacks on GPLv3, suggestions that it's weakened or dropped, such that these two parts of the community could keep on cooperating under terms you prefer but they don't, would be just as bad for others as taking GPLv2 away from you would? GPLv2 is not going away. GPLv3 is going to be one more option, and it's better than GPLv2 for many people. You can have different goals than GPLv3 and prefer other licenses over it as much as you want. I don't care (*). But please respect that others disagree with your goals and want GPLv3, and if this reduces the amount of cooperation you get from them to achieve your goals, realize that you're also refusing to cooperate with them to achieve theirs. This is unfortunate, but it's not unfair. What's unfair is to try to shift the blame onto only one of the parties. (*) I reserve the right to vocally oppose decisions for non-Free Software licenses, because I understand that, even though anyone may have a legal right to make such decisions, it's unethical to make such decisions, and it prolongs a social problem that I devote a significant portion of my life to terminate. I thank you all for your help in achieving this goal, even if it's involuntary. > it was really *you* who had no interest in reaching a mutually > agreeable compromise, This is an unfair characterization of the situation. I think both sides have very little interest in compromising their positions, and that's fair. Yesterday, when *I* (!= FSF, != FSFLA) started this thread with a proposal about mutual compatibility that seemed to me to be a reasonable compromise, that AFAICT would meet all of the points that had been brought in the long discussion that preceded, was when I started an effort of mediating a negotiation between two parties that AFAICT were not really interested in participating in such a negotiation. My suggestion wouldn't work unless both parties made some concessions, in order to obtain the benefits of mutual cooperation. No party would be required to make such concessions. The only thing that's clear so far is that one person in one party is not interested in using such an agreement; a person that had already voiced an opinion against relicensing his contributions to Linux in a GPLv3-compatible way, not even if Sun were to license the OpenSolaris kernel under GPLv3. No surprise here. I wish I'd got other opinions about this proposal, though, such that I can make a decision on whether it even makes sense for me to champion this suggestion towards inclusion in GPLv3. > at times where one could wonder if he was really sent by Tivo to > make sure the kernel would stay GPLv2. :-) :-) Dammit, how did you guess? :-) I even tried to disguise it by insisting that GPLv2 already prohibits this practice! :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote: >> No, this thread was about additional permissions to combine with other >> licenses. I didn't suggest anything about relicensing whatsoever, >> that's all noise out of not understanding the suggestion. > And that constitutes the change of license. I stand corrected. I misread what you wrote as "relicensing under GPLv3, or GPLv2+". Sorry. > Suppose ZFS _is_ pulled into the tree via that mechanism. Or even kept outside, such that third parties can create a combined work and distribute that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Theodore Tso <[EMAIL PROTECTED]> wrote: > has probably made it made it much more *unlikely* that the Linux > kernel will ever go GPLv3. That was a given from the start. The spin that there was any chance whatsoever it could possibly happen was just that. Even if Linus could possibly consider this, others have made it pretty clear that this was never an option for them, and Linus' explosion at my first one-liner intervention on GPLv3 isn't exactly a sign of being considering something reasonably. So, no, as I've repeatedly stated, I wasn't here to convince anyone to adopt GPLv3. I know you won't believe me. I don't care. I was here to dispell the lies that were being spread about GPLv3, the spirit and the goals of the GPL, as far as I understood them. I knew from the start that it was an uphill battle, and that I wouldn't be able to convince those who distrusted the FSF so much that they would listen to anything that resembled an FSF discourse with an extremely high rejection level. This was all expected. I wasn't here to convince them. I knew I wouldn't. I was here to set the record straight on the spirit of the GPL, not towards the most vocal opponents, but for others who hadn't formed an opinion, prejudiced or not. I was here to inform about GPLv3, not to push it. That I was perceived as pushing it is not surprising at all. The perception of "being forced" whenever something resembling the FSF ideology comes up is so strong here that some people just stop listening, stop thinking rationally (limbic system take-over?), or even get into outright name calling. No surprise here. I knew this was hostile territory, and I came prepared for this. I feel I have accomplished my goal: I've informed a lot of people about the GPL, about GPLv3, about Free Software and even about the FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal Free Software licenses, is up to them. Now, people who'd only been exposed to the prevailing views in this list can take something different into account, and make more-informed decisions. Thanks for listening. o-o -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Theodore Tso [EMAIL PROTECTED] wrote: has probably made it made it much more *unlikely* that the Linux kernel will ever go GPLv3. That was a given from the start. The spin that there was any chance whatsoever it could possibly happen was just that. Even if Linus could possibly consider this, others have made it pretty clear that this was never an option for them, and Linus' explosion at my first one-liner intervention on GPLv3 isn't exactly a sign of being considering something reasonably. So, no, as I've repeatedly stated, I wasn't here to convince anyone to adopt GPLv3. I know you won't believe me. I don't care. I was here to dispell the lies that were being spread about GPLv3, the spirit and the goals of the GPL, as far as I understood them. I knew from the start that it was an uphill battle, and that I wouldn't be able to convince those who distrusted the FSF so much that they would listen to anything that resembled an FSF discourse with an extremely high rejection level. This was all expected. I wasn't here to convince them. I knew I wouldn't. I was here to set the record straight on the spirit of the GPL, not towards the most vocal opponents, but for others who hadn't formed an opinion, prejudiced or not. I was here to inform about GPLv3, not to push it. That I was perceived as pushing it is not surprising at all. The perception of being forced whenever something resembling the FSF ideology comes up is so strong here that some people just stop listening, stop thinking rationally (limbic system take-over?), or even get into outright name calling. No surprise here. I knew this was hostile territory, and I came prepared for this. I feel I have accomplished my goal: I've informed a lot of people about the GPL, about GPLv3, about Free Software and even about the FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal Free Software licenses, is up to them. Now, people who'd only been exposed to the prevailing views in this list can take something different into account, and make more-informed decisions. Thanks for listening. o-o -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Al Viro [EMAIL PROTECTED] wrote: On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote: No, this thread was about additional permissions to combine with other licenses. I didn't suggest anything about relicensing whatsoever, that's all noise out of not understanding the suggestion. And that constitutes the change of license. I stand corrected. I misread what you wrote as relicensing under GPLv3, or GPLv2+. Sorry. Suppose ZFS _is_ pulled into the tree via that mechanism. Or even kept outside, such that third parties can create a combined work and distribute that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
? If you're unhappy with GPLv3, why couldn't people who want better assurance that their code won't be used in ways they don't want be unhappy that GPLv2 doesn't guarantee these defenses for them? Don't you see that attacks on GPLv3, suggestions that it's weakened or dropped, such that these two parts of the community could keep on cooperating under terms you prefer but they don't, would be just as bad for others as taking GPLv2 away from you would? GPLv2 is not going away. GPLv3 is going to be one more option, and it's better than GPLv2 for many people. You can have different goals than GPLv3 and prefer other licenses over it as much as you want. I don't care (*). But please respect that others disagree with your goals and want GPLv3, and if this reduces the amount of cooperation you get from them to achieve your goals, realize that you're also refusing to cooperate with them to achieve theirs. This is unfortunate, but it's not unfair. What's unfair is to try to shift the blame onto only one of the parties. (*) I reserve the right to vocally oppose decisions for non-Free Software licenses, because I understand that, even though anyone may have a legal right to make such decisions, it's unethical to make such decisions, and it prolongs a social problem that I devote a significant portion of my life to terminate. I thank you all for your help in achieving this goal, even if it's involuntary. it was really *you* who had no interest in reaching a mutually agreeable compromise, This is an unfair characterization of the situation. I think both sides have very little interest in compromising their positions, and that's fair. Yesterday, when *I* (!= FSF, != FSFLA) started this thread with a proposal about mutual compatibility that seemed to me to be a reasonable compromise, that AFAICT would meet all of the points that had been brought in the long discussion that preceded, was when I started an effort of mediating a negotiation between two parties that AFAICT were not really interested in participating in such a negotiation. My suggestion wouldn't work unless both parties made some concessions, in order to obtain the benefits of mutual cooperation. No party would be required to make such concessions. The only thing that's clear so far is that one person in one party is not interested in using such an agreement; a person that had already voiced an opinion against relicensing his contributions to Linux in a GPLv3-compatible way, not even if Sun were to license the OpenSolaris kernel under GPLv3. No surprise here. I wish I'd got other opinions about this proposal, though, such that I can make a decision on whether it even makes sense for me to champion this suggestion towards inclusion in GPLv3. at times where one could wonder if he was really sent by Tivo to make sure the kernel would stay GPLv2. :-) :-) Dammit, how did you guess? :-) I even tried to disguise it by insisting that GPLv2 already prohibits this practice! :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 22, 2007, Tomas Neme [EMAIL PROTECTED] wrote: The thing is, what matters in copyright and licencing matters is what the author of the code understands, no the licence's author, if ambiguous. And the kernel's rights holder is Linus. Since he didn't get copyright assignments, each contributor is the copyright holder of her/his own contribution. And this means each holder gets a say on how s/he understood GPLv2. IANAL, but I think if Linus' intended interpretation had been clarified all the way from the beginning, he could have grounds to claim that everyone else had implicitly accepted that reading by contributing to the project. But since it was a decision made many years later, his clarification on his reading of the license is in a way an additional permission that affects only his own contributions; other authors are still entitled to try to enforce their understanding of the legal terms of the license, and they would have the spirit of the GPL and its preamble on their side to guide the interpretation. Even if contract law states something like, in adhesion contracts, the party who writes the contract gives the other party the benefits of any ambiguity in the writing, the GPL is not a contract, it's a license, and per copyright law, licenses are to be interpreted restrictively. Linus has the last word on it. In the sense that he can decide to remove all contributions from dissenting authors, yes, he does. But he can't impose his more lax interpretation upon other authors. Under copyright, it's the more restrictive reading that prevails, in that any holder who understands his rights are being trampled can enforce them. And since at least one such author is vocal in his dissent, not even estoppel defenses would apply. But IANAL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > Great, so for ever and ever afterwards the code would have to keep a > clear separation between the bits that are under different licences and > make sure that no re-factor ever blurred the lines between them enough > that you had trouble telling which was which. As long as you care about being able to tell which is which, yes. I can understand why, under some circumstances, this might be taken as worse than not being able to use code under GPLv3 (or any other incompatible license) at all. > understand what licence the final work is under. If it's a mingled combination of code under GPLv2 plus permission to combine with v3, and GPLv3 plus (potential built-in?) permission to combine with v2, these are the combined terms. You can still use it with code under GPLv2 plus permission to combine with v3, and with GPLv3 plus (potential built-in?) permission to combine with v2. I can see that it boggles the minds not used to this kind of combination. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > None of this "Projects" nonsense. The reason I mentioned projects was because each project has its policies, around the interests of its own community. Each project can thus make a decision about its own policies, just like Linux has made its own decisions. It was not my intent to suggest that developers in certain projects (communities, groups, however you want to name that) should grant permissions for cooperation with other specific projects, even though this is certainly something that can be done under copyright law. So don't read too much into "project", think of it as "policy in a particular community of developers", and note that the terms I suggested didn't make any reference whatsoever to projects, but rather to licenses (part of the policy of each project). > Suddenly using other GPLv2 code becomes fraught with "which path did > I obtain this licence down" games I don't see how this could possibly be come up as a consequence of my suggestion. In fact, it is my understanding that the path is not relevant, what matters is the terms under which the copyright holders are willing to license their code. That someone might be able to enforce stricter terms upon a combined work is just a consequence of the "most restrictive license" rule, not of the path the code followed. But IANAL. > You're not going to make a happy, happy merging code sharing world > by fragmenting the licence landscape even more. I take it that removing barriers to cooperation in GPLv3 by default is undesirable. Well, then, what can I say? I tried. :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote: >> Do you agree that if there's any single contributor who thinks it >> can't be tivoized, and he manages his opinion to prevail in court >> against a copyright holder, then it can't? That this is the same >> privilege to veto additional permissions that Al Viro has just >> claimed? > You know, I'm rapidly losing any respect for your integrity. The only > "privelege" claimed is that of not relicensing one's contributions. No, this thread was about additional permissions to combine with other licenses. I didn't suggest anything about relicensing whatsoever, that's all noise out of not understanding the suggestion. You objected to granting additional permissions. You have that right, per copyright law, and the other developers can then decide between not granting an additional permission or removing all the code you contributed such that they can. That's veto. Similarly, if someone proposed an additional unambiguous permission to tivoize under GPLv2, any developer who objected to it could veto it (the alternative being to remove all of his contributions). > What really gets me is that you know it. Yes. The only disagreement is that I'm talking "additional permission to combine" and you seem to keep understanding "relicensing", even though these are very different concepts, with significantly different consequences. What they have in common is that you can veto either one with your status as copyright holder, and that they would both permit some forms of cooperation. Permission to relicense would provide for one-way cooperation out of Linux. I'm not proposing this. That would be stupid. You've already decided about it. I respect that decision. I even understand why you made that decision. Relicensing would provide for two-way cooperation, but under terms that you don't consider acceptable. You've pretty much already decided not to do it. I respect that decision. I even understand why you made that decision. Permission to combine in both sides would provide for two-way cooperation in ways that enable each author to enforce the terms s/he chose for his/her own contributions. This would address many of the concerns raised about relicensing, and would increase the amount of contributions in kind you can get. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote: >> It's not like anyone can safely tivoize devices with GPLv2 already, > So you really didn't pay any attention to anything people told you? Yes. Particularly to what Alan Cox and his legal counsel told me. A single copyright holder able and willing to enforce the license against tivoization is enough. What part of this don't you understand? > The license does not grant the right that you will be able to run the > software on any particular platform or whether it will even work at all. It doesn't grant TiVo the right to distribute the program without corresponding source code. They fail to distribute the source code to the functional signature derived from the kernel binary. Kaboom! As for the right to run the program, I've also explained why in Brazilian copyright law this is a right granted by the license, because the license says that right is unrestricted. Kaboom! > There is no need to take out contributions because the GPLv2 does > not prevent tivoization. Says you (or perhaps you're just repeating what you heard and want to believe). But what did your lawyer say about it? In reference to which jurisdiction? > A mutual compatibility agreement (sublicense) would effectively > terminate any rights granted by the GPLv2, Additional permissions to combine are not permission to relicense. Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1. That's the sort of additional permission I'm talking about here. The same kind of additional permission that GPLed projects that use openssl adopt. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > On Thu, 21 Jun 2007, Alexandre Oliva wrote: >> On Jun 21, 2007, [EMAIL PROTECTED] wrote: >> >>> this is your right with your code. please stop browbeating people who >>> disagree with you. >> >> For the record, GPLv2 is already meant to accomplish this. I don't >> understand why people who disagree with this stance chose GPLv2. >> Isn't "no further restrictions" clear enough? > everyone else is reading this as 'no further license restrictions' I didn't see anyone else add "license" where you did. "No further restrictions on the rights granted herein" is very powerful and extensive, and that's how it was meant to be. > not no hardware restrictions' becouse GPLv2 explicitly says that it > has nothing to do with running the software, only with distributing > it. It also says that running the software is not restricted, and since copyright law in the US doesn't regulate execution, receiving the software does grant the recipient the right to run the software. So the distributor can't impose restrictions on it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > It's this simple, those who chose the GPLv2 for Linux and their > contributions to it don't want people to create derivative works of their > works that can't be Tivoized. Do you agree that if there's any single contributor who thinks it can't be tivoized, and he manages his opinion to prevail in court against a copyright holder, then it can't? That this is the same privilege to veto additional permissions that Al Viro has just claimed? http://lkml.org/lkml/2007/6/13/293 http://lkml.org/lkml/2007/6/13/354 http://lkml.org/lkml/2007/6/14/117 http://lkml.org/lkml/2007/6/14/432 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote: >> Anyone who's not happy about it can still take that portion out, >> unless you accept changes that make this nearly impossible, which I >> suppose you wouldn't given how strongly you feel about this. > Oh, right. "Anyone who doesn't like proprietary code in the tree > can just remove it, what's the big deal?" analog. Sorry, doesn't work. Well, you do have proprietary code in Linux, and it's definitely not easy to take it all out, so, point. However, the difference that you appear to be missing is that when you get code under GPLv3, or under this hypothetical combination of GPLv2 and GPLv3 code, everyone who received the combination could still do everything the GPL says they could do: run the code for any purpose, study it, adapt it, modify it and distribute it, with or without modifications, under the same conditions, to the recipient, without imposing any further restrictions. The only thing that changes is that, for GPLv2, there's a possibility that some licensees might be able to get away not permitting other licensees to do the things the license you chose permits them to do, using tricks that have been invented or that became matter of new laws since GPLv2 was published. But this doesn't mean GPLv2 unambiguously permits this behavior; that you want it to doesn't make it so for all contributors. Just like you have the right to veto any additional permissions on Linux, so can other contributors. And unambiguous permission to tivoize is an additional permission, just like permission to combine code with GPLv3 is an additional permission. Heck, even the requirement to provide source code under GPLv1 and GPLv2 is a clarification along the same lines of the new provisions of GPLv3. Denying access to the source code is a restriction on the exercise of the rights granted by the license. So it's implied. But since some people might not see it that way, it's spelled out in full. Same deal with patents in GPLv2, and all the other new provisions with GPLv3. What makes them incompatible is not that they impose new restrictions (they really don't), it's that they remove any doubts about that. >> I can see that one-way cooperation could be perceived as unfair, even >> if permissions granted by GPLv3 are all granted by GPLv2 as well. > ... but not the other way round. So in effect we get a change of kernel > license, GPLv3 people *do* *not* get any license changes on their projects. > And you are saying that it's not one-way? GPLv3 people *do* get license changes too. This can be accomplished with additional permissions on both licenses with the current GPLv3 draft. I'm proposing that this backward compatibility could be a built-in feature of GPLv3. As to whether this has any effects on GPLv3 projects, it does. It weakens the legal defenses for the entire project, in as much as the wholes in GPLv2 might still be exploited. >> > ... except for that pesky "no added restrictions" part, but hey, who >> > cares? >> But see, nobody would be adding restrictions to *your* code. > What you are saying is "but your code will be still > available under GPLv2". No, I'm saying far more than this obvious conclusion, on which you apparently stopped thinking. I'm saying the project that uses it won't get as strong legal defenses as it would get if it were under GPLv3. So, yes, both sides sacrifice some of their stances in order to enable mutual cooperation. Sure, if you don't want to do that, that's your call. But don't try to frame it as if there was something wrong or unfair about it. > So it will be if e.g. SCO pulls it into proprietary codebase. Except that then I won't be able to enjoy any of the rights that you meant me to enjoy as to the code that SCO distributes. Whereas with combination of GPLv2 with GPLv3, every licensee still gets all of the same freedoms respected. The difference is only as to how much they can deny other licensees the freedoms you meant them to get. And if someone cares about using your code to deny other licensees freedoms, they still can. Depending on how much you intermingled your code with code that doesn't want to permit this, it will be more or less difficult to do, but it can be done. > The first change in v3 project affecting both imported v2 code and > native v3 one will create a big problem. Why? The licenses permit combination/linking, each portion remains under the same license as their authors meant. >> > ... because it's For The Benefit Of User Freedoms!!! >> It is either way. Do you deny that tivoization also benefits one >> user/licensee? And in detriment of others, while at that? > You know, we have another wanker here starting another thread from > hell - one about
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > My point was that your signature does indicate your affiliation with a > lot of different organizations/companies, so unless you explicitly > state that you are not speaking on behalf of them it's easy to assume > you do. And then, I did that a number of times in the other recent long thread, whenever I made statements that could be construed as FSF's opinion. Now, this time I missed it, added the clarification just in case, and you pick on me. Puhlease! > Quoting from that web page: "FSF Latin America is a sister > organization of Free Software Foundation (FSF)" > So when your signature states that you are a "FSF Latin America Board > Member" and FSFLA is a "sister organization of Free Software > Foundation (FSF)" that, at least to me, implies some association with > the FSF. How does that make me an FSF Board Member, as you claimed at first? Yes, I'm a co-founder of an independent organization that, for sharing the same goals as other FSFs, was welcomed into the global network of FSFes. That we have the same goals does not imply I'm in any way associated with the FSF. Your faulty assumption and your attempts to paper over your mistake won't make it true. > No, it does not, but it's easy to mistake a post by someone posting > from a company email and including that company in their signature for > speaking for that company. Indeed, compiler engineers are often the bearers of company's voices. Not! > I'm simply replying to you that indeed it is not clear for whom you > speak with all that info in your signature and the email address you > post from. Understood. Thanks for doing that so nicely. I'm glad it's clear now. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > this is your right with your code. please stop browbeating people who > disagree with you. For the record, GPLv2 is already meant to accomplish this. I don't understand why people who disagree with this stance chose GPLv2. Isn't "no further restrictions" clear enough? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> On Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote: >> >>> A balance of freedom to the licensee and the licenser. It's my >>> opinion that GPLv3 potentially shifts the balance too far to the >>> licensee. >> >> It's more of a balance of freedom between licensee and licensee, >> actually. It's a lot about making sure no one can acquire a >> privileged position, such that every licensee plays under the same >> rules. (The copyright holder is not *acquiring* a privileged >> position, copyright law had already granted him/her that position.) > I do see what you're saying here. But it does take the away the > ability of a licensee to protect themselves from another malicious > licensee. Sorry, I don't follow what the "it" refers to in your sentence. > If the ultimate goal of the Free Software community is to get source > code out to the public, I think that was captured in GPLv2. That's a correct logical inference, but since the premise is false, the conclusion is garbage. GPLv2 goes far beyond getting source code out to the public. It contains the "no further restrictions" language, which is very powerful. It is pretty obvious that when Linus adopted GPLv2 he didn't realize it reached that point. That when Tivo invented Tivoization, he decided he wanted to permit this, and thus grants an implicit additional permission for anyone to do it with his code, doesn't mean other participants in the Linux community feel the same way, or read the GPLv2 the same way, and could be somehow stopped from enforcing the license the way they meant it. Ultimately, the current situation is that we have two mutually-incompatible license intents being used in Linux, and no matter how much those who want to grant the permission say so, this doesn't trample other contributor's rights to enforce the license they chose for their code. Especially those who started contributing long before the decision that "what TiVo does is good" was announced. Now, since these two license intents are expressed by the same license, and what the license demands is that derived works must be under the same license, they are compatible, but since the intents are distinct, what prevails is, as in any case of combination of different licensing provisions, is the most restrictive provision. So Linux does not permit tivoization today. Linus does, Linux doesn't. All this fuss about the anti-tivoization provisions in GPLv3 is just a consequence of reading the GPLv2 without fully understanding its intended consequences, not having foresight to clarify the intent to constrain the "no further restrictions" provisions to match the alternate interpretation, and opposing the removal of the ambiguity because it doesn't match the choice that *some* of the developers would like it to go. Who's the ambiguity good for? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Are you seriously suggesting that the Linux kernel source contain code with > various different licenses It already does. All the way from permissive Free Software licenses to GPLv2-incompatible non-Free Software licenses. > Over time, the code will get so combined and interwoven that the > intersection of all permitted licenses would soon apply to > effectively the entire kernel. If you don't keep things clearly separate, yes. I was honestly thinking more along the lines of ZFS as a separate driver than about your bringing GPLv3 code into the core of the kernel. But then, it would be your call either way. This option of mutual cooperation wouldn't work for either party if you're not willing to cooperate, and that's what I believe makes it fair. Now, if you guys can't recognize a goodwill gesture when you see one, and prefer to live in the paranoid beliefs that "those evil FSFers are trying to force me into a situation in which they'll then be able to steal my code", that's really up to you. Don't try to shift the blame of your decisions onto the FSF. One thing is missing the spirit of the GPL and using it to serve a different purpose, without realizing it doesn't provide you with exactly what you want (tivoization, for example); another completely different is to try to put it as FSF's fault that clarifications and amendments are desirable to ensure the ability for authors to enforce the intent of the GPL. > Unless, that is, GPLv3 makes itself compatible with GPlv2. Hey, but that was precisely what I was suggesting! Except that it wasn't with GPLv2 alone, because this doesn't work. Each copyleft license insists that it be *the* license. So, in order to be able to combine two copyleft licenses, you need mutual compatibility provisions in both. Which is what I was proposing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't >> > I take any >> > GPLv3 program, combine it with a few lines of Linux code, and >> > Tivoize the >> > result? >> No. This is not permission to relicense. This is permission to >> combine. Each author still gets to enforce the terms of her own code. > This makes no sense. We are not talking mere aggregation here, we are > talking developmental convergence. If I wrote some code that was in the > Linux kernel, how can I enforce the terms of my code (guaranteed write to > Tivoize) in the derivative work that it becomes mixed with? In just the same way you'd enforce it today: with help from a lawyer who understands these issues that you clearly don't understand. >> So a tivoizer would have to take out the code licensed under the >> GPLv3, and use only the code that permits tivoization. Same as today, >> but without the possibility of cooperation for licensees who don't >> tivoize. > I am baffled how this could possibly work. You understand that the GPLv2 > specifically guarantees that any derivative work will be Tivoizable and the > people who chose the GPLv2 specifically want it that way? Yes. And the GPLv2 code would remain that way. If GPLv3 had this provision I suggested, and you wanted to cooperate with some other project that offered GPLv3 drivers, then you could use them by adding the mutual-cooperation provision I suggested. Of course you're free to not want to cooperate with anyone else who doesn't share your opinion. That's your call. > If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want > people to be able to Tivoize any derivative work made from my work that is > distributed. This provision was not intended to prevent anyone from tivoizing your work or derived works thereof. It was only intended to enable you to use code from GPLv3 projects as long as these GPLv3 projects could also use your code. Mutual cooperation, as opposed to no cooperation whatsoever. I *think* lawyers would probably recommend you to keep code under different licenses in separate files, like you already do with code licensed under GPLv2-compatible licenses. I *think* that, with this pair of mutual cooperation provisions, you could even use code licensed under the Apache 2.0 license. And OpenSolaris drivers, if it's licensed under GPLv3. And you wouldn't be departing from your intent to enable people to tivoize your code, which you currently choose not to enforce even though GPLv2 might very well enable you to; you could keep on cooperating with people who understand GPLv2 doesn't permit tivoization, and you'd be able to establish mutual cooperation with people who choose a license that makes this point clear. It's not like anyone can safely tivoize devices with GPLv2 already, so refusing to cooperate with GPLv3 on these grounds buys you nothing. It is only a public statement of refusal to cooperate, with you are entitled to make, even if it comes off as silly because you chose a license that already contains the provisions for "complete corresponding source code" and "no further restrictions on the exercise of the rights granted by the license" that tivoizers fail to comply with. At which point one gets to wonder why you chose this license in the first place, if it doesn't give you what you want. FWIW, all of my (very few) contributions to Linux were made with the intent of not permitting tivoization or any form of restricting users freedoms. I guess this means, from now on, you'd stop accepting my contributions and take out whatever contributions I've made, since otherwise I'd be able to enforce them against tivoizers. And what's more, I could still use your code in my GPLv2 projects, and enforce that against tivoizers, and there's nothing you can do to stop me. So what exactly are you trying to accomplish by pretending that mutual compatibility with GPLv3 would set you back in any way? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 21/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > [snip] >> >> BTW, I should probably have made clear that, as usual, I was speaking >> my own mind, not speaking on behalf of FSFLA or Red Hat, with whom I'm >> associated, and certainly not on behalf of FSF, with whom I'm not >> associated. Just in case this wasn't clear yet ;-) > Given your signature below, no, that's not at all clear : Do you assume I speak for the GNU project and for University of Campinas as well, just because my signature implies that I am somehow associated with them? >> FSF Latin America Board Member http://www.fsfla.org/ > If you don't speak for the FSF then adverticing the fact that you are > a FSF board member seems a little odd. What's odd is your assuming that I'm an FSF board member. Especially when there's a URL just next to it that explains what FSFLA is, and how it's not the FSF, but rather one of four members of the network of FSFs. > I also fail to see (or at least wonder at) how a board member of the > FSF can state that he's not associated with the FSF... hmm, the mind > boggles.. Yeah, it's really hard to clarify broken assumptions and jumping to conclusions. >> Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} > Same thing for the RedHat bit here, along with posting from a > @redhat.com email addr. Why would this convey the impression that I'm speaking on behalf of Red Hat, tell me. It doesn't even say I'm president, CEO, PR manager, press contact or any such thing... If I posted from my ISP e-mail address, would you assume I was speaking for the ISP? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > On Thu, 21 Jun 2007, Alexandre Oliva wrote: >> If it's input-only, then you can't possibly harm the operation of the >> network by only listening in, can you? > Ok, so you consider any anti-piracy measures to be something that > GPLv3 should prohibit. In general, I object to the use of my code in ways that don't permit users to run it for any purpose, study it, adapt it to suit their own needs, modify the code and distribute it, modified or not. If this means my code can't be used to implement DRM, that's a good thing. All anti-piracy measures I've ever known deprive users of legitimate rights too. So, yes, I don't agree with these measures. I believe in punishing the guilty, not in punishing innocent bystanders just such that the guilty have to find work arounds to become guilty. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote: >> - the kernel Linux could use code from GPLv3 projects > ... and inherit GPLv3 additional restrictions. No. Respecting the wishes of the author of that code. Are you suggesting they should not be respected? Anyone who's not happy about it can still take that portion out, unless you accept changes that make this nearly impossible, which I suppose you wouldn't given how strongly you feel about this. Without this provision, you wouldn't be able to use the code in the first place, so I don't perceive any loss for anyone. Do you? >> - GPLv3 projects could use code from Linux > Oh, rapture! How could one object against such a glorious outcome? Exactly ;-) Two-way cooperation. I'm told that's good. I was told this was even desirable. I can see that one-way cooperation could be perceived as unfair, even if permissions granted by GPLv3 are all granted by GPLv2 as well. >> - each copyright holder would still get to enforce the terms s/he >> chose for his/her own code > ... except for that pesky "no added restrictions" part, but hey, who > cares? But see, nobody would be adding restrictions to *your* code. You'd only be enabling mutual cooperation with projects whose authors weren't happy about restrictions some licensees could impose on others (including the authors themselves). >> If you were to permit compatibility with GPLv3+ (rather than GPLv3), >> would you constrain it? Would something like: >> >> as long as the later version grants each licensee the same >> permissions as GPLv2, except for constraining permissions that would >> enable one licensee to deny other licensees the exercise of the >> permissions granted by both licenses > ... because it's For The Benefit Of User Freedoms!!! It is either way. Do you deny that tivoization also benefits one user/licensee? And in detriment of others, while at that? > No. Permission denied. Your opinion is duly noted. Thanks. > If somebody wants to dual-license *others* code, This is not about dual licensing at all, and this is not about others code. This is a decision you would have to make in order to enable cooperation between projects. If you don't want to make this decision, that's fine. Nobody can be forced to cooperate. This works in both directions. Don't try to frame those who want to respect and defend users' freedoms as uncooperative. This is *your* decision, and your decision alone. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, [EMAIL PROTECTED] wrote: > this is standard dual-licensing, not special just becouse both > licenses are GPL versions No, seriously, it's not, it's quite different. If you dual-license your code between GPLv2 and GPLv3, I could combine your code with code under GPLv3, distribute it, and if anyone tivoized your code, I might be able to enforce the anti-tivoization provisions against the tivoizer. With a mere permission to combine, I can only enforce these provisions over my own code. I see that, for tivoization, the end result is very much the same as an all-GPL, although the tivoizer still has the option of removing the GPLv3 code and hoping GPLv2's implicit anti-tivoization provisions are not enforced. This would be just undoing the additional cooperation that this additional permission would have provided. However, for other GPLv3 defenses, it would make a difference. For example, on the patent licenses that are implicit in GPLv2 and explicit in GPLv3. > and for people who don't like one or the other of the two licenses > this will not be acceptable becouse it would allow someone else to > take their work, modify it a bit, and release the result only under > the license that they don't like Which is precisely why I suggested this approach of permission to combine, rather than as dual licensing. Because then nobody could do what you say. > one of the big problems that people don't realize is that if it takes > GPLv3+ exception to be compatible with the apache license For the record, it doesn't, GPLv3 is going to be compatible with the apache 2.0 license, no additional exceptions needed. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> However, if GPLv3 had a permission to combine/link with code under >> GPLv2, *and* Linux (and any other projects interested in mutual >> compatibility) introduced an additional permission to combine/link >> with code under GPLv3 (or even GPLv3+, constrained by some condition >> if you will), then: > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't I take any > GPLv3 program, combine it with a few lines of Linux code, and Tivoize the > result? No. This is not permission to relicense. This is permission to combine. Each author still gets to enforce the terms of her own code. So a tivoizer would have to take out the code licensed under the GPLv3, and use only the code that permits tivoization. Same as today, but without the possibility of cooperation for licensees who don't tivoize. Sorry if this wasn't obvious, it was for me. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > On Thu, 21 Jun 2007, Lennart Sorensen wrote: >> You can't use this code if you cooporate with anyone that requires >> DRM systems. > I think their earlier versions did say this. Show me a GPLv3 draft that did it? Start here, section 3: http://gplv3.fsf.org/gpl-draft-2006-01-16.html > DRM does have some legitimate uses, for example redhat installations > not installing unsigned software is a form of DRM Doh. Then chmod og-r is DRM too. And stronger DRM while at that, since the user denied permission to read the file cannot take it back, whereas the verification of unsigned software is just a warning, that you can often bypass by telling the software to go ahead and install it regardless of signatures. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote: > A balance of freedom to the licensee and the licenser. It's my > opinion that GPLv3 potentially shifts the balance too far to the > licensee. It's more of a balance of freedom between licensee and licensee, actually. It's a lot about making sure no one can acquire a privileged position, such that every licensee plays under the same rules. (The copyright holder is not *acquiring* a privileged position, copyright law had already granted him/her that position.) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> how can the server tell if it's been tampered with? > I agree with this statement. Err... That's a question, not a statement ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > Apparently the only restrictions ever permitted are the ones the FSF > thinks of. Where does this nonsensical idea come from? How does it follow that, from FSF offering a licensing option to authors, you conclude that nobody could ever establish whatever other restrictions they liked? > So really what the GPL v3 wants to have is to make sure that the user > can reproduce from the sources a bit for bit identical copy of the > binaries? No, this is not enough to enable someone to adapt the software to one's own needs. > Too bad compilers that put time stamps and such into the > binary would make that imposible. This would be the copyright author imposing such a restriction, not the software distributor. > I don't think there is any way that can be written into the GPL that > can prevent all loop holes for how to make signed binaries. Which is one possible reason to explain why the FSF switched to the 'Installation Information' approach. > There doesn't have to be an agreement. The software company could just > release specs for a hardware design and let others freely go and build > them from that design. Aah, so the software company has designed a mechanism to restrict users' freedoms, and is just leaving it up to third parties to complete the implementation? I think these design documents could be used in a court to prove intent to impose restrictions on the users, but IANAL. >> However, if there's no such agreement, if the copyright holder has no >> copyright claims over the hardware or works shipped in it, there's >> nothing the copyright holder can do about it, and that's probably how >> it should be, since a copyright license (!= contract) can't possibly >> prohibit people from creating hardware limited in function, it can >> only tell people that, in order for them to have permission to modify >> or distribute the covered work, they must abide by certain conditions. >> And if they don't want to abide by the conditions, and they don't >> manage to obtain a license from the copyright holders that doesn't >> impose conditions they can't accept, they just can't modify or >> distribute the work. > But if the hardware ships with only code that simply waits for the user > to provide some code for it to isntall (which has to be signed in a way > the hardware likes), then the hardware has nothing to do with the > license of the software. Correct. That's pretty much what I said, isn't it? > I hope no one does this, but I still don't see how the GPLv3 draft deals > with this case, or even how it could deal with it. It doesn't, and it probably shouldn't. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > I went and made some comments on the draft, and they appear to no > longer be there a few days later. This would be very bad. Please let me know what they were about and I'll try to figure out what happened. Did you by any chance file them against an earlier draft? Those (for obvious reasons) no longer appear against the current draft, but they're still accessible by other means. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> On Wed, 20 Jun 2007 12:55:10 -0700 >> "David Schwartz" <[EMAIL PROTECTED]> wrote: >> > A key is a number. A signature is a number. They are neither >> > statements nor >> > instructions. The argument that GPLv2 prohibits Tivoization is >> > really and >> > truly absurd. It has neither a legal nor a moral leg to stand on. >> A computer program is a number too. > No, it's not. It can be expressed as a number, but it is not a number. By this logic, then a key is a key, and a signature is a signature. They can be expressed as numbers, sure. > A computer program is a set of instructions to accomplish a particular > result. It can be expressed as a number, but that doesn't mean it is a > number. A key is an input to a cryptographical algorithm, and a signature is an output. I could try to come up with more creative definitions, but you get the idea already. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > On Thu, 21 Jun 2007, Alexandre Oliva wrote: >> On Jun 21, 2007, [EMAIL PROTECTED] wrote: >> >>> no, one of the rules for the network is that the software must be >>> certified, >> >> In this case you might have grounds to enforce this restriction of the >> network on the network controller itself, I suppose. > how would the network controller know if the software has been modified? The loader could check that and set a flag in the controller. > what sort of signal can the network controller send that couldn't be > forged by the OS? Whatever the network controller designer created to enable it to do so. > how would you do this where the device is a receiver on the netwoek > (such as a satellite receiver) If it's input-only, then you can't possibly harm the operation of the network by only listening in, can you? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: > There, that right there, wouldn't it again require a 'nod' from all > those who have contributed to the kernel (because at the time they did, > the license was GPLv2 without any additions)? That's my understanding, yes, but IANAL. Similarly, any GPLv2 and GPLv3 projects that wish to cooperate with each other could introduce mutual additional permissions in the way I suggested, even if neither GPLv2 nor GPLv3 themselves make such provisions. This is a decision that copyright holders can make, in very much the same way that they can make their decisions as to permitting relicensing under newer versions of the GPL, or even older versions of the GPL. BTW, I should probably have made clear that, as usual, I was speaking my own mind, not speaking on behalf of FSFLA or Red Hat, with whom I'm associated, and certainly not on behalf of FSF, with whom I'm not associated. Just in case this wasn't clear yet ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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/
how about mutual compatibility between Linux's GPLv2 and GPLv3?
Here's an idea that just occurred to me, after all the discussions about motivations, tit-for-tat, authors' wishes and all. If GPLv3 were to have a clause that permitted combination/linking with code under GPLv2, this wouldn't be enough for GPLv3 projects to use Linux code, and it wouldn't be enough for Linux code to use GPLv3 projects. That's because GPLv2 would still demand all code to be licensed under GPLv2, and GPLv3 wouldn't permit this. However, if GPLv3 had a permission to combine/link with code under GPLv2, *and* Linux (and any other projects interested in mutual compatibility) introduced an additional permission to combine/link with code under GPLv3 (or even GPLv3+, constrained by some condition if you will), then: - the kernel Linux could use code from GPLv3 projects - GPLv3 projects could use code from Linux - each copyright holder would still get to enforce the terms s/he chose for his/her own code Does this sound like something that would make sense for your community, so as to maintain/increase cooperation between authors who love GPLv2 and those who love defense for freedom, while respecting each author's not-always-compatible wishes? In other words, does it even make sense for the FSF to consider introducing such a provision in GPLv3, that AFAICT, by itself, would have no effect whatsoever, since an additional permission would be needed for the GPLv2 side? If you were to permit compatibility with GPLv3+ (rather than GPLv3), would you constrain it? Would something like: as long as the later version grants each licensee the same permissions as GPLv2, except for constraining permissions that would enable one licensee to deny other licensees the exercise of the permissions granted by both licenses do, subject to translation to proper legalese (if that's at all possible)? Do you know of any other communities that are like-minded with you, that are sticking with GPLv2, that I could poll about interest in such a provision in GPLv3? Thanks, and sorry for taking your attention away from coding one more time. I hope you find it worth it this time. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > no, one of the rules for the network is that the software must be > certified, In this case you might have grounds to enforce this restriction of the network on the network controller itself, I suppose. Not that you should disable the network controller entirely (this would render the computer useless for many other purpose unrelated with blocking connections to your network). You could instead arrange for the network controller to send some signal that enables the network to recognize that the device is running certified software. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > frankly, I haven't checked the licenses on the software. I'd suggest > going to www.tivo.com/linux and download all the source for all the > different versions there. Yeah, thanks, I remembered someone had posted that URL the second after a hit Send :-( I've already got cmd.tar.gz and I'm looking at it now. Thanks again, > by the way, it looks like there is one wireless driver that they ship > in some releases but don't provide the source for. but if you plan on > going after them for that you better go after everyone who ships > binary kernel modules. Only copyright holders of Linux can go after them on matters of kernel drivers. Or is this driver derived from any software copyrighted by myself? Or did you mean the FSF, with whom I'm not associated in any way other than ideologically? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > how exactly can they prevent a system that's been tampered with from > accessing their network? By denying access to their servers? By not granting whatever is needed to initiate network sessions? And note, "it's been tampered with" is not necessarily enough of a reason to cut someone off, it has to meet these requirements: > when the modification itself materially and adversely affects the > operation of the network or violates the rules and protocols for > communication across the network. > (something even you say they have a right to do) as long as this right is not used by the software distributor to impose restrictions on the user's ability to adapt the software to their own needs. The GPLv3 paragraph above makes a fair concession in this regard, don't you agree? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: > On Thu, 21 Jun 2007, Alexandre Oliva wrote: >> On Jun 20, 2007, [EMAIL PROTECTED] wrote: >> >>> but the signature isn't part of the kernel, and the code that checks >>> the signature is completely independant. >> >> Well, then remove or otherwise mangle the signature in the disk of >> your TiVo DVR and see at what point the boot-up process halts. > I have actually done exactly that. what happens is that the bootloader > detects a problem and switches to the other active partition ane > reboots. ir neither of the boot partitions meet the requirements the > cycle will continue forever. Oh, too bad. That must be a bug in the boot loader, right? :-) BTW, since you got a TiVo... I'm writing an article on Tivoization, could you (or anyone else) please help me get information as to what other GPLed programs or libraries TiVo includes in their devices? Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: On Thu, 21 Jun 2007, Alexandre Oliva wrote: On Jun 20, 2007, [EMAIL PROTECTED] wrote: but the signature isn't part of the kernel, and the code that checks the signature is completely independant. Well, then remove or otherwise mangle the signature in the disk of your TiVo DVR and see at what point the boot-up process halts. I have actually done exactly that. what happens is that the bootloader detects a problem and switches to the other active partition ane reboots. ir neither of the boot partitions meet the requirements the cycle will continue forever. Oh, too bad. That must be a bug in the boot loader, right? :-) BTW, since you got a TiVo... I'm writing an article on Tivoization, could you (or anyone else) please help me get information as to what other GPLed programs or libraries TiVo includes in their devices? Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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 Jun 21, 2007, [EMAIL PROTECTED] wrote: how exactly can they prevent a system that's been tampered with from accessing their network? By denying access to their servers? By not granting whatever is needed to initiate network sessions? And note, it's been tampered with is not necessarily enough of a reason to cut someone off, it has to meet these requirements: when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. (something even you say they have a right to do) as long as this right is not used by the software distributor to impose restrictions on the user's ability to adapt the software to their own needs. The GPLv3 paragraph above makes a fair concession in this regard, don't you agree? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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/
