Original Music Publishers

Django Music Publisher supports only one original publisher, and no administrators or sub-publishers. And this will never change. If you want to find more, click on the video thumbnail below. In this article, the reasons for this limitation will be covered in depth.

Free software must be self-explanatory for most of the target users. Otherwise, it will fail. As stated in the video, the data for administrators is far more complex, and even more so for sub-publishers. As will become obvious pretty soon, the last use case is definitely beyond self-explanatory.


Let us start with explaining a simple CWR registration, in the screenshot above. (All values are made up or random, similarity to any real publisher or writer was not intended.) If you have never seen a CWR file, this will be confusing, but if you work in music publishing, it will only take a few seconds to figure out the basics.

The first line (NWR) tells us the title and several technicalities about this work. The second and third lines (SPU, SPT) tells us who the original publisher is and what shares they own and collect worldwide. The next three (SWR, SWT, PWR) lines tell us about the author and what shares she owns and collects and that her original publisher is the one from lines two and three.

Ok, let us have a look at the same work with data about the administrator and only three sub-publishers. Please have a good look before the very detailed explanation below.


Don’t worry, it was just a joke. Let us just conclude that the first and the last three lines are about the same, while there are many additional lines in between. And this is a very simple case, covering only Germany, Poland and the UK.

Today, on average, one registration for one work is around 100 lines long, and there are registrations that are over 1000 lines long, while the original registration is only about 10 lines.

I think that makes it obvious if someone has to deal with as much complexity in a software solution, a user manual is not enough. Not by a longshot. So, it is not the development that is costly, it is user support. Everyone will use it, some just for a while, and some on a regular basis.

Ok, then, what about administrators? It can’t be that much complicated, right?

No, actually, it is not that much complicated. While everything else remains about the same, one Writer In Work line in DMP:


we must have all these fields, at least, if we want to have administrators and original publishers:


This is too complex to be self-explanatory. And, in both cases, there is only a single “relative/manuscript share” field. For a real administration software, there should be at least 6 fields here.

But, when it comes to DMP, this will not change either. With DMP 20 Twenty, one can set global agreement details, so it is no longer fixed at 50/100/100. But there will only be one field with shares per writer in work.

Do I believe that all publishers should have only one original agreement template? Well, no. Not all of them. But, DMP is not for all of them. Just for those who want to keep things simple.

The third major limitation is that DMP does not support medleys and other recording types based on multiple musical works. While I do plan to add more features for labels to DMP, this is not likely to change in the foreseeable future.