Add deprecation notices and migration page for add-on modules and IP …

content/en/docs/marketplace/manage-content/create-content/create-solutions/sol-adapt/_index.md

@@ -72,6 +72,10 @@ Conceiving a solution for adaptation requires an understanding of your customers
 
 {{< figure src="/attachments/appstore/create-content/create-solutions/sol-adapt/solution-three-parts.png" alt="Three parts of the adaptable solution" class="no-border" >}}
 
+{{% alert color="warning" %}}
+The tradeoff described below rests on [IP protection](#ip-protection), which is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0. The successor boundaries are soft: a publisher can mark a document as not-to-be-changed, and the consumer can override that. This means a document can be part of the common core while still being adaptable in the exceptional case, so the strict split between an immutable core and an adaptable core relaxes. It also means the core is no longer guaranteed to be unmodified, so a drop-in upgrade becomes a merge. For details, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 These different parts work together in the customer implementation. It is important to maintain these distinctions, because there is an inherent tradeoff: what is part of the common core and IP-protected cannot be adapted or modified, while what can be adapted can never be protected. This boundary can be created at a fine-grained level. All adaptations done to extensions and to the adaptable core can make use of functionality from the common core. For more information, see the [Application Design](/appstore/creating-content/sol-architecting/#app-design) section of *How to Architect Adaptable Solutions*.
 
 This table describes the three main functional parts in more detail:
@@ -84,6 +88,10 @@ This table describes the three main functional parts in more detail:
 
 ## IP Protection {#ip-protection}
 
+{{% alert color="warning" %}}
+IP protection is deprecated as of Studio Pro 11.18, and is removed in Studio Pro 12.0. It remains fully supported for the entire support duration of Mendix 11. There is no technical successor for keeping an implementation concealed from a customer. For what replaces it, what does not, and what this means for ISVs as opposed to enterprise platform teams, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 To ensure that the intellectual property (IP) that is created while [building the solution core](#lifecycle) is not disclosed to implementation teams or to customers, you can [apply IP protection](/appstore/creating-content/sol-ip-protection/). This will also render those components immutable, and make it easier to upgrade, as there will never be any merge conflicts.
 
 ## Documents in This Section

content/en/docs/marketplace/manage-content/create-content/create-solutions/sol-adapt/sol-architecting.md

@@ -78,7 +78,11 @@ Make sure to test this scenario before applying any customizations, since this o
 
 ## Application Design {#app-design}
 
-### Combining Module Types
+### Combining Module Types {#combining-module-types}
+
+{{% alert color="warning" %}}
+This section rests on solution modules hiding their implementation, which is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0. The guidance is accurate and supported for the entire support duration of Mendix 11. Two parts of it are expected to change: the **Implementation** column no longer reads **Hidden** once IP protection is removed, and the practice of pairing each core module with an open counterpart is intended to be replaced by declared substitution points within a single module. For details, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
 
 An adaptable solution can include multiple core and adaptable modules. When creating a solution, it is important to make a distinction between the different module types and their purpose in the application model:
 
@@ -120,6 +124,10 @@ When designing the interfaces of your solutions, Mendix recommends the following
 
 IP protection can be used to make parts of the application model and the common core immutable by customers. For practical guidance, see [Applying Intellectual Property Protection](/appstore/creating-content/sol-ip-protection/).
 
+{{% alert color="warning" %}}
+IP protection is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0. It remains fully supported for the entire support duration of Mendix 11. There is no technical successor for concealing an implementation from a customer. See [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ### Mendix Platform Version
 
 To [upgrade a solution](/appstore/creating-content/sol-upgrade/), the application's Mendix Platform version must match the version specified in the solution upgrade package. Therefore, Mendix recommends the following:

content/en/docs/marketplace/manage-content/create-content/create-solutions/sol-adapt/sol-ip-protection.md

@@ -6,6 +6,12 @@ weight: 2
 description: "Protect intellectual property in solutions, app services, and connectors"
 ---
 
+{{% alert color="warning" %}}
+Intellectual property (IP) protection is deprecated as of Studio Pro 11.18, and is removed in Studio Pro 12.0. Everything on this page remains fully supported for the entire support duration of Mendix 11.
+
+There is **no technical successor for commercial IP protection**. The replacement capabilities are soft boundaries that the consumer can override, which addresses governance of a shared core but does not prevent a paying customer from copying an implementation or disabling a check. This affects the [usage metering](#metering) and [entitlement management](#entitlement) guidance on this page in particular. Before you build a business case on this page, read [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ## Introduction
 
 When selling solutions or components that are created in Mendix, and where the customer or partner gets access to the model, you should consider protecting the intellectual property (IP) of that content. In addition, you want to ensure that developers use the implementation as intended, and protect any custom usage metering so that customers cannot accidentally or intentionally disable it. Therefore, it is a good idea to consider applying at least some IP protection to your solutions and components.
@@ -100,6 +106,10 @@ To protect your app services, connectors, and modules, follow these steps:
 
 ### Protecting Usage Metering {#metering}
 
+{{% alert color="warning" %}}
+This guidance depends on the consumer being unable to edit the metering implementation. Because IP protection is deprecated and the replacement boundaries are consumer-overridable, there is **no planned platform capability for tamper-proof usage metering**. The legal clause described in this section becomes the primary control rather than a backstop. See [Usage Metering and Entitlement Enforcement](/refguide/migrate-add-on-and-solution-modules/#metering).
+{{% /alert %}}
+
 To ensure customers do not accidentally or intentionally break usage metering, it is a good practice to hide the implementation of custom usage metering in a protected module.
 
 There are two common scenarios for custom usage metering:
@@ -116,7 +126,11 @@ These are the best practices for usage metering:
 * Have a legal agreement for your solution or app service in place. This needs to include a clause requiring the customer to ensure that any custom usage metering functions as intended.
   This means that where for some reason you cannot protect the metering implementation at the technical level, you are still covered at the legal level.
 
-### Entitlement Management
+### Entitlement Management {#entitlement}
+
+{{% alert color="warning" %}}
+Entitlement management is described here as a layer on top of IP protection. A signed license key is only as strong as the logic that validates it, so where a consumer can edit the validating microflow, edition gating, rate limiting, key expiry, and runtime URL binding all become advisory. There is **no planned platform capability for enforceable entitlement validation**. See [Usage Metering and Entitlement Enforcement](/refguide/migrate-add-on-and-solution-modules/#metering).
+{{% /alert %}}
 
 Applying IP protection prevents the people that consume your solution from inspecting details of the model and from copying the implementation. On top of that, Mendix recommends implementing entitlement management.
 

content/en/docs/refguide/general/mx-command-line-tool/dump-mpr.md

@@ -24,6 +24,10 @@ These are the `OPTIONS`:
 | `--exclude-protected-modules` | | Exclude protected modules from the JSON export. |
 | `--module-names` | A single module name, or a comma-separated list of module names. | Filters the results on the supplied modules and limits the JSON export. |
 
+{{% alert color="warning" %}}
+For `--exclude-protected-modules`, a protected module means an [add-on or solution module](/refguide/module-settings/#module-type). Intellectual property protection of those modules is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0, so this option has no modules to exclude once no module is protected. The option remains supported for the entire support duration of Mendix 11. For details, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ### Examples
 
 These are valid examples:

content/en/docs/refguide/general/mx-command-line-tool/module.md

@@ -48,6 +48,10 @@ The command will output the version of the module to the command line output.
 
 ## mx set-module-version Command {#set-module-version}
 
+{{% alert color="warning" %}}
+The add-on module type is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0. It remains fully supported for the entire support duration of Mendix 11. [Module version](/refguide/module-settings/#module-version) is available for every module type in Studio Pro 11.12 and above. For details, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 The `mx set-module-version` command changes the version of an add-on module.
 
 ### Usage

content/en/docs/refguide/modeling/app-explorer/app/app-settings/solution-tab.md

@@ -5,6 +5,10 @@ weight: 80
 #If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details.
 ---
 
+{{% alert color="info" %}}
+Solutions are not deprecated, and the settings on this tab are unaffected. However, intellectual property (IP) protection of solution modules is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0, which changes how the solution core is protected. For details, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ## Introduction
 
 Settings on this tab allow you to configure application distribution as an [adaptable solution](/appstore/creating-content/sol-solutions-guide/). 

content/en/docs/refguide/modeling/app-explorer/modules/_index.md

@@ -25,6 +25,10 @@ The sections below present categories and tables for all the different kinds of
 
 ## Module Types {#module-types}
 
+{{% alert color="warning" %}}
+The add-on module type and intellectual property (IP) protection through the **Export level** property are deprecated as of Studio Pro 11.18, and are removed in Studio Pro 12.0. They remain fully supported for the entire support duration of Mendix 11. Solutions are not deprecated. For what changes and what replaces it, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 When you create a module, it has a default **app module** type. The type can be changed at any time in [Module Settings](/refguide/module-settings/). 
 
 There are the following type of modules:

content/en/docs/refguide/modeling/app-explorer/modules/configure-add-on-and-solution-modules.md

@@ -5,6 +5,10 @@ url: /refguide/configure-add-on-and-solution-modules/
 weight: 20
 ---
 
+{{% alert color="warning" %}}
+The add-on module type and intellectual property (IP) protection through the **Export level** property are deprecated as of Studio Pro 11.18, and are removed in Studio Pro 12.0. Everything on this page remains fully supported for the entire support duration of Mendix 11. For what changes, what replaces it, and what has no replacement, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ## Introduction
 
 Add-on and solution modules are special types of modules that are developed to add functionality to an app. They have intellectual property (IP) protection enabled and have the *.mxmodule* extension. For more information on IP protection, see [Applying Intellectual Property Protection](/appstore/creating-content/sol-ip-protection/). 
@@ -21,6 +25,10 @@ All the content in add-on and solution modules is set to be hidden from consumer
 
 ### Changing the Export Level of a Document/Element {#export-level}
 
+{{% alert color="warning" %}}
+The **Export level** property is deprecated as of Studio Pro 11.18 and is removed in Studio Pro 12.0. It continues to work for the entire support duration of Mendix 11. The successors are separate capabilities for each of its two values: **Hidden** documents map to a read-only status that the consumer can override, and **Usable** documents map to a declared entry point. Usability of entities, attributes, and associations has no successor. See [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 Documents and some elements in the add-on and solution modules have the **Export level** property. This property defines whether the consumers are able to use a certain document/element in their app. For details on what documents and elements are supported for add-on and solution modules, see the [Supported Documents](#supported-documents) section below. 
 
 The **Export level** has two values:
@@ -103,6 +111,7 @@ If for some reason you switch the add-on and solution module to an app module (f
 ## Read More
 
 * [Create Solutions](/appstore/creating-content/sol-solutions-guide/)
+* [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/)
 * [IP Protection](/appstore/creating-content/sol-ip-protection/)
 * [How to Use Marketplace Content](/appstore/use-content/)
 * [Import and Export Apps, Modules, Widgets, and Documents](/refguide/import-and-export/)

content/en/docs/refguide/modeling/app-explorer/modules/consume-add-on-modules-and-solutions.md

@@ -6,13 +6,17 @@ weight: 30
 #If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details.
 ---
 
+{{% alert color="warning" %}}
+The add-on module type and intellectual property (IP) protection are deprecated as of Studio Pro 11.18, and are removed in Studio Pro 12.0. Add-on modules and solutions that you already consume keep working for the entire support duration of Mendix 11, and no action is required now. For what changes for consumers, see [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/).
+{{% /alert %}}
+
 ## Introduction
 
 An *add-on module* is a special type of module that adds functionality to your app. It has Intellectual Property (IP) protection enabled and has the *.mxmodule* extension. An add-on module is developed to be a *standalone functionality* that other users can consume in their apps, for example, an add-on can be a connector. 
 
 A *solution* is a Mendix app that has out-of-the-box solution suitable for multiple customers. Solution, as any other app, may consist of several modules, including app modules (standard modules) and add-on modules, but it also has solution modules that form the **solution core**. Solution modules have IP protection enabled. For more information on IP protection, see [IP Protection](/appstore/creating-content/sol-ip-protection/). 
 
-## Limitations
+## Limitations {#limitations}
 
 When consuming add-on modules and solutions, you may come across the following limitations and known issues:
 
@@ -51,6 +55,7 @@ The module is deleted from your app.
 
 ## Read More
 
+* [Migrating from Add-on Modules and IP Protection](/refguide/migrate-add-on-and-solution-modules/)
 * [IP Protection](/appstore/creating-content/sol-ip-protection/)
 * [How to Use Marketplace Content](/appstore/use-content/)
 * [Importing and Exporting Apps, Modules, Widgets, and Documents](/refguide/import-and-export/)