About the single-device license and the unreliability of BCR2000 hardware

Home Forums Support About the single-device license and the unreliability of BCR2000 hardware

This topic contains 3 replies, has 4 voices, and was last updated by Avatar of Christian Christian 9 years, 1 month ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #2460
    Avatar of prndrsn
    prndrsn
    Participant

    EDIT: I made the rookie mistake of not reading the FAQ properly. Some of my questions have already been answered. However, I think my proposed solution might still be worth considering compared to how replacement devices and license transfers are currently handled.

    My top left encoder suffers the problem of not responding unless turned very slowly. This began before I installed Zaquencer so it’s a problem with the unit. I
    probably should have seen about having it replaced before installing Zaquencer, but it worked decently enough for what I used it for previously that I could live with it. Turns out it becomes really annoying when trying to do live pattern manipulation in Zaquencer.

    I have discovered a possible solution, which I will write a separate post about, but I haven’t tested it properly yet.

    Theoretically, my BCR2000 is still under warranty. Technically I voided it when I flashed it, but it’s not as if anyone will know if I flash it with the original firmware before sending it back. It’s a good thing I’ve been too lazy to apply the stickers, hehe.

    I’m considering contacting the vendor to see if I can have it replaced, but that brings up a whole different issue: As far as I understand it, the Zaquencer license is not transferrable between devices, correct? I bought Zaquencer only a couple of weeks ago, so I’m not overly interested in purchasing another license just because I needed to have my unit replaced.

    I understand the reasons for the single device license, even though I am personally of the opinion that once you buy a piece of software (or hardware for that matter), private use should be unrestricted. I respect the decision of the vendor/developer however.

    Where the single device license becomes a real problem with Zaquencer has less to do with business/development philosophies, and more with the fact that it is widely known and accepted that the BCR2000 build quality is notoriously hit-or-miss and that it’s not unheard of for a brand new perfectly working unit to start exhibiting problems within weeks or days if you’re unlucky. I would have been quite pissed off if I had bought a new BCR2000 just for Zaquencer, installed it, and then it started failing a few days later. That would be €92 (including shipping and stickers) straight down the toilet. I can live with only being allowed to run a copy of Zaquencer on one device at a time, but the BCR2000 hardware is just not reliable enough to justify permanently locking Zaquencer to a particular device ID in my opinion. To me it greatly reduces the value of Zaquencer, even though it’s through absolutely no fault at all of zaq.

    I’ve been trying to think of an alternative authorization scheme, and I think I have a viable solution.

    If the challenge code had a static part based on device ID, and a random part for every installation, new response codes could be required and generated for every installation, and still only be valid for that particular device. It’s really a minor hassle to request a new code, I doubt most users reinstall very often.

    De-authorization could be made by a function for generating a de-authorization code in the same way. The de-authorization code would be submitted through a form and the response code would lock the device and present a confirmation code, submitted as proof that the device has been locked. Once this confirmation code is submitted and received, the device is removed from your authorized devices, allowing a new device to be registered and authorized in its place.

    There are some possible issues, and solutions to most, with this method:

    * Power outage after locking, but before sending the confirmation code.
    + Solution: after locking, the confirmation code is always shown on startup on a locked device.

    * Device has been sent for replacement prior to de-authorization, making proof of deactivation impossible.
    + Solution: ???

    * Device has suffered catastrophic failure and will not turn on/knobs can’t be operated, making input/deactivation impossible.
    + Solution: Send picture of smashed device with visible serial number (assuming the authorization is based on serial number) as proof of deactivation. Will require manual removal of the authorized device by zaq.

    * Device is reinstalled after writing down the confirmation code, but before submitting it, leaving you with a functional, although not reinstallable device.
    + Solution: Disable generation of installation response codes for that device ID when the request for de-authorization is sent until the deactivation confirmation code has been received.

    How does that sound?

    • This topic was modified 9 years, 1 month ago by Avatar of prndrsn prndrsn.
    #2463
    Avatar of alien_brain
    alien_brain
    Participant

    this is definitely a concern. its happened to me and others as well. im curious to see what Christian says. some good ideas here!

    #2471
    Avatar of Martin
    Martin
    Participant

    I can weigh in here a little bit, since I have had a short exchange of emails about this with Christian.

    Background: I bought a used BCR2000 off eBay with ZAQ Audio firmware already on it, but it came with 3 physically broken encoders.

    I managed to repair it eventually, but before I wrote to Christian to see if I may be allowed to switch to firmware to a replacement BCR2000 should I have to buy a new one.

    What his response (in essence) was is this:

    -> it IS possible to transfer your license
    -> he/they will check every single case if it is plausible and decide per case

    and he mentioned that the way they are transferring the license is about like this:
    1.) they have a special “delete” firmware which will operate similar to the challenge/response system and thus provides a proof for Christian that you cannot end up with TWO operational Zaquencers for the price of one – essentially a copy protection
    2.) after “deleting” ZAQ firmware from one unit, the resulting response code has to be sent to ZAQ Audio and will essentially result in a new license for your new BCR2000

    sounds rather safe to me – not too much hassle, in my opinion.

    #2473
    Avatar of Christian
    Christian
    Keymaster

    Hi prndrsn,
    thanks for sharing your thoughts about this topic.
    It is interesting for me to hear how this is perceived.
    I understand your motivation to write this is to help and smoothen the process and be able to convey more safety to the users, which I greatly appreciate.

    You´ve edited your post at the beginning, stating that you´ve read the FAQ in the meantime.
    For anyone following this thread, I´ll post the relevant section from the FAQ here again:

    Q: What if my BCR2000 with an installed Zaquencer license should break? Can I
    transfer the license?
    A: As a general rule, the Zaquencer license is bound to one BCR device.
    Still, if your BCR with a Zaquencer license on it should break, please get in touch with our customer service at support@zaqaudio.com. We don´t want to leave our customers hanging, but we will evaluate every case on an individual basis and reserve the right for asking for proof and denying the support request.

    This is our official policy regarding this topic.
    While it would be nice if we could provide our customers with more safety regarding a
    license transferral process, we can´t make any promises to avoid legal obligations.
    On top of that we also have to protect ourselves against software piracy and this is why we handle this on a per-case-basis.
    As a background, so far a bit more than 1% of Zaquencer users wanted their license transferred because of problems with their BCR.
    To work out a fully automated system in software is not a viable option for us at the moment because the number of cases is just too small and we´d rather invest the development time into new features of the Zaquencer itself.

    Thank you for understanding our one-device-per-license policy and respecting our decisions in this regard. I´d like to add to your understanding of this by saying that this policy is an absolute necessity for realizing the Zaquencer at all from a financial point of view. I acknowledge that this carries certain inflexibilities for our customer, which is not ideal. In the end though it´s a compromise I hope our customers a willing to make, with the benefit of getting such a product at all.

    Again, thank you very much for your input, and for voicing your ideas. It is really
    appreciated! I hope I could make it a bit more clear why the license system is how it is and that it really works in practice without problems.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.