Open Logistics Magazine: The legal and technical sides of software development still tend to be two different things. What are your experiences as a lawyer?
David Saive: In practice, developers only involve legal departments after all development work has been completed and ask for a legal assessment for a finished product. Unfortunately, then often, the following happens: After the legal review, it becomes apparent that the requirements of the law were only partially taken into consideration, or in the worst case not at all. For reasons of product liability alone – yes, software is also subject to the Product Liability Act – such software cannot be brought to market. Therefore, the development work must be continued, but this time considering the legal requirements. After completion of the new development, the software will then – again – be subject to another legal review.
Which, of course, delays the project completion enormously …
In the worst case, starting from scratch may even be necessary. This would result in additional development hours and considerable additional costs. That is why we need consistent interdisciplinary cooperation between law and IT. Today it is still the case that these departments are virtually opposed to each other: The developers perceive their colleagues from the legal department as slowpokes – from their perspective, this is understandable. But of course, the lawyers also have their point: they are simply doing their job, averting (legal) risk from their company or clients. But this approach is outdated: We need to adapt the process. Today, law and code must be inextricably linked. Law is code – and vice versa.
In the Open Logistics Foundation, companies jointly develop open source software. Are there any particular pitfalls here?
For the cooperation of companies – especially if they are market-dominant companies competing with each other – it goes without saying that no agreements contrary to antitrust law may be made. This is explicitly pointed out at the beginning of every meeting. Of course, this also applies to software. Antitrust law must not be undermined through the back door. It is also very important that all legal issues are discussed centrally and do not end up with a single project member or, in the worst case, dissipate completely.
You are available to the Open Logistics Foundation as a “Legal Product Owner”. What is the meaning behind this designation?
The “Legal Product Owner” is a lawyer who accompanies the software development process with his professional know-how. He is the counterpart to the classic product owner, who takes care of the technical aspects and the technical implementation of the software.
In concrete terms, your work at the Open Logistics Foundation involves participating in the Working Groups and projects. How is that received by the IT professionals?
My experience is that IT experts always appreciate it when they can discuss things with a lawyer at eye level. The Open Logistics Foundation community has welcomed me with open arms. In the Working Groups and projects, we are now at a point where the legal issues are becoming more and more concrete. Whenever the project team develops a new idea for the software, the technical owner designs an architecture, plays his work back to me and I check whether it meets the relevant legal requirements. The whole thing happens against a (legal) scientific background. We are solving many issues together for the first time. Digitalisation in transport law is still new and somewhat unexplored territory.
“LEGAL CERTAINTY FUELS INNOVATION WHICH IS ESSENTIAL FOR TECHNICAL EVOLUTION.”
You also describe the approach with the words “Community shapes the law – the law shapes the community” …
Legislation and legal provisions do not usually fall from the sky: it is often the case that a community – understood as the entirety of companies in a sector – first develops a custom, a practice or a process that works. For lawmakers, this lived practice serves as a template for the law. The best example is the Bill of Lading: The legislator has created a legal framework based on a universally valid practice. As a Legal Product Owner, I proceed precisely according to this principle: I am tasked to find ways to implement the lived practice. So much for the first part of my statement. But law can also help to shape or influence the industry solution. After all, some things that work well in analogue form cannot be implemented or make sense in digital format. As a Legal Product Owner, I then also get back to the community, i.e. the companies, to understand their processes and make suggestions as to how things must be solved differently digitally or even how they can be solved better.
Now, each of the two disciplines has certain peculiarities: How can the necessary openness be created in practice?
The agile way of working in software development does not in fact correspond to the classic way of working of a lawyer, who first needs a complete picture of an issue to then evaluate it. This approach, on the other hand, is foreign to a software developer. But the two disciplines are not far apart in terms of their basic understanding: legal assessment is based on logic, systematic methods, and precision just as much as the work of developers. Therefore, lawyers need to understand the needs of companies and programmers; and developers need to learn to describe their own technical environment. If we succeed in this, nothing will stand in the way of project success. Furthermore, legal certainty also promotes innovation, which is essential for technical development.
For software development, interoperability is now the ultimate goal. You demand interoperability for law as well. Why is that necessary?
Software today, must cross borders and work in an international context – especially in logistics. Legally we must be on the safe side. The electronic
consignment note is a good example of how the law must be designed: The eCMR-Protocol and the EU’s eFTI Regulation on Electronic Freight Information have created uniform law under European and International law. This helps us enormously in the development of software today. For universal plug-and play solutions, we need not only technical interoperability, but also legal interoperability. The eCMR can serve as a blueprint here.
Your appeal to companies and developers?
Producing legally compliant code is a joint task! To achieve this, a Legal Product Owner must be just as natural and fully accepted in agile teams as, for example, the business analyst, who builds a bridge between the business and IT worlds. If we strengthen the developers’ trust in the law, we will also enhance the users’ trust in the code.
The interview was conducted by Carina Tüllmann, Head of Communications and Marketing, Open Logistics Foundation.
Dr. David Saive, LL.M. advises companies, international organisations, and states on the digitalisation of foreign trade. He works as a Legal Product Owner for the Open Logistics Foundation and is an external advisor to ICC Germany e.V. He is also publisher and editor-in-chief of “Logistik & Recht” magazine, published by dfv Mediengruppe. The ICC UK and the “Centre for Digital Trade & Innovation (C4DTI)” have named Dr. Saive “Advisor of the Year 2023” for his work on the digitalisation of foreign trade.
This article was published in the second issue of the Open Logistics Magazine. You can read the entire magazine and register for future editions here.
