At first look the exchange protocol of binflash with my NEC 4550
seems to be quite simple.

How binflash was written?
Did the authors subscribed NDA with NEC or was binflash developed by RE?

In the latter case what is the opinion of NEC about it?
Is it Ok for NEC as long as the details of protocol aren't published?

Background question: Why the authors don't publish binflash
as open source?

It's indeed not very complicated, once you figured out what the commands are needed for.

We found the necessary commands by doing IDE traces when a drive was flashed with NEC's original flasher. Herrie owns an official Bustrace version that did the job. At first not everything was really clear but with further new drives and experimenting with different commands, it was possible to find out everything that was needed. TraceSPTI was a big help for me too.

I don't think NEC really likes my work, but I also think that it surely does NOT hurt their sales. Just the opposite is probably true.

It's very simple. With knowledge of the code it would be easy to write own programs that use this code. Although this does not really sound dangerous on first sight, it could lead to malware with the only intention of damaging drives and that's not what I want to be held responsible for. I did never mind sharing the code with people who I thought were trustworthy. This way it was possible to add a GUI and improve Linux support for example.

The code I use for accessing SCSI devices (fPLSCSI) is open source and can be found here. For my later programs I started working on my own class based device routines that I plan to release under an open source license. But I'm still waiting for Sourceforge to implement Subversion support.

Thanks for response and for Linux-Version of binflash!
Due to Linux-kernel source it was possible
to obtain the bit of information by using strace and
a small patch applied to ioctl-function of cd-drivers.

Thanks to this thread pointed me to forgotten TraceSPTI