Last month, a discussion circulated on LinkedIn, sparked by an imaginary dialogue between a RUP — the person responsible for the procurement procedure in Italian public contracts, roughly equivalent to a project owner’s representative — and a lawyer, published in an article on BIM and public procurement. The dialogue talked about designers’ jealousy of their native files, copyright, technical dependency, and concluded with the recommendation that public contracts should mandate the delivery of native files with full rights of use and modification on the part of the contracting authority.
I read the whole thing with growing puzzlement — not because the issue is new, quite the opposite, it made me feel very old — but because in 2026 we are still here discussing it, and doing so with the same arguments that circulated when the problem was called DWG.
I’ve seen this film before
I don’t know if you’re old enough to remember, but years ago we were having the same debate over DWG files. The designer didn’t want to hand over the editable file, the client didn’t know how to require it, the brief didn’t cover it, and in the end everything was done via paper and PDF, starting the drawings from scratch every time the appointed professional changed. Those who aren’t old enough to have lived through it firsthand may have experienced the aftermath: unusable archives, enormous redrawing costs, cascading interpretation errors, DWGs scraped clumsily from PDFs via plugins of dubious origin, and a generation of public officials convinced that “the project” was the signed PDF.
Now the problem revolves a model in native format, and the narrative is extraordinarily similar: the supplier doesn’t want to hand it over, the authority doesn’t know how to require it, and instead of addressing the problem at its root — correctly defining what you want and what you are entitled to receive — a legal edifice is built around a fundamental misunderstanding.
The misunderstanding is this: that there is something valuable in the native file that the supplier has the right to protect.
There isn’t any know-how in your models
The most authoritative voices in this type of discussion tend to argue that the native model is rich in company know-how and that, if required, it must be adequately compensated. It’s not mere copyright, they say, because copyright is well-regulated and covers only so-called works of creative authorship. Here we’re dealing with something beyond the conception of the work, according to some.
I understand the position. But I disagree, and I have concrete reasons for saying so.
I have had tens of thousands of information models pass through my hands over these long years of practice. Perhaps hundreds of thousands. Produced by the best Italian and international firms. Complex models, well structured, sometimes exemplary in their organisation. And in none of them have I ever found anything that could be defined as a trade secret. No modelling technique that wasn’t already widely documented in industry forums, no parametric logic that a competent professional couldn’t build themselves, no stratospheric sweep capable of winning tenders. Because, however well modelled, however much time may have been spent on it, an armchair is always just an armchair.
In other words, producing a well-made information model is not a secret, thank goodness. It is competence. And competence is not transferred with the file: it is transferred through training, experience, practice. If you know your job, you can read, use or modify someone else’s model without difficulty. If you don’t, opening someone else’s native file is like opening a text in a language you don’t know: the words are there, but they tell you nothing. And all those bizarrely constrained reference planes are considerably worse than Aramaic.
Technical dependency
The most jarring point in the debate is the notion of technical dependency. The fictional lawyer, in the original article, cited it as an argument in favour of delivering native files: without them, the public authority would be dependent on the supplier and unable to manage the asset over time.
True issues to be addressed. But the proposed solution is precisely what creates the dependency.
A native Revit file works with Revit (maybe, and only if the versions and the stars are aligned). A native ARCHICAD file works with ARCHICAD. If the contracting authority receives a model in a proprietary format and wants to use, modify, or update it, it needs that specific software solution — and someone who knows how to use it — for the entire lifecycle of the asset. When, in two years, Autodesk changes its licensing policies again, or when the firm that produced the model no longer exists, or when someone wants to compare that model with one produced by a different supplier using different software, they will find themselves holding a digital asset that is unusable without reacquiring the same dependency.
The IFC data scheme exists precisely for this. A well-built IFC — and I’ll return to this shortly — should be readable and usable by dozens of different tools, both open-source and commercial. It creates no dependency on any supplier. It does not require the public authority to have the same software as the designer.
Saying that you can’t work with IFC is fine when we’re in my living room or at the pub, all professionals frustrated by the latest time our software made a mess trying to read a wall. I’ve said it myself, I’ve written it: IFC has the problem of having been born as a data schema for reading rather than editing, of being interoperable but not operable. All fair. And yet, like democracy, it may not be perfect but it is the best system we have. And we cannot ignore the progress made in recent years. Saying that nothing can be done with it is either ignorance of the current state of the tools, or bad faith. Perhaps it’s just frustration, because it really is less convenient than having a file in the same native format I use myself. Of course it’s more convenient to send me the .rvt file if you originally worked with Revit. And I’d be foolish not to ask the exploratory question every time I receive an IFC. But none of this is a basis on which to build a policy for managing public assets.
So what is the actual problem?
The problem is that IFC works when it is well-made, when we know what we are doing and have taken the time to adapt it to the purpose of the next phase. And an IFC dataset is well-structured only if someone — on the contracting authority’s side — knows what to ask for.
This is the real blind spot in the discussion. Not the file format. Not copyright. Not the designer’s supposed know-how.
The blind spot is that contracting authorities do not invest in the capacity to define their own information requirements. The Employer’s Information Requirements — the document in which the contracting authority specifies what it wants, how it wants it, at what level of definition, and for what purpose — is still an instrument almost always copied from templates that bear no relation to the authority’s actual needs.
That is where the intellectual work of the public administration and its procurement manager lies. Everything else — negotiating over native formats, debating copyright, constructing bespoke contractual clauses — is an elegant way of avoiding that work without doing it.
There is also another consideration, more prosaic but no less real: the money to negotiate the supposed added value of native formats, in the context of public procurement, simply does not exist. Budgets are what they are, at least in Italy. The idea that a contracting authority could — or should — pay a premium to receive variably usable proprietary files is a fantasy that survives only as long as no one looks at an actual project budget.
On copyright, briefly
I have never believed that BIM models constitute a work of creative authorship in the technical legal sense, and my Country’s law gives me some grounds for saying so.
The Italian Law of 22 April 1941, n. 633 — our copyright law, still the primary reference on the subject — protects works of creative authorship belonging to literature, music, the visual arts, architecture, theatre and cinema. Architecture, note: not the representation of architecture. For a work to enjoy this protection, case law requires that there be an aesthetic value that frees the form from technical and functional constraints: a work designed purely for structural reasons might not be protected, whereas one that includes distinctive stylistic choices would be.
For engineering works, the situation is even more restrictive. Article 99 of the same law grants the author of engineering projects, or similar works that constitute original solutions to technical problems, the exclusive right to reproduce the plans and drawings of those projects, as well as the right to equitable compensation from those who execute the technical project for profit without the author’s consent. Original solutions to technical problems: that is the standard. Not “well-organised file”, not “carefully crafted parametric families”, not “reference planes with sensible names”. So the question is: does your model represent an original solution to a technical problem, or is it simply the expression of well-established industry practice?
There’s also a precedent — Genova, 1987 — reinforcing that engineering projects, lacking in themselves the quality of creative authorship, do not enjoy the same protection as architectural works endowed with creativity and originality, and that the client of an engineering project may introduce variations to it without the author’s consent. The categorisation of engineering work as inherently “non-creative” — and the somewhat uncomfortable association of architecture with literature and music — is a problem for another occasion.
Back to our model.
A model is a working tool. It represents an asset — a building, an infrastructure, a system — but it isn’t the asset itself, nor its architectural or engineering conception. It is the digital representation of design decisions that find their legal protection elsewhere, if and when they find it at all. Case law has recognised that there is a conceptual difference between the project as a document and the work as a built object: the project is a work in its own right, materialised in drawings, reports and graphic outputs; the built work is the physical manifestation of that project. The model is not even the project: it is one of the instruments through which the project is developed and documented.
This does not mean that the modeller’s work has no value, far from it. It does, and it is right that it should be remunerated. But the value lies in the service rendered, not in the file produced. When I deliver a model to a client, I am delivering the documentation of work that was commissioned and paid for. Withholding that documentation — or delivering it in an unusable form, as is the established practice of certain Italian design firms — is like a doctor refusing to hand over a patient’s medical records because they contain their professional notes. You are being paid, dear.
The money isn’t there
I touched on this a moment ago, and it is worth going into more depth. It is the elephant in the room of any public procurement process: money.
The “company know-how” argument, in its more sophisticated version, generally concludes with a proposal that sounds reasonable: if the client wants the native file, they should pay for it. It is a position that may even have its own logic in the private market, maybe. In the public sector, at least in Italy, that logic collides head-on with the reality of project budgets.
Italian contracting authorities operate with defined budgets, often insufficient, always under pressure. There is no line item for “modelling know-how compensation.” There is no room to renegotiate the contract around the delivery format. There is no official who can authorise an extra payment to receive a .rvt file instead of an .ifc, even if they wanted to, even if they understood the difference, which in most cases is not guaranteed.
Proposing that the market self-regulates through price, in a context where price is set by a race to the bottom and the brief is copied from a 2016 template, is optimism on the cheap. The solution cannot be economic, because the economy isn’t there. It must be normative, technical, and above all cultural.
What isn’t needed
If there is one thing that is not needed in this debate, it is a native file for facility management and maintenance. Not because having one is wrong — I have nothing against collecting crap — but because it is simply not the tool with which asset management is done.
Facility management platforms — IWMS, CMMS, operational digital twins — work with structured data. They need to know that a given system is located in a given room, that it has a given maintenance deadline, that it is connected to a given installation; they need attributes, relationships, unique identifiers. They do not need to know how the handrail sweep was built, nor to load a three-gigabyte file every time a technician opens a work order.
Nobody in their right mind does asset management with Revit. Nobody opens ARCHICAD to check whether a valve has been serviced. The native model is the tool of those who design and build (and even for the latter, there is often something better). Once that phase is over, what remains useful is information: extracted, structured, connected to a management system, along with a rough idea of certain critical geometries. That information, if the model was well-built, lives through IFC far better than in a proprietary file that requires a licence costing thousands of euros just to open.
Asking for the native file “for the future” is not an asset management policy. It is a policy of accumulating files that nobody will use, in formats that nobody will be able to read, on servers that nobody will update. In ten years, someone will find them in a folder called “ARCHIVE_FINAL_3_definitive_use_this_one” and will have no idea what to do with them.
What is actually needed
First of all, let us get over the library trauma. We have spent tens of people, hundreds of person-hours on production, sleepless nights on coordination and review — I know, I was one of those people — but it was a necessary cost to reach the point where we could benefit from the method and its associated technologies. It has been done, and if I’d had someone to help me it would have taken far less time. Every time we don’t share something, we are making someone else start from scratch. Out of spite. Because we’re still offended at having had to model that sofa, and now everyone else must suffer too.
Second: stop talking about native files as a solution, and start pushing for IFC as a requirement — not as a fallback, not as a second-best alternative — as the reference standard for the delivery of information models in public contracts.
To do that, contracting authorities need to learn to write serious Employer’s Information Requirements that are aligned with the standard (because if all your property sets are custom, you may well be back at square one). Procurement managers need to be trained not only in the regulations, but in the technical substance of what they are actually asking for. The market — professionals, contractors, software vendors — needs to stop using the opacity of proprietary formats as a shield against accountability for quality.
And frankly, we need a little less drama around designers’ jealousy and a little more honesty about the fact that the problem has never been the file. The problem is that nobody wants to do the work of properly defining what they want, and the native format — like DWG before it — has become a convenient way of not doing it.
BIM only works when functional models are shared, and this means that IFC needs to do better of course: we need to find ways to preserve the parametric behaviour of objects. But, with the current state of things, even if we find a way to preserve the parametricism of stuff through IFC, people will whine that they aren’t paid enough for their marvellous engineering of how the width of a window is the width of a window. We also need to acknowledge that BIM doesn’t work when every actor in the supply chain builds a fortress around their own data and calls that practice “protecting know-how.” The know-how is not in the file. It’s in the people. And people, fortunately, are not delivered with the contract.
No Comments