IP Rights and Open Source – Simone Giordano

Probably you noticed that in the last source files of Microsoft Business Central, the Open Source MIT license appeared:

// ------------------------------------------------------------------------------------------------
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License. See License.txt in the project root for license information.
// ------------------------------------------------------------------------------------------------
namespace Microsoft.Sales.Posting;

using Microsoft.Foundation.BatchProcessing;
using Microsoft.Intercompany.Outbox;
using Microsoft.Sales.Document;
using Microsoft.Sales.Setup;
...

The Business Central source code (and previous the NAV source code) has always been open, but is it the same for Partner APPs?

Resource exposure policy settings

Microsoft says:

When you develop an extension, your code is protected against downloading or debugging by default. Read below about adding Intellectual Property (IP) protection against downloading or debugging into an extension to see the source code in the extensions.

From the Customer side it’s a bit confusing: it pays a commercial license to Microsoft to use an Open Source software but it doesn’t have the code of the Partner’s APP.

In terms of “quantity” of source code, certainly the Microsoft Base Application has thousands (and thousands) more lines of code rather than a medium Partner APP.

In terms of “business critical”, probably the Partner APP is more important than Microsoft Base Application, because that APP could cover a specific need or even the entire “vertical sector” of the Customer.

But Open Source doesn’t prevent the commercial licensing of Partner APPS, so why Closed Source is the most popular choice?

Partner point of view

“We invested a lot of time and money to develop this APP and we want to protect our asset“. Quite simple!

Things change when requests arrive from a new Customer with third party (and closed) APP installed. Very often is impossible to debug, extend or simply understand the behaviour of the system.

In the worst case scenario, the third party developer is unreachable and the new Customer is locked: the only chance is to uninstall the APPs and change them with new ones.

In an even worse scenario, the APP is no longer compatible with the new version of Business Central and was automatically uninstalled.

Customer point of view

In every project that I managed, I always clarifed to the Customer:

The standard part of the solution (Microsoft Stack)
The ISV / Partner part (several APPs)
The custom part, developed specially for the Customer

Moreover, I always given to the Customer a GIT repository to view and download the source code of Custom APP.

Depending on Customer policies, I received various answers:

“It doesn’t matter, I trust you“
“I’m buying a Microsoft Solution, not a your solution!“
“OK, but I want assurances about the source code“
“What happens to your APP if you win the lottery?“

A little bit of reverse engineering

There are three possbile scenario when you receive an .APP package file.

Case 1) the file contains the source code. APP package is a “normal” ZIP file with “NAVX” header instead of the usual “PK” but it’s easy to open with archive tools such as 7zip.

The source code is inside the “src” folder.

Case 2) the file doesn’t contain the source code, but only the symbols for development with Visual Studio Code. Obviously “blind development” 🙂 because you don’t see anything in VSCode, only the function signatures. The “src” folder is missing.

Case 3) the file contains only the runtime and it’s impossible to open even with 7zip (the file is encrypted). To obtain this kind of file you have to use Get-NavAppRuntimePackage PowerShell command.

Get-NAVAppRuntimePackage -ServerInstance BC -Name 'My Great App' -Version 2.3.4.500 -Path 'My Great App_2.3.4.500_runtime.app'

Microsoft says:

You generate runtime packages for distribution of extensions that do not contain AL code, but only the final artifacts used by the server at runtime. Runtime packages allow you to protect the intellectual property represented by your AL source code. The extension in a runtime package can be installed on servers that do not have a developer license. The license is checked on the server where the runtime package is generated.

Behind the scenes: On Premise Database

Runtime and AL source code are stored in the “Application Object Metadata” table.

Regardless of Resource Exposure Policy settings, if you have contents inside “User AL Code” field, you can easily extract the source code.

Content is a Deflate stream with 4 bytes of headings. Here a C# example code to extract the code:

      MemoryStream compressedStream = new MemoryStream(userAlCodeBuffer, 4, userAlCodeBuffer.Length - 4);
      MemoryStream decompressedStream = new MemoryStream();

      Stream deflate = new DeflateStream(compressedStream, CompressionMode.Decompress);
      deflate.CopyTo(decompressedStream);

      string sourceCode = Encoding.UTF8.GetString(decompressedStream.ToArray());

If “User AL Code” is blank, you received only the runtimes from developer and the content is the C# conversion of AL code, that is executed by the Application Server.

This kind of files can be obtained also setting “true” the “EnableDebugging” in “CustomSettings.config” of the Application Server.

  <!--
    With the EnableDebugging flag set to true the Microsoft Dynamics NAV Server
      will start with debugging mode enabled.  This mode has three main functions:
    1)	Upon first connection by a RoleTailored Client all C# for that application
        will be generated.
    2)	C# files will be persisted between server restarts.
    3)  Application Objects will be compiled with debug information.
  -->
  <add key="EnableDebugging" value="true"/>

The files are stored in “C:\ProgramData\Microsoft\Microsoft Dynamics NAV”

“Decompiling” C# source code to obtain original AL code is complicated but possible.

SaaS

The above methods doesn’t work in the SaaS, neither is possible to download APP packages from AppSource. This limitation is obvious if you think about Intellectual Property protection.

Important
For Business Central on-premises, you cannot upload per-tenant extensions or install AppSource apps through the Extension Management page. You cannot install AppSource apps on-premises, including in Docker-based deployments.

Many has asked to Microsoft to reconsider this choice:

Ability to downloaded a runtime package for a given version from AppSource

Conclusions

The Partner is right to protect its Intellectual Property.

The Partner is also right to complain that it’s impossible to work (extend, debug, understand…) with third party closed APP.

The Customer is right to ask for the Source Code of the mission critical parts of its ERP.

The Customer has the right to known which part of the solution is sealed.

I think (and the Community too) that Open Source does not exclude Intellectual Property and the profits of selling software; with strong agreements Partner and Customer can protect each other.

Resource exposure policy settings

Partner point of view

Customer point of view

A little bit of reverse engineering

Behind the scenes: On Premise Database

SaaS

Other interesting posts about BC and Open Source

Conclusions