Mansi Rana

A commercial lawyer bills for judgment, not for reading the same indemnity clause for the four-hundredth time. Yet most in-house teams still spend the bulk of their week on exactly that: NDAs, vendor agreements, renewal notices, the steady drip of low-stakes paper that has to be checked but rarely surprises anyone. Legal AI moved from copilot to agent in 2026, and understanding what that shift actually means, rather than treating “agentic AI” as another marketing buzzword layered onto existing tools, is now a genuinely practical question for any legal team evaluating its technology stack. This guide covers what makes an AI agent structurally different from a copilot, the specific use cases where agentic AI for legal teams is already delivering real value, and how to pilot this capability without handing over more autonomy than the underlying risk justifies. Copilot to Agent: What Agentic AI for Legal Teams Actually Means Legal technology has followed the same broad curve as software development, roughly one cycle behind. In 2023, legal AI meant simple prompts and basic document question-answering. By 2025, it meant more advanced multi-step workflows, still largely directed step by step by a human user. In 2026, it means agents completing complex, end-to-end legal work autonomously, in context, with human oversight built into specific checkpoints rather than required at every single step. The underlying pattern that describes this shift is a four-stage sequence: Read (ingest unstructured information), Think (apply domain knowledge), Write (produce structured output), and Verify (check the output against defined standards). This sequence describes a junior associate working through a contract review just as accurately as it describes any other structured knowledge task. What has changed is not the underlying logic of legal work, which has always fit this model, but that the technology can now execute this full sequence at a high level of quality and reliability without requiring a human to manually direct each individual step. A useful, concrete way to see the distinction: a well-scoped legal agent does not decide whether to sign a contract. It decides whether clause 9.2 matches your pre-agreed fallback position on liability caps, and says so with a citation to the exact clause it is quoting. Serious contract agents ground every claim in the actual document text, so a lawyer can verify the finding in one click instead of simply trusting a summary, the same retrieval-grounded pattern that underlies reliable AI systems more broadly: the model reasons over your real content, not a generic pattern from its training data. Why This Matters Enough to Act On Now In a 2026 survey of in-house counsel, 52% of teams were already using or actively evaluating AI for contract review specifically, and the reason is straightforward: a large share of routine legal volume, NDAs, vendor agreements, renewal paperwork, is exactly the kind of steady, low-surprise work that an agent grounded in an organisation’s own playbook can now handle with defined, auditable checkpoints, freeing lawyer time for the genuinely judgment-intensive work that actually requires it. The vendor landscape has moved decisively in this direction through 2026. Thomson Reuters announced the next generation of CoCounsel Legal in February 2026, promising more autonomous agents requiring less human supervision, alongside expanding the platform to the UK market. Harvey’s Agent Builder, launched in early 2026, lets legal teams create custom AI agents for multi-step tasks, with more than 25,000 custom agents now reportedly operating across M&A, due diligence, contract drafting, and document review. Major international law firms, including collaborations between A&O Shearman and Harvey, have moved agentic AI into production deployment for complex legal workflows such as reviewing loan documents in leveraged finance transactions, not just pilot testing. The Practical Use Cases Already Working for Legal Teams Autonomous contract review against a playbook. With attorney oversight, agents can be trained to classify agreements, extract relevant provisions, compare terms against predefined standards, and flag contracts containing unusual or potentially significant language. This is consistently identified as one of the highest-value near-term use cases precisely because the outputs are inherently reviewable: an attorney can inspect exactly which provisions were flagged, check the underlying contract text directly, and make the final judgment call, rather than being asked to trust an opaque conclusion. Autonomous contract lifecycle management. A CLM agent integrated with an organisation’s contract repository, email, and ERP systems can handle intake, obligation tracking, and renewal alerts across the full contract portfolio autonomously, reclaiming attorney time from administrative tracking and giving legal operations genuine, proactive control over contractual risk rather than reactive, after-the-fact discovery of missed deadlines. Negotiation copilot during redlining. During active negotiation, agents can assemble first drafts by drawing on pre-approved clause libraries and rule-driven playbooks, leading to shorter cycle times and less manual editing. As redlines come back from a counterparty, agents can flag risky or non-standard language, recommend pre-approved alternative clauses, and surface bottlenecks, escalating specifically to the relevant account executive or legal lead with context on exactly what is holding a deal up, rather than leaving that escalation to happen only once someone notices the delay manually. Litigation document synthesis and case knowledge development. An early, emerging pattern uses agentic AI as a copilot for document-heavy litigation work and structured discovery workflows, not as a fully autonomous legal operator making strategic decisions. Keeping a human genuinely in the loop for anything touching case strategy remains essential in this specific use case. Regulatory and compliance monitoring. Autonomous agents can continuously track regulatory changes relevant to an organisation’s specific operations and flag when existing contracts, policies, or processes may need updating in response, converting a task that traditionally depended on someone remembering to check for updates into a continuously running background process. Why Legal Teams Are Not Handing Over Full Autonomy Because of the privacy, security, and broader risk considerations associated with agentic AI, legal professionals are consistently thinking of agents as capable legal assistants rather than as attorneys or independent decision-makers. Teams are not looking to hand end-to-end legal judgment to fully autonomous systems; instead, they are using

A Data Processing Agreement is the only document that stops a vendor’s data-handling failure from becoming your organisation’s own legal liability under India’s Digital Personal Data Protection Act, 2023. Under Section 8(1) of the Act, the Data Fiduciary, the organisation determining the purpose and means of processing, remains continuously responsible for compliance in relation to processing carried out on its behalf, even when a third-party Data Processor is actually doing the processing. Section 8(2) goes further: a Data Fiduciary may engage a Data Processor for covered activities only under a valid contract. Without a proper DPA, the engagement itself is not compliant, regardless of how carefully the vendor otherwise handles the data. This guide covers what the DPDP Act and its 2025 Rules require in a Data Processing Agreement DPDP Act, the essential clauses every DPA needs, and the specific compliance deadlines enterprises should track. Where This Obligation Actually Comes From Section 8 of the Digital Personal Data Protection Act, 2023 contains the core provisions governing Data Fiduciaries and Data Processors. The distinction between the two roles matters considerably: the Act’s compliance obligations fall primarily on the Fiduciary, not the Processor, which is exactly why the Fiduciary needs a properly drafted DPA to ensure the Processor’s obligations are contractually locked in, rather than relying on the Processor’s own goodwill or general data-handling reputation. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, alongside the establishment of the Data Protection Board of India, providing the detailed operational requirements the Act itself left to subordinate rulemaking. Critically, the DPDP Act does not prescribe specific mandatory DPA clauses by name. Instead, the required content of a compliant DPA is derived by combining Section 8’s obligations, the DPDP Rules 2025 (particularly Rule 6 on security safeguards), and internationally established best practice for data processing contracts more broadly. One clarifying point worth noting: unlike the EU’s GDPR, which prescribes Standard Contractual Clauses for international data transfers, the DPDP Act leaves DPA drafting to the parties themselves, without a government-issued template clause set. This means the responsibility for getting the DPA’s substantive content right sits squarely with the drafting parties and their legal counsel, not with a government-supplied form that can simply be adopted wholesale. Does the DPA Need to Be a Standalone Document? No. The Act requires a “valid contract,” not necessarily a standalone Data Processing Agreement as a separate document. DPA-equivalent clauses can be incorporated directly into an existing service agreement or Master Service Agreement, provided the substantive requirements described below are genuinely addressed within that broader contract, rather than needing their own dedicated document in every case. Essential Clauses Every Data Processing Agreement DPDP Act Needs 1. Identity, roles, and scope of the parties Clearly establishes which party is the Data Fiduciary and which is the Data Processor (or Processors, where sub-processing is involved), and defines the scope and purpose of processing precisely, since the Processor’s use of personal information should be strictly limited to what the Fiduciary has actually authorised. 2. Categories of personal data and data principals Specifies precisely what categories of personal data are being processed and which categories of data principals (customers, employees, or other individuals) are involved, since this scoping directly determines the applicable security and compliance obligations that follow. 3. Purpose and duration of processing Defines exactly why the processing is happening and for how long, preventing the Processor’s use of the data from quietly expanding beyond the originally authorised purpose over the life of the relationship. 4. Security safeguards Establishes appropriate security obligations specifically, rather than relying on a generic confidentiality clause borrowed from an unrelated template. Rule 6 of the DPDP Rules, 2025 governs this area directly, and the DPA should reflect the specific technical and organisational security measures the Processor commits to maintaining. 5. Data subject rights assistance Requires the Processor to cooperate with and support the Fiduciary’s obligations to respond to data principal requests, such as access, correction, or erasure requests, since the Fiduciary remains ultimately responsible for fulfilling these rights even where the underlying data actually sits with the Processor. 6. Breach notification and incident response This is one of the most operationally critical clauses in any DPA. A well-drafted breach notification clause typically requires the Processor to notify the Fiduciary within 24 hours of becoming aware of a breach, giving the Fiduciary the remaining time within the Act’s 72-hour notification window to prepare and submit its own notification to the Data Protection Board. Unlike the EU’s GDPR, the DPDP Act sets no minimum severity threshold for breach reporting, meaning even comparatively minor breaches can trigger a notification obligation, which makes a tight, enforceable notification timeline in the DPA considerably more important than it might be under a threshold-based regime. The Processor’s incident response plan should also be provided to the Fiduciary, ideally reviewed and refreshed annually. 7. Restrictions on sub-processing Addresses whether and how the Processor can engage its own sub-processors, requiring the Fiduciary’s prior approval before any sub-processor is brought into the processing chain, and ensuring sub-processors are bound by data protection obligations that are at least as protective as those the primary Processor has accepted. 8. Data residency and cross-border transfer terms For sectors or organisations subject to data residency requirements, whether for regulatory reasons or simply as an internal risk-management decision, the DPA should specify explicitly that personal data is processed and stored within India, and that the Processor will not transfer, access, or permit access to that data from outside India without the Fiduciary’s prior written consent for a specific, defined transfer. Section 16 of the DPDP Act separately allows the Central Government to restrict processing outside India to specified countries or territories through notification, which the DPA should be drafted to accommodate as that list develops. A DPA that allows the Processor discretion over where data is backed up or processed, for redundancy or similar reasoning, without the Fiduciary’s specific, informed consent, is a significant red flag rather than a routine

A mid-size IT company had an Internal Complaints Committee on paper. Its Presiding Officer had left the organisation eight months earlier, and nobody had reconstituted the committee. When a complaint was filed, the entire inquiry was challenged on the basis of improper constitution, the proceedings were invalidated, and the employer received a show-cause notice from the District Officer. This is not an isolated case. Across India, many organisations have a POSH policy and an Internal Complaints Committee that exist only on paper, and as of 2025 to 2026, that gap has become a serious legal and compliance risk, not merely a procedural formality. The Sexual Harassment of Women at Workplace (Prevention, Prohibition and Redressal) Act, 2013 applies to every Indian workplace with 10 or more employees, and a significant regulatory change in 2025 has made POSH Act compliance a matter of direct board-level accountability, not just an HR function’s internal responsibility. This guide covers how enterprises should set up and maintain a compliant Internal Committee, the statutory timelines governing complaint handling, and the annual reporting obligations now extending into corporate board disclosures. What POSH ACT Compliance Requires: The Baseline POSH compliance applies to every Indian workplace with 10 or more employees, regardless of whether any women are currently on the organisation’s rolls. The core obligations span constitution of a compliant Internal Committee, a written POSH policy, mandatory training and sensitisation, defined complaint and inquiry procedures, and annual reporting, each with its own specific requirements. Internal Committee Constitution: Getting the Structure Right Under Section 4 of the POSH Act, every applicable workplace must constitute an Internal Committee, commonly abbreviated as ICC or IC, with a specific, mandatory composition. Minimum four members. The Committee must have at least four members in total. At least 50% women. At least half of the Committee’s members must be women, and the Presiding Officer specifically must be a woman employed at a senior level within the organisation. One external member. The Committee must include at least one external member from an NGO or an organisation committed to the cause of women, or someone with relevant legal or social work background, brought in specifically to bring independence and expertise the internal members may not have. A maximum three-year term. Committee members serve fixed terms, and the Committee needs to be actively reconstituted before that term expires, not allowed to continue informally past its legal tenure. The consequence of getting this structure wrong, or allowing it to lapse without reconstitution, is not a minor technicality. As the mid-size IT company example illustrates, an improperly constituted Committee, including one where a key member such as the Presiding Officer has departed without replacement, can result in an entire inquiry being challenged and invalidated after the fact, precisely when the organisation most needs the process to hold up under scrutiny. The Statutory Inquiry Timeline Once a complaint is received, the POSH Act imposes a strict, defined sequence of timelines that the Internal Committee must follow. 7 days to send the complaint to the respondent after it is received. 90 days to complete the inquiry from the date the complaint was filed. 10 days after the inquiry concludes to issue the Committee’s report. 60 days for the employer to act on the Committee’s recommendations once the report is issued. Where a complainant has a legitimate reason for delay in filing, the Internal Committee can condone that delay by up to three months under the current framework, though this discretion should be exercised and documented carefully rather than applied informally. Confidentiality obligations under Section 16 of the Act apply throughout this entire process. Leaks of complaint details, the identity of parties involved, or inquiry proceedings can themselves trigger penalties and can derail the fairness of the process, which is why maintaining strict, documented confidentiality controls around every stage of a live inquiry is as important as meeting the procedural timelines themselves. Annual Report Filing: What Changed and What Is Required Under Section 21 of the POSH Act, every Internal Committee must submit an annual report to the employer and to the District Officer, typically the District Magistrate for the relevant jurisdiction, detailing the complaints received, resolved, and pending during the year, along with the actions taken. Timing. The annual report covers the calendar year from 1 January to 31 December, and organisations are generally expected to file before 31 January of the following year, since the report summarises the Internal Committee’s activity for the calendar year just completed. Filing method. Two routes are typically available: hand-delivering one signed original to the District Officer and obtaining a stamped duplicate as proof of submission, or sending it via Registered Post with Acknowledgment Due. The postal receipt or stamped duplicate should be retained indefinitely, since it is generally the organisation’s only concrete proof of timely filing if that filing is ever questioned later. While the government’s SheBox portal is being progressively upgraded for digital filing in specific states, hard-copy or registered post submission remains the more reliable route in most districts as of the current filing cycle. The 2025 Change That Makes This a Board-Level Issue In May 2025, the Ministry of Corporate Affairs notified the Companies (Accounts) Second Amendment Rules, 2025, effective from 14 July 2025, fundamentally expanding who must formally disclose POSH compliance and where that disclosure sits. Previously, detailed POSH disclosure within the Board’s Report under Rule 8(5)(x) applied mainly to listed companies or larger companies specifically, leaving many unlisted companies and MSME entities effectively outside formal, mandatory board-level reporting. Under the amended rules, every company other than One Person Companies and Small Companies must now disclose, within its Board’s Report (submitted via the revised e-Form AOC-4), the number of sexual harassment complaints received, disposed of, and pending beyond 90 days, along with an explicit confirmation that a compliant Internal Committee has actually been constituted. The practical effect of this change is significant: this is the same underlying data as the Internal Committee’s Annual Report, but it now also lives inside a

Pretty much every meaningful business conversation in India eventually runs into a Non-Disclosure Agreement. Founders share product roadmaps with investors. Employers hand financials to senior hires. Vendors exchange source code. Acquirers comb through target company books during diligence. In each of these moments, an NDA is what turns a verbal promise of secrecy into something a court can actually enforce. Legally, the NDA sits inside the Indian Contract Act, 1872, and drafted properly, it converts confidentiality from a handshake into a binding legal obligation. Drafted poorly, and it is simply a document that will not survive the first real dispute. This guide covers how to draft an NDA in India, including essential clauses, enforceability carve-outs, and how Indian courts assess these agreements when challenged. The Legal Basis for NDA Enforceability in India NDAs do not have a distinct, dedicated statute of their own in India and do not require any special government registration to be effective. An NDA’s enforceability flows from the general principles of contract law under the Indian Contract Act, 1872: to be valid, it must have a lawful object, must be supported by lawful consideration, and must be entered into with the free consent of the parties, consistent with Section 10 of the Act. Indian courts have consistently sustained confidentiality obligations under this general contract law framework, but they examine NDAs closely, looking specifically for provisions that are equivocal, inequitable, or that function as a disguised restraint of trade rather than a genuine confidentiality obligation. Generic NDA templates pulled from the internet rarely survive a genuinely contested dispute, precisely because courts review every concrete element: the underlying facts of the business relationship, each individual provision, and, where relevant, whether the document itself was properly stamped. The Clauses Every Defensible NDA Needs A precise, non-vague definition of confidential information “Everything discussed in this meeting is confidential” sounds protective but is actually weak, because it gives a court very little concrete substance to work with when deciding what was actually supposed to be protected if a dispute arises later. An effective NDA specifies categories of information with enough precision that a court can determine, on the facts, whether a specific piece of disclosed information genuinely falls within the definition: trade secrets, financial data, business strategy documents, client and customer lists, and proprietary source code are commonly named categories rather than left to a single, sweeping, undifferentiated phrase. Clear identification of the parties and their roles The agreement should specify who the disclosing party and receiving party are, and where the NDA is mutual (both sides may share confidential information) rather than unilateral (only one side is disclosing), the drafting needs to reflect that structure accurately throughout, rather than using one-directional language in a document intended to bind both parties equally. The duration of the confidentiality obligation An NDA needs to state clearly how long the confidentiality obligation lasts, both during the underlying business relationship and, critically, for how long after that relationship ends. Unreasonable durations, whether unreasonably short (undermining the protection’s practical value) or unreasonably long and indefinite (inviting judicial scrutiny as an unfair restraint), are among the most common drafting failures Indian legal practitioners report seeing across hundreds of reviewed NDAs, alongside vague definitions and missing standard boilerplate. Reasonable steps and treatment as secret Courts examining an NDA increasingly look for language demonstrating that the disclosing party actually treated the information as secret and took genuine, active steps to protect it. A confidentiality clause that simply labels information as “confidential” without describing any protective measures is generally insufficient on its own; the “reasonable steps” standard is best satisfied through a combination of well-drafted contractual language, actual physical and electronic access controls around the information, and consistent labelling or marking procedures applied in practice, not merely promised on paper. Exclusions and carve-outs from the definition of confidential information This is a clause first-time drafters frequently skip, and doing so is a genuine risk to enforceability, not merely an oversight. Standard exclusions typically carve out information that was already known to the receiving party before disclosure, becomes public through no fault of the receiving party, is independently developed by the receiving party without reference to the disclosed confidential information, and is received lawfully from a third party who owed no duty of confidentiality to the original discloser. Including these specific exclusions, tailored to the actual relationship, reduces the risk of overclaiming, and an NDA that overclaims by treating genuinely non-confidential information as protected tends to weaken the enforceability of the core obligation as a whole, since a court may view the entire definition as unreasonably broad. Permitted disclosure and consequences of breach The agreement should specify any circumstances under which disclosure is permitted despite the general confidentiality obligation, such as disclosure required by law or a court order, and should clearly set out the consequences of breach, whether through a specified remedy, a right to injunctive relief, or a liquidated damages provision, so both parties understand what happens if the obligation is violated. IP assignment where the relationship involves creating new work Where the NDA governs a relationship involving development work, such as engaging a freelance developer or a vendor building custom code, a clear IP assignment clause matters as much as the confidentiality clause itself. If the receiving party develops something, a code module, a design, a process, using the disclosing party’s trade secrets or confidential information as a foundation, that new work should be explicitly assigned to the disclosing party rather than left ambiguous, since confidentiality alone does not automatically resolve ownership of derivative work product. Jurisdiction and governing law The jurisdiction clause should name an Indian court with genuine, practical jurisdiction over the parties and the relationship. Naming a foreign court as the governing jurisdiction forces an additional, often costly enforcement step within India if the NDA is ever breached and needs to be enforced against an Indian party, since a foreign judgment typically requires its own separate recognition and enforcement process under Indian law. The

A Memorandum of Agreement (MOA) is a legally binding and enforceable type of contract between two or more parties. When parties sign an MOA, it constitutes a formal understanding of exactly what each party can expect from the other, with agreed objectives and a defined allocation of risk between them. Unlike its more casual cousin, the Memorandum of Understanding (MOU), an MOA goes further in detailing the specific terms each party is genuinely agreeing to, and is enforceable under contract law if a party fails to meet its obligations.

A procurement contract is a legally binding agreement between a buying organisation and a supplier that governs the price, scope, delivery, performance, and risk allocation of a sourcing engagement. It goes well beyond what a basic purchase order provides, offering a more comprehensive, protective framework that establishes clear terms for both parties: vendor selection, product or service requirements, payment terms, delivery expectations, performance obligations, and the process for resolving disputes if they arise.

A software license agreement is a legally binding contract between a software creator or owner (the licensor) and the party granted permission to use it (the licensee), setting out the terms under which the software may be used, distributed, and modified, without transferring ownership of the underlying software itself. Software license agreements grant usage rights, not ownership: the licensor retains the intellectual property in the software, and the licensee receives a defined, bounded right to use it. For enterprise legal teams, software license agreements are among the highest-volume and most consequential contract categories to manage, since they directly determine cost, compliance exposure, and operational flexibility across every software tool the organisation depends on. What a Software License Agreement Covers A software license agreement defines how, when, and by whom a piece of software can be used. Usage limits, renewal structures, support terms, and specific restrictions all shape how an organisation can actually deploy and scale that software over time, which is why the terms of the agreement matter well beyond the point of initial signature. Most software license agreements, whether for a simple mobile app or a complex enterprise platform, share a common underlying structure, even though the specific terms vary considerably by software type and licensing model. Identification of the parties. Clearly names the licensor, the software owner, and the licensee, the user or entity being granted the license. Definitions. Clarifies key terms used consistently throughout the agreement, reducing the risk of ambiguity in how central concepts like “authorised users” or “permitted use” are interpreted later. Grant of license. This is the core of the agreement: it specifies exactly what the licensee is permitted to do, use the software on a defined number of devices, for a specific purpose, within a certain geographic area, and whether the license is exclusive or non-exclusive, transferable or non-transferable, revocable or irrevocable. Term of the license. States how long the license remains valid, whether perpetual (a one-time grant with no defined end date) or tied to a subscription period requiring ongoing renewal. License fees and payment terms. Outlines the cost structure, payment schedule, and any applicable taxes associated with the license. Restrictions on use. Details what the licensee is explicitly prohibited from doing, commonly including copying beyond what is licensed, reverse engineering the software, or reselling or sublicensing it without authorisation. Key Clauses That Determine Risk Exposure While the overall structure above is relatively consistent, a small number of specific clauses do most of the work in determining how much risk each party is actually carrying under the agreement. Grant of license (scope). Beyond simply existing, the scope clause needs to specify access rights precisely: on-premises deployment, installation on designated devices, or access via remote servers, since ambiguity here is one of the most common sources of later licensing compliance disputes. Intellectual property rights. Asserts the licensor’s ownership of the software itself and any associated IP, and, where the licensee’s own data or systems interact with the software, should separately confirm that the licensee retains ownership of their own data and IP, with clear limits on how and when the licensor can use it. Fees and payment terms. Beyond the headline pricing, this should address what happens with usage-based or metered pricing models, renewal pricing structures, and any conditions under which fees can be revised during the term. Liability limitations. Caps the licensor’s financial exposure for claims arising from use of the software, typically excluding indirect or consequential damages, and is one of the most heavily negotiated clauses in enterprise software agreements specifically. Indemnification. Addresses how financial risks and liabilities are shared between the parties. Commonly, the software developer agrees to compensate the licensee for losses, damages, or legal claims arising from specific issues, such as a claim that the software infringes a third party’s intellectual property rights. Termination conditions. Specifies the circumstances under which either party can end the agreement, what happens to the licensee’s access and data upon termination, and any notice periods required. Confidentiality. Protects proprietary information shared between the parties during the relationship, relevant both to the licensor’s underlying technology and to any sensitive business information the licensee shares in the course of using the software. Support and maintenance. Defines what ongoing support the licensor provides: how long support services last (for the duration of the license term, or for a separately defined period), the specific types of support offered (bug fixes, updates, troubleshooting), and response time commitments for resolving technical issues. Assignment and transfer. Governs whether either party can assign their rights under the agreement to a third party, for example if the software developer is acquired or restructures, and what approval or restrictions apply to such a transfer. Types of Software Licenses Different license models create meaningfully different legal and commercial obligations, and choosing the right structure depends on the nature of the software and how it will be deployed. Proprietary licenses grant the licensee the right to use the software under terms fully controlled by the licensor, with the source code and underlying technology remaining closed and protected. Open-source licenses allow a party to use, and often modify and redistribute, another party’s code within their own applications, subject to the specific terms of the open-source license involved. Common open-source license types, including Apache, MIT, and GPL, differ significantly in the distribution rights and obligations they impose, and organisations incorporating open-source components need to understand these differences to avoid inadvertent compliance issues. Subscription-based (SaaS) licenses grant access to software hosted and maintained by the provider, typically on an ongoing payment basis, with access contingent on continuous compliance with the subscription terms rather than a one-time grant. Perpetual licenses grant a one-time right to use a specific version of the software indefinitely, usually for a single upfront fee, though ongoing support and updates are often priced and licensed separately. OEM licenses refer to licenses that a manufacturer installs on new devices at the point of manufacture. These are typically non-transferable to a different installation, with limited exceptions

A clickwrap agreement is a digital contract that requires a user to actively confirm their consent, typically by clicking a button such as “I Agree” or “Accept,” or checking a box, before they can access a service, complete a transaction, or create an account. Unlike passive agreement methods, clickwrap ensures that the user clearly and demonstrably acknowledges the terms before proceeding, which is precisely what makes it one of the most consistently enforceable forms of online contract in courts today.

A ratified contract is an agreement that has been formally confirmed or approved by the parties involved, making it legally binding and enforceable. Ratification is the act of demonstrating clear, voluntary intent to be bound by an agreement, and it plays a specific and important role in two distinct contexts: confirming that both sides have finally agreed to every term of a negotiated contract, and separately, retroactively validating an act or agreement that was entered into without proper authority in the first place.

An RFQ, or Request for Quotation, is a formal procurement document used by a company or public entity to invite suppliers to submit price quotes for a clearly defined product or service. It is one of the most common tools in procurement, used specifically when the requirements are already well understood and standardised, and the primary factor in the buying decision is price and commercial terms rather than a novel or complex solution.