[QUESTION] Where is the source code for the actual bootloader shipped with the Prusa Mini+?

[matthewlloyd]

The Prusa Mini+ Buddy board ships with a bootloader pre-flashed at the factory.

When compiling the firmware source code from this repository, the bootloader is downloaded in binary form by utils/bootstrap.py as part of the build process, from this URL:

https://prusa-buddy-firmware-dependencies.s3.eu-central-1.amazonaws.com/bootloader-mini-1.0.0.zip

This ZIP file contains a 128KB binary file named bootloader.bin:

Archive:  bootloader-mini-1.0.0.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   131069  2019-11-08 07:09   bootloader.bin
      212  2019-11-08 07:09   __MACOSX/._bootloader.bin
---------                     -------
   131281                     2 files

The source code which generates this binary file, which contains executable ARM code, does not seem to be available anywhere in Prusa's GitHub repositories. This bootloader is distributed with the Prusa Mini+, in the flash memory on the ARM chip on the Buddy board, alongside and packaged together with the rest of the firmware, which of course is based on Marlin. It is also distributed in binary form, similarly packaged with Marlin, as part of the official firmware file downloadable from Prusa's website (https://www.prusa3d.com/drivers/).

The entire project is a covered work under the terms of the GPL v3 license, as it is based on Marlin which is also GPL v3. I believe that Prusa is required to supply the complete source code for the entire firmware, including the bootloader, because it is packaged together in the distribution media which Prusa itself distributes, to form a larger program. Therefore, in order to comply with Marlin's source code license, I believe Prusa is required to supply the source code for the bootloader.

I hereby request Prusa make available the source code for bootloader.bin.

[JustAnother1]

It is sad that prusa does not comment on this :-(

They might think that as long as they do not link the bootloader against the firmware they don't need to provide the source. One could argue that the bootloader and the firmware are separate executables that are side by side in the chip and therefore different software. If that holds then they would not be required to publish the source. But I'm not a lawyer.

But they also release the 3d files of the plastic parts and so much other stuff that they would not need to release. So why not the bootloader? Maybe they have a good reason?

If you do $ strings bootloader.bin you get all the text contained in the binary file. strings.txt

So the Bootloader can do an update from USB. And there is this string

Developer firmware

Maybe they don't want everybody to know how to create a Developer firmware ?

Next we can do this $ arm-none-eabi-objdump -D -bbinary -marm bootloader.bin -Mforce-thumb > output.s that gives us a disassembly. output.s.zip

Looking through that could take some time. A help could be Radare2 like this $ r2 -a arm -b 16 -m 0x08000000 -w bootloader.bin To understand how that works take a look here: https://radare.gitbooks.io/radare2book/content/first_steps/intro.html

So now who will be first to understand how the Developer firmware feature works?

[matthewlloyd]

They might think that as long as they do not link the bootloader against the firmware they don't need to provide the source.

GPLv3 is quite clear on this topic:

5. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply ... to the whole of the work, and all its parts, regardless of how they are packaged.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

The first paragraph clearly applies. Prusa might argue that the combination of the bootloader and the main program is just an aggregate, but the license clearly states that it is not an aggregate if they are combined to form a larger program in or on a storage or distribution medium - and clearly the flash memory of the STM32F407 is a distribution medium. Furthermore, Marlin includes bootloaders, so the Prusa bootloader is "by its nature an extension of the covered work".

Developer firmware

Good find. Some disassembly reveals the "Developer firmware" message is activated if the 64-byte signature (normally produced from Prusa's private key, and verified using the public key in the bootloader) is filled with 0xFF. The signature is flashed at the start of the firmware image, at memory offsets 0x8020000 - 0x8020040. This is easy to arrange for with a small modification to the build script (specifically pack_fw.py, change 'sig = bytes(64)' to 'sig = b'\xff' * 64'). I'm not sure what the practical implication of this is. I already broke the appendix so I can't determine whether it allows the normal intact-appendix signature check to be bypassed or not, but it's a possibility. It may also bypass the SHA hash check.

Practically speaking, I'm currently trying to get Klipper running, and it would be a much easier task if I could see how the bootloader works. Another reason I could use the source is that the bootloader that shipped on my Mini+ was v1.1.0, but the binary bootloader downloaded by the build script is an old version v1.0.0; I've already accidentally downgraded and don't have a copy of the v1.1.0 bootloader binary to replace it, let alone the source.

I hope they take care of this matter quickly, otherwise it may be necessary to escalate to their legal team, or the great man himself.

[JustAnother1]

I used a original BBF file and changed the first 64 Bytes to 0xff. I could not flash that image. I did not see the Developer Firmware message.

I have bootloader 1.1.0 and did not break the appendix.

Could you share the BBF file that got you to "Developer firmware" ?

Regarding Klipper: The bootloader will most probably only shift the start address of the firmware and the address of the Vector table. You can probably get both from the Lionker file used to compile the Prusa Firmware. With those changes it should be possible to put the Klippy Firmware into a BBF file and have it flashed and run as Develeoper firmwware.

But the you will need to repeat that with every Klipper update that chenges the firmware,...

Or as you have already broken the apendix, jsut use the SWD interface, get rid of the Bootloader and flash the Klipper firmware using SWD.

You might want to sdisassemble the display unit and remove the foil from the screen, that will also remove that green thing in the bottom left corner.

[matthewlloyd]

I could not flash that image.

That confirms breaking the appendix (or lifting BOOT0 etc.) is still necessary to open things up, even when uploading "Developer firmware".

Could you share the BBF file that got you to "Developer firmware" ?

Don't have it handy but it was identical to what you created by patching the first 64 bytes.

DFU via USB seems more reliable than the stock bootloader (slow and occasionally ignored BBF updates on the USB drive). I added a cable to extend the 2-pin header outside the box, I just add the jumper and reset, then use dfu-util. SWD debugging is working too using OpenOCD.

I have Klipper running - bootloader offset was the issue. Foil on the screen is to protect it from the appendix-shaped PCB projectile flying around the room ;)

[JustAnother1]

I could not flash that image.

That confirms breaking the appendix (or lifting BOOT0 etc.) is still necessary to open things up, even when uploading "Developer firmware".

Not so fast. I used a different Bootloader than what you tested with. So it might be a new feature in the 1.1.0 version. They might have changed the Developer Firmware signature to something else or removed the feature completely.

You can test if the "appendix" is the issue by connection BOOT0 and SWDIO to GND. That is all the appendix does.

Now I also want to see the Source code of the Bootloader,....

[JustAnother1]

@JohnnyDeer What is the Prusa position regarding GPL and the Bootloader?

GPLv3 is quite clear on this topic:

1. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply ... to the whole of the work, and all its parts, regardless of how they are packaged.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

The first paragraph clearly applies. Prusa might argue that the combination of the bootloader and the main program is just an aggregate, but the license clearly states that it is not an aggregate if they are combined to form a larger program in or on a storage or distribution medium - and clearly the flash memory of the STM32F407 is a distribution medium. Furthermore, Marlin includes bootloaders, so the Prusa bootloader is "by its nature an extension of the covered work".

Can you point us to the Bootloader repository, or does Prusa have a different view on the license terms?

[dragomirecky]

Hey @matthewlloyd and @JustAnother1,

Thank you for your patience regarding this issue. To answer the primary question here: the bootloader is a separate project from the Buddy firmware. The Buddy firmware is in no way dependant on it and is fully functional without it. The bootloader isn’t part of the Buddy firmware, and we don’t distribute it as part of the BBF files on our website (as mentioned in the first comment). Therefore, we believe that seen from the point of the GPLv3 license, the firmware and the bootloader form an aggregate, and we are not obliged to release the bootloader’s source code. In the same way, the license does not require us to open source the source code of the stock bootloader pre-flashed by STMicroelectronics.

But hey, that being said, we are planning to open-source the bootloader :slightly_smiling_face:. Even though it is not a current priority, we are taking steps towards making it eventually happen.

So now who will be first to understand how the Developer firmware feature works?

Don’t want to spoil the fun, but I have to say that there is no hidden “Developer Firmware” feature. The “Developer firmware” string you found in the disassembly appears when the firmware isn’t signed. And to flash an unsigned firmware, you have to break the appendix first. So again, no hidden feature here – even all the printers at our offices have broken appendixes.

but the binary bootloader downloaded by the build script is an old version v1.0.0; I’ve already accidentally downgraded and don’t have a copy of the v1.1.0 bootloader binary to replace it

Thanks for pointing this out! I just made a note to update the bootloader there.

[JustAnother1]

Thank you for your patience regarding this issue. To answer the primary question here: the bootloader is a separate project from the Buddy firmware. The Buddy firmware is in no way dependant on it and is fully functional without it. The bootloader isn’t part of the Buddy firmware, and we don’t distribute it as part of the BBF files on our website (as mentioned in the first comment). Therefore, we believe that seen from the point of the GPLv3 license, the firmware and the bootloader form an aggregate, and we are not obliged to release the bootloader’s source code. In the same way, the license does not require us to open source the source code of the stock bootloader pre-flashed by STMicroelectronics.

One might argue that the Prusa Bootloader and the Prusa Firmware share the same medium(Flash) but the ST Bootloader is in ROM, but I'm not a lawyer.

But hey, that being said, we are planning to open-source the bootloader slightly_smiling_face. Even though it is not a current priority, we are taking steps towards making it eventually happen.

It would be great if you could post the link to that (once it happened) here, so that others with the same question can find the link.

but the binary bootloader downloaded by the build script is an old version v1.0.0; I’ve already accidentally downgraded and don’t have a copy of the v1.1.0 bootloader binary to replace it

Thanks for pointing this out! I just made a note to update the bootloader there.

A link to the binary would also be appreciated (for the same reasons).

Thank you for looking into this. Like I said before Prusa is opening up so much,also opening up the mechanical (printed) parts of the printer, so not opening up the Bootloader sounded wrong. I'm happy that this will be solved. Keep up the great work!

[dragomirecky]

but the binary bootloader downloaded by the build script is an old version v1.0.0; I’ve already accidentally downgraded and don’t have a copy of the v1.1.0 bootloader binary to replace it

Thanks for pointing this out! I just made a note to update the bootloader there.

A link to the binary would also be appreciated (for the same reasons).

Here it is :) https://github.com/prusa3d/Prusa-Firmware-Buddy/pull/1482

[matthewlloyd]

Many thanks to Prusa for replying to this thread.

we don’t distribute it as part of the BBF files on our website

I stand corrected, and agree that the bootloader is not distributed in the BBF downloaded from Prusa's website. It is, however, distributed on the board's flash. It is also clearly intended to be linked with it as part of the process in utils/build.py.

The Buddy firmware is in no way dependant on it and is fully functional without it... the firmware and the bootloader form an aggregate.

This is not entirely accurate. The bootloader and Buddy firmware communicate bidirectionally via shared memory. Using shared memory to communicate is generally considered dynamic linking, which does make programs a combined work.

We can only see one side of the communication since the bootloader is closed source. At the very least we can see that the firmware communicates update mode flags (set via the GUI menu) to the bootloader, and the bootloader communicates the status of the appendix to the firmware. Perhaps there is more. Here are some code excerpts:

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/3b406f5cf0ba7f90471842434cbd66aed7e8434f/src/common/sys.cpp#L16

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/src/common/shared_config.h

typedef struct {
    uint8_t fw_update_flag;
    uint8_t model_specific_flags; // ~ "reserved1" originally
    ...
} data_exchange_t;

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/3b406f5cf0ba7f90471842434cbd66aed7e8434f/src/STM32F407VG_FLASH_boot.ld#L111

 /* to exchnage data between bootloader and application */
 /* this section is filled with zeros on each application start */
  .boot_fw_data_exchange 0x20000000 :
  {
    _sboot_fw_data_exchange = .;  /* global symbol at start */
    KEEP (*(.boot_fw_data_exchange))
    . = ALIGN(4); /* allignment is important as 4 bytes are written to zero at once in startup code*/
    _eboot_fw_data_exchange = .;  /* global symbol at the end */
  } >RAM AT> FLASH /* AT> FLASH added to avoid the binary size increase*/

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/3b406f5cf0ba7f90471842434cbd66aed7e8434f/src/common/support_utils.cpp#L173

bool appendix_exist() {
    const version_t *bootloader = (const version_t *)BOOTLOADER_VERSION_ADDRESS;

    if (bootloader->major >= 1 && bootloader->minor >= 1) {
        return !(ram_data_exchange.model_specific_flags & APPENDIX_FLAG_MASK);
    } else {
    ...

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/3b406f5cf0ba7f90471842434cbd66aed7e8434f/src/common/sys.cpp#L262

void sys_fw_update_on_restart_enable(void) {
    ram_data_exchange.fw_update_flag = FW_UPDATE_ENABLE;
}

But hey, that being said, we are planning to open-source the bootloader 🙂. Even though it is not a current priority, we are taking steps towards making it eventually happen.

This is very good to hear. I do hope given the above, that Prusa honors the open source community and respects the terms of Marlin's GPLv3 by releasing the source code for the dynamically linked bootloader as soon as is reasonably possible.

[matthewlloyd]

Here it is :) #1482

Fantastic - thank you so much for uploading the latest version. We are all very excited about the upcoming release of the i3 MK4 and XL.

[miko007]

@matthewlloyd what you describe only applies, if the dynamically linked software is under gpl license. then you are correct, the linking software has also to comply with the gpl.

the other way around makes no sense whatsoever, because it would leave people unable to dynamically link non gpl libraries in their gpl projects.

i can not force, say microsoft, to open source their proprietary library by dynamically linking it in my gpl project, you see my point, right?

[matthewlloyd]

i can not force, say microsoft, to open source their proprietary library by dynamically linking it in my gpl project, you see my point, right?

The GPL specifically carves out an exception for "System Libraries", which applies for example to Microsoft's proprietary libraries, but does not apply here because a bootloader with bidirectional communication via shared memory does not meet the definition of a System Library. You can read the GPL FAQ here for more information: https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException.

The incorrect assertions in the rest of your comment are addressed in the GPL FAQ here, and in other places: https://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc. In short, the GPL does not allow GPL-covered software to be linked (dynamically or otherwise) with closed source libraries, except for the System LIbrary exception as described above, and for aggregates, which this is not (see https://www.gnu.org/licenses/gpl-faq.html#MereAggregation).

[miko007]

@matthewlloyd that of course was an exaggerated example.

you can not force me to put my MIT licensed js library under GPL by using it in your GPL project, either.

[matthewlloyd]

you can not force me to put my MIT licensed js library under GPL by using it in your GPL project, either.

Your statement is irrelevant because there is no MIT licensed library involved here. I have already addressed your original incorrect assertions in my previous response. My original arguments still stand. If you wish to improve your understanding of the GPLv3, I recommend reading the GPL FAQ and the text of the license itself.

[miko007]

then this discussion does not lead anywhere. my original arguments also still stand and i do not need to improve my understanding of the gpl.

[JustAnother1]

@miko007 The issue here is that the "dynamic linking" if we can call it that goes both ways.

1.) The Bootloader boots the Firmware. (That is the Linking that would not cause an issue if the Bootloader is non GPL but the Firmware is)

2.) The Firmware accesses / talks to / uses the Bootloader. After booting the Firmware the Bootloader is not just gone. As pointed out before there is interaction between Firmware an Bootloader. Therefore we have some linkage from the Firmware to the Bootloader.

Then again you are right the discussion does not lead anywhere as @dragomirecky already promised to open source the Bootloader. So if they have to do it or they do it on their own is a moot point.

[matthewlloyd]

All they have stated is that "we are planning to open-source the bootloader 🙂. Even though it is not a current priority, we are taking steps towards making it eventually happen."

While I applaud Prusa's agreement to come into compliance, their statement is not sufficient under GPLv3. Since the bootloader is dynamically linked, they are legally obliged to provide the source code, and furthermore, it needs to be provided in a reasonable period of time. It has already been two months since I opened this request. "Eventually" is not good enough. It is not a question of priorities - it is a legal requirement.

When I have made similar requests to other companies, they have been handled within days. For example, I asked BigTreeTech to provide the source code to their modified version of RRF for their Octopus board, they did so in two days (https://github.com/bigtreetech/BIGTREETECH-OCTOPUS-V1.0/issues/40). When I asked Fokoos to provide the source code to their modified version of Marlin for their Odin 5 F3 printer, they supplied it within a few hours.

[JustAnother1]

@dragomirecky Could you provide reasons for the delay in open sourcing the Bootloader? Keeping the "i3 MK4" and "XL" a secret couldn't be it any more. Do you have swear words in the code that need to be removed before going public?

So it basically is just a click on "make it public" ? Or what needs to be done ? Or are you waiting on approval from @josefprusa ?

[bschollnick]

By no means am I even related to Prusa, but…

While I applaud Prusa's agreement to come into compliance, their statement is not sufficient under GPLv3. Since the bootloader is dynamically linked, they are legally obliged to provide the source code, and furthermore, it needs to be provided in a reasonable period of time. It has already been two months since I opened this request. "Eventually" is not good enough. It is not a question of priorities - it is a legal requirement.

Define reasonable period of time.

And then consider that there maybe proprietary comments, code that relies on proprietary functions or modules, and generally cleaning the code up to meet their standards.

Prusa has stated that they are working on this, so at this time, they have stated that they intend to make it available. They haven’t given a time line, so ranting isn’t going to make it happen faster.

If you want to see it faster, then give them constructive reasons that it is worth putting more man power on that project.

Why is it advantageous to Prusa to redirect manpower from Prusa Slicer, or other software projects to open sourcing the boot loader? For all we know they may only have a single FTE or a partial FTE on this project. That’s more than enough to show GPL compliance..

GPL compliance does not mean complying with your timeline, just that it will be available and that they are working on it.

- Benjamin

On Jul 21, 2021, at 10:35 AM, Matthew Lloyd @.***> wrote:

All they have stated is that "we are planning to open-source the bootloader 🙂. Even though it is not a current priority, we are taking steps towards making it eventually happen."

While I applaud Prusa's agreement to come into compliance, their statement is not sufficient under GPLv3. Since the bootloader is dynamically linked, they are legally obliged to provide the source code, and furthermore, it needs to be provided in a reasonable period of time. It has already been two months since I opened this request. "Eventually" is not good enough. It is not a question of priorities - it is a legal requirement.

When I have made similar requests to other companies, they have been handled within days. For example, I asked BigTreeTech to provide the source code to their modified version of RRF for their Octopus board, they did so in two days (bigtreetech/BIGTREETECH-OCTOPUS-V1.0#40 https://github.com/bigtreetech/BIGTREETECH-OCTOPUS-V1.0/issues/40). When I asked Fokoos to provide the source code to their modified version of Marlin for their Odin F5 printer, they supplied it within a few hours.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/1440#issuecomment-884240622, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHPEZU723ZXG2TEOIZUQGDTY3LMZANCNFSM45QWZ3NA.

[matthewlloyd]

Define reasonable period of time. ... GPL compliance does not mean complying with your timeline, just that it will be available and that they are working on it.

I have not defined a timeline. That would be up to a judge. There is simply a legal requirement that they provide the source. Until they do so, they are violating Marlin's GPL.

It is the same with any contract. A promise to do something eventually does not satisfy a legal requirement to do that thing, until that thing is actually done. That is one reason suits get filed.

And then consider that there maybe proprietary comments, code that relies on proprietary functions or modules, and generally cleaning the code up to meet their standards.

The requirement from GPL is that the source code for the binary must be released, at the same time as the binary, and for the exact version of the binary as it was released. This also applies to all historical versions. The source code versions released must be in a 1:1 correspondence with the binary versions released. There is no allowance in GPL for removing proprietary comments or cleaning up code to meet their standards after releasing a binary. Once a binary has been released, it is a requirement to release the source code that was used to compile it. See https://gpl-violations.org/faq/vendor-faq/.

If you want to see it faster, then give them constructive reasons that it is worth putting more man power on that project.

It is not a question of how Prusa should allocate its manpower. That is up to Prusa. They are legally obliged to release the source code, period. Obviously there are legal, ethical, and community relations reasons why it would be to Prusa's advantage to come into compliance, but it is not my job to define those advantages for them.

I will say that I personally find it disingenuous that a company like Prusa profits commercially from the IP provided for free by the Marlin authors, yet fails to comply with the terms of Marlin's license agreement. They claim to support open source, yet they deliberately added a mechanism to the Buddy board which makes it difficult for owners to install their own firmware - "the appendix". Then they added code to the free software that checks the appendix and acts as a gatekeeper to modifying and improving the software itself, but they are withholding the source code for this tightly integrated additional piece. The entire spirit of the GPL - and free software - is to allow anyone to make their own changes to the software.

[SamuelHaleMN]

So... Nearly a year later and still no resolution on this?

[JustAnother1]

@dragomirecky you said:

But hey, that being said, we are planning to open-source the bootloader slightly_smiling_face. Even though it is not a current priority, we are taking steps towards making it eventually happen.

If it is purely a matter of developers are busy and this is a low priority then let us help!

If whatever needs to be done to get the boot loader to be able to be published can be outsourced then I would be willing to do that. I could sign an NDA, get the source and the todos. I would do all the todos. And then you can publish the result as open source. And I would do all that for free! What more could you possibly ask for?

The XL is out now. Do we also need to wait for the mk4 to be out before the devs can sign off on releasing the boot loader?

[Jookia]

The MK4 is out and also uses the same proprietary bootloader.

[Prusa-Support]

Thank you for writing to us.

Open-sourcing the boot loader is not due nor promised, but it was in our plans. Our plans about this haven't changed but the boot loader has been deeply reworked in the last few years and I believe it is still being worked on.

Please be advised, this may take some time but I'll send a reminder to our developers right away.

On a side note, as our team keeps on expanding so outsourcing may not be necessary. The firmware is open source though and we can take into consideration Pull Requests from volunteering collaborators. There are several open issues and PRs out there waiting for help. 🙂

Michele Moramarco Prusa Research

[JustAnother1]

Open-sourcing the boot loader is not due nor promised, but it was in our plans. Our plans about this haven't changed but the boot loader has been deeply reworked in the last few years and I believe it is still being worked on.

Here https://blog.prusa3d.com/the-state-of-open-source-in-3d-printing-in-2023_76659/ @josefprusa said and I quote:

"Our desktop 3D printers will always be open source."

"The standard GNU GPL license under which our printers and software are available..."

I think that the bootloader of the Mini+ is part of the Mini+. And that is a desktop 3d printer,.. I think you see where I'm going with this. The bootloader is also "software".

And yes I read that blog post and understand the reasoning, and the issues that arise from cheap Chinese clones.

I think It would hep in this situation to split the problem in smaller and therefore probably easier to solve parts. I think an important difference is software vs hardware. Open source software (especially firmware) is something very different to open source hardware.

Right now Prusa is not doing open source firmware! The STM32 is a very popular chip and there are many open source bootloaders available for it. Firmware is also very specifically designed to fit the hardware. The bootloader also includes the signature check for Prusa signed firmware. Therefore nobody who would want to do an 1:1: copy of the printer would benefit from the source code for the boot loader.

Who could benefit is the community that wants to look into it and wants to experiment with it. Also Prusa could benefit from it if the community finds bugs or sends a pull request for a new feature. Not merging pull request because they are of bad quality is a sign that software quality is taken seriously! Feel free to use this to help the community to produce better quality firmware. We are in this together!

That the bootloader has been worked on and is still being worked on is a reason to make it open source, not to hide it away. Once the development on it has stopped the community can not help any more. Also knowing how older versions worked could be helpful. Asking for help when bad actors violate licenses and make the open source unworkable is OK. But making it impossible for the community to help and then complaining that the community does not help is just stupid.

If you want the open source business case to work than it wont happen with a new license that makes all the problems go away. You rather have to look at all the issues separately and try to find solutions.

If I only look at the boot loader issue presented in this issue then I'm not proud on Prusa. And that is a sad situation. In this small issue Prusa does some of what the blog post accused others to do. If that is how Prusa wants to save open source, then it will not work, and that would be a very bad outcome for us all.

[Prusa-Support]

"Our desktop 3D printers will always be open source."

"The standard GNU GPL license under which our printers and software are available..."

I think that the bootloader of the Mini+ is part of the Mini+. And that is a desktop 3d printer,.. I think you see where I'm going with this. The bootloader is also "software".

Please see https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/1440#issuecomment-861301974.

Right now Prusa is not doing open source firmware! The STM32 is a very popular chip and there are many open source bootloaders available for it. Firmware is also very specifically designed to fit the hardware. The bootloader also includes the signature check for Prusa signed firmware. Therefore nobody who would want to do an 1:1: copy of the printer would benefit from the source code for the boot loader.

Yet we are planning to open source it.

If you want the open source business case to work than it wont happen with a new license that makes all the problems go away. You rather have to look at all the issues separately and try to find solutions.

If I only look at the boot loader issue presented in this issue then I'm not proud on Prusa. And that is a sad situation. In this small issue Prusa does some of what the blog post accused others to do. If that is how Prusa wants to save open source, then it will not work, and that would be a very bad outcome for us all.

Your feedback is most valuable to us. Please visit our forum for open discussions and feel free to share your thoughts as a comment in the relevant blog post.

This request will remain open on GitHub for the time being.

Michele Moramarco Prusa Research

[JustAnother1]

"Our desktop 3D printers will always be open source." "The standard GNU GPL license under which our printers and software are available..." I think that the bootloader of the Mini+ is part of the Mini+. And that is a desktop 3d printer,.. I think you see where I'm going with this. The bootloader is also "software".

Please see #1440 (comment).

I did not argue that the bootloader would be part of the "Prusa-Firmware-Buddy". I argued that the bootloader is part of the printer and Josef claims his printer would be open source.

Right now Prusa is not doing open source firmware! The STM32 is a very popular chip and there are many open source bootloaders available for it. Firmware is also very specifically designed to fit the hardware. The bootloader also includes the signature check for Prusa signed firmware. Therefore nobody who would want to do an 1:1: copy of the printer would benefit from the source code for the boot loader.

Yet we are planning to open source it.

Once you have open sourced it then you can claim that prusa printers are open source. Until that time they are not.

If you want the open source business case to work than it wont happen with a new license that makes all the problems go away. You rather have to look at all the issues separately and try to find solutions. If I only look at the boot loader issue presented in this issue then I'm not proud on Prusa. And that is a sad situation. In this small issue Prusa does some of what the blog post accused others to do. If that is how Prusa wants to save open source, then it will not work, and that would be a very bad outcome for us all.

Your feedback is most valuable to us. Please visit our forum for open discussions and feel free to share your thoughts as a comment in the relevant blog post.

Been there, done that, ... ( even with the same name as here, you could have found that)

I don't understand the reason why you are not just pushing whatever code is currently available. The release of the MK4 and the XL is done now. So no more secrets that could be reveled by releasing the source. I also suggested to help (under NDA) to get the source into a releasable state. But that offer was declined. So it could only be an issue of politics, or should I say waiting for the decision on the new license that Josef mentioned in the linked blog article? "politics" comes from "poly" meaning many and "ticks" ;-)

I can only recommend that in that discussion you clearly separate between open source software and open source hardware. As the arguments and options to deal with people ignoring the license are very different. Also the damage caused by violators are different.

If Prusa has to deviate from being completely open source then deviating only on the hardware or only on the software side is better than deviating more in a general form.

From a cost / benefit analysis I can imagine that there is information that, if not open sourced, would harm the 1:1 clones more than it would harm the community. But the bootloader is not such an information.

If you need more feedback from me my email is my profile.

PS: Sorry for being so direct. But I don't like this very polite way of saying basically nothing. And I don't wand Prusa to go closed source.

[theacodes]

The Prusa MINI launched in 2019 and y'all still haven't released the sources for the bootloader. There really isn't any excuse at this point, you're just stringing your users along with the promise of open source without the actual commitment.

[Jookia]

I just want to note here that Marlin and the Prusa firmware is specifically licensed under the GPLv3 which REQUIRES Prusa not just release the source code of Marlin but provide a way to install modified versions of Marlin. The bootloader does not allow this and as such violates the anti-Tivoization clause of the GPLv3. Maybe Marlin developers could sue? :)

This is especially ironic considering Prusa has spent the last few months complaining about companies not respecting their licensing.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[theacodes]

This issue is still relevant and should not be automatically closed.

On Mon, May 20, 2024, 9:47 PM github-actions[bot] @.***> wrote:

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/1440#issuecomment-2121548628, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5I47TW3YEYEMW7G2ZNO3ZDKRRXAVCNFSM45QWZ3NKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGE2TIOBWGI4A . You are receiving this because you commented.Message ID: @.***>

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[JustAnother1]

Hey @Prusa-Support you said:

This request will remain open on GitHub for the time being.

Just post the link to the sources, then you can close the issue. Doesn't hurt if it takes less than 60 days ;-)

Regarding the discussion about abandoning open source, new license and Chinese clones: Do you really think that what they need is the Bootloader code?

[theacodes]

This issue is still relevant.

In a private conversation with Josef, he indicated that he had some concerns around releasing the source to the bootloader since it may be abused my malicious users. I'm re-affirming my offer to assist in resolving those concerns and taking the time to prep the code for public release.

[JustAnother1]

I'm re-affirming my offer to assist in resolving those concerns and taking the time to prep the code for public release.

I would also be willing to put in work to get the code ready for release.

[Jookia]

It's been a year since I last dropped by. To my knowledge this issue now affects 4 printers: The mini, the mk4, the mk4s and xl. The Prusa website still labels the printers as 100% open source and links to this repository for source code, which isn't available. The public and customers believe these printers are hackable, open source hardware and firmware. People are paying a lot of money for printers that are suppose to be fully open source, and hackable. Currently Prusa is delivering neither. That's not good.

Prusa being so tight lipped about the code being used by bad actors certainly hints that there's some security by obscurity happening. Perhaps it's time to start reverse engineering this bootloader and audit it?

[github-actions[bot]]

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.

[theacodes]

this issue is still relevant

On Sun, Oct 13, 2024, 10:00 PM github-actions[bot] @.***> wrote:

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/1440#issuecomment-2409694447, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5I44R7SUZYPMK7662MN3Z3MQU3AVCNFSM45QWZ3NKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBQHE3DSNBUGQ3Q . You are receiving this because you commented.Message ID: @.***>

[JustAnother1]

Just stumbled over this:

A reason for arguing that the boot loader must be open source is that it shares a common address space with the firmware.

The "communication" between the firmware and the boot loader also works over this shared address space.