Legislation is constantly affecting the way in which software developers can create software systems, and deliver them to their users. This raises the need for methods and tools that support developers in the creation and re-distribution of software systems with the ability of properly cope with legal constraints. We conjecture that legal constraints are another dimension software analysts, architects, and developers have to consider, making them an important area of future research in software engineering.

Introduction
Software is complex not only technically, but also from a legal point of view. Legislation places constraints in the way that software can be created, used, reused, integrated, and distributed. Free, and Open-Source Systems (FOSS), but also commercial software systems, are distributed under certain licenses, that determine under which condition the software can be used, modified, and re-distributed. Local and international legislation places constraints in the way a software system can be deployed and used.

At the minimum, developers should be (i) aware of constraints that licenses impose when they decide to integrate somebody else's software into their own, and (ii) aware of the limitations that legislation, such as privacy law, imposes on what a software system can and cannot do. Software systems are intrinsically complex, and subject to continuous changes. So is the law and software licenses.

Issues requiring both legal and technical proficiency include:

• What legal conditions allow the reuse of the software system's source code, and is it permissible?
• Which architectural design should be chosen for the integration of components with specific licenses?
• If incorporating a component without possession of its source code, is there a method to ascertain its licensing terms, and in what scenarios might usage of the component be legally permissible?
• Are there any legal regulations that could restrict the functionality of the software?
• I'm going to incorporate a component that I don't already have. Have the code's source. Is there a way to figure it out? How was the source code licensed, and am I included? Could make use of the component in certain circumstances?
• Are there any regulations that could limit how the software works?

Analogous to prior scholarly work that introduced methodologies to aid developers in activities like change impact evaluation, detection of software vulnerabilities, and identification of design flaws, we assert the imperative necessity for the development of techniques and instruments that assist developers in navigating legal complexities from a technical perspective. This paper posits that "lawful software engineering" constitutes a significant prospective challenge for the software engineering research domain.

The Purview Of Software Engineering Under Intellectual Property

Intellectual property rights relevant to software engineering predominantly encompass patents and copyrights. Patents safeguard inventions and inherently grant the patent holder exclusive rights to exploit the patented invention for up to 20 years. Recent scrutiny has intensified around software and business method patents due to the complexities of enforcing a legal framework that is equitable for inventors, users, and the public. There are ongoing debates about whether such patents should be abolished entirely.

Conversely, copyright protects the expression of ideas rather than the ideas themselves. It confers a monopoly on the copyright holder for a minimum of 70 years in the United States. From the perspective of software engineering, copyright's primary protections include the exclusive rights to reproduce the software (e.g., to copy verbatim source code) and to create derivative works (e.g., to develop a new software product based on an existing one). Intellectual property owners use licenses to permit third parties to exercise these rights.

The prevailing patent system, especially in the United States, poses challenges for software developers in preemptively assessing whether their software infringes on any patents and thus requires licensing. In contrast, copyright law allows for multiple software implementations of the same concept without infringing upon each other's copyright, similar to how different authors can independently craft distinct spy narratives.

A principal aim of software engineering principles, particularly those emphasizing design, is to facilitate reuse. Large software applications are seldom developed entirely from scratch; rather, they are assembled by integrating various components, including reused code snippets, self-contained binary libraries, or pre-existing applications. In recent years, research has increasingly concentrated on the technical dimensions of enhancing and supporting component-based software development. For instance, Garlan et al. address the challenges associated with component development arising from architectural and interface incompatibilities.

Typically, developers identify suitable software components for reuse, such as libraries, and subsequently seek management approval to negotiate a license for these components. Such a license delineates, at a minimum, the rights and obligations of the copyright holder (licensor) and the user (licensee). Licensing agreements generally encompass matters such as warranties, liabilities, and remedies for breaches, and are typically formalized through contracts. Nevertheless, there is ongoing debate regarding whether certain Free and Open Source Software (FOSS) licenses, such as the General Public License, constitute enforceable contracts.

The rise of FOSS has cultivated an ecosystem where software distribution and utilization are inherently fluid. Numerous commercial and governmental entities are active participants in this ecosystem, engaging in the production and/or reuse of FOSS as part of their routine operations.

Recent developments have introduced additional complexities to licensing and acquisition processes:

• A shift in legal standards now imposes expectations on software producers to deliver defect-free software.
• The international scope of software development has expanded the considerations relevant to licensing.
• The increasing prevalence of FOSS has further complicated licensing dynamics.

Perfect Software? On Warranty And Liability

The software industry has historically diverged from other sectors with respect to warranty and liability considerations. Standard license agreements typically stipulate that software is provided "as is," disclaiming any express or implied warranties and absolving the vendor of liability for any damages resulting from the software's use. This longstanding practice is increasingly under scrutiny. Recently, the American Law Institute (ALI) unanimously approved a report entitled "Principles of the Law of Software Contracts." In the report's preface, the editors assert that "perhaps no other commercial subject matter is in greater need of harmonization and clarification." Principle 3.05 of the report states: "A transferor who receives monetary compensation or a right to payment in exchange for software warrants to any party within the normal distribution chain that the software is free from material hidden defects of which the transferor was aware at the time of transfer. This warranty cannot be disclaimed."

Essentially, Principle 3.05 posits that software vendors have an inalienable duty to provide software devoid of material defects. This provision has faced substantial criticism from software industry representatives, as well as business and legal experts. In a notable development, Microsoft and the Linux Foundation jointly petitioned the ALI to reconsider the Principles. Critics, including lawyers and business experts, have voiced concerns regarding potential adverse effects on industry flexibility, costs, and uncertainty. Nimmer, in his critique "Flawed ALI Software Contract Principles," questions the clarity of terms such as "material" and "hidden" defects.

Although the ALI Principles are advisory rather than legally binding, they are evidently intended to sway legislative action. In response, software organizations are beginning to amend their contracts to align with these Principles. Mark Radcliffe of the Linux Foundation has outlined recommendations for implementing the Principles, including methods for disclosing material defects and reviewing implied warranties, particularly concerning indemnity for intellectual property infringement.

While the ALI Principles pertain to the U.S. legal context, similar debates are unfolding globally. It is evident that the software industry will encounter substantial challenges arising from evolving legal and regulatory frameworks worldwide. The proliferation of diverse privacy regulations and sector-specific regulations, such as Canada's medical devices regulation now encompassing all electronic health record software systems, further complicates the engineering of "compliant" software. Additionally, the cross-border nature of cloud-based software systems exacerbates these regulatory challenges, further increasing the complexity of software engineering.

The International Scope Of Software Development And Use

Various forms of intellectual property receive distinct levels of international protection. Copyright, for instance, enjoys worldwide protection, albeit with minor variations in national legislation (e.g., the Canadian Copyright Act does not encompass the right to make available or digital rights management, in contrast to the American Copyright Act). Conversely, patent and trademark laws are confined to national jurisdictions.

Jurisdictional Considerations In Intellectual Property And Dispute Resolution

The protection of intellectual property varies internationally, with copyright being broadly safeguarded across borders, though with minor national differences (e.g., the Canadian Copyright Act does not include provisions for the right to make available or digital rights management as seen in the American Copyright Act). In contrast, patent and trademark laws are strictly territorial. For instance, an organization situated in one country might utilize a patent without paying royalties if it operates outside the jurisdiction of the patent's owner.

However, the organization could face infringement liability if it begins selling products or services within the jurisdiction where the patent is enforced. A notable case highlighting this risk is Research In Motion (RIM) versus NTP Inc. (NTP Inc. v. Research in Motion, LTD, 03-1615 (Fed. Cir. Dec. 14, 2004)). RIM contended that its activities, and potential patent infringement, occurred in Canada, thus falling outside U.S. jurisdiction. However, the Federal Court ruled that the presence of RIM's customers and their use of Blackberry devices within the United States established sufficient territoriality under Section 271(a) of the Patent Act.

This decision raised significant territorial issues, prompting the Canadian Government to file an amicus curiae brief supporting RIM. The brief warned that the court's adoption of a "control and beneficial use" standard might lead to an improper extraterritorial application of Section 271(a), contrary to principles of comity between Canada and the United States. Ultimately, RIM settled the lawsuit by paying $612.5 million after exhausting all legal avenues.

Future Directions
As delineated in this document, legislative frameworks significantly influence the methodologies through which organizations and their software developers conceive, deliver, and operate software systems. In recent years, substantial progress has been witnessed in this domain, as evidenced by initiatives such as the Requirements Engineering and Law Workshop (inaugurated in 2008) and the inclusion of a "Licensing" session at ICSE in 2010. Future research should focus on the following key areas:

1. Integration of Legal Considerations into Software Development Models and Methods: The pervasive impact of legal considerations on software construction necessitates their incorporation into software development models and methods. This includes addressing how Free and Open Source Software (FOSS) is integrated into systems—whether as components or through code replication—and how to manage legislative constraints on processing and data exchange, such as privacy laws. Additionally, research should explore how jurisdictional issues influence the creation, deployment, and operation of software systems.
    
2. Education for Stakeholders: There is a pressing need to enhance educational efforts for developers, legal professionals, judges, and the general public concerning the legal aspects of software development. While the ACM Computing Curriculum includes intellectual property as a topic, it should be expanded to cover the implications of utilizing FOSS, the impact of privacy and other legislation on software functionality, and the influence of jurisdictional issues on global software development and deployment. The software engineering research community should also focus on strategies to educate these stakeholders effectively.
    
3. Development of Auditing Methods for Intellectual Property Evaluation and Compliance: Effective auditing methods are crucial for ensuring compliance with intellectual property laws. This includes verifying whether software developers adhere to legal requirements, assessing whether purchased software complies with privacy and intellectual property regulations, and determining ownership and licensing rights in the context of organizational acquisitions.
    
4. Advancement of Compliance Tools: There is a notable gap in tools designed to assist software developers and auditors in evaluating licensing compliance. Currently, such evaluations are largely conducted manually by experts. Future research should aim to develop sophisticated tools to streamline this process and enhance compliance assessment efficiency.

In conclusion, future research should be directed towards facilitating the creation of legally compliant software systems by addressing these critical areas.

Regarding dispute resolution, a critical contract component is the specification of jurisdiction for resolving conflicts between parties. For example, the University of Victoria's Faculty of Engineering decided to open-source its Web-based Recruiting System, Mamook. However, the university administration found OSI-approved open-source licenses insufficient for their needs, particularly concerning jurisdiction.

This led to developing a new open-source license, the Adaptive Public License, which OSI eventually approved. This license allows licensors to designate British Columbia as the governing jurisdiction, addressing the university's concerns.

In terms of data privacy, cross-border data flows have raised concerns about the exposure of sensitive information to foreign legal frameworks. In 2006, there was significant apprehension in Canada about subcontracting medical information processing to the United States, potentially exposing data to the PATRIOT Act.

In response, the Canadian Government issued a report on privacy concerns associated with "transborder data flows," particularly when private and sensitive information is outsourced internationally. The report concluded that while transborder data flows are an enduring reality, there is a need for more uniform privacy best practices across the federal government and additional measures to enhance existing safeguards.