Let's get started. Sorry, I'm a lawyer. I should start with an apology. Not everyone likes lawyers. Over the next 20 to 30 minutes or so, we can talk about things that are of relevance to you. I'm watching your questions as they come through, so feel free to ask. It is simply a taxi - the background gave me a strong no. This is the quietest place to find this type of thing.
I'm a lawyer. Probably not your lawyer. I might be if that might be up your street. My details are at the end. Feel free to drop me a line. I do internet, telecoms, and tech law, so hopefully most of what I work on is going to be relevant to the things that come across your desks and the things you do from day to day. If you are a Twitter person, you're welcome to follow me on Twitter. I'm happy to chat to people of any background or any interest whatever you might do, scan the QR code and that will take you to the enquiry the profile and also on Mastodon if you prefer an alternative.
I'm a lawyer, so couldn't start a presentation without disclaimers. There are lots of you here here today, and I'm only an English lawyer. The laws in your country maybe different to the laws I'm going to talk through today. Hopefully, the themes and tips I'm going to talk through are generally useful whatever the specific legal situation is, but please be aware yours do vary between countries. Not only do laws vary, but the right answer to any question is fact-specific. These are general tips rather than tips for any specific situation.
I've got about 20 minutes to give some time for questions, so this is a very brief discussion of some issues. I can't give you all of the answers you need within the time here. But, if you have questions, ask them. If you ask questions and I don't have time to get to them and you don't think of the question until later, do not hesitate to get in touch. You are more than welcome to come and ask me. What I probably can't do is give you legal advice, but I can point you in the right direction or have interesting general discussions. Okay, 20 minutes, five tips. Let's go.
I've broken this down just for the sake of giving some framework for starting a business to two areas that are probably most prevalent to developers, whether that is software, web, whatever it might be. The two areas I'm going to talk about are firstly some things to do with contracts. And secondly, some things to do with copyright.
The tips that I'm going to give are likely to be applicable whether you are directly involved in the contract process, or in stuff to do with copyright, or whether this is for your general background and your awareness. They also apply whether, certainly for the contract stuff, whether you are a buyer or whether you are a seller, and most people are buyers and sellers at the same time, just for different things, but these are general tips, and they're likely to apply whichever side you're on.
Now, even if you're not involved in the process, perhaps that is down with people with different skills, or people who are more senior, or managerial level, understanding the basics can still help you, and it can help you ask the right questions, ask sensible questions. Ask questions they may not have thought about when it comes to defining the work that you're doing. Also, the questions you might ask around a contract with likely to apply when someone asks you to do work within a company as well.
You understand what I mean by that when we come to talk to them, but if you are not involved in a contracting process with a customer, these are likely to help you when you work out what you need to do to plan your day and deliver things.
We will start with contracts. And the aim of a contract in most cases is simply to get clarity and certainty. Clarity and certainty on a number of different things which you will go on to talk about. Your overall goal is to understand what it is you have to do, what they have to do, what are your obligations, what is the impact of doing these things, how do you get your knee, or how do you pay someone, and in sufficient detail and sufficient clarity, sufficiently unambiguous language that, if there is a problem, you can turn to the contract and say yes, this is what I need to do, or this is what I expect of you.
Where things go wrong is typically where things are ambiguous, where things are not clear, where someone didn't think of something and the contract doesn't say what you have to do. Hopefully in most cases, you're going to be able to talk with them and come up with a reasonable, fair, common-sense resolution.
In all the years I've been doing work involving contracts, and that is 15 or 16 years now, I don't think I have had one that has gone to dispute. While disputes may be things that you worry about, if you get your contracts right, if you work with your suppliers or customers, you may be able to avoid disputes completely.
Let's start, tip number one. Define the deliverables clearly. The deliverables are the things that you have to do. If you are a seller, they are the things that you have to deliver for the customer to be satisfied that you've done your job properly. And if you're the customer, they are the things that you are buying.
You want to be specific about what it is that you're buying, what it is that you're selling, and ideally, like objectives or goals, these things should be measurable, or assessable. You don't want to be them to be vague. To deliver a good enough system - good enough for what? Specify in detail what it is that you're selling or what it is that you're buying so that if someone produces what you done or what you need to do, you can look through and say, yes, I have ticked all these boxes, I've done what is required of me. If you leave it more vague than that, you run the risk of someone saying that is not what I was expecting. The contract says this is what I have to deliver. If you can't be that specific, you do run the risk of someone being upset, whichever side you're on.
In a lot of cases, you will try and come up with a specification: this is what I'm going to deliver. Maybe you need to charge for the development of that specification. It may be that sort of, that detailed you need to do a discovery phase, a piece of work first to work up the specification. You may not working out what you need to do. Working out what you need to do is a valuable service. If you're going to do that, make your specification as detailed and unambiguous as possible. Ideally, it is almost a tick list, what you've gone through saying done that, done that, done that, and it is will he S very clear whether you've done it or not. Attach that to the contract and reference it in the court.
Again, you're trying to get certainty and clarity. What is the process for testing it does meet the expectation? Who has to do what and by when? You don't want to do your work and find out a customer doesn't want to test it for another three or four weeks. You don't want to find the work is done and you're squeezed into 48 hours to do the testing on a really big project.
The timescales that apply will depend on what is being done. If there are no timescales in there, that starts to be ambiguous, and you go back to the idea of clarity and certainty. Not everything works first time. Sometimes, things will need to go back, and in general read in them.
You may think you hit the specification, but the client does the testing and say, actually, it doesn't do this. Well, hopefully, you've pretested it yourself to be confident, but things do come up. What is the process for fixing those? Are you promising that if they spot something that doesn't comply with the specification in the acceptance test process will fix it? That might be reasonable.
What you probably don't want to do is find yourself that you're on the hook for fixing it forever, that the customer pops up in two years' time and say that code that you wrote isn't running any more. You probably want to say, well, you accepted it and tested it, that's now done. I may be offer to offer you a service to help you fix it, that's fine, but this is not something you're getting for free.
From a customer point of view, you want to be confident that if you spot a load of defects in something, ideally, during your testing period (a) you have a testing period, and, if you spot defects you're not going to be charged more to meet the specification of the service. So, try and get it documented as much as you possibly can. Chances are you can't do something on your own.
If you're buying something, you need to do something that they're producing or selling to you. If you're the developer, the seller, you may still need the customer's input. They may need to make decisions, and those decisions may impact timescales. If they're too slow, they may impact costs. Write down what is the other side responsible for? What do they have to do and when? What do they need to provide? That is number one: define your deliverables clearly.
Tip two is all about the money. You are here for business. There is nothing wrong talking about money. If you don't talk about money, something's gone wrong. I will say as a caveat that if you're developing free and open source software, then issues around money are perhaps different, but we're thinking here about the scenario where you're perhaps being paid to do some development, or you're buying some development from someone, so, money is a perfectly reasonable topic to talk about. Think about the basics.
How much are you charging for this work? Is it a fixed price? Is it time and materials where you charge based on how long something takes you, or what you need to do for that project? Is it a mix of both which you might call a capped fee? This is the upper limit, the ceiling. You will never charge more than that, but if it actually costs you less in time to do it, you will charge something lower. What currency are you being paid in? Increasingly, I'm being asked will I accept cryptocurrency, bitcoin? Will I accept payment in digital representations, or linkages to ... I'm quite boring.
I prefer pound sterling, transfer to a bank account, thanks. If the other party trades in a different currency, someone has a currency conversion cost. Is that you? Is that them? Are there bank charges applicable for doing an international transfer, for example? Who bears that cost? Presumably, if you're a developer, you want a certain amount of money, and if it costs the customer to transfer that to you, they need to pay that on top.
If you have a customer, you might have a total budget, and that is all you can spend. You might not have the money for doing extra on top, so think about it and document it. When do you get paid? The customer may not want to spend money in advance. You want the certainty that you're going to get your product before you part with your money.
As a developer, it can be very difficult to run everything in arrears. The idea that you're not getting money until later on. Can you split it? Can you get some in advance and some later? Are there milestones or interim payments as you deliver the project, perhaps, on a monthly basis, or on a quarterly, or as you hit certain milestones whenever they happen rather than waiting for all your money at the end or demanding it all at the beginning? What is the impact of late payment?
Now, English law provides an automatic scenario for you to recover the costs of claiming late payment and for interest for late payments. In fact, some automatic fees for late payments are. I'm not going to go into the detail of those, but if you are trading under English law, it will be worth familiarising yourself with international debts framework. Write about it in your contract, saying this is what happens. Don't be shy charging it. You can always say the first time, look, I could have charged you this, you were late paying your invoice, but I'm not going to. You can waive it, but, be specific. And don't be shy about asking for payment.
If you've done the work, you deserve to be paid for it. Ask for your money. If you need to rely on the late-payment clauses, consider doing so. It is not a business if you're selling something and people are just take it and not paying you the money they should deserve - sorry, they should deserve the money you've agreed if the contract.
Tip three, intellectual property. This covers a whole load of things and I'm not going to get in the detail. We are talking about particularly copy writing things, possibly patentable innovations, but it's copyright I'm thinking of here. You've taken photographs, produced some awed euro, designed a website so you've got code and media files, or written some software, and you've got source code, and the content, and the sound recordings and videos, whatever goes into what you're doing.
Are you transferring or assigning the ownership of that copyright to the buyer? Do you want a licence back so you can use what you developed for your own purposes, or giving a licence, a permission to the customer to use it but they don't get to actually own it? If you're going to develop something and then try to sell it to others, or license it under a free or open source license, you probably don't want to transfer the ownership away because it would stop you from doing that.
The chances are, giving a licence, the customer will see less valuable than getting ownership, so you might not get as much money for it. The customer may not care, they may not want ownership. A licence, as long as it is a specific licence, what the licence covers, how long it lasts, may be just as good as ownership for them, and you need to have these conversations up front and document what the position is.
What if you're bringing your own tools to the situation? You've already got some libraries which will do what you need to do? You probably don't want to find you've accidentally given away ownership in those, so be clear about what happens about your own existing intellectual property or library. What happens if during the course of the project you develop an enhancement to your own pre-exist ing work? Who owns the enhancement? Be clear about your use of free and open source software.
Some organisations are happy with it, it speeds up development time, you can use codes that loads of others have seen and worked on, and, if you're doing something in cryptography, rolling your own is probably a really bad idea. But the customer may not be happy with you using free and open source software, or they might be specific about which licences that you can use. So try and think about it up front.
If there is no prohibition in your agreement, you're probably free to do it, but if I were you, I would be asking that question. If I were the customer, I would probably want to know is my solution going to come with free and open-source software in in it, and what licences? I can go away and think about the implications for that and how I intend to use it.
Tip four: it is about your liability, your risks. If things go wrong, what might it cost new what might the impact be? Start simple. Work out what your risks are. What is the impact of those? Ideally in financial terms, if x happens, what would this mean to me? What would I have to pay? Think about capping your liability, or excluding your liability so that you're not on the hook for absolutely everything.
Maybe you've agreed to do a piece of work for £2,000. It's probably not reasonable for you to be on the hook for hundreds of thousands or millions of liability. There are some things you can't exclude - personal injury or death caused by negligence, for example, or liability caused by your own fraud, but there is plenty you can do particularly in a commercial relationship. Limit the period for bringing in claims.
If someone wants to sue under this contract, you want to limit it to a year from the date of delivery, a year from the date of performance, two years from the point of termination. Whatever it might be. Some sort of dispute resolution process. There has to be an escalation before they can sue you. You could look at other things, mediation, or arbitration, but each of those has its own vagaries and specificities as well. Overall, think about and assess your liability.
Read your contract. Read it twice. Things you didn't pick up the first time. Do not just sign it. Do not be told this is standard. Don't click accept. Seriously, don't do it. I mean, don't! You can usually negotiate stuff as well.
If someone presents you with a set of terms and you don't like them, ask about them. Everyone says it's standard. So what? The deal needs to work for the specifics of what you are doing here. We never negotiate this. Okay. But if you want the delivery, maybe you need to. I can't pretend that always you'll be able to negotiate everything. I would love to pretend you're going to sign up with a service with Amazon or Microsoft and negotiate the contract with them. Realistically, in 99.99 of cases, you're not. Oftentimes, you can, and you need a deal that works for you.
You often see a threat, "We will walk away if you don't sign it." Apple if your supplier it trying to hold you over a barrel like that, or a customer threatening you that way before you've even started work, I would be really worried about what that relationship is going to be like and how the delivery and the performance of the contract is going to go. It might be time to talk away.
There are a couple of books if you want more reading about negotiations, two books I particularly like Getting to Yes, an older book, but a whole load of useful tips and techniques in there. Never Split the Difference, is a more modern book, by an FBI hostage negotiator, and it has practical exercises and examples of how to improve your own posture.
Yes, good comment there from Darren: although I've been talking about sales or procurement contracts, selling or buying stuff, the same principles work with employment contracts. You can typically negotiate things. I'm conscious I've hit my 20 minutes and I will go a few minutes longer.
Think about a template. Something that you can give when someone asks you for work. It can make your contracting faster. Make it suit your needs, obviously, but if you're unreasonable or unbalanced, probably you will get people asking you to make changes and that takes time that you might want to avoid. Be open to amendments to your own template. People say I've got a template, I can't deviate from it, unless that is justified.
If you've got a template that works for you, even if you end up with someone else's contract, that's what I would have liked, hmm, there's something different here. It's a useful tool in itself.
I promised you five and we are on tip seven! Let's dive into copyright. I will give you the fastest primer I can. Copyright is a bundle of property rights. They're automatic. You don't have to do anything. You've written your code, you saved it, copyright has automatically arisen in that code, and they arise when someone creates when someone creates "a work", copyright works cover a number of things.
Instructions, software, database, are a literary work, and there are dramatic music and artistic work, songs, musical scores, photos, drawings, videos can be within that. Things that you might use in your project. A sound recording is a copyright work in itself. So chances are the things that you're doing attract copyright, and the impact of that is that certain rights are reserved to the owner of that copyright.
Now, it could be you as the author or someone else depending on what you signed up to, but, the owner has exclusive rights. They last a long time. If you've written a software, a literary work, for example, copyright lasts 70 years after the death of the author. In software terms, that's a massively long time.
Now, I'm not a huge fan of copyright. I can't believe that 70 years from the end of the year of the death of the author is appropriate, but that's another presentation for another day. So those rights, the things that are reserved to the owner, anyone else who wants to do them needs some kind of permission. And that could either be where the law says you can do this, or you need to get a licence from the owner that says you can do it.
Now, any sensible situation you would try and get that licence in writing, and you would want it to be specific. I think that is the contract things. A licence and a contract aren't quite the same legally, but a lot of the tips will be absolutely the same for a licence. You may have heard about fair use, I can do that without a licence, it's fair use. Happy days, great, if you're in the USA. Still not brilliant.
The scope of fair use is certainly greyness around the edge of it. It fades as a defence. If I infringed your copyright but I have a defence that let's me do that. If you're outside the USA, I would be far less worried about fair use. So, about reading your contracts and not just signing, the same with your licences: read them carefully, try to identify problems before you're committed to using that code or that photograph, or whatever it might be.
If like me you're a fan of free and open source software be aware that not all free and open source licences are interoperable. You may need to work out what you're going to do with the code and then check that the licences will interoperate correctly and allow you to do what you want to do. Similarly, not all creative commons licences let you use the covered thing commercially or let you modify it. If you're looking to a creative commons with NC in the title, it is for non-commercial use only, and ND, no derivative works, you can't make modifications or changes to it.
Kevin has asked: any common issues with open source licences folks don't realise? Yes, that's a great topic for another presentation! But not one I will be able to cover now. There are a number of things you need to think about if you're using free and open source software, and, if I haven't bored you all to tears this year, maybe that's a topic for next year.
Avoid the common mistakes. They're easy to make. Lots of people make them, particularly with strong-minded people on the internet will often be in your mentions, in your replies, making these kinds of comments. Don't be that person. It's on the internet, so it's in the public domain. It might be in a colloquial sense but not in a legal sense. You can't just take stuff from the internet. Copyright still applies to content that people upload.
As long as I reference the source and cite it, I can do whatever I want with it. It doesn't work like that. Citing things can be a requirement for some of the permitted uses under law, but they're still pretty narrow. It is free or open source so I can use it however I want. No, there is a fair amount of litigation relating to breach of, or infringement of free and open source licences. Again, you probably don't want to be that person.
Hopefully, you could find a good way of solving an infringement, find a way of settling, but don't assume that because it's free and open source you can use it however you want without consequence.
Tip 10: this is the final one. Know when to bring in an expert. You are, I'm sure, great at what you're doing. You wouldn't be here on a Saturday or watching this recording afterwards if you didn't care about what you do. There are limits to what your knowledge and expertise are. You can't be a master of everything. It is easy to miss something, or misunderstand something.
Now, taking professional advice can lower your risk, and help you make more money. There are upsides to doing it, but it also costs money. Not all projects or all situations justify money and time spent on legal review. It is not easy to do when you're beginning, but try and work out is this one of the things that you really need legal review on? What would be risk if you didn't do it? And then consider talking to an expert.
Use the tips that I've given here. Be clear about what is needed and be year about the specification for that work. Is it going to be a fixed price? What is a fixed scope that you're going to get if you can avoid just paying someone by the hour - what an old-fashioned way of doing things. It is not always possible to avoid that. Sometimes things are vague and ambiguous that the only way your adviser can do it is say I can start but I can't tell you how long it's going to take me.
Realistically, they could probably give you a price for a fixed scope. Do your homework. There are loads of people out there asking about - sorry, there are loads of people out there offering advice on things. Find someone who can actually help solve the problem they've got. Ask them what did they learn from doing it before? You're spending your money, so spend it wisely. So I promised you five tips. I've given you ten.
You can download the slides from our website, or just scan this QR code on your phone, and the slides should either start to download automatically, or you will get prompted to do so. Not too many questions have come through at the moment, so, if you have them, now's the time. I think there are probably a couple more minutes before we run out.
My email address is on the last slide, and you're welcome to get in touch and email me about it. There we go. The slides have come back! There is our website again, and my email address. Just say this is where you heard of me from because, by all means, drop me an email. Talk with me on Twitter, or Mastodon. Question, can I go back to the QR code for the slides. There we go. I will leave it there.