Hi all, I’m Attila.
I work as a Research Laboratory Automation Specialist at Danish Technical University (DTU) Biotechnology Research institute for the Green Transition (BRiGHT)
I have known about pylabrobot for a while, but have not dived in deep yet. (hopefully will be soon – also will be seeing some of you late September in Copenhagen for the PLR course)
I have a question about the legal/practical boundary around reverse-engineered device drivers in PyLabRobot. I am looking into adding support for some laboratory equipment, and I am trying to understand how PLR approaches this issue and how existing drivers have been developed.
I’m creating the post here on the forum because I imagine other people developing support for older or undocumented laboratory equipment may be sitting with some of the same questions, so it could be useful to have the discussion here on the forum for future contributors as well.
My understanding is that there is quite a mixture of approaches. Some devices have documented APIs/SDKs or use standard protocols, while for others it appears that communication has been figured out through things such as firmware logs, black-box testing, Wireshark/USBPcap captures, or other forms of reverse engineering.
That raises a question for me about where PLR draws the line between reverse engineering something locally for interoperability and publishing the resulting implementation as part of an open-source project.
The situation I am thinking about
I guess there are many ways of discovering how to communicate with an instrument such as:
-
A documented public API/protocol.
-
A manufacturer-provided SDK or API, potentially with its own licence terms.
-
Observing communication between the manufacturer’s software and the instrument, for example using Wireshark, USBPcap, serial monitoring, or vendor-generated communication logs.
-
Black-box experimentation: send commands, observe responses, and determine how the protocol works.
-
Inspecting/decompiling manufacturer software where the necessary interoperability information cannot otherwise be obtained.
Obviously these are not all equivalent in a legal sense.
In the EU there also seems to be an important distinction here because Directive 2009/24/EC provides specific rights to observe, study and test software, and under certain conditions to decompile software where this is indispensable to obtain information necessary for interoperability of an independently created program.
My understanding is also that contractual/EULA restrictions cannot necessarily override those particular statutory rights.
However, the part I find less clear is publication.
There might be a meaningful difference between being legally permitted to reverse engineer something in order to make my own software interoperate with an instrument, and subsequently publishing what I learned on the internet. (Although Article 6(2)(b) of Directive 2009/24/EC about decompilation. Does actually state: not to be given to others, except when necessary for the interoperability of the independently created computer program)
At the same time, with an open-source device driver this distinction seems somewhat difficult in practice to me.
Questions for PLR
1. Does PLR or the applicable law distinguish between different forms of reverse engineering and what can subsequently be published?
For example, is there an important distinction between observing USB/TCP traffic or black-box testing and actually decompiling manufacturer software?
PLR seem to allow drivers based on reverse-engineered interfaces, but I am particularly interested in whether the method used to obtain the information changes what can appropriately be included in the public backend. For an open-source driver, the commands, encodings, method names, packet structures, etc. required for interoperability will often necessarily be visible in the source code (if I’m not missing something?).
2. How do EULA restrictions and jurisdiction work for an international open-source project like PLR?
Many manufacturer EULAs explicitly prohibit reverse engineering. In the EU, my understanding is that some of these restrictions may be overridden by statutory rights concerning observation/testing and interoperability, but how does this work in practice, both within and outside the EU?
In particular, how does this apply to publication and contribution? Could a contributor in the EU lawfully develop and publish an interoperable driver while someone in another jurisdiction might not be legally permitted to perform the same reverse engineering themselves, or perhaps even use/download the resulting implementation? How does an international project such as PLR deal with that?
Is the position essentially that contributors are responsible for ensuring that they are legally entitled to contribute their implementation and users are responsible for their own jurisdiction, or does PLR perform any additional assessment?
3. Should reverse-engineering material be limited in the driver? What is actually needed?
For example, if development involved packet captures, vendor trace files, decompiler output, experimental command-response logs, etc., I’m guessing that the expectation is that these remain outside the repository and only the resulting implementation is contributed?
Similarly, is there a practical lower bound to the level of control that PLR aims to expose?
Reverse engineering can potentially provide increasingly low-level control over an instrument. Is there a point at which further protocol-level or hardware-level control is no longer useful or appropriate for a PLR backend? In other words, what is the lowest level of control that PLR would ideally want a backend to expose?
Related issue from another angle; What if the manufacturer provides an API, but only at a higher level than the user wants or needs?
For example, a vendor API may allow running complete methods, while a user wants lower-level control over individual operations. Does the existence of the higher-level API affect whether reverse engineering the lower-level interface can be considered necessary for interoperability?
More generally, how is “necessary for interoperability” understood when some interoperability is already possible, but not at the level of control required by the user or their independently created software? Presumably there is some limit to what can be considered “necessary” simply by defining increasingly specific or low-level requirements — where is that line drawn?
Question about; Decompilation specifically
Suppose a protocol cannot reasonably be determined through documentation, packet capture or black-box experimentation, and someone lawfully decompiles part of the manufacturer’s software solely to determine the information required for interoperability.
Would PLR accept a clean, independently written backend resulting from that work?
Or does the project prefer not to accept implementations where decompilation was part of the discovery process at all?
If it can be accepted, is there a preferred “clean-room”-style approach to make sure no manufacturer’s copyrighted implementation ends up in PLR?
4. Is any provenance required for contributed device drivers?
When contributing a backend, is there any requirement or expectation to state how the interface was derived — for example, public documentation, a vendor SDK, packet capture, black-box testing, decompilation, etc.? How is this handled for existing PLR drivers?
In summary the questions I am trying to answer are
When developing a new PLR backend for a device without a documented public API, I’m mainly trying to understand what methods of obtaining the necessary interoperability information are acceptable, and whether the method used affects what can subsequently be published, what level of detail or control exposed is appropriate, how EULAs and different jurisdictions affect this, and what PLR expects contributors to disclose about the provenance of a driver.
I realise that PLR maintainers cannot provide legal advice and that the precise answer will vary by jurisdiction, licence and circumstances. I’m mainly interested in PLR’s own experience, understanding of this legal landscape, and how these questions have been handled for existing drivers and contributions.
Best
Attila
