The French government’s reported refusal to provide India with the source code for the Rafale’s Thales RBE2 AESA radar, the Modular Data Processing Unit (MDPU), and the SPECTRA electronic warfare suite should prove sobering to the GoI.
Under the circumstances, an emotionally charged debate is raging on social media around the question: should India still go ahead with the Rafale deal?
Ironically, some of the most vociferous participants in the debate don't understand what really is at stake because they don't clearly understand the role of software in a fighter aircraft.
In the following paragraphs, I will try to explain the value and role of software in a fighter aircraft.
Software by Value
Approximately 30–40% of the total cost of a modern fighter like the Rafale is typically attributed to software development/integration. What that means is—if the OEM doesn't supply the source code along with the fighter, you get only 60% of the aircraft despite paying for 100%.
As technology advances, it's likely that the percentage cost representing software will increase well past 50%.
However simplistic it may sound, a nation does get shortchanged when it buys a fighter, and in the future the shortchanging will be even greater.
Dependency on OEM
More importantly, when nations buy modern fighters, they have to keep reverting to the OEM to address any requirements for changes in the software with evolving tactics and weapon systems. In a manner of speaking, the money paid for software changes is money burnt because software alterations have zero tangible value. You pay for the tweak, but physically you return with what you had earlier.
The continued dependency on the OEM may prove crippling, for example, if the OEM does not allow software changes required to integrate third-party weapon systems. For example, if Dassault disallows integration of the Russian R-37M missiles on the Rafale.
No OEM Will Provide Full Source Code
Software in fighter aircraft is built in layers of abstraction. This hierarchical design (often called a "layered architecture") separates concerns, improves reliability, and allows independent certification and upgrades.
Lowest-level software layers
These provide hardware access abstraction and include device-driver layers. They directly interface with sensors (radar, INS, EO/IR), actuators (flight controls, weapons release), data buses (MIL-STD-1553, AFDX), storage devices, and processors. They translate raw sensor signals into usable data.
Medium layers
These include operating system services and common libraries that provide universal, reusable functionality not tied to any single mission. Examples include:
Data read/write services (file systems, database-like buffers, or ARINC 653 partitioning)
Mathematical function libraries (e.g., Kalman filters, coordinate transformations, floating-point math)
Other common services: timing, memory management, communication protocols, and real-time operating system (RTOS) primitives
In fighters, this layer often includes certified middleware that abstracts the underlying RTOS (e.g., VxWorks, INTEGRITY), so higher layers don’t need to know hardware details.
Highest layers
These are the application/mission-specific layers.
They implement operational logic unique to a task (e.g., sensor fusion, target tracking, weapons release sequencing, flight-control laws, electronic warfare response, or cockpit display management).
The highest layers can be thought of as the personality or the potential of the aircraft. The layers define the aircraft's maneuvering and combat capabilities. The layers serve as the interface between the pilot and the aircraft as a whole, including the weapons that it's armed with.
The entire source code of the Rafale will comprise millions of lines. IAF programmers would take years, perhaps decades, to acquaint themselves with the entire code. More importantly, it would serve little purpose because the low-level and medium-level layers are well proven and extensively tested.
Most likely, what the IAF seeks from Dassault is access to the sensor- and hardware-specific lowest layer to fit new sensors and weapon systems, and possibly the highest layers to tweak combat load and maneuvering parameters.
It's important to understand that providing access to a software layer is not the same as transferring the full source code of the layers.
Access to the underlying code can be provided through a layer of abstraction without transferring the code. Coding new functionality through a layer of abstraction entails using a programming interface. When working through such an interface, the user cannot know how the source code actually functions.
The Real Issue
A programming interface provides limited and safe abstract access to limited segments of the internal source code.
It's likely that Dassault is ready to provide an interface to integrate indigenously developed weapons that are currently operational or under development. However, over the years, the interface may not prove adequate for integrating the IAF’s future weapons and other operational requirements because weapon systems are fast evolving, both in terms of technology and concepts.
For example, in the future, the IAF may want to launch drones from the Rafale or launch weapons from an unmanned collaborative combat aircraft (CCA) operating with the Rafale. For such requirements, the IAF would require a more extensive programming interface to the underlying source code.
Accidental / Intentional Limitations
There is another problem with interface-only access to source code. The underlying code may have accidentally or deliberately planted limitations that the operating country is not aware of. These limitations, which could have been coded or escaped detection during testing, may not show up when the aircraft is operating in the OEM country.
In the early 1980s, the IAF acquired Durandal runway-penetration bombs for the Jaguar aircraft. The IAF acquired the Durandals based on their successful integration with French and Royal Air Force Jaguars.
Several years after acquiring the bomb, the IAF realised that its Jaguars could not release the bombs, which had been lying unused as strategic reserves for years, due to a software bug.
A software tweak fixed the issue, but it was fortunate that the issue was discovered during a planned demonstration of the lethality of the Durandal for the Raksha Mantri at the Pokharan range, not during an operation.
So, if and when a requirement emerges, the OEM must be willing to provide a more extensive interface than the one initially provided, at a nominal cost. The IAF must pay for the source code only once.
Conclusion
India should not buy the Rafale unless France commits to providing access to any part of the source code that the IAF needs to access.
The additional access should be provided at a very nominal, pre-negotiated cost. If the OEM declines to provide additional access, it must surrender the source code.
