DEV Community: Peesh Chopra

AI-Generated Code Is Not Automatically Legally Safe: What Developers Should Know

Peesh Chopra — Mon, 21 Sep 2026 16:05:06 +0000

AI coding tools can now generate functions, fix bugs, write tests, explain unfamiliar code, and even produce large parts of an application.

For a developer, that can feel like a productivity breakthrough.

But there is another question worth asking before generated code reaches production:

Who is responsible for the legal risks attached to that code?

The answer is not always as simple as saying, "The AI wrote it."

The Developer Still Owns the Integration

When an AI tool generates a piece of code, a developer still decides whether that code enters the project.

That decision matters.

The developer may:

Accept the generated code.
Modify it.
Combine it with existing code.
Add dependencies around it.
Deploy it into a production environment.

The AI system may have produced the suggestion, but the human development team controls how that suggestion becomes part of the software.

This makes review important not only from a security perspective, but also from a legal and compliance perspective.

The Hidden Risk of Code Similarity

One concern with AI-generated code is whether a generated snippet may resemble existing code.

That does not mean every similar-looking function creates a copyright problem. Short, functional code can raise different questions from substantial creative software components.

The practical issue for development teams is simpler:

Do you know where important code came from, and can you explain why it was used?

For small internal experiments, this may not receive much attention.

For commercial software, regulated products, or large engineering teams, provenance can become important.

Open-Source Licences Still Matter

AI assistance does not make open-source licensing requirements disappear.

Suppose generated code introduces a dependency or reproduces code associated with an open-source project.

The development team still needs to understand the applicable licence.

Different open-source licences can impose different conditions relating to:

Attribution
Copyright notices
Distribution
Modification
Source-code availability
Licence compatibility

A developer should therefore avoid treating an AI coding assistant as a substitute for dependency and licence review.

Security Review Is Only Half the Job

Security scanners can identify vulnerable packages, suspicious patterns, and known security issues.

They do not necessarily answer every legal question.

A code review process should therefore consider several separate questions:

Security:
Could this code create a vulnerability?

Licence:
Are the dependencies being used consistently with their licences?

Privacy:
Does the code collect, transmit, or expose personal information unnecessarily?

Provenance:
Can the team identify where important third-party components originated?

Documentation:
Can the team explain how the code entered the product?

These questions become increasingly important as AI-assisted development becomes part of ordinary engineering workflows.

Keep a Simple AI Development Record

Teams do not necessarily need a complicated bureaucracy.

For significant pieces of generated code, maintaining a lightweight record can help.

For example:

Feature: Payment validation
AI assistance: Used
Developer review: Completed
Third-party dependency review: Completed
Security review: Completed
Licence review: Completed
Production approval: Developer A

The purpose is not to document every autocomplete suggestion.

The purpose is to create accountability around material software decisions.

Don't Put Sensitive Code Into an AI Tool Without Checking the Rules

There is another issue developers sometimes overlook.

An AI coding assistant may process the information supplied to it.

Before submitting source code, configuration files, customer information, credentials, proprietary algorithms, or internal documentation, developers should understand the tool's data-handling terms and their organisation's policies.

A five-second coding shortcut should not create a much larger confidentiality problem.

Never paste:

API keys
Passwords
Private certificates
Customer databases
Confidential contracts
Proprietary source code

into an AI system simply because the tool makes debugging easier.

AI Assistance Does Not Replace Engineering Judgment

The most useful way to think about AI-generated code is not as "safe" or "unsafe" by default.

It is another source of code that requires appropriate review.

A developer should be able to ask:

Would I approve this code if a junior developer submitted it?

If the answer is no, the fact that an AI generated it does not change the review requirement.

The Practical Rule

AI coding tools can make development faster.

They do not automatically make software legally compliant.

Before shipping significant AI-assisted code, developers and engineering teams should consider security, licensing, privacy, provenance, confidentiality, and human review.

The strongest development workflow is not one where AI writes the most code.

It is one where developers remain accountable for the code that ultimately reaches users.

Disclaimer:

This article is for general legal and technology awareness and does not constitute legal advice. Specific copyright, licensing, privacy, or contractual questions should be reviewed according to the applicable law, licence terms, and facts of the project.

Peesh Chopra
Advocate | Legal Writer
Exploring law, technology, digital evidence, privacy, public justice, and legal awareness.

Your Third-Party SDKs May Be Collecting More Data Than You Think

Peesh Chopra — Thu, 10 Sep 2026 19:58:59 +0000

A developer adds an analytics SDK.

Another SDK handles crash reporting.

A payment library is added for transactions. A social login library makes authentication easier. An advertising SDK helps measure campaigns.

The application works.

But there is another question developers should ask:

What data is leaving the application because of these SDKs?

Third-party software development kits are now part of almost every modern application. They save development time and provide functionality that would otherwise take weeks or months to build.

But an SDK is not just a piece of code.

It can also become part of your application's data flow.

That makes SDK selection a technical, security, privacy, and potentially legal decision.

An SDK Can Change Your Data Flow

Consider a simple mobile application.

A user creates an account and enters:

Name
Email address
Phone number
Location
Device information

The application may initially send this information only to its own backend.

Then a developer integrates an analytics SDK.

Suddenly, certain events, device identifiers, application information, or user-related data may also be transmitted to the SDK provider.

The developer may not have written the code that sends that information.

But the application is still responsible for understanding what happens.

This is why installing an SDK should not be treated as the same as installing a normal development dependency.

What Data Does the SDK Collect?

The first question should be simple:

What exactly does this SDK collect?

Do not rely only on the SDK's marketing description.

Review its documentation, configuration options, privacy documentation, permissions, network behaviour, and available controls.

Depending on the SDK, information may include:

IP addresses
Device identifiers
Advertising identifiers
Application activity
Crash information
Diagnostic data
Location information
Browser or device characteristics
Account-related information
Usage events
Information contained in URLs or parameters

The important point is that data collection can occur indirectly.

For example, a developer might send an event such as:

purchase_completed

That appears harmless.

But consider an event like:

purchase_completed_user_98765

or:

password_reset_email@example.com

The second examples potentially expose information that the analytics provider never needed.

The problem may not be the SDK itself.

The problem may be what the application sends to it.

Read the Network Traffic, Not Just the Documentation

Documentation tells you what an SDK is supposed to do.

Network inspection can help you understand what it actually does in your application.

During development and testing, developers should consider examining:

API requests
Request URLs
Headers
Query parameters
Request bodies
Cookies
Device identifiers
Event payloads
Third-party domains receiving data

Tools such as browser developer tools, application proxies, mobile debugging tools, and server-side logging can help identify unexpected data flows.

A useful question is:

If I were the user, would I expect this information to be sent to this company?

If the answer is no, investigate before shipping.

Permissions Do Not Tell the Whole Story

Developers sometimes assume that if an SDK does not request a sensitive operating-system permission, it cannot access sensitive information.

That assumption can be dangerous.

An SDK may receive information from the application itself.

For example:

analytics.track("profile_updated", {
plan: user.plan,
country: user.country
});

The SDK may not need access to the user's contacts, camera, or microphone.

The application is voluntarily providing the information.

This distinction matters.

Permissions control one category of access. Application code controls another.

Both need to be reviewed.

Be Careful With Identifiers

Identifiers deserve particular attention.

Developers often use internal IDs because they are convenient.

For example:

analytics.track("checkout_started", {
userId: currentUser.id
});

An internal identifier may not look like personally identifiable information by itself.

But when combined with other information, it can become meaningful.

A safer design question is not:

"Is this identifier technically anonymous?"

Instead ask:

"Can this identifier be linked back to a particular person or account?"

If the answer is yes, the privacy implications become more significant.

Avoid Sending Sensitive Information to Analytics

Analytics systems are generally designed to measure application behaviour.

They do not need to know everything about the user.

Developers should avoid placing information such as:

Passwords
Authentication tokens
Payment credentials
Private messages
Government identification numbers
Health information
Confidential business information

inside analytics events, URLs, crash reports, or diagnostic metadata unless there is a specific, justified reason and appropriate safeguards.

A simple rule can prevent many problems:

Collect the minimum information necessary to achieve the technical purpose.

Third-Party SDKs and the Indian Legal Context

For applications handling personal data in India, privacy responsibilities cannot be separated from the application's technical architecture.

The Digital Personal Data Protection Act, 2023 establishes a framework concerning the processing of digital personal data and the responsibilities of relevant entities.

That means developers should not think about privacy only when writing a privacy policy.

Privacy considerations can begin much earlier, when selecting libraries, SDKs, APIs, analytics tools, and infrastructure providers.

The technical question is:

What data is being processed, where is it going, and why?

The legal question may then become:

Is that processing properly justified, disclosed, controlled, and protected?

The answers depend on the application, the data involved, the parties involved, and the applicable legal requirements.

Vendor Documentation Is Not Enough

Before integrating an SDK, developers should examine more than a README file.

A practical review can include:

1. Data collection

What information does the SDK collect?

2. Data transmission

Which domains or servers receive the information?

3. Purpose

Why does the SDK need the information?

4. Configuration

Can unnecessary collection be disabled?

5. Retention

How long is the information retained?

6. Third parties

Does the provider share information with other service providers or third parties?

7. Security

How is the information protected during transmission and storage?

8. Geographic processing

Where may the data be processed or stored?

9. User controls

Can users access, correct, delete, or otherwise exercise applicable privacy rights?

10. Contractual terms

What agreements govern the relationship between your organization and the SDK provider?

These questions are not merely legal paperwork.

They can influence architecture and implementation decisions.

Build an SDK Inventory

A practical way to manage the problem is to maintain an SDK inventory.

For each third-party SDK, record:

This inventory does not need to be complicated.

The goal is visibility.

If nobody knows which SDKs exist, nobody can properly assess their data flows.

Review SDKs During Code Review

Privacy review should not happen only before the application launches.

SDKs change.

Applications change.

Configuration changes.

New developers add libraries.

An update may introduce new functionality or alter data collection.

For that reason, SDK review should become part of the development lifecycle.

When a pull request adds a new dependency, ask:

What does this dependency receive from our application?

That one question can reveal issues before they reach production.

A Simple Developer Checklist

Before adding a third-party SDK, ask:

What problem does it solve?
What data does it collect?
What data will our application send to it?
Does it receive user identifiers?
Does it receive sensitive information?
Where is the data transmitted?
Can unnecessary collection be disabled?
Does the SDK add new permissions?
What domains does it communicate with?
What does its privacy documentation say?
What happens when the SDK is removed?
Has the security and privacy impact been reviewed?

If these questions cannot be answered, the SDK probably deserves more investigation before production use.

The Smallest Dependency Can Create a Large Data Flow

Modern development encourages reuse.

That is usually a good thing.

Developers should not reinvent every authentication system, payment mechanism, analytics platform, or monitoring service.

But convenience should not eliminate visibility.

Every external SDK creates another relationship between your application and an outside system.

That relationship can affect:

Privacy
Security
Compliance
Data governance
Incident response
Vendor management
User expectations

The most important question is therefore not:

"Does this SDK work?"

It is:

"What does this SDK cause our application to do with user data?"

That is a question developers, security teams, product teams, and legal professionals should be able to answer together.

Good software is not only software that functions correctly.

It is software whose data flows are understood, intentional, and defensible.

Disclaimer

This article is provided for general educational and legal awareness purposes and does not constitute legal advice. The applicable legal requirements may vary depending on the facts, organization, data involved, and jurisdiction.

Your App Logs Can Become Legal Evidence: What Developers Should Preserve

Peesh Chopra — Tue, 08 Sep 2026 15:40:40 +0000

A production incident usually starts with a technical question.

What happened?

A legal dispute often starts with a different one:

Can you prove what happened?

For developers, those two questions are much closer than they appear.

A user claims that an account was accessed without permission. A customer disputes a transaction. A company investigates whether an employee downloaded confidential information. A security team discovers suspicious activity several weeks after it occurred.

The first place everyone looks is often the same: the logs.

But logs are not only useful for debugging and security investigations. In the right circumstances, digital records can become important evidence in a legal proceeding.

That creates a responsibility developers and engineering teams sometimes overlook.

The way your application creates, stores, and preserves logs can affect their usefulness later.

What Counts as an Application Log?

An application log can record events such as:

User login and logout activity
Password changes
API requests
Failed authentication attempts
Account modifications
File uploads and downloads
Administrative actions
Payment events
Changes to important records
Access to sensitive information

The exact contents depend on the application.

A simple timestamp and error message may be enough for debugging. For an investigation, however, the context surrounding that event can be much more important.

For example:

2026-09-08 10:41:12
user_id=4821
action=download
resource=customer_export.csv
ip=203.0.113.10

This tells us something happened.

But it may not tell us enough to establish who actually performed the action, whether the account was compromised, whether the log itself was altered, or whether the recorded time is reliable.

That distinction matters.

Why Developers Should Care About Evidence

Indian law recognises electronic records as a form of evidence, subject to the applicable legal requirements.

The Bharatiya Sakshya Adhiniyam, 2023 contains provisions dealing with electronic and digital records.

This does not mean that every log file automatically becomes conclusive proof in court.

The circumstances in which the record was created, stored, maintained, produced, and authenticated can matter.

For an engineering team, this means one thing:

Evidence quality begins before litigation begins.

By the time lawyers become involved, it may already be too late to recover deleted logs, establish missing timestamps, or determine whether an administrator modified a record.

The Difference Between Logging and Preserving

This is one of the most important distinctions.

A system may generate logs continuously, but that does not necessarily mean the organisation is preserving them properly.

Consider a startup that keeps authentication logs for seven days.

A suspicious account takeover happens on January 1.

The customer reports it on January 15.

The relevant logs have already been deleted.

The application technically had logging enabled. Yet the organisation may no longer have the information needed to investigate what happened.

Logging answers:

What did the system record?

Preservation asks:

Did we retain the relevant record long enough, and in a sufficiently reliable form, to use it later?

These are different engineering decisions.

What Should Developers Consider?

1. Accurate Timestamps

Timestamps should be consistent and properly managed.

If one server records an event in UTC while another records local time, investigators can struggle to reconstruct the sequence of events.

A consistent time standard makes incident reconstruction considerably easier.

2. Identity and Context

A log saying:

DELETE /customer/4821

may be technically useful but legally weak without additional context.

Where appropriate, organisations should consider recording information such as:

User or service identity
Relevant request or transaction identifier
Timestamp
Source information
Action performed
Resource affected
Authentication context

The exact information should depend on the application's security, privacy, and operational requirements.

More logging is not automatically better.

3. Protection Against Tampering

If an administrator can freely modify or delete the same logs used to investigate that administrator's actions, the reliability of those records can become questionable.

Sensitive logs should therefore be protected through appropriate access controls and retention mechanisms.

For critical systems, organisations may also consider append-only or otherwise tamper-evident storage.

4. Retention Policies

Keeping everything forever is not necessarily the answer.

Logs may contain personal information, identifiers, IP addresses, device information, or other sensitive data.

A sensible retention policy should balance:

Security requirements
Legal requirements
Business needs
Investigation requirements
Privacy obligations
Storage costs

The important point is to have a deliberate policy rather than allowing logs to disappear through an undocumented automated cleanup job.

What About IP Addresses?

IP addresses often appear in security logs.

They can be useful when investigating suspicious activity, but developers should avoid assuming that an IP address automatically identifies a particular person.

An IP address may correspond to:

A shared network
A corporate gateway
A mobile network
A VPN
A proxy
A public Wi-Fi connection

Therefore, an IP address can be an important investigative clue without necessarily proving who was physically using a device.

Context matters.

What Happens When an Incident Occurs?

Imagine a customer claims that ₹50,000 was transferred from an account without authorisation.

The engineering team investigates and finds:

A successful login
A password reset
A change to the registered device
A transaction request
An API response

If these events are recorded consistently, investigators can reconstruct a timeline.

But suppose the password reset event exists only in one application log, the transaction appears in another system, timestamps use different time zones, and the authentication logs were deleted after seven days.

The technical investigation becomes much harder.

The legal investigation may become harder too.

A Practical Logging Checklist

Engineering teams can ask a few basic questions before an incident happens:

Do we know what events need to be logged?

Are timestamps consistent across our systems?

Can we identify the relevant user, service, or administrator?

Can logs be modified without appropriate authorization?

How long are important logs retained?

Who can access them?

Are logs backed up appropriately?

Can we reconstruct a significant security event from the available records?

Do our retention practices align with our privacy and legal obligations?

These are not purely legal questions.

They are architecture questions with legal consequences.

Developers Should Not Become Lawyers

There is an important balance here.

Developers should not be expected to determine whether a particular log will ultimately be admissible in court. That is a legal question requiring analysis of the facts and applicable law.

But engineering teams should understand that technical design decisions can affect the quality of information available to investigators and legal professionals later.

A lawyer cannot recover a log that was permanently deleted six months earlier.

A security team cannot reconstruct an event that was never recorded.

And a company cannot easily demonstrate the integrity of a record if its preservation process was undocumented.

The Broader Lesson

Modern software systems create enormous quantities of digital information.

Some of it is temporary.

Some of it is operational.

Some of it may eventually become important evidence.

The challenge is not to turn every application into a surveillance system. It is to identify the records that genuinely matter, protect them appropriately, and establish sensible retention and access practices.

Good engineering therefore has a legal dimension that is easy to overlook.

The strongest evidence is often not created when a lawsuit begins.

It is created quietly, through ordinary system design, months or years before anyone expects a dispute.

Disclaimer: This article is intended for general legal and technical awareness and does not constitute legal advice. The treatment and evidentiary value of electronic records depend on the facts of each matter and the applicable law.

The DPDP Act Is "In Force." Here's What That Actually Means for Your Codebase

Peesh Chopra — Mon, 10 Aug 2026 16:53:54 +0000

A three-person startup ships an MVP. It stores user phone numbers, email addresses and rough location data in a shared Postgres instance. There is no consent banner, no data retention job, no documented breach process. When a co-founder raises the Digital Personal Data Protection Act, the answer from the team is: "relax, it's not even fully in force yet."

That answer is half right and half dangerous. Understanding which half applies to your product is the difference between a weekend of groundwork now and a scramble later.

The Core Question

India's Digital Personal Data Protection Act, 2023 received presidential assent in August 2023 but sat without operative rules for two years. On November 13, 2025, the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules, 2025, along with the establishment of the Data Protection Board of India. That single notification changed the Act from a law on paper to a law with a working timetable.

The question developers actually need answered is not "is the DPDP Act in force." It is: which obligations are live today, which are switched off until a later date, and what should get built into the product architecture in the meantime.

Applicable Legal Framework

Three documents matter here.

The Digital Personal Data Protection Act, 2023 is the parent statute. It defines core roles: the Data Fiduciary (the entity that decides how and why personal data is processed, meaning most product companies), the Data Processor (anyone processing data on the fiduciary's behalf, which can include your cloud vendor or analytics tool), and the Data Principal (the individual whose data it is).

The Digital Personal Data Protection Rules, 2025 operationalise the Act's provisions, filling in procedural detail the Act itself left to delegated legislation, things like exact breach notification timelines, consent notice content, and children's data verification.

The enforcement notification issued alongside the Rules sets a staggered timeline. Provisions establishing the Data Protection Board came into force immediately on notification. Rules relating to Consent Managers become operative from November 13, 2026. The bulk of the substantive obligations, including detailed consent requirements, data principal rights, and the full breach notification and penalty regime, become enforceable from May 13, 2027.

So as of today, the regulator exists, the rulebook is published, but most compliance obligations carry an eighteen-month runway rather than an immediate deadline.

Regulatory and Constitutional Position

It helps to know why this framework exists in the first place. In Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1, a nine-judge bench of the Supreme Court held that privacy is a fundamental right under Article 21 of the Constitution. That judgment is the constitutional foundation the DPDP Act was eventually built on, and it is why courts are likely to read the Act's provisions in favour of individual control over personal data where the statutory language leaves room for interpretation.

On the regulatory side, the Data Protection Board of India is now a functioning body, though independent commentary has noted a lag between its formal establishment in November 2025 and its Chairperson and Members being fully appointed, which happened only around mid-2026. Enforcement capacity is still being built even as the legal obligation exists. That gap between "law is in force" and "regulator is fully staffed and enforcing" is common for new regulatory regimes and is worth factoring into your risk assessment, not your compliance timeline.

Practical Examples for Developers

Consider four situations that come up in ordinary product work.

A signup form collects a phone number and email for OTP-based login. Once the relevant consent provisions are live, that form needs a notice, in clear language and not just legalese buried in a privacy policy link, describing what data is collected and why, at or before the point of collection.

A mobile app uses a third-party analytics SDK. Under the Act, that SDK vendor is likely a Data Processor. The Data Fiduciary, meaning the app's own company, remains accountable for how that processor handles the data, so vendor contracts need data protection clauses even if the vendor is a well-known name.

A gaming or edtech app has users who are, or might be, under 18. Rule provisions on children's data require verifiable parental consent before processing a minor's data, and the Rules set out specific mechanisms considered acceptable for that verification.

A production database is exposed by a misconfigured access control setting. Under Rule 7 of the DPDP Rules, once the organisation becomes aware of a personal data breach, it must intimate the Board without delay with an initial description, followed by a detailed report within 72 hours of becoming aware, and must notify affected individuals as well. This is one of the provisions scheduled to become fully enforceable in the later phase of rollout, but building the internal detection and escalation workflow now is far cheaper than building it under pressure after an incident.

Common Mistakes

Founders and engineering leads tend to make the same handful of errors. Treating "not yet fully enforced" as "does not apply to us" is the biggest one; the obligations exist in the statute now and will become enforceable on a fixed date, not on a date of the company's choosing. Assuming GDPR compliance automatically covers DPDP compliance is another; the two frameworks overlap conceptually but differ on specifics like the definition of significant data fiduciary, breach notification content, and children's data thresholds. Treating the privacy policy as a substitute for an actual data inventory is a third; without knowing what personal data lives where, in which database, in which log file, in which third-party tool, a company cannot honestly assess its own exposure.

Practical Steps to Take Now

Start with a data inventory: list every place personal data is collected, stored, or sent to a third party, including logs and backups. Map every third-party processor, from your email service to your customer support tool, and check whether their terms include data protection commitments. Draft a breach response runbook that assumes a 72-hour clock starting from the moment the team becomes aware of an incident, not from when the investigation concludes. Build consent capture into the product now, even ahead of the enforceable date, since retrofitting consent UI into an existing user base is far more disruptive than designing it in from the start. Finally, keep a compliance log, dated notes of what was built and when, because demonstrating good-faith preparation matters if the Board ever asks.

Conclusion

The DPDP Act's phased rollout is not a grace period to ignore the law. It is a runway to build the right architecture before the obligations become enforceable and the penalty schedule, which runs up to several hundred crore rupees for serious violations, becomes a live risk rather than a future one. Treat the current phase as free engineering time, not free legal exposure.

Disclaimer: This article is intended for general legal awareness and does not constitute legal advice. Readers should consult a qualified advocate for guidance specific to their organisation's data processing activities and compliance obligations under the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025.

DEV Community: Peesh Chopra

AI-Generated Code Is Not Automatically Legally Safe: What Developers Should Know

The Developer Still Owns the Integration

The Hidden Risk of Code Similarity

Open-Source Licences Still Matter

Security Review Is Only Half the Job

Keep a Simple AI Development Record

Don't Put Sensitive Code Into an AI Tool Without Checking the Rules

AI Assistance Does Not Replace Engineering Judgment

The Practical Rule

*Disclaimer: *

Your Third-Party SDKs May Be Collecting More Data Than You Think

An SDK Can Change Your Data Flow

What Data Does the SDK Collect?

Read the Network Traffic, Not Just the Documentation

Permissions Do Not Tell the Whole Story

Be Careful With Identifiers

Avoid Sending Sensitive Information to Analytics

Third-Party SDKs and the Indian Legal Context

Vendor Documentation Is Not Enough

Build an SDK Inventory

Review SDKs During Code Review

A Simple Developer Checklist

The Smallest Dependency Can Create a Large Data Flow

Disclaimer

Your App Logs Can Become Legal Evidence: What Developers Should Preserve

What Counts as an Application Log?

Why Developers Should Care About Evidence

The Difference Between Logging and Preserving

What Should Developers Consider?

1. Accurate Timestamps

2. Identity and Context

3. Protection Against Tampering

4. Retention Policies

What About IP Addresses?

What Happens When an Incident Occurs?

A Practical Logging Checklist

Developers Should Not Become Lawyers

The Broader Lesson

The DPDP Act Is "In Force." Here's What That Actually Means for Your Codebase

The Core Question

Applicable Legal Framework

Regulatory and Constitutional Position

Practical Examples for Developers

Common Mistakes

Practical Steps to Take Now

Conclusion

Disclaimer: