Most commercial lawyers agree that anything created, done or owned jointly is more likely to cause more headaches than the equivalent done by one person or company on its own behalf or on behalf of a customer. Here are four brief examples of troublesome joint-ness:

Although it’s possible to create jointly-owned intellectual property rights, lawyers generally discourage it because joint ownership demands detailed rules to ensure that the co-owners are free to do what they want with whatever has been created.

The weakest link of a services-based relationship is usually a list of joint responsibilities because, where any particular obligation is not done, there’s likely to be no effective remedy for the paying customer.

Most lawyers feel uncomfortable at agile-based software development programmes because the inherent joint-ness of an agile methodology, and agreement to a process not price-plus-requirements, undermines the chance of a legal remedy.

Few legal concepts contain more traps than the deceptively simple idea of a joint venture. Joint ventures are successful in direct proportion to the degree of clarity as to who does what.

So the usual result of two entities deciding to do something jointly is that the lawyers spend lots of time behind the scenes agreeing exactly what “joint” means in terms of who does what.

There may be perfectly sensible reasons for agreeing to joint-ness. The parties may have concluded that an agile approach to a software development problem is more likely to succeed and so is worth the lack of clarity on responsibility and remedy.

And there are at least some areas of commercial contracts where I admit that it makes sense to work towards joint-ness. For example, most of the governance obligations in any services-based relationship work much better if balanced and based around the concept of joint participation and joint involvement. This extends even further into areas such as innovation in services delivery which only really works at all as a concept if based upon the idea of joint participation in the development, funding and implementation of specific instances of innovation.

The key is to recognise when joint-ness makes sense and not simply to default back to the basic setting of accepting joint?ness simply because it’s too difficult to agree in advance who is supposed to do what. If it’s too difficult to do in advance, it’s going to be even harder to sort out in retrospect when something has gone wrong and the parties are looking to blame each other.

European cloud industry doesn't need regulation