Setting the scene

Does this sound like you?

You need to have a custom theme or plugin developed. Or you need help modifying an existing theme or plugin. You need someone to build a WordPress platform of some sort. Or you otherwise need help doing X, Y or Z with your WordPress site or business that, like the other tasks just mentioned, will involve the creation of new software code. You need the work done yesterday, you’re happy to pay a reasonable amount for it and you just want to get on with it. I’ve been in this kind of situation a few times and I’m sure there are thousands out there that either have been too or are in it right now.

Rather than going to a known developer (you might not know any), you might turn to one of the WordPress-specific job shops such as codeable or WerkPress or similar services for which WordPress is clearly an important category, such as Elto (formerly Tweaky) or Envato Studio. In your hurry, you may tick the “agree to terms” checkbox without fully digesting the myriad terms they contain. But did you pause to reflect on the intellectual property provisions in the terms? Did you consider what sorts of rights you’ll need for the use case you have in mind and did you check that you’ll obtain those rights? You might, for example, be having a theme or plugin developed that you propose to distribute and sell. Will you obtain all the rights you need to do so?

I ask these questions because I’ve noticed some significant differences in the intellectual property terms of the kinds of services I’ve mentioned above. I’m going to discuss each of them but, first, let’s sketch out some key points relating to copyright and WordPress development.

Copyright and WordPress development

Key points relating to copyright and WordPress development are as follows:

Software code qualifies for copyright: In a large number of countries, sufficiently original software code qualifies for and is protected by copyright. That is the case in, for example, the United States, Canada, the United Kingdom, Australia, New Zealand and many, many other countries that have signed up to international treaties such as the Berne Convention for the Protection of Literary and Artistic Works, the TRIPS Agreement and/or the European Union’s Computer Programs Directive.

Copyright owner’s exclusive rights: Usually this means the copyright owner has the exclusive right to do a number of things, such as copy the code, adapt the code, distribute the code, sell the code and so forth. If someone else does one of these things without permission, s/he will infringe the owner’s copyright and the owner will then have a range of remedies against the infringer.

Developers create new copyright works: When a developer develops a WordPress theme, plugin or other WordPress code for you, chances are that s/he will be creating a new copyright work. The developer could be writing everything from scratch or s/he could be utilising and adapting some pre-existing code, such as a starter theme, an existing plugin or other code. It could be the developer’s own code or it could be third party code or a mixture of the two.

Clients need to know about use of pre-existing code: If you’re the client, and particularly if you’re interested in selling or otherwise distributing the end product being developed for you, I suggest you need to know whether the developer is writing everything from scratch or not and, if not, what existing code s/he is using and the licences (if any) that have been applied to that code by the relevant copyright owners.

Not all pre-existing code is licensed under the GPL: If pre-existing code is being used, you or the developer may fall into the trap of thinking that it’s all derivative of WordPress and therefore, given that WordPress is licensed under  the GPL, that the pre-existing code is likewise licensed under the GPL. That is not necessarily the case. Not only do certain elements of code, such as CSS and javascript, not necessarily need to be licensed under the GPL (depends on the context), but the owners of the pre-existing code may not have licensed their code under the GPL even in cases where one might say they should have.

Derivative works of GPL’d code need to be GPL licensed when distributed: Where pre-existing code that is being used is licensed under the GPL, if the theme, plugin or code that is being developed for you is derivative of that code, i.e., a new derivative work is created, then if you distribute (e.g., sell) your new theme, plugin or whatever it is, you’ll need to release at least certain elements of it under the GPL too (except for any elements to which the GPL’s downstream licensing requirement does not apply, e.g., new CSS or images that are not derivative of the GPL’d code).

But you need the relevant rights to do that: You can only do that, however, if you own the copyright in any new copyright components of the derivative work or if the developer has already licensed those components under the GPL or has agreed to allow you to do so.

Ownership rules and contract: As to the ownership issue just mentioned, most countries have default statutory rules as to who will own the copyright in a new literary work, such as software, or new copyright elements in a derivative work, that is being commissioned from an independent contractor. However, in many cases, the safest approach is to agree the ownership position contractually. This can be important where client and contractor are from different countries and you’re not sure how the applicable law will apply to your situation.

Contractual content: A good contract will deal with the copyright and licensing position in relation to both any pre-existing intellectual property that is being used for the development and any new intellectual property.

Caution where developer using pre-existing non-GPL’d code: Where pre-existing copyright code that is being used is not licensed under the GPL, you may need to proceed with caution. Ideally you’ll want to know whether the developer has the right to incorporate or adapt that pre-existing code and (because it incorporates or adapts that code) whether you will be entitled to use, copy and distribute the end product you’re commissioning from the developer to the extent you wish. If the answer to either question is no or if you can’t find out, you may, depending on your circumstances, wish to either not proceed or require the developer to use an appropriately open source licensed alternative to the problematic code or rewrite the relevant code (without copying…).

Themes, plugins etc written from ‘scratch’: Let’s turn now to the scenario where the developer has written a theme, plugin or other code without reliance on third party code (GPL’d or otherwise). If you own the copyright in the end product (whether by contract or under applicable copyright law) and want to distribute it, you need to decide how to license it. (If you keep it to yourself or your organisation, you don’t need to license it.) As discussed in previous posts, the prevailing view in the WordPress community is that at least some portions of themes and plugins are likely to be derivative of WordPress and, therefore, that under the GPL you too must license at least the GPL-derived components under the GPL.

Phew! With that context in mind, let’s now take a look at the relevant terms of use or service for codeable, WerkPress, Elto.

codeable

What the codeable terms do say

Under the codeable terms, a standard Service Contract comes into being between the user (client) that requests work to be done and the developer (contractor) that agrees to undertake the work. In other words, your Service Contract is not with codeable. It’s with the developer you select. The standard terms are set out in a section of the codeable terms headed “Terms Between Client and Contractor – Service Contract”. The important intellectual property terms in this Service Contract are those headed “Work Product”, “To ensure that the Client will be able to acquire, perfect and use such Proprietary Rights, Contractor will:” (yes, that’s displayed as a heading…) and “Pre-existing Intellectual Property in Work Product”. Key aspects of these terms can be summarised as follows:

• Copyright works developed by a contractor in connection with a fixed-price contract are owned by the contractor until such time as full payment has been made by the client. If under applicable law proprietary rights cannot be assigned, the contractor grants a broad exclusive licence to the client to use and commercialise the work product.
• To ensure the client will be able to acquire, perfect and use such proprietary rights, the contractor will transfer ownership, possession and title to various things containing the work product to the client and sign any documents that the client requires in order for the client to perfect and enforce its rights. The contractor will also waive and agree not to enforce other rights it may have in the work product, such as what in many countries are called moral rights (although “moral rights” as such are not referred to by name).
• The contractor will ensure that no work product includes any pre-existing software, technology or other intellectual property, whether owned by the contractor or a third party (this expressly includes “code written by proprietary software companies or developers in the open source community”) without the prior written consent of the client.
• The contractor will not be entitled to payment for services performed if the work product contains any such pre-existing intellectual property that was not approved by the client.

Under many countries’ laws (certainly the countries’ laws that I’m familiar with), these terms should be effective to transfer ownership of new intellectual property in the work product to the client on full payment or at least to require the contractor to transfer ownership (if you need confirmation of that in your own jurisdiction, you may wish to seek advice from a local lawyer).

Note, however, that I refer here to “new intellectual property”. In the WordPress context, it’s not unusual for clients to request, for example, enhancements to existing themes or plugins and in some instances the work product will be an adaptation or derivative work of an existing theme, plugin or other code. That makes the codeable terms’ treatment of pre-existing intellectual property particularly important.

What the codeable terms don’t say

From the perspective of the countries’ laws with which I am familiar, the relationship between the new intellectual property rights in a work product and pre-existing intellectual property rights that are incorporated in a work product could have been more clearly or comprehensively expressed in the codeable terms. I say this because:

• the contractor is not in a position to “transfer ownership” of pre-existing intellectual property rights that it does not own; and
• the ownership and licensing status of pre-existing code that it does own and incorporates into a work product is not, in the terms, entirely clear.

To put this another way, the terms require the contractor to assign or transfer ownership to the client or, if this isn’t possible, grant the client a broad exclusive licence. That may not be possible if the contractor is using certain third party code and the position in relation to its own pre-existing code is not clear. The terms do, of course, go on to say that pre-existing code cannot be used without the client’s consent. From this one might say a commercially sensible reading of the “contractor will transfer or exclusively licence” clause is that, where pre-existing code is used with the client’s consent the clause will be qualified by the existence and potential restrictions of the pre-existing code.

Important practical point

But – and here’s the important point – before granting consent the client needs to understand the potential implications of doing so. There are no default provisions in the terms that expressly cover this scenario (i.e., provisions that would apply and define the rights position in respect of pre-existing code unless the parties agree otherwise), in the case of either the contractor’s pre-existing code or pre-existing third party code. The practical consequence is that how the client and developer approach the consent process may be particularly important to whether the client will obtain the rights it needs. The situation where this is likely to be acutely important is where the client wishes to distribute and on-sell the end product. It is in this situation that the copyright-related risks are greatest as the code may become accessible by at least anyone who wishes to pay the applicable fees (e.g., the cost of a theme or plugin) and an owner of third party code used in the product (or someone else in the WordPress community) may recognise striking similarities.

A suggested approach

For these reasons, I suggest that:

• before a developer requests consent from a client to use pre-existing code in what is to be developed for the client, s/he assesses (1) what pre-existing code may be used, (2) whether it is his/her own code and/or third party code, (3) if his/her own code will be used, whether s/he will transfer ownership of it to the client or license it to the client and, if the latter, on what terms, and (4) if third party code is being used, the licensing position in relation to that code, in terms of the rights the developer will have to use and adapt the code and the rights the client will have to use the code as incorporated in the work product;
• the developer informs the client of the position on these issues (or the relevant subset of them) in writing when requesting consent to use pre-existing code for the development; and
• the client makes sure, before granting consent, that s/he (1) obtains such information from the developer, (2) considers whether s/he will obtain sufficient rights to do what s/he wants to do with the developed theme / plugin / code, particularly where s/he has subsequent distribution (e.g., sale) in mind;  and (3) assesses what licensing obligations s/he may have if s/he wishes to distribute the developed theme / plugin / code (e.g., where it is a derivative work of GPL’d code).

I’ll call these considerations the Pre-Agreement Checklist.

The existence, nature and any current licensing of pre-existing code should be documented and, in the case of the developer’s own pre-existing code (if any), the client and contractor should agree in writing on the rights the client will obtain, whether in the form of ownership of the intellectual property or a license that is sufficiently broad to enable the client to do what it wishes to do with the end product. (The client may also wish to state that no other pre-existing code may be used during the course of the project unless the same kind of process is followed.)

One other point to note is that, in software development and similar technology contracts, clients often seek to include:

• an intellectual property warranty by which the contractor promises that s/he has the rights to use any pre-existing intellectual property that s/he uses for the development and that the client will receive a licence enabling the client to exploit that intellectual property (as incorporated in the developed product / code); and
• an indemnity clause under which the contractor would be obliged to cover any losses the client may incur if the above warranty is breached or proves to be incorrect.

There are no such provisions in favour of the client in the standard Service Contract terms. In this respect one may think the terms are more pro-developer than pro-client. In a sense they are. At the same time, because we’re dealing here with WordPress, developers will often be dealing with open source code whose origins they may not be able to trace or in respect of which they’re not really able to grant the warranty and indemnity mentioned above, at least not without limiting them “to the best of the developer’s knowledge” (or something along those lines). Then there’s the point that services obtained through codeable are often competitively (if not very competitively) priced. In these circumstances some developers may be unwilling to accept the risks that even qualified warranty and indemnity clauses create for them. I should stress that the absence of these terms does not mean the client cannot proceed but it does mean the client may bear a measure of risk it may not be able to control. The magnitude of risk, in turn, may depend on whether the client wishes to distribute the developed product / code.

At the end of the day, the important point is that the client be careful, when considering a developer’s request for consent for the developer to use pre-existing code, to ensure that the right questions are asked and that the client will obtain the rights it needs for the use case(s) it has in mind. A client can only make sound decisions in this space when s/he has the right information.

WerkPress

WerkPress operates in a different way to codeable, in that the services contract created by its client terms is a contract between the client and WerkPress itself, not between the client and a separate contractor.

The key aspects of the intellectual property terms (clauses 6 and 7) can be summarised as follows:

• Once the client pays all fees owing, and except as stated in any ‘Exhibit A’ that will be completed when the parties agree to a development project, the Services will constitute a ‘work for hire’ and the client will own the intellectual property in the Services (i.e., deliverables).
• To the extent that the Services do not qualify as works for hire, WerkPress assigns the intellectual property in the Services (deliverables) to the client and will execute any documents required to confirm such assignment.
• However, existing code, “other background technologies, “any new functionality created by WerkPress in providing the Services … (except Client-owned data or intellectual property) and any other proprietary information of WerkPress”, among other things, shall be and remain the property of WerkPress.

The reference to Exhibit A is important. I suggest that WerkPress and the client should work through the same kind of Pre-Agreement Checklist outlined above in the discussion of codeable and that the outcome of the assessment be recorded in Exhibit A.

Just as with the discussion of codeable, the existence, nature and any current licensing of pre-existing code should be documented in Exhibit A and, in the case of WerkPress’ own pre-existing code (if any), the client and WerkPress should agree in writing on the rights the client will obtain, whether in the form of ownership of the intellectual property or a licence that is sufficiently broad to enable the client to do what it wishes to do with the end product. It is advisable for this to be done before any contract is signed or otherwise entered into. (The client may also wish to state that no other pre-existing code may be used during the course of the project unless the same kind of process is followed.)

The WerkPress terms do not contain any intellectual property warranty or indemnity provisions in favour of the client.

Elto

The Elto terms and conditions do not clearly address the issue of ownership of new intellectual property in code deliverables or the copyright and licensing status of pre-existing intellectual property that may be used in the deliverables (clauses 6 and 16 do deal with certain intellectual property issues but their application to the likes of a custom web design for a client is not clear). This leaves the resolution of such issues to either debatable application of the terms or the applicable intellectual property laws. That, in turn, makes matters unclear for users requesting certain kinds of deliverables.

For many of the kinds of work that Elto expressly offers, this may not pose any problem for clients, as many kinds of work (such as website transfer, custom domain name setup, advice on growing an email list and the like) are unlikely to involve the creation of any intellectual property, either at all or which the client would want to exploit. In that event, the issues I’m discussing don’t arise.

It is not clear, however, that that is necessarily the case for all the kinds of services on offer, such as ‘custom website design’. To the extent that any of the kinds of services available through Elto may result in the creation of new copyright code or entail the use of pre-existing code, in my view it would be preferable for the terms to deal with such matters expressly. That could take the form of a prescribed process that replicates the one I’ve suggested for codeable and WerkPress that results in the right questions being asked and the right things being documented.

In the absence of such a process in the terms, the client is left to think about these things and ask relevant questions of Elto or the developer before agreeing to proceed. Whether any client does that will depend on the work being requested, whether the client thinks to do so and the potential risk if the rights position is not addressed as it should be.

The Elto terms do not contain any intellectual property warranty or indemnity provisions in favour of the client.

Envato Studio

Excellent drafting

When I first wrote this post, I had focused only on codeable, WerkPress and Elto. I had nearly completed it, and was reflecting on the challenges that some of terms I’d already discussed create, when I realised I’d overlooked Envato Studio (formerly Microlancer). Big mistake. Why? Not only because WordPress is a distinct category of jobs within Envato Studio but, more importantly for present purposes, because the Envato Studio User Terms, Service Provider Additional Terms, and Services Agreement are all extremely well drafted.

Now, it’s unusual I know, and perhaps somewhat nerdy, to wax lyrical about the drafting of terms of use but, just as coders do (I’m sure) respect beautifully written code (“Code is Poetry”, after all), so too do lawyers respect other lawyers’ well written legal code.

The Envato Studio terms are beautifully written and presented. They use welcoming and approachable language, they are well structured and, in relation to the intellectual property issues I’ve been discussing in this post, they cover all bases. And they cover them well. They even include brief, punchy notes to emphasise certain points, in the right-hand sidebar. Take a look:

The other tasteful thing they do to emphasise important liability-related terms is place them in yellow note-style boxes. This is far preferable, in my view, to the typical U.S. approach of putting them in all caps and/or all bold. It shows how lawyers and designers can work together to produce an outcome that respects legal practices whilst being aesthetically pleasing.

Lawyers seldom receive congratulatory messages for the content and style of their drafting but – in my view – whoever drafted these ones is worth every cent Envato is paying them. I suggest the terms are well worth a look by businesses thinking about how to draft and present their terms of use to customers.

A run-down of the key terms

Anyway, moving on, let me explain how the terms work in relation to the intellectual property issues I’ve been discussing in this post:

• When you click on the “Terms & Conditions” link, you’re presented with the User Terms. These terms apply to all users of the site, regardless of whether you’re a member. They are between each user and Envato. Clause 4 explains and links to additional terms that apply to service providers and clause 6 explains that a service provider agrees to provide services by entering into a separate agreement directly with the buyer called the ‘services agreement’. Clause 6 links to that services agreement. (In this regard, Envato’s contractual approach is similar to codeable’s approach.)

• Clauses 21-26 of the User Terms address intellectual property: clauses 21-22 deal with Envato’s intellectual property and clauses 23-26 deal with users’ intellectual property. They require you to “promise that you own, or have the appropriate rights to use, everything that you submit on or via the site” and that “the use of your content on or via our site won’t infringe anyone else’s rights and that no further permissions from others are required regarding your content” (clause 23). They confer an appropriate publication licence on Envato (clause 24) and clause 25 explains that:

“Service providers will retain rights in their pre-existing materials provided to buyers, but grant buyers a broad license to these materials. Service providers will assign to buyers all materials created specifically under the agreed brief. This is set out in the services agreement.”

I turn now to the Service Provider Additional Terms that apply to service providers (terms which are between Envato and service providers). Clauses 19-21 deal with intellectual property. Clauses 19-20 are well worth quoting in full:

“19. Under the services agreement, you agree to give the buyer a license for any pre‑existing materials you give to them as part of services. You must specifically identify any pre-existing material, so that the buyer is aware what they will not have exclusive rights in. You also agree to assign materials which you have created specifically for the buyer as part of services. This means you must ensure that you have the rights necessary to license or assign these materials to the buyer, so that the buyer receives ongoing rights to use the materials provided free of limitations other than any set out in any of the Envato Studio terms.

20. You must ensure that you also have appropriate rights to use the content and tools you use to provide the services. You will not include any content not created by yourself (such as creative commons, open source or other content) unless the buyer specifically agrees to this and you give the buyer a copy of the relevant use or license terms for those materials. If the brief involves you finding additional assets owned by others (e.g. stock photos), you must make clear to the buyer that these are to be licensed directly by the buyer at their cost, and you must give the buyer instructions on how to do so.”

These clauses, which confer enforceable rights on Envato, are spot on. They address, in clear terms, the distinction between pre-existing materials (e.g., pre-existing code) and new materials (e.g., new code), they require service providers to identify pre-existing material, they require transfer of ownership to the buyer of new materials created specifically for the buyer and they put a process in place regarding the need for buyer consent to the use of third party content such as third party GPL’d or other third party licensed code with an obligation to provide the relevant licensing terms to the buyer.

Now let’s take a look at how the Services Agreement deals with these issues, bearing in mind that it is the Services Agreement that contains the terms that apply as between the service provider and the buyer.

• Clauses 4 and 5 address the job on which the buyer and service provider are agreeing. Clause 5 states that:

“We promise to each other that we each own, or have the appropriate rights to use, everything that we submit on or via the site to each other. This includes everything that we send to, or make available to, each other including all files, assets, communications and materials (‘content’).”

• Clauses 13-19 deal with the service provider’s intellectual property. Among other things, the service provider promises that it either owns the content used for the job and materials to be delivered to the buyer or has the appropriate rights and licenses to use or provide the content or materials. In the case of the service provider’s pre-existing materials used for the job, the service provider grants the buyer a “worldwide, non-exclusive and perpetual license to use those materials.” The service provider agrees to “specifically identify any pre-existing materials” and agrees that the license “includes the right to publish, distribute, communicate, broadcast, edit, modify, and create derivative works from those materials”. As regards materials created specifically for the job, the service provider “assign[s] all worldwide intellectual property rights (such as copyright) in those materials” to the buyer. Clause 16 states:

“16. If any of the materials I propose to deliver to you are not covered by clauses 14 or 15 (for example they are creative commons, open source or owned by others), I will not deliver such materials unless you have specifically agreed to my including them, and I must also provide you a copy of the relevant use or license terms for those materials.”

• Clause 19 also deals appropriately with the treatment of moral rights. Moral rights are usually statutory rights that are personal to the author of a work, such as the right to be identified as the creator or author. Among other things, under clause 19 the service provider agrees that “you do not need to attribute me as the creator of the assigned materials”.

One might also note that the Envato Studio terms are significantly different to (more client-friendly than) certain other terms on the issue of intellectual property warranties and indemnities in favour of the client / buyer. Clause 5 of the Services Agreement contains a mutual warranty (promise) between buyer and service provider that they “each own, or have the appropriate rights to use, everything that [they] submit on or via the site to each other”. Under clause 13 the service provider promises that it owns the content it uses to do the job and the materials it will deliver to the buyer or have all the appropriate rights and licenses to use or provide the content or materials. And under clause 24 the service provider agrees to indemnify the buyer “for any and all claims, liabilities, costs, expenses (including legal fees) and loss arising as a direct result of” the service provider breaching:

• the user terms;
• an applicable industry code, regulation and law;
• intellectual property belonging to others; or
• the services agreement.

I’ve outlined the relevant Envato terms in a bit of detail because, of all the terms I’ve reviewed, they are (in my opinion at least) clearly the best. They provide the most comfort to buyers (if the clauses are applied correctly usually buyers should obtain, or be armed with the information they need to determine whether they will obtain, the rights they need) and developers are required to consider issues of pre-existing material (their own and others) used for the job, to inform buyers where such materials are used and to obtain consent for the use of third party materials.

Issues to bear in mind

If we now focus specifically on WordPress-related jobs, what issues do developers and clients (service providers and buyers) still need to bear in mind?

As noted above, developers need to identify any of their own pre-existing materials (e.g., code) used for the job and to specifically identify them for clients. Where pre-existing material is not their own, they must seek client consent before using it for the job and they must provide all relevant licence terms to the client. The purpose of the latter requirement is to enable the client to assess whether the third party licensing terms will give it the rights it needs. Only then is s/he able to determine whether s/he is happy for the third party code to be used.

Clients need to assess the implications of the developer’s use of pre-existing materials (if any). The buyer will usually obtain the rights it needs in relation to the developer’s pre-existing material (given the broad licence that the developer grants to the buyer in relation to that pre-existing material). As for third party pre-existing code, whether the client will obtain the rights it needs depends upon the terms under which the third party pre-existing code is licensed. As noted above in the discussion of other services, this may be particularly important where the buyer has subsequent distribution (e.g., sale) in mind. And, because we’re dealing here with WordPress (which is released under the GPL), the client needs to assess what licensing obligations s/he may have if s/he wishes to distribute the developed theme / plugin / code (e.g., where it is a derivative work of GPL’d code).

Room for improvement?

Before I leave the Envato Studio terms, I thought it might help to ask whether there are any respects in which the intellectual property terms might be improved or reconsidered. Two come to mind:

First, the licence in clause 14 that the service provider grants over its own pre-existing materials used in a job is worded as follows:

“Where the materials I deliver to you are my pre-existing materials (such as designs or templates) I give you a worldwide, non-exclusive and perpetual license to use those materials. I will specifically identify any pre-existing materials. This license includes the right to publish, distribute, communicate, broadcast, edit, modify, and create derivative works from those materials.”

It is not 100% clear whether this licence includes the right to sell. Reading all the relevant terms as a whole, one might argue (among other things) that the right to “distribute” includes the right to sell but it may be more helpful to buyers if this were made explicit in the clause 14 licence. The kind of use case I have in mind here is where a service provider develops a WordPress theme or plugin that contains or is based on pre-existing copyright code of the service provider which, for whatever reason (and in some cases there may be legitimate reason), is not all licensed under the GPL. If the client wishes to sell the developed product, s/he may wish to be 100% confident that the developer will not be able to argue that s/he is not permitted to do so in relation to the portions of the product which are the developer’s pre-existing and non-GPL’d copyright code.

Second, I note that the intellectual property warranty and indemnity terms in favour of the client / buyer (clauses 13 and 24 of the Services Agreement) are absolute, that is, they are not qualified in cases where third party pre-existing material that is used for a job is available under an open source software licence or, for example, a Creative Commons licence. This potentially casts a significant risk on developers where they believe the pre-existing code or other content has been appropriately openly licensed but it turns out the licensor of the code or content did not have all the rights to license it. A potential solution here is to qualify the warranty and indemnity terms so that, in the case of third party openly licensed code or other content, the developer will only be liable under the warranty and indemnity provisions where it knew or ought to have known that the relevant pre-existing code or content was or may not have been licensed with the authority of the true owner (or something to that kind of effect).

Wrapping it all up

As I’ve sought to show in the “Copyright and WordPress development” section of this post, a range of issues need to be considered when clients and developers are agreeing to the development of themes, plugins or other code for WordPress-related solutions. When online services like codeable, WerkPress, Elto and Envato Studio are used for development jobs, the agreements are prescribed – to greater or lesser degrees – by the service providers’ standard terms.

The different service providers terms’ approach matters in different ways, both structurally and in terms of the clarity they provide for both clients and developers alike. The first three service providers’ terms require clients and developers to be aware of certain issues regarding pre-existing versus new intellectual property that are not covered clearly in the terms and, armed with that awareness, to ask the right questions before proceeding with a development that relies on the use of pre-existing code (at least where they may wish to exploit the output commercially). The Envato Studio terms go considerably further by requiring developers to think about the right things and to provide clients with the information they need to make sound decisions in relation to the use of pre-existing material in the end products being developed for them.

Given the complexities of software development and the issues that arise when using GPL’d and other pre-existing code, both developers and clients still need to be aware of issues relevant to their own circumstances and use cases that may not be fully covered in any standardised terms, but hopefully this post has gone some way to helping them understand what those issues may be.

(Featured image: Bloomua / Bigstock.com)