On Thursday 05 October 2006 19:45, Timothy Miller wrote: > > There's something I'd like to prevent, but which may be hard to > prevent.
Well, the goal of this discussion (at least from my side) was mainly to make a definition. Whether it can be completely protected by law is something else. After all, RMS' first freedom is the freedom to use for any purpose, and the GPL explicitly says that, as a copyright licence, use is outside its scope entirely. Still, if you don't have that freedom, it's not free software. Also, the law changes all the time. So let's not get bogged down into what is or isn't possible to implement in a licence given the current legal system, and instead focus on the "philosophical" issues if you will. > Someone could buy an OGD1 board and resell it all they > like. Fine. Someone could buy an OGD1 board and completely reprogram > it and resell it as a proprietary product. Fine. But I don't want > someone leaving the PCI controller on the XP10 intact, reprogramming > the S34000, and then selling it as proprietary product. In that > case, I want them to release the source to their design or pay a > licensing fee for the use of that PCI controller. > > The desoldering requirement is met. You can physically remove either > FPGA. But I want to declare the two FPGAs as being effectively one > device and that whatever's in one is license-bound by what's in the > other. Or in other words, what is in one chip is not merely > aggregated with what's in the other chip, simply by virtue of the > licensing of the PCI controller and the rest of OGA. I think this comes down to what the boundaries of the system are. What is considered part of the system, and what isn't? And it's not just about the hardware. If we have a chip with a nanocontroller, which runs some software, which is loaded into it by driver software running on a generic system, then arguably the nanocontroller, its software, and the driver, could be considered a single system. To a certain degree this boundary is arbitrary. The GPL declares any compile- and link-time interfaces to be "tight" in the sense that the GPL propagates across such an interface. The LGPL declares run-time (late) link interfaces "loose". The MIT licence declares all interfaces "loose". Authors can make "loose" couplings "tight": you can relicence a work derived from one published under the LGPL under the GPL. But you can't make a "tight" coupling "loose" (you can't relicence a work under the GPL under the MIT licence). So maybe we could declare certain interfaces "loose", just like you can publish a programme under the GPL with a special exception to allow linking to some proprietary library you use. For your PCI controller, you would have to declare the PCI interface "loose", but not anything else. But even then someone could take the PCI controller, add a new "loose" interface, and connect it to proprietary HDL in the 3S4000. So, we need the "tightness" of interfaces to propagate. If you connect something to a "tight" interface, then it can't have "loose" interfaces. That means that a new "loose" interface can only be added if all the rights holders agree, or if it can be built on top of an existing "loose" interface. That is, anything that connects to your controller via PCI can have "loose" interfaces galore, but anything else necessarily connects to some other internal interface in the HDL, and thus must have the same licence, and may not define new "loose" interfaces. I wonder if that would be too much of a limitation. Perhaps we need a third category of "standardised" interfaces? Which may always be added? But then you lose the protection you want... Lourens
pgpJfK44FTqBl.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
