On 07/06/2015 01:35 AM, Gert Menke wrote:

Can you describe the problem with a bit more detail? Gimbal lock
always is a problem with 3 axis rotation. One of the options to
prevent this is to use quaternions for the calculation I think.

Some other notes...

The class name MainWindow is a bit misleading. There are multiple
instances when more than one document is open. Having the event
loop for every instance might not be ideal (in case the library
supports multiple open calls at all).

Calling updateGL() in a timer is going to kill performance for
every non-trivial model. There is already quite a big issue with
render performance due to the legacy OpenGL code.

To get the code included in the official release it would need
to be separated (new driver class maybe?) as there seems to be
no Windows or OSX version of the library yet.

ciao,
Torsten.

Hi Torsten,

thank you for the quick answer.

Am 06.07.2015 um 03:26 schrieb Torsten Paul:

I am looking for a function
f(current_camera_rotation, rotation_values_from_input) ->
new_camera_rotation
that always does what the user expects, regardless of the current
orientation of the object.
(I would like to mimic the behavior of FreeCAD. Blender does it
differently and it's fun to switch between the two, but that's another
story. :-))

When I ignore y and z,
cam.object_rot.x() += x;
does exactly what I would expect: Tilting the controller around the x
axis rotates the object around an axis that is parallel to the camera's
x axis.
That is because X is the "outer ring" of the gimbal. Right?
But,
cam.object_rot.z() += z;
Always rotates around the object's Z axis, which may or may not be
parallel to the camera's Z axis. And the Y axis does something in
between.

I tried to compensate for the effects of the x-rotation for y and z:
double rx = x;
double ry = -cos(cam.object_rot.x()/180.*M_PI)*y +
sin(cam.object_rot.x()/180.*M_PI)*z;
double rz = sin(cam.object_rot.x()/180.*M_PI)*y +
cos(cam.object_rot.x()/180.*M_PI)*z;
but that does not cover all possible cases, and you can rotate the
object into a position where tilting the controller around the Z axis
actually rotates the object around an axis parallel to the camera's X,
not Z.

I imagine it might help to convert the gimbal angles to some kind of
rotation matrix, update the matrix according to the input values, and
convert it back to gimbal angles. That way you probably would not have
to worry about gimbal lock either.
I am not familiar with quaternions and I'm a bit embarrassed to say
that my linear algebra is quite rusty these days, so they might be
exactly what I described, but maybe not.

Good point. I'll look into that.

Ah, you are right. The timer only calls QGLView::rotate (and translate),
which in turn calls updateGL(), when there's actually a movement event
from the controller. However, there is indeed no need to call updateGL()
again in the timer. I'll remove that.

I agree. I'm was wondering what would be a good way to detect the
spacenav library at compile time and only activate the code when the lib
is actually available. I just tried
exists("/usr/include/spnav.h") | exists("/usr/local/include/spnav.h") {
message("spacenav found")
DEFINES += SPACENAV
}
in the openscad.pro file, and it works, but it's not particularly
elegant... Can I tell qmake to check for a file in INCLUDEPATH?
Also, suppose someone who has the spacenav header installed wants to
compile a version without spacenav support (i.E. for distribution), how
can I account for that? I don't know much about autoconf/automake (and I
believe this makes me a happier person), but I guess I am looking for
the qmake-equivalent of ./configure --without-spacenav here. Any ideas?

Gert

Am 06.07.15 um 01:35 schrieb Gert Menke:

Recently I bought a new 3Dconnexion SpaceNavigator to use with OpenSCAD
and FreeCAD on MacOS.

So do I. As Torsten mentioned already: There may be multiple instances
of the class MainWindow. So you can not put the device interaction into
it. I implemented a small class that cares about the USB IO and emits
translate, rotate and button event signals. There is only one instance
of this USB IO class. (Maybe I should make it a singleton.) The
MainWindow instances then connect slots to those signals.

I had a look into the spacenav library too. But it is more or less Linux
only. And, as far as I see it, it can not coexist with the 3Dconnexion
drivers. This is not acceptable for me on MacOS. The best way would be
to use the API of 3Dconnexion. But the license of the API is prohibitive
for Free- / Open Source Software. So I interface to the USB device
directly, reading and interpreting the USB HID reports. This proved to
be quite simple using the HIDAPI library. The later has the advantage of
multi platform support.

You can see my USB IO test code here:
http://forum.openscad.org/Need-help-to-support-3Dconnexion-SpaceNavigator-tp12962.html
It is written on MacOS. I tested it on Linux (Debian, using
hidapi-libusb) and it worked. Maybe you can give it a try with your device.

Same for me.

Attached is the current state of my hack. You need to drop in hid.c for
your platform from hidapi in additoin to the patch.

tschüß,
Jochen

Hi Jochen,

great to see that someone else is working on the same thing too.
I won't be able to work on this until I get home next week, but then
I'll definately have a look at your driver then.

Am 2015-07-06 22:47, schrieb Jochen Kunz:

Sounds good!

Huh. Whithout having looked at the code, I see no reason why it could
not coexist with the 3Dconnexion driver - IF you switch off the X11
event stuff that's mainly there for 3Dconnexion compatibility anyway.
I'm currently connecting to spacenavd via unix socket. I just have to
make sure that X11 does not try to use it as a regular mouse too, and
that I ignore all motion events when my window is not active.
But, assuming spacenavd cannot coexist with the 3Dconnexion driver, your
approach seems to be the best solution.
(Well, actually, fixing spacenavd would be the best solution, but I have
no idea how easy that would be.)

That's so sad and stupid. But then again, the 3Dconnexion drivers are
only available for a very limited number of platforms, and only
maintained for a limited time anyway. (I also have an old Labtec
Spaceball 4000 which still works fine with a RS232/USB adapter and
spacenavd. Even on my Raspberry Pi, if I wanted to. :-) )
(BTW: Doesn't FreeCAD use the proprietary drivers on Windows and OSX?)

I will!

The hack I have at the moment does work moderately well, but I'm still
trying to figure out how to do it completely right.

Thanks!
I will give it a try when I'm back home next week.

I'll attach the current state of my patch too, in case you're interested
in the rotation stuff (even though it's not perfect yet).

Gert

On 7/7/2015 1:56 AM, Gert Menke wrote:

dunno how it works on Linux but on win it seems to talk to spacepilot on
the level "below" regular driver api... I have the spacepilot (the one
HP was selling, not the spacey round new one) and for e.g. freecad don't
see any buttons, only the navigation thingy ... and any settings you
make in driver (sensitivity etc) is completely ignored by the freecad. I
got the dev pack for windows from the 3dconnexion and wanted to add
support for it to the openscad, just I got the dev pack only recently so
not yet even looked at it let alone tried to add support into openscad
:D ..

Von: "Bogdan Kecman" arhi.smece@gmail.com

With the ridiculous license for the official SDK, there is no legal
way to distribute an OpenSCAD version using that SDK (I'm assuming
part of the SDK will be linked to the applciation). You could build
a version for your own personal use, but as there are other options
and people are working on that, I guess it makes more sense to pick
one of those.

ciao,
Torsten.

On 7/7/2015 5:39 PM, Torsten Paul wrote:

I was not reading the license details (as I said, just got the files
recently and some work came and...) but I heard that before... now it is
probably possible to create a wrapper and allow a blob with their sdk to
be downloaded as part of non-open lib usable by openscad .. donno, will
look at it as soon as I have time, missing support for this pilot is a
fairly big issue for me .. so even making patch that works "just for me"
will "work for me" initially ...

otoh making "interface" in the openscad to allow external manipulation
of the 3d object would probably be a good thing irrelevant to the pilot
as then you can easily add support to rotate object controlled by
wiiiiii camera and ir markers on fingers or any other contraption we can
create :D .. so then when openscad export the interface for object
manipulation, we can create completely independent apps that talk to it
and move/rotate object :) ... i will probably try to solve "my problem"
this way.. it's just .. time ..

again, I just posted to say freescad is IMO not using the driver but
talks directly with the pilot since anything set in driver is ignored
and not everything is recognized properly (probably they test with that
aerodynamic version of pilot :D ) .. the "other" thing I wanted to make
myself with - if I make it and it's good enough I share it, if I don't
make it .. well what the hack, would not be the first time :D

On 07/07/2015 05:55 PM, Bogdan Kecman wrote:

No, wrappers don't fix license violations.

Sure, no problem as long as it's not distributed, that's fine.

With multiple people working on getting it to work, I do hope at
least some basic support is not that far away.

Yeah, that could be useful for a number of cases. It might not be
easy to find an interface that makes everybody happy, but I like
the idea :)

ciao,
Torsten.

Am 07.07.15 um 01:56 schrieb Gert Menke:

The driver / daemon jumps on the device and programs it. E.g. setting
the speed / acceleration, tuning the LED on/off, programming the LCD...
When the 3Dconnexion driver and spacenavd try to do this at the same
time I expect to get a confused device.

Something I thought about too. If the client library of spacenavd could
talk to either its own spacenavd or the proprietary 3Dconnexion driver
on all platforms, it would solve all problems. Unfortunately spacenavd
isn't there at the moment. But direct USB HID access turned out to be
that easy that I postponed spacenavd. For now I have enough to do inside
OpenSCAD. Once that is sorted out I may return to the USB HID versus
spacenavd problem.

Corporate lawyers... ;-(

Seconded. Maybe it is best to support spacenavd and direct USB HID
access. There should be no problem for OpenSCAD to use both at the same
time. If you have a newish USB HID install the 3Dconnexion driver and
use the USB direct route. If you have an old (serial) device install
spacenavd instead and be happy. OpenSCAD can probe both interfaces and
use what ever it finds. It is just a matter of trying spnav_open() and
hid_open() until one succeeds, then divert into the suitable subroutine
to do the rest.

AFAIK only on Windows. I tried on MacOS and FreeCAD did not react to the
Space Navigator.

tschüß,
Jochen

Am 07.07.15 um 17:55 schrieb Bogdan Kecman:

I thought about that too. I have some experience with DBus. Adding a
DBus RPC interface to control translation / rotation from outside should
not be that hard. (Once the SpaceNavigator stuff is done. Some parts of
the two problems overlap.) Then you'd need an extra program / process
that fills the gap between the 3dconnexion API and the DBus API of
OpenSCAD. You would have to distribute this as binary only. As it is a
separate process it would not infect OpenSCAD with any poisonous license.

But this would be overcomplicated, IMHO. Talking to the USB HID directly
proved to be simple and is much more efficient.

tschüß,
Jochen

On 7/7/2015 10:26 PM, Jochen Kunz wrote:

Why I think it is a good idea is because it seems that different 3dconn.
devices have slightly different protocol so supporting them all is going
to be pita ..  otoh with the interface supporting "any" device gets
pretty simple

Am 07.07.15 um 01:56 schrieb Gert Menke:

Forgot to mention: I have an old SpaceBall 2003. I used it with my SGIs.
But I never run more then the SGI confidence tests. I should dig it out
and see if I can get it to work with spacenavd. But IIRC it didn't work
anymore when I tried it last time, several years ago... Ahhh, I also
have the buttons and dials boxes... :-)

Attached is my current state of the affair. I moved the event handling
into class QGLView and I handle translate / rotate in separate methods
like you. I switched from signals for event delivery to QEvent
subclasses. This makes it easy to deliver events to the in-focus window
only. See SpaceNav::Impl::operator()( void). It should be easy to modify
for spacenavd.

The button handling needs a bit work. I noticed that this is slightly
different on MacOS compared to Linux and NetBSD. Maybe because the
3Dconnexion driver reprograms the device on MacOS...

The rotation problem is still unresolved.

tschüß,
Jochen

On 07/09/2015 12:34 AM, Jochen Kunz wrote:

Nice, I'll try to provide some simple framework allowing different
driver types. Maybe the events could be renamed to a more general
name to be used by other implementations too.

I've attached the hidapi.pri I'm using for testing. At least on
Debian, hidapi comes with pkg-config support. This should work on
Linux and MacOS (tested only on my Debian system so far). Windows
builds use the MXE cross build environment which does not seem to
have hidapi, but that should be easy to solve by either adding it
to MXE or including the two files directly. Good thing is MXE has
libusb already.

To use hidapi.pri, it needs to be added to (similar to harfbuzz)

openscad.pro:CONFIG += hidapi

common.pri:include(hidapi.pri)

ciao,
Torsten.

Am 09.07.15 um 00:57 schrieb Torsten Paul:

Realistically there are only two alternatives: Raw USB access (via
HIDAPI) or spacenavd. They can coexist and it seems there is no need for
runtime configuration to switch between those two. Detection can be
automatic. You probably wane compile time switches to disable one or
both options. I'll have a look at spacenavd later. The only Space
Navigator / HIDAPI specific parts are in SpaceNav::Impl::operator(). It
should be simple to add support for spacenavd.

There are more things to do. We want a configuration menu to assign
different functions to the buttons of the device. Probably we want a
local speed setting. I can't help much here as I have no clue about Qt
GUI programming. (And I am not much interested to gain that skill. I am
fine with "reconfiguration by recompilation". ;-) )

Depending how things work out it may be necessary to add some device
description. I.e. a way to determine the total number of buttons of the
currently connected device, nim. / max. axis scaling factor, ... For now
I avoided this, there are more basic things to do for now.

The SpaceNav classes could be renamed to e.g. SixDoFDev (Six Dimensions
of Freedom Device) or the like. They are not Space Navigator specific.

Thanks for the help. I plan to do some testing on Debian. But I have to
install it on my old laptop first... This way I can build an interface
to spacenavd based on Gerts work.

I haven't used it since 1993 and don't plan to change this in the near
future. So I can't provide much help in that department. ;-)

tschüß,
Jochen

On 07/09/2015 10:39 PM, Jochen Kunz wrote:

For the Space Navigator devices that's probably the case, but
there are other devices that could be used as well like joysticks,
the remote interface discussed lately or maybe there are other
3d mouse devices with more reasonable licensed SDKs.
No need for something hugely complicated, the event stuff you
wrote covers probably already quite a big part of it.

I think it makes sense to first get things working with same
sane default settings and add config options in the next step.

Yep, something like that.

Well, I'm not using it either except for testing. The number of
OpenSCAD users running the Windows version is quite large though,
so it does matter a lot. No need to worry, I'll try to take care
of that part (even if a bit grumpily ;-).

ciao,
Torsten.

tp3 wrote

Oh good, I was lurking while waiting for a Windows mention.
If there is a commitment (obviously no absolutes) to getting it working, I'm
happy to buy one and help with testing.

Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-tp13057p13114.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Am 13.07.15 um 21:41 schrieb Torsten Paul:

Congratulations. :-)

Probably this would be a worthwhile interface to add.

Have you tried spacenavd?
On Debian the libspnav-dev package comes with test and demo code. The
"cube" demo didn't work out of the box as it used the X11 protocol but
"simple_af_unix" did work.

I expect that we will go with spacenavd / libspnav on Linux. It seems
the best option there.

For MacOS it may be better to avoid HIDAPI and use the native MacOS
systemcalls.

The problem with rotation is gimbal lock. The "cube" example in libspnav
shows how to do the rotation and avoid this by using quaternions. I try
to understand this and port it to OpenSCAD. But my math-foo is a bit rusty.

Fits. The first byte is the report ID. What ID did you get? The
remaining 12 bytes are the six axes as int16_t. Can you determine how
this int16_t are mapped to the axes? And what is the USB vendor /
product ID? This information may be sufficient for me to add MacOS
support for this gadget.

Probably. What does "lsusb -v" show? Look for "Report ID" 1, 2, 3.

tschüß,
Jochen

On 07/18/2015 09:12 PM, Gert Menke wrote:

Cool.

I've just finished integrating the patch that Jochen posted,
it's now in:

https://github.com/openscad/openscad/tree/inputdriver2

First commit is basically the patch from the mailing list.

I've set Jochen as author as git does only support one, but
added you both in the about screen. If you want some link
added, let me know or just post a patch.
I've also added the default OpenSCAD licence to the drivers
and added the info about the initial Public Domain implementation
https://github.com/openscad/openscad/blob/inputdriver2/src/input/HidApiInputDriver.cc#L28
Let me know if that's ok for you both.

What I did in addition is:

• Separate into different driver objects
• Move to QThread as c++11 is not yet possible as default
• Collect some more USB IDs (totally untested)
• Add Joystick driver (works with my SpaceMouse Wireless
  without spacenavd installed/running)
• Add DBus Remote Driver based on QtDBus
• Make all drivers compile time optional

Both Joystick and DBus driver are quite rough still and
Linux only.

ciao,
Torsten.

Am 18.07.15 um 21:12 schrieb Gert Menke:

Not left? ;-)

Have a look at:
https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
Also look at the examples from libspnav in libspnav-0.2.3/examples/cube
which is an example implementation of rotation using quaternions.

I tried your code and it is much better then the current state of the
affair. But it still has a problem: The rotation originates at the
origin of the view / camera. It should rotate the object around the
origin of the object. This is easy to see when you move the object away
from the view / camera origin. Try the cube example from libspnav, this
does it right. (Not left).

I handle event reception in an extra thread and send custom QEvents to
the window in focus. Also I support libspnav (for Linux) and HIDAPI (for
MacOSX and possibly Windows) at the same time. See attached code.

There is an other reason: To get X11 events the spacenavd needs to
connect to the X11 server. To do so you have to start it from your
~/.xsession to get the needed authorization credentials. At least Debian
starts spacenavd at boot time, so it can't connect to the X11server as
it has no authorization credentials. Thus no X11 events from spacenavd.
The AF_UNIX way still works, as it is independent from X11.

Please don't troll. ;-)

tschüß,
Jochen

Hi!

Am 18.07.2015 um 22:00 schrieb Torsten Paul:

That's great!

Fine by me, but to be fair, I don't see much of my code in there...
So if you're adding me to the about screen, please take my rotation
code. ;-)

Regards
Gert

Hi,

Am 18.07.2015 um 22:53 schrieb Jochen Kunz:

:-P

I have looked into quaternions a little, but the thing is that the
camera object still wants euler angles. And since the conversion to a
rotation matrix was already there, it seemed natural to use that.

Well, personally, I find it more intuitive to rotate around the origin
of the view.
Take for example an scad file that contains several objects that belong
together and are placed next to each other. When I want to inspect, say,
the leftmost object, I place it in the center of the screen and zoom in.
Then, rotating around a point that is currently off-screen would be
irritating to me.

You can use "spnavd_ctl x11 start" to tell the daemon to connect to the
X server once it's started. That works, but it's still a bit of a pain.
I'm glad we don't need to to it that way.

It's a personal thing between X11 and me.
I won't mention it again, promise. ;-)

Regards
Gert

On 07/18/2015 11:32 PM, Gert Menke wrote:

Yep, that's next on the list :-). Thanks for getting this to
work.

For now I've added a decoder for the different HIDAPI values my
Space Mouse Wireless produces and fixed the Windows compilation.
While my test setup is a bit unusual (Windows7 VM running on a
remote server + USB redirection of the 3D mouse from my Notebook),
I guess it should work on a normal Windows system too.

Multiple OpenSCAD-Windows of a single instance work fine, I'm
not yet sure how to support multiple OpenSCAD instances.
Probably this would mean to close the HID device when losing
the focus. Right now only the first instance is able to open
the device and the connect polling got lost in the driver
separation changes.

ciao,
Torsten.

tp3 wrote

I just ordered one, so can help with some testing shortly.

Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-tp13057p13246.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Am 18.07.15 um 23:54 schrieb Gert Menke:

Yes. As I understand things it is easier to calculate with quaternions
then linear algebra with a matrix. They also avoid gimbal lock. Thats
why they are preferred e.g. in robotics. You need conversions in both
cases and they are equivalent.

[...]
Probably this is a matter of personal taste or prior experience. The
demos from 3Dconnexion, libspnav and SGI (IIRC) rotate around the object
origin.

"spnavd_ctl x11 start" didn't work for me due to privilege separation
issues.

tschüß,
Jochen

Am 18.07.15 um 23:32 schrieb Gert Menke:

I took some "inspirations" from your code to refactor my code. (E.g.
separating translation and rotation in methods of calss QGLView, using
spnav for Linux.)

tschüß,
Jochen

On 07/19/2015 05:02 AM, MichaelAtOz wrote:

:-)

I've uploaded snapshots from the inputdriver2 branch to files.openscad.org

OpenSCAD-2015.07.20-x86-{32,64}_inputdriver2*

Right now, no config at all. I guess we want something similar
to the config UI FreeCAD has:

http://www.freecadweb.org/wiki/index.php?title=3Dconnexion_input_devices

ciao,
Torsten.

Thanks, I'll let you know how it goes when I get it.

Also I tried.... failed. Wasn't expecting much, but had to ask. See thread
below:

Hello Michael,

thank you for your interest in our products. We appreciate your dedication
to support the developers to integrate the support for our 3D mouse into
OpenSCAD.

Can you perhaps explain why you think that our license is prohibitive?

Regards,

Uta

From: 3Dconnexion Team [mailto:info@3dconnexion.com]
Sent: Friday, 10 July, 2015 02:38
To: support.us
Subject: Licencing for use with FOSS?

language: ENG
salutation: Mr.
first_name: Michael
last_name: Marx
company:
email: oz.at.michael@gmail.com
phone:
extension:
country: AUS
product: SpaceMouse Wireless
serial_number:
connector: USB
driver_version:
os: Linux
application:
summary: Licencing for use with FOSS?
description: Hi,

I'm a user of OpenSCAD, I am not part of the official developer group, but
help out with bug fixes and testing etc.

A forum thread has started looking to support your devices, however comments
say:
"The best way would be to use the API of 3Dconnexion. But the license of the
API is prohibitive for Free- / Open Source Software."

So they are looking to support it via HID.

OpenSCAD is free, as in http://www.gnu.org/philosophy/free-sw.html

So cannot include non free components.

Is there any chance you can release something under an open license to allow
wider implementation into FOSS products? Perhaps a bare bones driver? I
imagine you would sell more hardware.

Regards,
Michael
REMOTE_ADDR: 60.242.97.120
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
Firefox/38.0
DATE: 00:38:01 2015-07-10

!!!
Note: If you send an answer to this email please use the "Reply" function of
your email client and do not change the subject. Otherwise your email will
not be processed.
!!!

3Dconnexion Technical Support

Clarita-Bernhard-Str. 18
81249 Muenchen
Germany

Tel:  +49 (89) 897 45 42 - 44
Fax:  +49 (89) 897 45 42 - 50

TechnicalSupportWW@3dconnexion.com

www.3dconnexion.com

Geschäftsführer: Antonio Pascucci
Sitz der Gesellschaft: München
Registergericht: München HRB 99232

From: OzAtMichael [mailto:oz.at.michael@gmail.com]
Sent: Monday, 20 July, 2015 03:07
To: 3Dconnexion Technical Support
Subject: RE: [CASE:68455] Licencing for use with FOSS? [3DCX-20150710-0004]

Hi Uta,

To a degree, this is not an issue as they appear to have got the HID driver
version working (at least on one platform) and are fine tuning it.

However for your edification I’ll list a few points, seeing I already wrote
them…

The definition of Open as applied to OpenSCAD is from
http://www.gnu.org/philosophy/free-sw.html (hereafter referred to FREESW to
save my fingers) it would help if you read it as it gives the ‘flavour’ of
the concept. Specifically it uses the GNU General Public Licence (hereafter
referred to GPL), various formats are available here
http://www.gnu.org/licenses/licenses.html#GPL. To quote FREESW “Roughly, it
means that the users have the freedom to run, copy, distribute, study,
change and improve the software.”

OpenSCAD is also in a number of distributions to FOSS operating systems
(Linux and BSD based),  MacOS and available for MS Windows.

Some of the FOSS distributions are known to be fanatical in their
application of the terms of open licences. One recent example was a
requirement, by Debian IIRC, to remove a small Flatter icon/link (called
‘The Button’ by Flatter) in the OpenSCAD Help/About screen because the
Flatter Licence for The Button did not meet the FOSS standards. Specifically
at https://flattr.com/terms, Clause 7, para 4, “All rights, titles and
interests in and to any Button, including but not limited to all
intellectual property rights, are the exclusive property of Flattr. Each
Site Owner acknowledges and agrees that the Buttons are provided by a
non-exclusive licence, and not sold or transferred, as part of the Service
and that he will not use them for any use other than his permitted use of
the Service.” therefore it is viewed as a restriction, not free.

The OpenSCAD development & support community has members who are fully
versed in S/W Licencing and take it very seriously. Many are commercial
software developers.

In terms of your Licence, I (and others on the OpenSCAD forum) read the
licence for the SDK at
http://www.3dconnexion.eu/service/dla-programistow/licence-agreement.html
(hereafter referred to SDKL).

I presume that is the applicable Licence?

Where I quote text from the SDKL I will italicise it. Where I quote from the
FREESW or GPL definitions I will underline it.

Below I show sections of your SDKL and relevant conflicting terms from the
GPL or FREESW.

SDKL Clause 1. “Subject to … grants to you a…, revocable license …distribute
in object code form the 3DCONNEXION SDK.” & “In addition no license is
granted under any patents that may be or later become infringed by your
modifications or derivative works”

GPL Preamble “For example, if you distribute copies of such a program,
whether gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive or
can get the source code.” and be able to distribute the source code, – I
also suspect revokable would be an issue. FREESW “The freedom to run the
program as you wish means that you are not forbidden or stopped from doing
so.”

GPL clause 11. “Patents”, I’m not as knowledgeable about patents, but at
face value this clause is in conflict with SDKL Clause 1.

SDKL Clause 2. ‘In the format set forth below, you must provide attribution
…"3D input device development tools and related technology are provided
under license from 3Dconnexion. © 3Dconnexion 1992 - 2013. All rights
reserved." ‘.

All rights reserved is in conflict with the GPL. While FOSS and GPL do allow
(and in some cases proscribe) attribution, it is in accompanying copyright
documents or source code. It does make allowances for a copyright and
warranty disclaimer to be displayed. I suggest the ‘must’ aspect would be
viewed badly, as too prescriptive.

SDKL Clause 3. “Restrictions”. Just not compatible with FOSS.

SDKL Clause 5. “Confidentiality”. Ditto.

That ends the discussion of licensing.

If (and as I did not agree to the licences, so I did not download the SDK,
and hence don’t know), the SDK requires the use of the 3DxWare driver to
integrate with other software, the absence of Linux support would rule out a
high proportion of the OpenSCAD user community.

So my original suggestion of the possibility of releasing a bare bones
driver under GPL (or compatible) license. Without your most precious trade
secrets.

I understand companies producing graphics cards and other peripherals have
managed to release GPL compliant drivers in some way. Possibly resulting in
their lawyers having a coronary ;)

Regards,

Michael.

p.s. I have just ordered a SpaceMouse.

p.p.s. There is not much discussion re Licencing, but the HID support is
discussed in the forum at:
http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-td13057.html

Hi Michael,

thank you for sending the information. The licensing stuff seems to be
rather complicated. At least for a Technician like me. ;)

The direct access of our devices seem to be the only way then to implement
it in OpenSCAD. This works fine as long as you are using a device that was
known by the developers at the time when the development was done. If
3Dconnexion launches a new device the developers have to make sure this
device is recognized by OpenSCAD, too. Additionally problems will occur if
someone is using OpenSCAD together with an application that has implemented
the support for the 3D mouse by using our SDK and therefore is using our
driver. But this might not be the case – or not your problem then. ;)

Let me know if you have any further question. Thanks.

Regards,

Uta

Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-tp13057p13257.html
Sent from the OpenSCAD mailing list archive at Nabble.com.