On Sun, Dec 08, 2013 at 09:44:26PM +0100, Thomas Haber wrote: > > Discussing the GPL is always nasty.
It often ends up that way, yes. :) > I once asked the GPL guys themselves about a problem > and their answer was,i should ask a lawyer !! - unbelievable ! It's not really that unbelievable a response. The FSF wrote the license but that doesn't mean they can advise you appropriately on its implications for *you*. They can say what their intent was when writing it, and they can provide their own interpretations on various issues, and those may carry some weight in some situations. But it would be up to a court - not the FSF - to decide on what effect the terms of the license really have in the event of any serious dispute. In that situation іt would not be appropriate for the FSF to be advising you, and that's why they won't give individual advice. Of course, even if you did hire a lawyer to ask, you would probably not get a straight answer. :) But you would at least be getting qualified advice from someone who was required to be acting for your interests. > But i think your comparison is not correct. > The GCC plugin in eclipse is also specific to GCC, with GCC options > and GCC error parser. > Other compiler means other options and other error parser. > Same with Sigrok, plugin code is specific for Sigrok, > but i have other plugins for other external devices like opc. The > total does not depend on sigrok. > In both cases just the executable is called, no linking, should be > ok with GPL to my understanding !?! I'm not saying that having some code that is specific to GCC or Sigrok automatically implies a derived work. It is a quite straightforward and reasonable argument, that having such "adapter" code to help users use other programs, doesn't mean that the result is substantially derived from them. But it's not the case that "just calling an executable" is *always* permissible under the GPL, either. Consider the extreme case: you write a command-line program that lets you call any function of the libsigrok API with any arguments. You link that program with libsigrok, and release it under the GPL. Then you write another non-GPL library which calls that executable to do everything, and exposes the functionality to other non-GPL programs. By the "just running an executable is always OK" rule, that would be fine. Nothing non-GPL is linked to anything GPL. But it's quite obvious that the new non-GPL library would actually be very much a derived work of libsigrok, and thus subject to the terms of the license. So there is a limit somewhere; exactly where it is would be hard to define. I'm also not suggesting there's anything wrong with what you're doing now; it looks pretty reasonable to me personally. Also, your project as a whole is clearly usable without sigrok, and that would be a significant factor against it being considered a derived work. But if you think that going via a CLI is *always* okay, and are talking about how to extend sigrok-cli to make that easier to do... well, hopefully you see why I have some concerns about that point of view. > Have you been able to see signals with impulse ? > Would be very keen to get your impression. When I open a VCD file (generated by sigrok-cli from the random/1mhz_clock/1mhz_clock_1channels.sr file in the sigrok-dumps repository), and drag the trace to the view, I get what you see in the attached screenshot. It's like the view is zoomed way out, but the zoom controls don't seem to work, and playing with them seems prone to locking up Eclipse with 100% CPU. I gather that Eclipse 3.8 is somewhat abandoned, so perhaps this is just an issue with that version. I have also created a multi-port adapter with a Sigrok source per your instructions, but I don't see how to then use it. Martin ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
