@Arachnid lumenier lux is closed hardware, can you confirm you're now supporting requests for closed hardware ?

@hakirari I assumed the hardware the PID was requested for was in the linked repo, but it appears that contains source for the firmware, and design files for different hardware.

@mlyle Can you clarify please, what hardware this PID is intended for, and what license it's available under? If it's not open-source, or you're unable to respond, I will be obliged to revoke the PID.

@Arachnid It is for our firmware to support outside closed hardware. The project says "open source software or hardware". I explained that in this comment: #122 (comment)

Note that we are a software-only project and support many other flight controllers, open and closed. Other ones have pre-existing PIDs/VIDs. This one doesn't, and for us to support it effectively it needs one while it is running our open-source firmware.

I'm sorry that I missed that comment initially.

Why can't the producers of the hardware obtain a PID themselves? Alternately, why do you need a PID per device that uses your software?

@Arachnid We have no association with the vendor of the hardware. It ships on top of another firmware (Cleanflight, where apparently @hakirari comes from).

We can hardly use the PIDs belonging to other vendors of hardware for this device. We need a VID/PID pair so we can talk to it with USB. No VID/PID pairs belong to our project.

So to clarify, the manufacturer ships with different firmware; you're obtaining this PID so users can flash your open source firmware to hardware they've purchased?

Does the PID need to be specific to this piece of hardware, or would it be useful to have a PID assigned to your code regardless of what device it's deployed on?

So to clarify, the manufacturer ships with different firmware; you're obtaining this PID so users can flash your open source firmware to hardware they've purchased?

Yes.

Does the PID need to be specific to this piece of hardware, or would it be useful to have a PID assigned to your code regardless of what device it's deployed on?

Ideally it'd be specific, because we have a bootloader and currently our code decides what firmware is legal to update to the target by USB VID/PID (and announces what flight boards are plugged in by USB/VID before you click "connect")

Basically, our users tend to have several flight controllers. They can buy a Lux, hold down the boot button, go into OpenOCD and flash one of our "entire firmware" images. After that, they can interact with the flight controller in our ground system, update the firmware, along with all their other ones-- usually telling them apart currently by USB device IDs.

On the other hand, we're not planning on adding many targets soon because we're drowning in maintenance. This one was a special case because it's cheap and looks nice and we think it'll make it easier for new users.

Fair enough, and thanks for clarifying. I've clarified the howto,
specifying that if you're producing both hardware and software, both need
to be oss; if it's just one, additional justification may be required.

The motivation here is that I really don't want to subsidise a company
producing closed source hardware and using someone else's code by offering
them a free pid; but I'm totally fine - enthusiastic, even - about groups
like yours who are using oss to make stuff work better.

Thanks for your patience, and best of luck. If you need more pids for
similar reasons in the future, please don't hesitate to file another pr.

-Nick

On Wed, 9 Dec 2015 17:43 Michael Lyle notifications@github.com wrote:

So to clarify, the manufacturer ships with different firmware; you're
obtaining this PID so users can flash your open source firmware to hardware
they've purchased?

Yes.

Does the PID need to be specific to this piece of hardware, or would it be
useful to have a PID assigned to your code regardless of what device it's
deployed on?

Ideally it'd be specific, because we have a bootloader and currently our
code decides what firmware is legal to update to the target by USB VID/PID
(and announces what flight boards are plugged in by USB/VID before you
click "connect")

Basically, our users tend to have several flight controllers. They can buy
a Lux, hold down the boot button, go into OpenOCD and flash one of our
"entire firmware" images. After that, they can interact with the flight
controller in our ground system, update the firmware, along with all their
other ones-- usually telling them apart currently by USB device IDs.

On the other hand, we're not planning on adding many targets soon because
we're drowning in maintenance. This one was a special case because it's
cheap and looks nice and we think it'll make it easier for new users.

—
Reply to this email directly or view it on GitHub
#122 (comment)
.

Thanks for taking all the time and the valuable service you're providing. :) We're excited to be able to move forward (and are amused by having the [STM32] F3 Flight Controller 0xF3FC PID).

Hi,

so sorry guys I caused so much confusion. The mistake is mine, I wasn't sure about the opensource software clause. Thanks a lot for the clarification.

As @mlyle implied some vendors do decide independently what they ship their boards with, some of them are just abusing the oss and selling degenerative clones !

dronin had started supporting this board way before it was even publicly announced, imho the vendor should have the balls to osh and start shipping it with dronin !

congrats for the nice PID btw ;-)

@hakirari No worries - this is something that definitely needed clarification, and it's cases like this that help clarify it.