Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official Pre-2.4 beta discussion thread
#11
ToyMaster458 Wrote:My only concern is that Charmed Quark has a way to decrypt these drivers in the case the original programmer goes to the moon in a balloon and can be taken over by another programmer that has the proper NDA in place.

Inasmuch as I am a lawyer, the easiest way to handle this is to write exceptions into the NDA to anticipate the issues raised by ToyMaster, so that in given real life scenerios where the programmer really won't care about the NDA anymore, Dean would be free to unencrypt per the express terms of the NDA.
#12
Dean Roddey Wrote:Protected drivers. We have some situations where drivers cannot be done because the folks who license the interface won't allow that interface to be seen by anyone who hasn't signed an NDA with them. Since CML is a virtual machine language, all the drivers are shipped as source and compiled on the fly when loaded, so it's not possible to hide the contents of CML drivers. We will provide a means for driver writers to encrypt the driver package when they export a driver (which is why CML was never stored as just text, because it needs to be able to support this.)
Just curious, can you give an example of this?
#13
How about offering encryption at a price. This would limit the amount of users that encrypted their code "Just Because" and would also generate revenue for you. $50/Driver to have a key that allows you to encrypt that driver.
David
Z-Wave World Magazine|Baltimore Hackerspace
"Why think outside the box when you could let the box think for you." - My take on Home Automation
#14
scott Wrote:Not sure if that is the intention, but it sounds like this encryption thing will be used as a vehicle to provide drivers for payment.
Too bad, since I like the openness of the CQC driver system, and created an open source environment, where everybody cooperated.
That same thought was going through my head also when Dean first mentioned driver encryption. But in the same thought I can see the need for this. Right now if a manufacturer has a protocol for their products that requires a NDA, Dean is the one who has to sign the NDA and developer the Driver in C++ which takes time away from CQC programming. And if Dean ends up not doing it due to either time or cost then CQC does not get that driver.

As far as programmers creating drivers for resell and encrypting them in some cases it is justified. For example if they have to pay a couple thousand for the protocol and sign a NDA or spend many, many hours developing the driver, they need some way of getting their investment back.

On the other hand, one of the big selling points of CQC is all the drivers are included in the price. Once drivers start costing money we loose this selling point and fall into the same category as other products like ML that charge for add-ons out side of the base product.

The only way I can see us controlling this is as a community as a whole. If someone creates a driver that does not justify payment, don't buy it!!
#15
As part of the driver "reconfiguration" task would it be possible to configure a manifest file to dynamically generate field request, and values.

for example, i have CQC Monitoring driver that can be used to monitor and send alerts on configured drivers and fields. if a manifest could enumerate what drivers are allready loaded into CQC, you could do things like have a user pick an existing driver to watch when this driver is loaded. Then you could changed it using the new driver "reconfiguration" stuff.

it would be really cool if a manifest could read/write databases or files on driver installation...then you could do things like build the DataLog DB database when it's loaded up, build dynamic web pages on the fly for installed drivers, etc.
~~~ B01nk
#16
ToyMaster Wrote:On the other hand, one of the big selling points of CQC is all the drivers are included in the price.
I know the open nature of the drivers is a big reason I signed up. If it cost me $15 extra for the Sony 777, I wouldn't be happy. If Sony made a 7777 as a 400 disk changer which handled Blu-ray, would you want to pay for that? Additionally, locking down drivers so that others can't change them for their personal (or the community) needs is another example. If the 777 driver was encrypted, just because, does it help the product that a whole new driver has to be written from scratch for a new Sony Blu-ray changer?

I was proposing that only Dean/Mark be able to encrypt rather than allowing that tool for the general public. Then users could submit drivers that had a real reason for encryption to them once they're done for encryption/inclusion.

Russ...
#17
I would love if there was a way to allow drivers to write outside the MacroFileRoot. I know the risks, I really do. If the driver configuration allowed limitation to the MacroFileRoot (and it'd really make sense to allow narrowing rather than just MacroFileRoot or all) by default, the end user would have to understand the risks of opening up everything.

Russ...
#18
I don't actually see how encryption promotes charging per driver - all it means is that you cannot see the source code, aka compiled code. I don't think it insinuates a license key to install it, in which case it's the same as the current scene.
ToyMaster458 Wrote:As far as programmers creating drivers for resell and encrypting them in some cases it is justified. For example if they have to pay a couple thousand for the protocol and sign a NDA or spend many, many hours developing the driver, they need some way of getting their investment back.
In this case, folks could see if there's enough other folks willing to contribute to pay for the protocol/NDA/dev time to help defray the costs. Or, perhaps it's worth $1K-$2K in value so they front it. They can ask for donations post-fact but not tie it to usage.

Quote:On the other hand, one of the big selling points of CQC is all the drivers are included in the price. Once drivers start costing money we loose this selling point and fall into the same category as other products like ML that charge for add-ons out side of the base product.

The only way I can see us controlling this is as a community as a whole. If someone creates a driver that does not justify payment, don't buy it!!
One more thing I know I'll do is to instantly go quiet/stop helping any CQC'er who damages the fabric of the open driver community by charging for drivers. If they're going to treat their fellow CQC-er in a non-CQC way, then I have no issue treating them in a non-CQC way.
------------------------------------
Some of my devices: Sonos, Aeotec zWave, Nest, Rain8Net, Various H/T
What's next: CQC-Voice, Brultech GEM
My vlogs: https://www.youtube.com/c/IVBsHomeAutomation
#19
Quote:for example, i have CQC Monitoring driver that can be used to monitor and send alerts on configured drivers and fields. if a manifest could enumerate what drivers are allready loaded into CQC, you could do things like have a user pick an existing driver to watch when this driver is loaded. Then you could changed it using the new driver "reconfiguration" stuff.

A driver selection prompt could be done easily enough.
Dean Roddey
Explorans limites defectum
#20
There won't be any key you have to get or anything like that. It just prevents you from seeing the source code, nothing else. The source code will just be encrypted on the disk so you cannot open it up and look at it like you can now. It looks pretty wierd now, because it's not just raw text, but still you can read it.

The immediate impetus for this is the C-Bus driver. They will not allow us to ship a driver in the product that is readable, so we cannot ship the C-Bus driver. You have to get a dispensation from Clipsal and then get the driver from Rohan. If we could encrypt the source, then we could ship the driver with the product, or at least make it much easier for Rohan to provide it to you.

But there wouldn't be any way for the driver writer to prevent anyone from loading the driver who has access to the driver pack. So it wouldn't be any different from now in terms of the issues of charging for a driver.
Dean Roddey
Explorans limites defectum


Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 41,754 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 7,322 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,300 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,910 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 87,644 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,804 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 197,129 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,502 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 489,144 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,314 11-01-2016, 10:32 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)