IPR (C)

Types of Property
⮚ Real
● Land

⮚ Personal
● Cars, jewelry, clothing

⮚ Easements
● Non-corporal interest in real property
• Railroads, utilities

⮚ Intellectual
● Patents, copyrights and trademarks

Patents
⮚ Grant of a property right to the inventor

⮚ Issued by the Patent and Trademark Office

⮚ Term of a new patent is 20 years from the date on which the application for the
patent was filed in the United States

⮚ US patent grants are effective only within the US, US territories, and US
possessions.
⮚ The right to exclude others from making, using, offering for sale, or selling” the
invention in the United States or “importing” the invention into the United States

⮚ Not the right to make, use, offer for sale, sell or import, but the right to exclude
others from making, using, offering for sale, selling or importing the invention

Computer Contracts
INTRODUCTION
• Contracts set out the agreement between the parties:

• they set out the aims of the parties;

• provide for matters arising while the contract is running,

 • ways of terminating the contract

• and the consequences of termination.

• Where there are gaps in the agreement because the parties have failed to contemplate a
particular issue,
• it is a function of contract law to fill them,
• for example by implying terms;
• also contract law provides rules for the termination of the contract if performance
becomes impossible;
• and sometimes, although fairly rarely, it sets aside contracts which are too harsh or
unconscionable (unreasonably excessive).
• Since the advent of the Internet, the market has globalized to a far greater extent than
ever before,
• and there is greater need for international harmonization of laws.
he EU has therefore been very active in line with its policy
• There are therefore directives and proposals for directives on:
1. legal protection for encrypted services in the internal market;
2. electronic signatures;
3. electronic commerce;
4. distance contracts;
5. distance selling of financial services.

Digital Signature:
An electronic signature, or e-signature, refers to data in electronic form, which is logically
associated with other data in electronic form and which is used by the signatory to sign
• One of the problems with computing contracts is that many lawyers are still not familiar
with the technology.
• On the other hand even fewer computer scientists are familiar with the law.
• As both lawyers and computer scientists use jargon known almost only to themselves, the
difficulties are compounded.
• These difficulties are however receding,
• for more lawyers are becoming familiar with computing through use of computers at
home and in work;
• there are more lawyers specializing in this area of the law;
• and many books have been written describing
– the framework of computer contracts,
– and providing model contracts or precedents, which lawyers can adapt to the needs
of their clients
Structure of the contract
• Producing a good contract costs a lot of money;

• Good commercial lawyers are not cheap.

• For this reason, software suppliers try to use what are known as standard form contracts,
which are used or intended to be used many times over.

• Such a contract might consist of:

@ a short introductory section, which specifies, the names of the parties to the contract;
@ a set of standard terms and conditions;
@ a set of appendices or annexes.
@ may be a few other things.
• The standard terms and conditions do not change from one project to another;
• They contain references to the annexes, which contain all the project specific material.
Sections of a contract
• The introductory section
• What is to be produced
• What is to be delivered
• Ownership of rights
• Confidentiality
• Payment terms
• Calculating payments for delays and changes
• Penalty clauses
• Obligations of the client
• Standards and methods of working
• Progress meetings
• Project Managers
• Acceptance procedure
• Warranty and maintenance
• Indemnity (exemption/protection against a loss or other financial burden)
• Termination of the contract
• Arbitration
• Inflation
• Applicable law
Deliverables (What is to be delivered).
• Source code
• Command files
(for building and installing the executable code)
• Documentation
• Manuals (Reference, Training, Operations)
• Software tools to help maintain the code
• User training (on site / off site)
• Training for client’s maintenance staff
• Test data and test results
Obligations of the Client
• Information on Client activities/setup
• Information on software environment
• Access to staff
• Facilities for development and testing
• Facilities for software company staff on client premises
• Attendance at progress meetings
IPR and other rights
• Who owns the rights to what
– Books, documents, disks
– Intellectual Property Rights
• Author of the software
• Software House
• Client (upon payment)
• Written agreement (assignment of rights)
• Sale or Licence …
Licencing Agreement
• Exclusive Licence (expensive)
– Software house retains copyright
– Software house can’t re-use the code
 • Non-Exclusive License (cheaper)
– Software house retains copyright
– Software house can re-use the code
– Client may acquire right to veto grant of licence to others (competitors)
• Matters to consider
– Duration of licence (termination)
– Right to assign (transfer) licence to others
– Scope of licence
• One or more computers
• One or more sites
–Confidentiality
Client is prevented from allowing others to become familiar with the software
Confidentiality Agreement
• Confidentiality of Client business
• Confidentiality of the software and the properties of the system
Applicable at different stages:
– Pre-Contractual stage
– Whilst software is being developed
– After delivery
Payment terms
Issues to be considered:
• Staged payment
• Milestones
• Delays and changes (attributable to Client)
– Calculating the cost
– Changes to delivery schedule
– Changes to performance
Indemnity
Each party will indemnify the other against potential liability for accidental or deliberate
infringement of IPR due to their own fault
e.g. if the software includes proprietary components which the developer had no right to use
Termination of the Contract
• Client’s needs or circumstances may change
• Software may no longer be appropriate
• Issues to consider
 – Indemnity for termination
– Ownership of software developed so far
Other contractual Issues
• Quality control
• Progress meetings
• Managing the project
• Acceptance procedure
– Determine if Contract has been delivered
• Warranty and maintenance
– Bug fixing (free of charge – e.g. 90 days)
– Extended warranty (enhancements)
• Arbitration
– Arbitration clauses are common
– Cheaper and faster than going to court
– Usually governed by Arbitration Act 1996
• Inflation
– In case of long term maintenance
– Automatic review of agreed price
– Frequently linked to Business Costs Index
• Applicable Law
Choice of the law which applies to the Contract (and its interpretation)
– If the parties have registered offices in different countries
– If the performance of the Contract involves more than one jurisdiction
• Language of the Contract
– If contract is to be translated, which is the binding version
Limitation of Liability
Unfair Contracts Terms Act (Section 3)
• Provides that a software house using a standard from contract cannot, unless it is
reasonable to do so,
– Exclude liability for its own breaches of contract, or
– Claim to be entitled
• To render a contractual performance substantially different from that which
was reasonably expected of it
• Render no performance at all (in respect of the whole or part of its
contractual obligations)
 Crime bill 2016
10-Cyber terrorism
19-Offences against Modesty of a Natural Person and Minor
15-Unauthorized issuance of SIM cards etc.

Cognizable: Police officer can make an arrest without a warrant and start an investigation with
or without the permission of a court.

Bail-able: The defendant may be able to secure his release upon the payment of bail.

Compoundable: The complainant enter into a compromise, and agrees to have the charges
dropped against the accused.

Offences and Punishments

 Failures and Errors in Computer Systems
Most computer applications are so complex that it is virtually impossible
to produce programs with no errors.
Some errors are minor, some incidents are funny, but some are tragic.
Some cost billions of dollars.
Studying these failures and risks contributes to understanding their causes
and helps prevent future failures.
Computer glitches and system failures have numerous causes, including:
Faulty design, sloppy implementation, careless or insufficiently trained users, and
poor user interfaces.
Often, there is more than one factor.
Because of the complexity of computer systems, it is essential to follow
good procedures and professional practices for their development and
use.
When should we, or the government, or a business decide that a
computer system or application is too risky to use?
Why do multimillion-dollar systems fail so miserably that the firms and
agencies that pay for them abandon them before completion?
We cannot answer these questions completely, but this lesson provides
some background and discussion that can help us in forming conclusions.
It should help us understand the problems from the perspective of several of the
roles we play:
A computer user: Whether we use our own tablet computer or a sophisticated,
specialized system at work, we should understand the limitations of computer
systems and the need for proper training and responsible use.
A computer professional: If you are planning a career as computer professional
(system designer, programmer, or quality assurance manager), studying
computer system failures should help you become a better professional.

Understanding the source and consequences of failures is also valuable if you

will be responsible for buying, developing, or managing a complex system.
An educated member of society: There are many personal decisions and social,
legal, and political decisions that depend on our understanding of the risks of
computer system failures.
Problems for Individuals

Billing errors

The first few errors we look at are relatively simple ones whose negative
consequences were undone with relative ease.
A woman received a $6.3 million bill for electricity; the correct amount was $63.

The cause was an input error made by someone using a new computer system.
Programmers and users can avoid such.
For example, programmers can include tests to determine whether a billing
amount is outside some reasonable range or changed significantly from previous
bills.
These errors are perhaps more humorous than serious.
They are worth studying, because the same kinds of design and programming
errors can have more serious consequences in different applications.

Inaccurate and misinterpreted data in databases

Credit bureau records incorrectly listed thousands of residents as not having paid their local
property taxes.
An input error appeared to be the cause of the problem.
More serious, perhaps, are all the errors in individual people’s records.
In one case, a man applied for jobs at several retail stores and they all turned him down.
Eventually he learned that the stores used a database to screen applicants, and it listed him as a
shoplifter.

It is difficult to get accurate and meaningful error rates for major databases with information
about millions of people.

When errors occur in databases used by law enforcement agencies, the consequences can
include arrests, searches, and time in jail.

Factors that contribute to the frequency and severity of the problems people suffer because of
errors in databases include:
A large population (Many people have identical or similar names)
Automated processing without human common sense
Overconfidence in the accuracy of data stored on computers
Errors (some due to carelessness) in data entry
Failure to update information and correct errors
Lack of accountability for errors

System Failures
Modern communications, power, medical, financial, retail, and transportation
systems depend heavily on computer systems.

They do not always function as planned.

An aim is to see the serious impacts of the failures—and to see what you want
to work hard to avoid.

The lessons of adequate planning and testing, of having backup plans in case of
failures, and of honesty in dealing with errors apply to large projects.
Millions of BlackBerry users did not get their email for nine hours after the
company installed a faulty software update.

A three-line change in a two-million-line telecommunications switching program

caused a failure of telephone networks in several major cities.

Although the program underwent 13 weeks of testing, it was not retested after
the change—which contained a typo.
Log-ins overloaded Skype’s peer-to-peer network system when a huge
number of people rebooted their computers after installing routine
Windows updates.

A majority of Skype’s Internet phone users could not log in for two days.

Every few years, the computer system of one of the world’s large stock
exchanges or brokerages fails.

The sources of the problems included:

technical difficulties (converting software to a different system),

poor management decisions (inadequate testing of the modified system on the

new platform), and,

according to the customers, dishonesty in promoting the system and responding to

the problems.

Abandoned systems
The flaws in some systems are so extreme that the systems end up in the
trash after wasting millions, or even billions, of dollars.

A large British food retailer spent more than $500 million on an

automated supply management system; it did not work.

The Ford Motor Company abandoned a $400 million purchasing system.

Such large losses demand attention from computer professionals,

information technology managers, business executives, and public officials
who set budgets and schedules for large projects.

Software expert Robert Charette estimates that from 5% to 15% of

information technology projects are abandoned before or soon after
delivery as “hopelessly inadequate.”
Some of the major reasons he cited are:

Lack of clear, well-thought-out goals and specifications.

Poor management and poor communication among customers, designers,

programmers, and so on.

Institutional or political pressures that encourage unrealistically low bids,

unrealistically low budget requests, and underestimates of time requirements.

Use of very new technology, with unknown reliability and problems, perhaps for
which software developers have insufficient experience and expertise.

Refusal to recognize or admit that a project is in trouble.

Legacy systems
Legacy systems are out-of-date systems (hardware, software, or peripheral
equipment) still in use, often with special interfaces, conversion software, and
other adaptations to make them interact with more modern systems.

Old hardware fails and replacement parts are hard to find; Old software often
runs on newer hardware, but it is still old software.

Old programs often had little or no documentation, and the programmers who
wrote the software or operated the systems have left the company, retired, or
died.

A complete redesign and development of a fully new, modern system would, of

course, be expensive.

It would require a major retraining project.

The conversion to the new system, possibly requiring some downtime, could
also be very disruptive.

What Goes Wrong?

Computer systems fail for two general reasons:

The job they are doing is inherently difficult, and sometimes the job is done
poorly.

Several factors combine to make the task difficult.

Computer systems interact with the real world (including both machinery and
humans), include complex communications networks, have numerous features
and interconnected subsystems.

Automobiles, passenger airplanes, and jet fighters contain millions of lines of

computer code.

A smartphone has several millions of lines of code.

The job can be done poorly at any of many stages, from system design and
implementation to system management and use.
Vulnerability
A vulnerability is a set of conditions or behaviors that allows the violation of an
explicit or implicit security policy.

Vulnerabilities can be caused by software defects, configuration or design

decisions, unexpected interactions between systems, or environmental changes.

Vulnerabilities can arise in information processing systems as early as the design

phase and as late as system deployment.

National Institute of Standards & Technology (NIST) offers the following

definitions of vulnerability:

1. “Weakness in an information system, system security procedures, internal

controls, or implementation that could be exploited or triggered by a threat
source”.

2. “A weakness in a system, application, or network that is subject to

exploitation or misuse”.
A vulnerability may be thought of as an undesirable, exploitable, and
likely unintended feature of software or hardware components that allows
an attacker to perform actions that wouldn’t otherwise be available to
them.

The impact of such vulnerabilities can vary greatly,

from being able to access someone’s private data,

to taking control of a computer,

to causing physical damage and bodily injury.

Exploits, Malware, and Incidents
An exploit is software that uses a vulnerability to achieve some effect.
Sometimes the effect is as simple as demonstrating the existence of the
vulnerability.

Other times it plays a role in enabling adversaries to attack systems.

Malware is software used by adversaries to compromise the security of a

system or systems.

Not all malware involves exploits.

An incident is a violation or an attempted violation of a security policy,

and may involve malware, exploits, or vulnerabilities.

Vulnerability Response (VR)

Vulnerability Response (VR) is the overall set of processes and practices
that deal with the existence of vulnerabilities in systems.

VR encompasses everything from reducing the introduction of

vulnerabilities through the remediation of deployed vulnerabilities via
patch deployment.

For those vulnerabilities that do escape detection by early lifecycle

practices, it is necessary to plan for their eventual discovery and
disclosure.

The goals of vulnerability response include the following:

Limit attacker advantage over defenders.

Reduce the population of vulnerable product instances as quickly as possible.

Reduce the impact of attacks against vulnerable systems.

Vulnerability Disclosure
ISO/IEC 29147 defines Vulnerability Disclosure as follows:

Vulnerability disclosure is a process through which vendors and vulnerability finders may work
cooperatively in finding solutions thatbreduce the risks associated with a vulnerability.

It encompasses actions such as reporting, coordinating, and publishing information about a

vulnerability and its resolution.

The goals of vulnerability disclosure include the following:

Ensuring that identified vulnerabilities are addressed.

Minimizing the risk from vulnerabilities.

Providing users with sufficient information to evaluate risks from vulnerabilities to their
systems.
Disclosure Choices
Non Disclosure

All information about the vulnerability is kept private.

Sometimes this is enforced by non-disclosure agreements

(NDAs).

Vendors sometimes prefer this scenario to protect trade secrets

or to lessen the impact of perceived negative press.

Some finders prefer not to disclose vulnerabilities, in the hope

that malicious actors will not find out about the vulnerability if it
is not disclosed.

Private Disclosure

When a product’s vendor is aware of a vulnerability, the vendor may take action to address it
but will only notify its own customer base of the vulnerability.

Many of the same motives as the Non Disclosure policy are also in play here.

The hope is that malicious actors are much less likely to find out about and exploit a
vulnerability.

Avoiding negative press is also cited as a reason for this approach.

Some vulnerability finders are satisfied by this method if all known customers can be reached.

However, this approach is often not practical for widely deployed or open source software.
Limited (Partial) Disclosure
When a vulnerability is found, only some information about the vulnerability is disclosed to the
public.

The goal is typically to slow down the exploit development long enough for a fix to be
developed and deployed.

This is done by withholding proof of concept code or other technical details of the vulnerability.
But still providing enough information that users of the product may take action to mitigate the
issue.
Full Disclosure

When a vulnerability is found, all information about the vulnerability is disclosed to the
public.

Typically, this scenario results in the release of proof of concept exploit code along with a
report describing the vulnerability.

Finders following a full disclosure approach may or may not attempt to notify the vendor
at all in advance of the public release of the vulnerability report.

The belief is that this approach serves the greater good by allowing consumers:

To be aware of the full impact of issues in their products

Demand action from vendors

Have information available to take appropriate defensive action.

Another perceived benefit is that it allows other researchers and organizations to

reproduce and confirm the vulnerability.

This type of disclosure may also be performed by the vendors themselves.