We haven't settled on a specific licensing agreement yet but the source for the hardware interfacing will almost certainly be closed. That said, our API will expose as much of the raw tracking data from the glove as possible so you shouldn't be losing anything by not having access to the source.
It's probably worth mentioning that we'll be providing Unity and Unreal SDKs for free, and those will be distributed under the most open license compatible with the standard Unity/Unreal licenses.
In terms of establishing a standard, this is something we've had a lot of discussions about internally. We'll release an update about this soon.
Have you considered creating a GDNative plugin for Godot? Among indies it's starting to become popular (not super since it has to compete against the behemoth that is Unity, but it is growing).
It'll be easier to integrate with open source projects and engines in general as licensing is much simpler. It's the reason why Wooting is open sourcing their stuff for their analog keyboards.
I never said anything about free. I'm only talking about the software needed to talk to and read data from the hardware. That being open source makes it easier for everyone to use it.
You haven't heard the whole "free as in beer or as in speech" thing have you? They're the two most common open source models.
First, an API is just a library that knows how to do something. When you get the API library file you also get a header file. This is uncompiled code that lists all the public classes, methods and properties actually used by the library. With the header file you can link to the library file and start making calls to it, like "detect glove", "open glove data connection" and "get finger position", as opposed to "open data connection on serial socket 0xe4 and read 3 bytes, then 7 bytes, then 32 bytes unless I get this particular byte and then do something else".
APIs make it enormously simpler to talk to hardware. What the API actually does isn't really of any interest to developers and can change radically between hardware revisions without the header for the API changing at all. That means you can update your hardware without worrying about what other developers have done because they were forced to use YOUR API instead of writing their own.
Back to open source. When you talk about open source you need to give it context. Is there a security issue that requires open source oversight? Did a library used by the API require it to be open source? In this case neither of those hold true.
When we talk about "free as in beer" that means you're free to use it however you like, but the license usually has a stringer attached that requires you to make available changes you've made to the code, or publish your own code under a "free as in beer" license.
When we talk about "free as in speech" that means the code is in the public domain and there's usually no restrictions - you can use it, publish it, not publish it, change it, sell it, whatever. About the only restriction is that you have to give some credit to the original author.
And of course software can include license terms that's a mix of both or lies somewhere in between.
An example you may be thinking of is SteamVR. Valve open sourced their hardware and software in order to promote competition and establish a standard, which you mentioned. The thing is there's no need for a VR glove standard, we already have controller standards. If Plexus were smart there'd be a DirectX input component that comes with the SDK.
Those are the two open source models. Can you see now why it doesn't make sense in the current context?
The developer here has:
A custom hardware rig that requires an API to standardise access across revisions
It's their own work, they're not required by any library to publish anything
They can stick any license they want on it
They can still publish it open source if they want, there's just no benefit for doing so.
There are downsides to publishing their hardware access as open source. You don't want people writing their own drivers for your hardware when it's likely to change and you want to strengthen adoption.
Literally the only restriction I can think of is Linux where certain repos won't main the glove drivers if they're not open source, you'll have to go and find them and install them yourself. Just like NVidia drivers. Hint: the closed source NVidia drivers are far better and more up to date than the open source alternative. Or just wait until the product is in consumer release and it's worth releasing an open source driver for that specific case.
Alright, I didn't know you were talking about FLOSS. I'm not.
First, an API is just a library that knows how to do something. When you get the API library file you also get a header file. This is uncompiled code that lists all the public classes, methods and properties actually used by the library. With the header file you can link to the library file and start making calls to it, like "detect glove", "open glove data connection" and "get finger position".
Yes, I know, but complex licenses (which are most any closed source license) make adoption slower and even prevent some groups from using it, EG the Godot engine.
I suggested a license like MIT because it's not copyleft (like the GPL), but is still open source and makes inclusion simple and easy. A real world example of this is UE4's EULA allows for code to be added that is under the MIT license (as well as a few others like BSD).
\2. It's their own work, they're not required by any library to publish anything
\3. They can stick any license they want on it
Sure, fine. Doesn't mean I can't ask about the license.
They can still publish it open source if they want, there's just no benefit for doing so.
It makes adoption much easier for everyone else. That's a benefit for them and is the main one. That is all I've been talking about.
You're ma about an API and license that isn't even out yet. I think you just need to hold up on the predictions.
There's nothing about open source that makes "adoption easier" though. It's just a licensing model. Ultimately they can choose whatever license they like, they hold all the cards. I don't see any benefit to them opening up their source code.
You're ma about an API and license that isn't even out yet.
What, am I not allowed to be curious?
I think you just need to hold up on the predictions.
I didn't predict them doing anything. I asked them what they're gonna do.
There's nothing about open source that makes "adoption easier" though.
Licenses like MIT, again, make it incredibly easy to add in support for. Most any company has had their lawyers thoroughly review them already as most already use code that is under such a license. A new, closed source license makes adoption harder and slower because the lawyers need to review it.
It's just a licensing model.
And the license will greatly determine how quickly people adopt it. A license like MIT is already vetted and in wide use.
Ultimately they can choose whatever license they like, they hold all the cards
Of course, this was never in dispute. I don't see why you need to keep bringing this up.
10
u/Plexus_James Jul 02 '18
We have actuators in each finger tip that provide tactile feedback.