If you canít understand it Ė donít sign it! Takeaways from the User's-Only X-change on negotiating software contracts. 02 October 2018


Licence contracts can be confusing by design. They are far from transparent, and there is little room for negotiation. Beltug has been touching on this issue for several years, including speaking with software suppliers and other stakeholders, creating the Proposal for a Software Publishers’ Code of Conduct (CoC) and, recently, transposing its principles into concrete contract clauses.


During this session, we had a look at the importance of a solid contract, for both parties. Next, we focussed on the contract clause models that have been built, and how you can use them. Finally, we zoomed in on software procurement in the public sector.  The presentations from the event are available, exclusively for Beltug members (after login).



Erik Valgaeren, Partner and Head TMT/IP practice at Stibbe was a co-author of the CoC, and also a contributor to our translation of the CoC into actual contract clauses. He started by explaining the 'freedom of contract' and 'no formalism' principles (have a look at slide 3 for more detail on these concepts).


Formalities are not required to create a contract, he emphasised. So make sure you are aware when you are agreeing to one: don't 'stumble' into an agreement. The reason for written contracts is to have solid evidence of what has been agreed, and to avoid disputes.  But you can certainly have a legal agreement between parties without a written contract.


Taking a look at software contracts, we see a patchwork of protection mechanisms (see slide 5).  Copyright, for example, applies to all software: all software that is developed is automatically protected by copyright. So a software developer doesn't need to specify this protection.


Next, Erik went over a few important points when it comes to agreeing on using/purchasing a software (see slide 10).


To conclude his exposé, he revealed few pitfalls:

  • The ambiguity of terms: definitions are complex and need correct interpretation, while licences come in various versions, so you need to be aware of the version you are looking at.  What is an authorised 'use' (execute, run, access, indirect access) and who are the authorised 'users'? (See slide 12).
  • "If there are more than 2 lines in a clause, you know it’s trouble!" he added.  The terminology in contracts is often “confusing by design”.  Pay attention as well to terms that are written in Anglo-Saxon law and then translated - make sure you have the correct interpretation and 'feel' for the term.
  • Evolution of technology: licensing models are often written for mainframe technology and are not suitable for new technologies.  (Have a look at slide 16 for possible solutions.)
  • ‘General terms and conditions’ (T&C): software vendors may try to 'tackle' clients with T&C versions they never accepted – i.e. newer versions of the T&Cs the clients accepted years, even decades, ago, during the original signing of the contract.


Second on the agenda was Piet Herman, seasoned expert in negotiating software agreements who also co-authored our Contract Clauses paper.  After a short context of how the original CoC came to life, he went over its guiding principles (see slide 7).  He emphasised that this CoC needs a maximum adoption to make sure it becomes 'common practice'.  The first step to facilitating that adoption and gain ambassadors was the translation of the CoC into real contractual clauses.


Next, Piet discussed different paragraphs of the contract clauses paper:

  • No Unilateral Amendments
  • Software Asset Management
  • Exit
  • Permitted Use
  • Metrics
  • Maintenance Services
  • Audit
  • Choice of Law

(Have a look at slides 12 to 26 for more detail.)


Piet's advice:

  • Use your own contract template (see slide 27 for the main reasons why).
  • Integrate the CoC Model Clauses into your template, or at least the clauses that matter to your context.
  • Make your contract draft/template part of your bid
  • Spread the word - use the contract clauses!


Kristof Debergh, General Counsel at Smals, finished off the event with his view on the public side of software procurement.  First Kristof touched upon the constraints he sees in public procurement of software:

  • Legislation is not at all constructed for IT, let alone licence procurement
  • You are essentially buying a contract
  • The Competition principle at the heart of legislation limits the scope of choices to be made before launching a procedure
  • Negotiating is not possible in principle for 'off the shelf products'
  • There is limited potential for flexibility during a contract term


Yet he also sees opportunities in public procurement:  part of your public contract is determined by legislation. Plus, the client may be able to enforce certain unilateral changes and certain legal powers.  And as a public authority, the organisation has the option to pool its needs with other public organisations.


To conclude, Kristof touched upon a few typical topics for public tenders:

  • Prior to the purchase, requiring a testing phase - without negotiating.
  • When assessing offers it is important to differentiate between essential and non-essential contract clauses, and to add an award criterium for 'overall bid quality'.
  • A framework contract can be established with the supplier - including an agreement on which contract clauses would be acceptable in the framework of other commercial agreements.
  • In special cases, it can be interesting to have a 'letter of intent' with a main provider, avoiding resellers coming up with non-agreements that aren't valid.

















Dear visitor,

Access to more information about this topic and/or to download the paper is easy and fast, but exclusively for Beltug members (just login to get access).

Beltug gathers a lot of information. Here you find the advantages of Beltug membership

The Beltug Team

Click here to login

>>> Back to overview