Re: How Delegation Works, in 10 Easy Steps
* Branden Robinson: > Let me know if you feel this is an accurate characterization of the > Constitution; I've done my best, but I'm not infallible. Also, I'd > like to hear your thoughts on whether you think delegation is a tool > that I should use more. I appreciate your comments. You missed one point: Nothing in the constitution requires that delegations are made publicly. I'm very disappointed that you keep your delegations mostly secret, like your predecessors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Retailing
On Mon, Nov 14, 2005 at 05:44:25PM -0600, Peter Samuelson wrote: > > [Michael Poole] > > For example, GRUB and Linux are both licensed under the GPL. Both > > would be included with these retail systems and would be written to > > locate and call functions within the BIOS; that is, GRUB and Linux > > would be dynamically linked against the (presumably non-free) BIOS. > > It has long been a perception that the computer BIOS, like the kernel, > provides an API across which a program can execute without considering > the kernel a derived work of the userspace programs, or the BIOS a > derived work of the kernel. The same is not believed to be true of > shared libraries in a userspace application. > > I myself am not certain what the important distinction is between those > two cases, but this is very well established GPL interpretation dogma. I think it comes back to the *intent* of the "modules it contains" restriction. It's quite simple to build a binary-only shared object and modify a GPL-licenced program to use it, so if this were allowed the copyleft provision of the GPL would be severely constrained in the face of a determined software hoarder. On the other hand, modifying a kernel or a BIOS to provide this binary-only interface is quite a bit more difficult[1]. Looking at it that way, it becomes a lot easier to see why dynamically-linked libraries are targeted, while BIOSes aren't. - Matt [1] There aren't a lot of OSes to choose from to hack on, for instance, and the primary choice -- Linux -- is protected by it's own GPL sphere of invulnerability[2]. As for BIOSes, well, the argument goes double for that little pool of non-freeness. [2] Although if you were utterly determined to go through with it, I suppose you could write a non-free program to run in userspace, then write a GPL kernel module which called it, and then modify the GPL'd program to call the kernel module which would call the non-free program. I can't imagine how that would really escape anyone's attention for long, and while judges may not be particularly tech-savvy, they're certainly not stupid. signature.asc Description: Digital signature
Re: Retailing
[Michael Poole] > For example, GRUB and Linux are both licensed under the GPL. Both > would be included with these retail systems and would be written to > locate and call functions within the BIOS; that is, GRUB and Linux > would be dynamically linked against the (presumably non-free) BIOS. It has long been a perception that the computer BIOS, like the kernel, provides an API across which a program can execute without considering the kernel a derived work of the userspace programs, or the BIOS a derived work of the kernel. The same is not believed to be true of shared libraries in a userspace application. I myself am not certain what the important distinction is between those two cases, but this is very well established GPL interpretation dogma. > Has it simply gone unnoticed by those who campaign so hard to kill > competition? Not unnoticed. The ever-present issue of non-free driver firmware will ensure that nobody ever forgets to consider cases involving software that doesn't run in userspace or kernel space. Debian obviously can't *distribute* non-free BIOS or driver firmware, but I don't think anyone has been arguing that Debian kernels can't *use* the BIOS and other firmware supplied to the system by someone other than Debian. signature.asc Description: Digital signature
Re: Retailing
On Mon, Nov 14, 2005 at 08:12:06AM +0100, Peter Vandenabeele wrote: > On Sun, Nov 13, 2005 at 05:38:59PM +, Philip Hands wrote: > ... > > You should be careful not to give the impression that you are charging a > > license fee though -- you are allowed to charge a fee for the copy of > > the programs, or for the service of installing them, but not for the > > licenses (in the case of the GPL software at least, which covers most of > > the software in question) > > My understanding was different. > > Indeed, in GPL you are only allowed to charge for the price of the physical > copy (the CD, the shipment cost) when you are asked to provide the sources > after you already delivered the program (e.g. in binary format). Yes, as mentioned in the "Selling Free Software" document to which I referred, this is the only case in which you are restricted in the amount you can charge for a copy of a GPLed program. If you were always providing the source along with the binaries no such limit on the charge would exist. The fact that you are charging for a copy of a program and it's source does not mean that you are charging for the license. Clause 2.b) of the GPL reads: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. so you're not allowed to charge for the license. The reason being that if you were supposedly charging for the license then the implication would be that the recipient would have to pay you again to get a second license, which is not the case. > But initially (before you have not delivered any part of the program), you > can charge any price for the program, as long as you obey with GPL and only > relicense the program under GPL to the customer. You can do that repeatedly if they feel like paying you for it, but what you're charging for is the act of distribution, not the license. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
