On 14/04/14 15:18, Matthias Toussaint wrote: > Hi Joel, > > I used GPLv2 for a good reason (at that time). I wanted a strict > (and that actually can be enforced in Germany) license for free > software. GPLv2 worked for me (and had been used with success in > Germany severla time). The first draft of GPLv3 where a lot weaker > in Germany and quite US centric (which did not pleae me :). Also I > think that the DRM clauses (Don't get me wrong, I'm very much > against DRM) shouldn't be in there. If someone wants to use DRM, > his problem. GPLv3 is also a lot more complex than GPLv2 which > doesn't make it easier. All in all I got a bit pissed with Mr. > Stallman (getting a bit too religious with hist license). That's > why I've chosen v2 only. > > AFAIK the final version of GPLv3 is more friendly in terms of the > German Urheberrecht, which is also relevant for me beeing German. > Therefore I would be willing to lift it to GPLv3-only. I can't > agree to GPLv3-or-later as I lost faith in the FSF (and Stallman). > I don't want to be forced to automatically accept any future > changes in the license. > > Just to make it sure. GPL is still the best alternative for me (BSD > and the like won't dig it). >
Sure it's your code, and we respect your right to license it how you will. I'm really glad you're willing to relicense the code. It would be a great shame if a simple license incompatibility were to prevent us from benefiting from your work. What is the correct way to declare your code officially relicensed? > It has been a long time, since I worked last time on QtDMM. It's > actually a shame as it seems to quite popular (among the few people > that need it). So it might be good to keep the (simple to use) > standalone GUI for it. > >> had a quick look at the sigrok page. Looks like sigrok already >> supports more multimeter than QtDMM does !? Or are you looking >> more into the GUI part, means you need a DMM GUI for sigrok? I first started working on QtDMM because I was interested in your GUI code, but the cdmm code could have some useful things in also. It seems to me like there's a danger that your valuable work is going to decay away without your continued involvement, or the help of a community. And we need a GUI, so it seems sensible to me to not reinvent the wheel, and take advantage of your work. Then there are various options. We can either take over the maintainership of the code, or we make a friendly fork: qtdmm-sigrok, or you could join our effort if you want to. > cdmm (at least the driver portion of it) might be the most > interesting part for sigrok as it does the interesting stuff > (although I'm actually not too happy with the implementation. It > polls the device, as I couldn't come up with a good cross platform > solution that was not too complicated / had too many dependencies). > Maybe a SCPI interface for cdmm would be nice (it could translate > crappy chinese binary lcd segment output to SCPI <- Yes there are > multimeter that just output the segments of the display :) > > What do you think? So we have a serial port abstraction called libserialport. I was thinking there would be a roughly 1-to-1 mapping between calls to your serial port abstraction and libserialport. Therefore it would likely be quite easier to translate code across. That said, I'm not sure it's the right thing for us to do unless we also have the device on hand to verify the transfered code. > > Matthias > Thanks for your reply Joel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
