Contracts

00:00

Hi, I'm Matthew Clark, and this is less than 2.8 contracts.

00:06

In this lesson, we will first establish that I'm mellow lawyer.

00:10

And then after that, we'll discuss why we need contracts.

00:13

We will review the parts of a contract, and we'll talk about why all this actually matters. So let's get started.

00:21

Okay? So obviously, I'm not a lawyer. Uh, this is where I would say the obligatory I'm not a lawyer, and I don't play one on TV. So this isn't legal advice. Um, take this as just information.

00:34

So let's talk about contracts scope and will define the scope to include expectations and definitions.

00:41

Eso The very first thing you want to do is to find what are the key deliverables. What is the service that needs to be rendered, or what's the product that needs to be created?

00:52

The specifics and detail that work to be performed, they all All that needs to go into a statement of work.

00:58

The contract should identify what's the timetable? What type of development will be used? Waterfall agile, rapid prototyping.

01:06

What's the final product look like? What do the characteristics of that final product and what language will be used if you're coding something, is there gonna be C or C sharp python or ruby on rails?

01:18

What are the technical requirements? This is important because it helps to find scope creep, and these technical details requirements they need to be accurate and measurable and enforceable.

01:30

Ah, work report is is also a good thing. Work reports you can also call these status updates is generally the way that communication is gonna flow. So put it in the contract,

01:41

identify the mechanisms that you is. The client can review and approve the work and understand what rework is. How much money is that going to cost and how and under what circumstances does rework cost you? Is the client

01:57

change? Management is another good section that section and outlines a process for handling changes.

02:01

Testing reveals a flaw in the design. So how are you gonna handle that?

02:06

Our vulnerability is found and open source library, which is included in the agreed upon specifications. So how is that handled?

02:15

Acceptance? Testing is another good one. This defines the acceptance testing gates, so to speak.

02:22

Onda should follow up with the gate. These gates should follow each of the key deliverables

02:28

payment is it could be tied thio the successful approval of those gates.

02:34

Non performance. How do you How do you define nonperformance? What are the penalties for that? And how can you end the contract for non performance? What happens to the work product? In that case, are there any termination fees that are associated with it?

02:49

Let's discuss problem management.

02:52

This section of the contract addresses the underlying issues of change. The contract should outline how the developer will handle product defects. How are the defects? How would they be reported? Who's gonna pay for the correction

03:06

and where it is? Defect Data stored

03:08

Cancel for cause is a good thing to talk about. Determination for cause can take place if one party cannot fully complete or fulfill their contractual obligations.

03:20

An example of this might be a developer terminating the contract for calls because the OM they have failed to pay them

03:28

Or another example might be that the OM is terminating the contract recalls. Because the developer failed to include agreed upon feature

03:38

now versus four calls versus for convenience for convenience is determination.

03:43

When the contract is terminated, when there's no contract breach.

03:47

So a termination of conveniences Onley legal when is expressly written in the contract.

03:53

This clause allows for both parties to end their responsibilities in a way that avoids the cords

03:59

but for convenience. In my experience, you know, sometimes it works great, and sometimes it doesn't so just be aware of that.

04:09

So let's talk about security and privacy.

04:12

So confidential data is data about your business. Let's define it that way.

04:16

How should the developer handle confidential data that you share with them about the I O T ecosystem, the product or your business plans? Should the developer isolate their development teams from other clients that maybe working on the similar or related field or project? There's a good questions.

04:33

Sensitive data is generally data about people.

04:38

So what obligations does your company have for protecting the various data types?

04:42

What laws and regulations protect certain data types, for example, ph. I that personal health data or personally identifiable information or credit card data

04:53

does the product requirements need to reflect any obligations relating to those data types?

04:59

Intellectual property is something else to consider data such as trade secrets. The ownership is a good one. The first area to focus on is, of course, the ownership of the end product.

05:11

Who will own the finished product. If you pay someone else to build a product that they end up selling is a software as a service for other businesses that could happen without a contract in place.

05:23

Or you could pay for a product that you really never get the source code for. And it's painful to get out of those types of relationships and get out of it. Whole feel are feeling like you're you've been made whole.

05:34

I'm told that the Copyright act requires ownership really clearly assigned against. I'm not a lawyer, Uh, but my understanding is a freelance developer. Providing programming services to a client is usually a work for hire relationship. Therefore,

05:50

any language that suggests the contractor retains all rights and licenses resulting

05:57

of that work. Those things should be avoided if you plan to own it yourself. Escrow is a good a good concept that protects both parties by storing software in a neutral third party

06:08

s broken physically hold copies of intellectual property or source code, so that if the developer goes out of business, the source code is still protected.

06:16

Of course, that requires a process to get the developed code to the escrow agent and another process to verify that the contract has been completed successfully.

06:26

Licensing is another great topic. To address the contract. The developer may require license to continue to develop and work on the software after it's been delivered, so you may need to think about that.

06:40

So let's talk about the differences between warranties and indemnity.

06:44

So a warranty is a promise from the cellar that the product will do what it's supposed to do and that the seller will fix and replace it if it doesn't

06:53

eso. Basically, it states that that the developer is gonna follow the terms of the contract in the statement of work. So, for example, ah, warranty might be that I guarantee that the project is free of back doors.

07:04

Many times a developer will provide a warranty that their software is, as is,

07:11

this is, and then they will not state that it is, but for specific purpose or compliant with a regulation or law like PC I or D. D. P r.

07:19

Indemnity is different. To indemnify means to compensate someone for his or her harm or loss and identification clause,

07:29

um, is the opposite of a liability protection.

07:32

It provides protection in case the developer infringes on third party copyright.

07:38

It covers his business losses if third Party claims from Frenchman,

07:43

and it might be hard to get a developer to take on too much risk, especially if they don't have insurance

07:47

liability. Um, there's something really discussed within this context. The developer should agree to some sort of liability that's related to the warranties in the identification in your agreement. And maybe that does mean that the developer will have toe seek out some type of insurance.

08:05

But they need to have a way to that. The liability will be calculated, and that's done you usually either through a fixed dollar amount or limited cumulative amount.

08:18

So let's talk about payment terms and ongoing support, so details about payments could include deposit or down payment or invoice timing 30 60 90 days or the amount to be, um, to be build

08:30

and ongoing support really includes, like support services and the duration of support agreement, different service level agreements or exclusions

08:39

and those types of things. And he's a really important toe to figure out and have inside the contract of possible.

08:46

So why is this important?

08:48

Well, a very simple terms. Contracts provide layers of protection much in the same way that technical controls protect I o T devices. Except this protects the business.

09:00

Um, so, for example, when I cannot verify vendors security level, I generally will encourage stronger contract terms.

09:07

They also established risk tolerance levels and contracts, allow unacceptable levels of risk to be transferred to another party.

09:16

And finally, contracts set acceptable levels of risk for the business relationship itself.

09:26

Well, that's it for this lesson.

09:28

In this lesson, we discussed the fact that I'm not a lawyer and none of this legal advice.

09:33

We also established why contracts are important and we discussed the protections that they can afford. And then we m.