<h2>Generally: No</h2>
<p>Let's face the obvious problems of the files exchanged and the files used for printing, and then look into why it is a bad idea in the first place.</p>
<h2>G-code</h2>
<p>G-code is in its design a .txt file that contains specific orders for a machine. There is a g-code command that forces the printer to delete the file (<a href="https://marlinfw.org/docs/gcode/M030.html" rel="nofollow noreferrer"><code>M30</code></a>) but that needs the exact file path - and just does nothing if the path is incorrect. One could make a slicer profile, that after printing, deletes the file from the SD-card, but doing so as a user is only useful for one-off jobs and it can be prevented by the user by simply shutting down the printer before the line is triggered.</p>
<p>Because .gcode is essentially a .txt without any special features but a custom ending, it can't provide DRM beyond containing a self-delete-after-completion.</p>
<h2>STL &amp; OBJ</h2>
<p>STL and OBJ are the most relevant exchange files. They are open source and not intended to contain any DRM.</p>
<h2>Other formats?</h2>
<p>Even with a different format, you would need both a <strong>proprietary 3D format</strong> that can only be read by your DRM-enabled slicer as well as a <strong>proprietary printer file type</strong> that both contain DRM. However, using a proprietary printer command type means you lock down your file to be only available to your printer family, which in turn makes this printer family <strong>less</strong> desirable, as it can't work with the standard g-code format.</p>

CC BY-SA 4.0
2020-05-28T14:04:49.030Z
2020-05-28T14:04:49.030Z
2020-06-18T08:29:41.667Z
Trish
<p>Good luck with that.</p>

<p>Issues you will face:</p>

<ul>
<li>using a G-code editor (or built-in printer software) to create multiple copies of the object in a single print session</li>
<li>user writing the printer file to an SD card, then block-copying the SD card</li>
<li>defining a "print". Specifically:</li>
<li>is #2 another functional copy of the object, or did #1 fail? Failed prints happen a lot.</li>
<li>is #3 another functional copy of the object, or was #2 damaged in post-processing? Like removing supports or left it in the acetone 5 seconds too long and it's now a blob.</li>
<li>is #4 another functional copy of the object, or was #3 tossed because the guy running the printer grabbed the wrong spool and made a perfectly good print in the perfectly wrong material/colour.</li>
<li>is #5 another functional copy of the object, or was #4 damaged in shipping?</li>
</ul>

<p>The whole process is one-way. There just isn't a path for anything other than the end user to know what they pulled off the print bed. Unless you make the entire process from design software to printer you won't change that. And good luck selling it, 'cause the user base is rather strongly opposed to that kind of thing. For example, ANY kind of DRM in the product, from printer software to filament, is an immediate no-buy for me. I don't care if you are paying me to take it, I will find an alternative without that particular annoyance. And no, I don't use Microsoft or Adobe products either. </p>

CC BY-SA 4.0
2020-05-28T13:52:03.330Z
Yes, a "full stack" solution from software to printer would be an option, the problem is I don't know any. I'm not interested in selling the DRM solution, I basically need a "safe" path between my business and another one. We are already working together, we just need to add some "accountability".
piotrek
CC BY-SA 4.0
2020-05-28T22:50:07.640Z
"a "safe" path between my business and another one" -> that's easy. Contracts. Have your lawyer and their lawyer play tennis.
Also, it would have helped greatly if you specified the scope you were looking for. A "one-to-one" scope is much different from the "one-to-mass market" scope.
peter
CC BY-SA 4.0
2020-05-28T13:20:36.013Z
2020-05-28T13:20:36.013Z
peter
<p>Is there any DRM or license management solution for 3D printing? I'm looking for something, that would help me limit the number of prints someone can make from my projects. Basically, I would like to sell the "right to make no more than X copies" of my design. I don't expect it to be bullet-proof (like Widevine L1 for video), but it should at least help me with license management.</p>

<file-formats><legal>
DRM or license management solution for 3D printing
piotrek
# DRM or license management solution for 3D printing

(Asked by: username_0 on 2020-05-28)

Is there any DRM or license management solution for 3D printing? I'm looking for something, that would help me limit the number of prints someone can make from my projects. Basically, I would like to sell the "right to make no more than X copies" of my design. I don't expect it to be bullet-proof (like Widevine L1 for video), but it should at least help me with license management.

**Tags:** file-formats, legal

---

## 2 answers

### Answer by username_2 on 2020-05-28. Score: 3 | Accepted answer

Good luck with that.

Issues you will face:

* using a G-code editor (or built-in printer software) to create multiple copies of the object in a single print session
* user writing the printer file to an SD card, then block-copying the SD card
* defining a "print". Specifically:
* is #2 another functional copy of the object, or did #1 fail? Failed prints happen a lot.
* is #3 another functional copy of the object, or was #2 damaged in post-processing? Like removing supports or left it in the acetone 5 seconds too long and it's now a blob.
* is #4 another functional copy of the object, or was #3 tossed because the guy running the printer grabbed the wrong spool and made a perfectly good print in the perfectly wrong material/colour.
* is #5 another functional copy of the object, or was #4 damaged in shipping?

The whole process is one-way. There just isn't a path for anything other than the end user to know what they pulled off the print bed. Unless you make the entire process from design software to printer you won't change that. And good luck selling it, 'cause the user base is rather strongly opposed to that kind of thing. For example, ANY kind of DRM in the product, from printer software to filament, is an immediate no-buy for me. I don't care if you are paying me to take it, I will find an alternative without that particular annoyance. And no, I don't use Microsoft or Adobe products either.

> **Comments:**
> **username_0**: Yes, a "full stack" solution from software to printer would be an option, the problem is I don't know any. I'm not interested in selling the DRM solution, I basically need a "safe" path between my business and another one. We are already working together, we just need to add some "accountability".  
> **username_2**: "a "safe" path between my business and another one" -> that's easy. Contracts. Have your lawyer and their lawyer play tennis. Also, it would have helped greatly if you specified the scope you were looking for. A "one-to-one" scope is much different from the "one-to-mass market" scope.  

---

### Answer by username_1 on 2020-05-28. Score: 0

## Generally: No

Let's face the obvious problems of the files exchanged and the files used for printing, and then look into why it is a bad idea in the first place.

## G-code

G-code is in its design a .txt file that contains specific orders for a machine. There is a g-code command that forces the printer to delete the file ([`M30`](https://marlinfw.org/docs/gcode/M030.html)) but that needs the exact file path - and just does nothing if the path is incorrect. One could make a slicer profile, that after printing, deletes the file from the SD-card, but doing so as a user is only useful for one-off jobs and it can be prevented by the user by simply shutting down the printer before the line is triggered.

Because .gcode is essentially a .txt without any special features but a custom ending, it can't provide DRM beyond containing a self-delete-after-completion.

## STL & OBJ

STL and OBJ are the most relevant exchange files. They are open source and not intended to contain any DRM.

## Other formats?

Even with a different format, you would need both a **proprietary 3D format** that can only be read by your DRM-enabled slicer as well as a **proprietary printer file type** that both contain DRM. However, using a proprietary printer command type means you lock down your file to be only available to your printer family, which in turn makes this printer family **less** desirable, as it can't work with the standard g-code format.


---

