Software Development Agreements are there to improve the relationship between a client and a software development team. If everything goes according to plan, this agreement will only be looked at once. But if the worse should happen, having a clear and solid agreement can save thousands in legal fees and lost time. Slovenian attorney and legal technology founder Marcel Hajd tears down his own contract for software development. Looking at it from both the attorney and client perspectives, Marcel walks us through liability and priorities. Especially considering that this needs to be an agile agreement.
Questions in this Episode
- What role does customer feedback play when testing software for acceptance?
- What do startup lawyers need to keep in mind when it comes to ownership of the software?
- What are the different priorities when representing a buyer?
- How to deal with intellectual property rights in a software development agreement?
- What is the general principle to look for while drafting such agreements?
Overview of a Software Development Agreement
A software development agreement is a contract between a corporation and a software developer in which the firm expresses its ideas and requirements. The developer then proceeds to design the software according to the company’s schedule constraints. Agreements like these are common in software organizations where developers are contracted to create computer software. As a result, it’s critical to define the scope of both developers’ and companies’ rights in relation to the software.
Before beginning any real software development operations, the development plan is the first and the most significant step, and a well-written software development plan can help avoid future conflicts and disputes.
Exploring the Stages of a Development Plan
Section three, which deals with the development plan’s acceptance, is essentially a chronological consequence of preparation. After the development plan is prepared and ready, the customer should have agreed on a specific number of days to review and provide comments.
| 3 | Acceptance of Development Plan |
| Developer shall deliver the Development Plan to customer by [DEVELOPMENT PLAN DEADLINE]. Customer shall have [NUMBER] days to review the Development Plan. Upon approval of the Development Plan by Customer, it will be marked as Exhibit B and will be deemed by both parties to have become a part of this Agreement and will be incorporated by reference.
If the Development Plan is in Customer’s reasonable judgment unsatisfactory in any material respect, Customer shall prepare a detailed written description of the objections. Customer shall deliver such objections to Developer within [NUMBER] days of receipt of the Development Plan. Developer shall then have [NUMBER] days to modify the Development Plan to respond to Customer’s objections. Customer shall have [NUMBER] days to review the modified Development Plan. If Customer deems the modified Development Plan to be unacceptable, Customer has the option of terminating this Agreement upon written notice to Developer or this Agreement is terminated, the obligations of both parties under it shall end except for Customer’s obligation to pay Developer all sums due for preparing the Development Plan and the ongoing obligations of confidentiality set forth in the provision of this Agreement entitled “Confidentiality.” |
As a result, the second paragraph focuses mostly on the procedure. There are also additional safeguards in place for how to proceed if the development progresses and the onset is satisfactory. As a final resort, there is also the option of terminating the entire agreement.
Once the software is developed and installed, the third stage begins. The customer must have a set amount of time to test the complete software, as well as the ability to object and suggest ways to improve certain processes and things.
In a software development agreement, add additional safeguards on the side of the customer so they can object if certain things are not done properly. - Marcel Hajd #ContractTeardown Click To Tweet
Ownership of Software Clause
Section 18 gives you four options. The first is basically the essence of every software development agreement. The second and third options are more related to the license agreement.
- Ownership by customer
- Ownership by developer with exclusive license to customer
- Ownership by developer with nonexclusive license to customer
- Joint Ownership
| 18 | Ownership of Software |
| [OWNERSHIP BY CUSTOMER]
Developer assigns to Customer its entire right, title and interest in anything created or developed by Developer for Customer under this Agreement (“Work Product”) including all patents, copyrights, trade secrets and other proprietary rights. This assignment is conditioned upon full payment of the compensation due Developer under this Agreement. |
When dealing with IP ownership, not only are patents, trade secrets, and copyrights essential, but trademarks too.
This paragraph starts, “the developer shall assign to a customer”. Avoid the wording “shall assign” since this insinuates somehow that the entire transfer is moved on a certain point in the future. This creates a potential risk for the customer.
Finally, there is an interesting clause dealing with joint ownership. Since this developer is more directly involved in the entire project and the parties must divide shares on the specific software, this may be more economically appealing to the client. Because we know that startups are often financially strapped in their early stages, hiring a software developer and not investing money in the early stages of the business is a possibility.
Priorities as a Buyer
As a buyer, it’s critical to choose the option where you own the entire software because it’s a unique software that will be tailored to your needs. In general, any other choice is unacceptable, particularly license agreements, and to some extent, if you are unable to assess the financial cost. There is also the possibility that you will onboard the software developer, at least in some small percentage.
Intellectual Property
IT contracts often include IP indemnity clauses. The reason is the fact that by just buying the developer’s product, customers may risk IP litigation. Since this is an IP infringement clause, it would also be advisable to extend it in some format. For example, if a glitch in software resulted in personal injury or any other consequence, we only have an IP infringement clause that does not cover the resulting consequences.
In the following text of the first paragraph of this section, what first came to Marcel’s mind is the term ‘knowingly’. Drafters should try to avoid this term because it’s too vague and leaves quite an open door for interpretation.
| 22 | Intellectual Property Infringement Claims |
| Developer warrants that Developer will not knowingly infringe on the copyright or trade secrets of any third party in performing services under this Agreement. To the extent any material used by Developer contains matter proprietary to a third party, Developer shall obtain a license from the owner permitting the use of such matter and granting Developer the right to sub-license its use. Developer will not infringe upon any existing patents of third parties in the performance of services required by this Agreement, but Developer MAKES NO WARRANTY OF NON-INFRINGEMENT of any [COUNTRY]. |
Balance Developer Flexibility and Client Interest
Maintaining the flexibility that a developer needs to create something good, while also preserving your interest in a new product can be challenging. It’s important to balance all the rights and obligations on each side. The ownership clause is the most important and should be drafted with attention to detail.
Show Notes
THE CONTRACT: Software Development Agreement from LexRatio
THE GUEST: Marcel Hajd is fully qualified Slovenian lawyer (State Bar Exam passed in 2016), LegalTech expert and In-house Legal Counsel. His area of expertise is Commercial, Corporate and Labour Law. His professional journey includes work experience in different esteemed Law Firms across several EU jurisdictions. These placements enabled him to develop not only specific legal knowledge, but also valuable social skills. And last but not least, he is founder of LexRatio, LegalTech research, consulting and products development institute. He can be found on LinkedIn or Twitter.
THE HOST: Mike Whelan is the author of Lawyer Forward: Finding Your Place in the Future of Law and host of the Lawyer Forward community. Learn more about his work for attorneys at www.lawyerforward.com.
If you are interested in being a guest on Contract Teardown, please email us at community@lawinsider.com.
Transcript
Marcel Hajd [00:00:00] So we should not impose too much obligation on the developer.
Intro Voice [00:00:05] Welcome to the Contract Teardown show from Law Insider, where legal experts tear down contracts from some of the most well-known companies and high profile executives around the world.
Mike Whelan [00:00:18] In this episode, Slovenian attorney and legal technology founder Marcel Hajd tears down his own contract for software development. This is an unusual episode as we see Marcel both as attorney and as client. He walks through his thinking on liability and priorities and what he knows as client needs to be an agile agreement. So let’s tear it down.
Mike Whelan [00:00:42] Hey, everybody, welcome back to Law Insider’s contract teardown show. I’m Mike Whelen. The purpose in the show is exactly what it sounds like. We take contracts and we beat them up. Sometimes we’re nice, but most of the time we’re not. If we’re being honest, I am here with my buddy. Marcel Hajd. Marcel. How are you today?
Marcel Hajd [00:01:00] I’m doing fine.
Mike Whelan [00:01:02] Awesome. I appreciate you joining us. We’re doing sort of a sort of a weird twist on what we normally do because we’re talking to you as both a lawyer and as buyer, as contractor. So it’s a real interesting thing. Guys, what we’re talking about is this document here. This is a custom software development agreement. It’s an agreement for services for software services. Marcel, tell me about this document. Why are we talking about this specific document?
Marcel Hajd [00:01:30] So if we go a step, I said earlier, I am basically a lawyer by the profession of a fully qualified Slovenian lawyer, and I’m also a legal technologist. I am founder of Lex Ratio, which is basically legal research and consulting institute, and we are mainly supporting startups in Slovenia to enter the legal tech market. So this is also the reason why we signed up for this agreement, and currently we are working on the project that we are building sharing economy economy platform for legal services to increase access to general legal services. This is the reason why I find this country very interesting.
Mike Whelan [00:02:16] Yeah, and that might answer the second question, which is why you I mean you you’ve got this interesting background of both being an attorney who’s looking through this as an attorney, but as I said, also as a buyer, which is really interesting. So what we’re going to do, Marcel, is we’re going to go through and look at some of these points and take it a bit as your consideration, both as the lawyer thinking through an agreement like this, but also as somebody who’s having to hire somebody to do these things like what are what are you focusing on? So. So let’s go through it. Point by point, we’re going to start with number two. It talks about the preparation of a development plan in section two. Talk to me about what a development plan is. This sounds somewhat similar to what we talked to John Grant about earlier with an agile software development plan. But but tell me about this section. What are you thinking about here?
Marcel Hajd [00:03:05] So basically, the development plan is first and very important stage before starting any real software development activities and well written and prepare a software development plan may avoid potential arguments and disputes in the future. So, for example, our software development plan is is at the very beginning of of the of the contract, and there is not much, much to say. It is well structured here. And there is also what is important that if you are also considering to start any sort of startup, it is advisable to have at least IP friend or someone who is able to assist you in when preparing detailed technical details related to the development plan. So as mentioned, here are only main points which are going to be discussed later on.
Mike Whelan [00:04:04] Yeah, it’s an inch again. We talked about this with John Grant, which is why I love having this conversation. You know, when you’re doing these sort of software development plans, you have to have a weird balance of flexibility and boundaries, right? If you’re talking about a contract, the whole thing is to identify the boundaries. But when you’re doing software, you’ve got to have a lot of flexibility. So we’ll talk through practically what that looks like for you. I like how this section starts with like, these are the big things that we super duper care about. You better make sure your development plan has that in there. If we look at Section three, it talks about the acceptance of the development plan. So the developers are going to come up with, OK, this is what we’re after. This is how we’re going to do it. Talk to me about section three and how you’re thinking about this acceptance process of the plan once it’s created.
Marcel Hajd [00:04:52] So Section three, which deals with acceptance of development plan, is basically a chronological consequence of preparation. So once the development plan is prepared and ready, customer sure should have exactly agreed number of days to review it and to make some comments with here. With this agreement, I would like to add the second paragraph was initially not included in the contract, so we edit and tailor its doors for the particular particular piece. So the second paragraph deals mainly with with the procedure and give, but the there are additional safeguards how to proceed in case the developments develop and find its onset to the satisfactory. So the last as a last resort, there is also a possibility to terminate the entire agreement. And what I didn’t like about about the the second paragraph is that that the customer should pay all the sums for the preparation of development. I think this should be excluded at all costs since we cannot cannot. There is no fault on the customer signed for unsatisfactory preparation of development plans.
Mike Whelan [00:06:05] Hey everybody, I’m Mike Whelen. I hope you’re enjoying this episode of the Contract Teardown show. Real quick, I want to ask you to do me slash you really a quick favor. Look down below. You’ll see a discount code to join the Law Insider Premium subscription. When you do that, you get access to more content like this. You’ll see webinars daily tips on contract drafting. Not to mention access to the world’s largest database of sample contracts and clauses. It will help you write better contracts faster if you want to do it. Right now, there’s a code below, so get there. Also, if you’re part of a larger team, if you’re in-house or in a law firm, just email us we’re at sales@lawinsider.com. Will make sure you get a deal as well. Come join us in the community. The code is below. Let’s get back to the show.
Mike Whelan [00:06:50] Yeah, and it gives you, you know, even though you were the one drafting this, it’s sort of also gives you some duties to list out what was it that you didn’t like about it, which I like. You’re being mindful of both parties, which I think is smart. You know, there’s a bunch in here in the next sections about the stuff that you know really is the basic What are we paying? When are we paying? How are we paying kind of thing? But if we jump down to, there’s a bit about changes in scope and delays, which is, you know, sort of common with these sort of agile development methods. But if we go down to 11, Section 11, you talk about the acceptance testing of the software. So tell me how this is working. They’ve they’ve gone out, they’ve built something, they bring it back to you. Is that what this section is talking about?
Marcel Hajd [00:07:38] Is exactly this is and this is basically the third stage. Somehow, once the software is developed and you start on the on the hardware off of the customer here here is also necessary that the customer had, for example, a certain amount of time to test the entire software and that he can he can object and suggest how to repair certain processes and things. So by this, this section, it was also necessary, similar to the previous section Section three, if I’m if I remember correctly to add additional safeguards on the side of the of the customer that he can object if certain things are not are not designed properly. So this is mainly mainly it. So it is really, really important that we have all of these three stages.
Mike Whelan [00:08:28] Hmm. Yeah, we’re going to skip past it. But I just as an aside, I thought it was interesting looking at number 12 on the training section since I deal with this a lot and what my company does the onboarding piece right, trying to make sure that people can adopt it and know what they’re doing. I like that you were explicit in here about how that’s going to work, who’s dealing with that cost and and who’s going to be part of that if we jump down to 18, this, you know, always comes up when you’re paying for the development of software. Talk to me about section 18, which is the ownership of software. How are you thinking about that?
Marcel Hajd [00:09:02] So this section 18 is basically built. All the four options and the second and third options are more related to the license agreement. But the first option is is basically what is the essence of of every software development agreement. And if I may just briefly read developer assigns to customer its entire rights, titles and interests in anything created or developed by developer or customer under this agreement, so including patents and or other intellectual property rights. Here, I would like to add that also, trade trademarks should not be overlooked and also included not only patents and trade secrets and so on, and copyrights. And as as mentioned, sometimes I also notice that. This paragraph starts the developer shall assign to customer, we should avoid the wording shall assign, since this insinuates somehow that the the the entire transfer is moved on certain point in the future. So this make a potential risk for for the customer. So there are also the second and third and third paragraph, but within within this ownership costs. And I would like to add that somehow we should include certain types of of back license clause or something like that in case everything anything goes wrong. So in case the entire software is not transfer customer need to have some certain safeguards that he can use in its entirety. The whole software, which was basically prepared and tailored to his needs.. So this is this is in brief about the the the ownership or customer ownership clause. And as a fourth option, there is an interesting clause which is basically dealing with joint ownership. So what does joint ownership means that may be somehow economically more attractive for for for the customer, since the developer is more personally involved in the entire project? And basically, it is important that the parties divide shares on the particular software. But as we know that startups are at the very beginning of the business, they are struggling financially. So this is somehow an option to to to get on board a software developer and to not to not invest the money in so much money in the first stages of the business.
Mike Whelan [00:11:50] Yeah, I was going to ask like, as you’re doing this, I mean, you’ve got oars in here, meaning you’re going to pick which one is appropriate for the context of the particular project that you have. But how are you thinking through that as a buyer? Like how do you in what scenarios are you deciding, OK, this should be I own everything. This should be they own and they license to us. Or which scenario should it be jointly owned? Where are you prioritizing, like thinking about the project that you’re working on now? Are you leaning a direction? What’s driving that?
Marcel Hajd [00:12:20] We will probably decide for for the first option so that we will get the the the entire the entire software since it is unique software and this is basically it will be tailored to our needs. So basically any other option is not acceptable, especially license agreements and to some extent, if if we could not evaluate financially the cost. There is also an option that we will on board to the software developer, at least in some small percentage.
Mike Whelan [00:12:57] Got it. Yeah, yeah. I was thinking about, you know, obviously if somebody got an almost completed software and they’re adapting it to you, obviously they should own the majority of that so they can use it in the future. But if you’re paying for full development from scratch, right, that’s going to take a lot of money and that should that should come out. So there are some sections in here that I’m looking at the source code access, which we’ve talked about in previous episodes, some of these warranties we’ve talked about in previous episodes. But if we jump down to 22, Section 22 and the intellectual property infringement claims, you’ve got some edits in here. Tell me how you’re thinking about this section.
Marcel Hajd [00:13:36] So IT contracts often include IP indemnity clauses, so the reason is the fact that by just buying the developer’s product, customer may risk IP litigation. Since this is an IP infringement costs, it would be also advisable to extend it in some format. For example, if if a breach in software resulted in personal injury or any other any other consequence, you’re here. For the moment, we have only like IP infringement clause. So in the following text of the first paragraph of this section what first came to my mind is third, knowingly, I would try to to avoid this term because it’s to walk and to walk and to leave quite open door for the interpretation. So and what is again missing, as we already discussed earlier, is our trademarks. Trademarks are also very important intellectual property rights and should be included and cover on their IP.
Mike Whelan [00:14:47] Hmm. Well, that’s awesome. And as I’m again, as I mentioned before, we we’ve talked about software agreements and development agreements in different ways. I’m thinking about in general principles. As we wrap up you as the buyer, you’re in sort of a different position than what we’ve talked about as the lawyer. You know, obviously, as the lawyer, you’re trying to represent the interests of the buyer, but you are truly trying to change the technology landscape in the legal space in an area that is underserved. And so, you know, you want this development to work, you want this to be functional. You’re not just thinking of this in terms of me as the buyer getting what I want. You’re thinking about the ecosystem, you’re thinking about the quality of the output of this software. So tell me in a document like this, I think this is about 12 pages, 13 pages. How are you using this contract to maintain the flexibility that the developer needs to create something good, but also to protect your interest in what is a fairly new development product in the area that you’re in, in the region that you’re in?
Marcel Hajd [00:15:55] So basically, what was the main principle to be followed when drafting and preparing this contract is to balance somehow all the rights and obligations on each side. So as as mentioned to the the ownership clause is the most important clause and should be very well drafted. But as discussed, other terms would be should be somehow in balance. We shall not impose too much obligation on the on the developer. And on the other hand, as a customer, we should have additional and necessary safeguards how to how to object and if anything goes wrong in the preparation stage, testing confirmation stage and and also once we start to use the the restart, that’s to use the use, the software. And if there is any necessary maintenance.
Mike Whelan [00:16:53] Yeah, it’s interesting because I could see a developer, Burris bristling at this very, you know, broad ownership clause, but that it’s interesting because that gives you the comfort to say to the developer, actually, go do your thing, man. Like, go make whatever you’re making. I know that I’m protected in the background by this very broad ownership clause, but that actually gives you dear developer the ability to go make what needs to be made. I think this is really interesting. The approach that you’ve taken here. I’m excited to see what you’re creating. Like, we talked about it in a, you know, legal technology is underdeveloped in every market. That’s a side conversation, but specifically where you are. So it’s exciting to see what you’re doing if people want to reach out to you to learn about what you’re doing as an attorney, but also as a legal technology founder. What’s the best way to connect with your Marcel?
Marcel Hajd [00:17:41] I would suggest to connect through or through an 18 or Twitter, but I am mainly present on on all the social social media. So if you want to reach out and have any meaningful conversation with with me about the legal tech law or anything related to feel free, feel free to reach out.
Mike Whelan [00:18:00] Very cool. And we’ll have links to Marcel’s information, to this document, to related clauses that you can find inside Law Insider that are over at LawInsider.com/resources. And if you want to be on the Contract Teardown show to talk about what you’re working on as an attorney or otherwise. Just reach out to us. We’re at community@LawInsider.com. Marcel, again, thank you for coming on with us. We will see you guys at the next Contract Teardown show have a good one.