Software forms the foundation of numerous business models, industrial processes, and public administration structures today. It is created in complex ecosystems consisting of source code, data, interfaces, and architectures – and thus gains legal relevance far beyond traditional copyright issues. Allegations of manipulation, liability issues in the event of security breaches, disputes over rights of use, and even the precise reconstruction of technical processes are increasingly leading to source code and software artifacts being used as evidence in court. This article focuses specifically on the Java programming language to present the identifiability and integrity of software versions, documentation-relevant artifacts, and tools for forensic investigation. The use of AI in software development also leads to new responsibilities, growing dangers, and demonstrates the need for qualitatively reliable and verifiable software.
The Algorithmization of Law
Software is no longer just a tool for developing applications. In our modern industrial society, it is rather the backbone of business models, production processes, public administration, and almost all digital processes[1]. Its significance goes far beyond pure, almost historical, process optimization. Software is becoming a commercial product, a trade secret, a distinguishing feature; it arouses desire, creates opportunities, is subject to legal and organizational frameworks, and thus creates value of all kinds[2]. Software is no longer limited to source code – it manifests itself as a complex interplay of algorithms, databases, user interfaces, interfaces, and hardware[3]. Whereas source code was often considered the “measure of all things” in the past, its role is changing as more and more code generators are used. For example, writing data access classes, unit tests, or even developing user interfaces now involves less and less typing by developers, so that even the legal concept of “creative height” can be less and less anchored in pure source code .
Specific use cases demonstrate the complexity and relevance of software, particularly in legal contexts[4]: in the automotive industry, for example, a vehicle’s control software can not only influence engine functions, but also manipulate exhaust emissions in a targeted manner – as numerous court cases in recent years have made clear[5]. In the financial world, complex algorithms regulate the processing of stock exchange transactions – errors or manipulations of these systems can have far-reaching legal and economic consequences . In public administration, software solutions control the allocation of services and the conduct of elections, and are regularly the target of a wide variety of cyber attacks . Malfunctions or manipulation of digital systems are now considered one of the greatest risks to individuals, businesses, public administration, and even society itself.
With this ongoing digitalization, software is inevitably also finding its way into courtrooms. The source code is often only one of many technical foundations here, as the focus is usually on questions about how the system works, the interaction between systems, the traceability of decisions, security, or even questions about the rights to the solutions used . These can include copyright disputes, rights of use, liability issues following a cyberattack, allegations of manipulation—such as the circumvention of emissions regulations—or even data protection violations due to faulty programs[6]. In all cases, software has long been a central and often decisive piece of evidence in legal discourse. In numerous proceedings, IT experts are asked not only to analyze the pure source code, but also to classify the entire ecosystem of a software solution[7]. This then includes the architecture, the libraries used, the supply chain and documentation, configuration files, data and databases, as well as the interaction with external systems. This is the only way to reconstruct and evaluate the actual facts in a legally secure manner .
The Java programming language plays a special role in this context, which will also be the focus of a detailed examination below. Due to its widespread use in enterprise applications, financial systems, critical infrastructure, and also in the form of Android applications on countless smartphones, it is disproportionately often the focus of forensic investigations[8]. But how can code be “interrogated”? How can abstract classes and lambda expressions be translated into a language that a judge can use to make a ruling? What if AI in all its forms also comes into play?
To answer these questions, this article examines the general legal framework and, above all, the methodology in the context of Java applications and from the perspective of Java developers in order to generate secure, traceable, and unassailable source code.
Legal framework
Under German and European law, source code is generally protected as a work in the sense of copyright law, provided it reaches a certain level of creativity[9]. This means that the copyrights to the source code initially belong to the developer, but can also be transferred to companies on the basis of contracts or employment relationships. This in turn results in exclusive rights, such as the right of reproduction, distribution, and editing, which enable the rights holder to control the use and distribution of the source code and, if necessary, to enforce this legally . Alarmingly often, lawsuits arise in which one party accuses the other of either stealing or copying source code or using components unlawfully. The granting of rights of use, in turn, entails guarantees, warranties, the obligation to correct errors, and much more, which can regularly cause manufacturers distress.
While developers used to do most of the source code production themselves—and some of the case law still dates from this period—modern tools such as code generators now take care of a certain amount of the typing work. However, since the advent of AI and AI-generated source code, an additional aspect has become increasingly important: AI-generated works are initially free of rights, i.e., the developer does not even own the copyright in the first step, since the AI system itself is not a natural person and the code it generates cannot therefore be protected[10]. However, it must be taken into account at this point that the source code is typically embedded in complex system architectures and its creation is also significantly controlled by developers . This creative process, in turn, represents a certain level of creativity. Many lawyers argue that this embedding or prompting can indeed generate protection. However, numerous legal proceedings are currently working to resolve the resulting uncertainty regarding the enforceability of claims or the usability of such source code.
Identifiability, Security, and Integrity
Before an analysis can begin, the procedural integrity of the evidence must be ensured. Unlike physical evidence, however, digital information is fleeting and easily manipulated. For an expert, the work therefore does not begin with reading the code, but much earlier – namely with the acquisition of the source code for the period in dispute.
Considering that several years may pass between the trigger of the dispute and a court hearing, this is a difficult undertaking in practice. In civil or criminal proceedings, for example, it must be proven beyond doubt that the source code under investigation corresponds exactly to the status at the time of the damaging event. If this is not possible, a central pillar of the argumentation is often lost.
Thanks to modern tools such as Git[11], source code can now be reconstructed to any historical state. This is a considerable advantage in the event of an incident. If cryptographic hash functions (such as SHA-256) are also used, the status in the repository can be provided with a “digital fingerprint,” thus proving that any subsequent changes or manipulations would be immediately noticeable.
However, software is not just pure source code – from the aspect mentioned here, it is also advisable, for example, to regularly store documentation, database dumps, architecture documents, test cases, and test results in the repository so that, together with the source codes, they form a consistent and complete status.
In this way, complete, uniquely identifiable software can be made available at any time. Developers should therefore document each delivery of a version via tag and hash value and check in the corresponding data and documentation status.
Source Code Changes
Git also plays an important role in another aspect: companies or individual developers are increasingly being accused of illegally taking source code, e.g., from their previous employer, and integrating it into the products of a new employer. In the rarest of cases, these are 1:1 copies. However, if large parts of the source code are similar—regardless of the programming language used—suspicions may arise that a developer has copied C# source code, for example, and then simply rebuilt it in Java and integrated it into the new employer’s software.
In such cases, it is extremely helpful to be able to consult the Git history. This often allows the creation and genesis of source code to be very well documented and traced. For example, if an unusual 10,000 lines were checked in during a commit, this could be an indicator of stolen source code. However, if the Git history proves and documents that the source code has been developed in “commercially available” quantities, and if conversion and dismantling measures are visible in Git, this can be used to develop a good argument for the independent and original creation of source texts. Of course, there is no need for concern about automatically generated source code, such as test cases or data access classes, as experts are able to distinguish between these and such structures have only a very low level of creativity. The “Gource” project (https://gource.io) has elevated the visualization of source code changes to a true art form by visualizing the Git history as a film.
However, this also means that developers should check in their results regularly. Comments and explanations in the source code are also helpful.
Analysis Methodology – From Bytecode to Business Logic
The analysis of Java applications differs fundamentally from the examination of native languages such as C++ or C. The concept of the Java Virtual Machine (JVM) offers both advantages and hurdles in this regard.
Often, courts do not have access to cleanly documented source code, but only to a precompiled jar, war, or ear archive. These can be translated back into source code with high precision using decompilers. Tools such as the CFR Decompiler or Fernflower make it possible to reconstruct readable source code from binary files . However, this approach also has its limitations . If obfuscators are used, for example, all methods, variables, and class names are replaced by incomprehensible and cryptic identifiers, which significantly reduces readability. However, in modern software architectures, these have the major problem that they make the development of services, APIs, or reusable components much more difficult, because methods and structures must be preserved for this very purpose. For special, critical areas, however, obfuscators offer additional security and protection against decompilation into readable (!) source code .
If source code is available either in its original form or through decompilation, the expert then checks the logical consistency, software quality, and hidden functions, or compares the source code in the context of the evidence question.
In this context, it is also important to mention the aspect of security checks. There are often disputes as to whether a given source code meets the (hopefully jointly) defined quality criteria. CVE databases (Common Vulnerabilities & Exposures) with associated vulnerability scanners[12], such as Grype, Trivy, and SonarQube, offer convenient tools for automatically detecting such vulnerabilities. However, the problem here is that it is almost never a question of evaluating current vulnerabilities, but rather of evaluating software at a specific point in time. This means that the CVE database must also originate from time X in order to be comprehensible, verifiable, and fair. This requirement can be met by linking snapshot repositories (e.g., NVD) or archived scans[13].
Developers should therefore consider using obfuscators and regularly try decompiling their own applications to gain an understanding of what information third parties might be able to access if they obtain jar, war, or ear files.
Developing and documenting an understanding of the dynamic aspects of software is significantly more complicated than pure, static source code analysis. In order to be able to reproduce error states, it is usually not enough to follow the algorithmic approach. Rather, framework conditions such as configuration, data quality, infrastructure, and even hardware conditions play a role. In this context, tools such as AspectJ , Eclipse Memory Analyzer , or—if possible—remote debuggers are important for developing an understanding of the runtime behavior of applications. These can be very helpful not only for checking the quality of applications, but also during development or testing.
Ultimately, it is important to remember that modern applications are almost never developed from scratch. They consist largely of libraries, in the Java context mostly even open source libraries. However, this does not mean that a developer’s responsibility ends with their own source code. Rather, the complete dependency tree of a software, the Software Bill of Materials (SBOM), must be included in the review. The best example of why this can be important is outdated libraries with security vulnerabilities. Regular testing of the SBOM and regular updating of components is part of professional software development and can be held against the application manufacturer in the event of improper implementation. The security vulnerability in the popular logging framework Log4j was a prominent example and caused difficulties worldwide.
It is strongly recommended to continuously review the SBOM of applications and incorporate the results into the software. Especially in open source projects, developers who use the software are even more responsible for the functionality of their own components, as there is no manufacturer with corresponding contracts who could be held liable in case of doubt.
Artificial Intelligence
With open source code, data, and documentation, quality or problem assessments can usually be carried out with sufficient expertise. However, all this becomes more difficult when artificial intelligence comes into play. AI-generated source code raises completely new questions: for example, who is responsible if an AI suggests an insecure Java method? Copyright law does not play a major role in terms of responsibility either, because, similar to the review of the SBOM, the developer has a clear responsibility to review AI-generated results when using AI . At this point, however, the developer must also have the relevant expertise, and this is becoming increasingly problematic: Vibe Coding, for example, specifically addresses non-developers by using functional descriptions to prompt an AI to independently create source code that cannot be verified by untrained “developers,” from which applications can then be created. Here, too, the developer is responsible for the solution, even though the whole concept of “vibe coding” is precisely designed to ensure that they do not have to assume this responsibility . Unfortunately, the use of AI in software development is also increasingly leading to junior developers relying too heavily on AI and no longer being able to evaluate the results. Such cases can quickly become problematic for developers.
When using AI, developers should therefore be able to check and evaluate the results. Otherwise, problems and, in some cases, liability risks are inevitable. In addition, it is essential to document which parts of the code are AI-generated and which are human-made. This can also be important for later training or optimization processes on your own code base, as AI should not be trained with AI-generated data if possible.
Conclusion and Outlook
“Code in court” will increasingly become a standard scenario in the coming years. For software companies, this means that quality assurance and documentation of source code and related artifacts are not only a technical necessity but also essential risk prevention. Java’s structure and excellent analysis tools provide a good basis for objective investigations and quality standards. In court, this allows for the creation of a comprehensible and verifiable expert opinion.
The human component is becoming increasingly crucial in this context. Companies and developers today need to know which components can pose a risk and what measures can be taken to manage this risk. This article has listed a number of specific recommendations that are relevant at different levels and at different stages of the development process. If these are taken into account, they can provide a solid basis not only for high-quality software, but also for good arguments in the event of a dispute. Because at the end of the day, we all hope that your code won’t have to be discussed in court.
Prof. Dr.-Ing Stefan Wagenpfeil
SLW – IT-Experts, Brühl
PFH Private University of Applied Sciences, Göttingen
Literature:
[1] Bundesministerium für Wirtschaft und Energie (BMWi), Digitale Transformation erfolgreich umsetzen – Herausforderungen und Erfolgsfaktoren für Industrieunternehmen, 2020.
[2] Fraunhofer ISI, Metzger, F.M. (2023): Digitale Geschäftsmodelle: Zugrundeliegende Trends und kennzeichnende Charakteristika.
[3] Buxmann, Diefenbach & Hess (2015): Geschäftsmodelle in der Softwareindustrie. Springer.
[4] Wagenpfeil (2026): Nachhaltiges Software-Engineering, Springer.
[5] EuGH (2020): Abgasmanipulationssoftware ist illegal
[6] FINRA (2024): Algorithmic Trading – Risiken & Regulierung
[7] FES / USAID (2023): Elections and Cybersecurity Reference Document
[8] Ferner, J. (2022). Quelltext als digitales Beweismittel. Ferner Alsdorf. https://www.ferner-alsdorf.de/bgh-einsichtsrecht-in-software-quelltext-bei-vermuteter-urheberrechtsverletzung-softwarerecht-rechtsanwalt/
[9] UpCounsel. (2025, August 26). Forensics software in legal and cyber investigations. https://www.upcounsel.com/software-forensics
[10] Braguinski, L. (2025). Urheberrecht vor Gericht: Wie soll ich beweisen, dass mein Code nicht KI‑generiert ist? RSW/Beck. https://rsw.beck.de/aktuell/daily/meldung/detail/urheberrecht-gericht-code-ki-generiert-beweislast
[11] [11] Chacon, S., & Straub, B. (n.d.). Pro Git (2nd Edition). Git‑Projektseite. https://git-scm.com/book/en/v2
[12] CVE Program. (n.d.). Common Vulnerabilities and Exposures (CVE): Global reference standard for publicly disclosed cybersecurity vulnerabilities. https://www.cve.org/
[13] National Vulnerability Database (NVD). (n.d.). NVD Data Feeds: Annual CVE feeds and modified feed update guidance for local mirroring. https://nvd.nist.gov/vuln/data-feeds
This article is part of the JAVAPRO magazine issue:
From AI as a Feature to AI as Infrastructure
Move beyond AI experimentation and into AI engineering.
Explore the architectures, platforms, and operational practices required to build trustworthy AI systems at scale. From governance and observability to modern Java infrastructure, this edition examines the foundations of production-ready AI.
Discover the edition →
This article is part of the JAVAPRO magazine issue:
Java Security – Special Edition
Build secure Java applications from the language to the software supply chain. Explore modern security practices, API protection, SBOMs, reverse engineering, software forensics, and practical strategies for reducing risk across the entire development lifecycle.
Discover the edition →
