Re: [sigrok-devel] sigrok adapter for impulse

[Martin L. <mar...@ea...>]

Hi Thomas,

On Sun, Dec 08, 2013 at 05:17:54PM +0100, Thomas Haber wrote:
> 
> >Be aware that since the libsigrok and libsigrokdecode APIs are the
> >normal method of accessing sigrok functionality, you're going to be
> >on your own going through the CLI. It is intended as an end-user tool
> >and there is no guarantee that options, output formats and so forth
> >will not change without warning in future versions.
>
> I undestand !  Problem is that i'm not getting sufficient
> informations about the devices from it.  I would like to make the
> dialog more usable like a combo with the available devices or
> available rates.  With scan i get the device names but don't get the
> associated drivers/device.

The first thing in each line returned by --scan is the driver name,
which is what is required by the --driver option. You can get a list of
supported drivers, input/output formats and protocol decoders with
--version.  The --show option will list supported settings for a given
device.

You are welcome to submit bug reports or patches if you feel that
sigrok-cli could be improved by outputting additional information, but
do bear in mind that these would be considered in terms of whether they
improve sigrok-cli for the end user. It's not the aim of the program to
provide a machine-readable CLI mapping of all libsigrok functionality.

I would note also that although it's a commonly used guideline, the fact
of going through an existing CLI doesn't automatically imply compliance
with the terms of the GPL. The real question is whether what you are
producing is a "derived work" of the GPL code in the specіfic legal
sense of that term, which is harder to answer definitively.

To provide some comparison: Eclipse is often integrated with GCC, by
calling GCC on the command line and working with its output. In that
instance any other compiler could be substituted, so it's hard to argue
that the result is a "derived work" of GCC, and this is generally
considered OK.

In this case however, you are adding code specifically to interface with
sigrok - no other existing software could be substituted. As the level
of integration increases it becomes progressively harder to argue that
the result is not a derived work. There's a limit somewhere, and I can't
autoritatively tell you where it is.

Sorry for the lecture - I just don't want to see anyone running off
selling fancy software that looks for all intents and purposes like it's
linked with libsigrok but is actually calling sigrok-cli behind the
scenes for everything, and then claim that's permitted because some
dev said so on the mailing list...

Also: I don't speak for the rest of the project here, only for myself.


Martin