Rename files and folders and recreate image

Hi My use case is very simple in hindsight. I just need to rename the
3 Content inside those filenames.

For example, keeping case-sensitivity in mind :
jitsi, Jitsi, JITSI become —> myname,Myname,MYNAME
jibri, Jibri, JIBRI etc become —> record,Record,RECORD
jigasi, Jigasi and JIGASI becomes ----> sip_gateway,Sip_gateway, SIP_GATEWAY

and so forth. This is for ease of use purposes and remembering the names easily.

Is there a way to copy the above changes to existing docker files and build the container from base jitsi images. When i move onto building the frontend, I intend to follow the same nomenclature.

Or Do i need to build each Base image for each service and where should i start from?
My primary objective while I’m building is to remember the names as per my convenience
My ultimate objective is to re-brand , sell services and publish the code itself with changes mentioned on GitHub the way it is of course retaining the original license and explicitly crediting the original authors.
This use case is therefore also for those with custom brand name requirement for their respective products.

You will run into problems - TONS of problems. The nomenclature is baked into the code. A lot of function calls in the base code reference those brand names. And I’m not even sure you’re permitted to do this (even if you can) without violating the very generous MIT license.

So we cant even rename the code knowing that we will be eventually publishing it ourselves ? Who can guide me on this ? Can i tag the repo owners ?

In fact it’s the Apache license. Although MIT and Apache are effectively almost the same.

They do permit modification and redistribution/selling of the modified code. What they do not permit is use of the original trademark and failing to provide credit to the original. That is, if we describe it very shortly.

If you modify the code, you need to add the original license (Apache 2.0 license), its authors and explicitly describe what has been changed.

The license is not a strict copyleft one, but you still can’t just take the code away. You can fork the code, change it, re-brand it, etc. You can sell your modified code.

IANAL and I may be wrong on some details. Can you tell us what exactly you want to do (sell, re-brand, close, etc.)?

1 Like

Hi : Thanks for the detailed note.
My ultimate objective is to re-brand , sell services and publish the code itself with changes mentioned on GitHub the way it is of course retaining the original license and explicitly crediting the original authors. My primary objective while I’m building is to remember the names as per my convenience. I just forgot about the license thing while drafting the question. Will put it now.

From a technical standpoint, I’m still not sure how best to achieve this since building the base image for each of web, prosody, jvb, jibri, jigasi etc will be a longer process but not impossible if I’m guided in the right direction.

Just a note: if you just want to create a service using your brand, it will be enough to use the original code and do the customization and whitelabeling/branding on the web platform, not in the code of Jitsi. You can re-brand it and sell the service, and if you replace all the logos and names nobody will tell it is Jitsi underneath.

This way you can keep syncing with the latest upstream code and benefit from all the new features and bugfixes. Most of the branding can be changed through the config files - but even if you need changes in the code, it’s easier to sync your changes to upstream code once in a while, than maintaining a whole fork with a lot of internal variables renamed.

And of course, if you re-brand and customize, you can’t call it “Jitsi”. You should use another name and logo, add the license and mention that it is derived from Jitsi.

1 Like

This part could you clarify ? If i need to change the code itself with renaming files apart from branding ?
If i understand correctly, Since i will be using Docker for my setup , the images need to be pulled from jitsi always right so that i I’m updated with latest bug fixes/changes.
How can i put in my code changes with renames(COPY command maybe?) to jitsi docker images ?

My mistake. Yes, it’s the Apache license.

My point here though is less on the licensing and more on the original stated intent. Changing the nomenclature as described originally is not an easy task. You’d need to make changes to the entire library, not just the web frontend. It appears the OP was looking to erase all mention of “Jitsi”, “Jibri”, “JIgasi” e.t.c. This is a lot of work as there’s cross-pollination between components and of course, their corresponding codes.

Jitsi already offers a rich avenue to rebrand without needing to rename libraries. If the intent is just to whitelabel, this is easily achieved through changes in interface_config and config.js. Going into the backend to remove all traces of “Jitsi” e.t.c. is such a herculean task, it makes no sense whatsoever.

I believe its needed from a commercial perspective when consistency in branding is needed and easier to remember as per your own nomenclature.

The point is you’ll be creating a major headache for yourself. Of course you’re free to do whatever you want to do (within the confines of the very generous license), but what you’re stating demands a lot of manpower and offers minimal benefit. Every time there’s an upgrade - and upgrades are not just aesthetic, there are upgrades that if not done will result in your system not working - you would need to go through that entire process all over again AND capture new code that’s introduced using Jitsi nomenclature. Missing even one of those names risks breaking your system. And it’s uncertain what benefit that effort offers since you have to preserve the original reference in the license to Jitsi. Anyone who is astute enough to go look in the backend will also be able to see that you whitelabelled Jitsi. Just not worth the effort to me.

…but again, of course, this is your choice.

1 Like

Of course yes, the license will be maintained. The intention is to just maintain consistency and remember better while building , not hide the fact that I’m not using Jitsi. I’m a firm believer in open source projects and had it not been for projects like jitsi, i would have to build the whole from scratch. Grateful always. Nevertheless, I’m abandoning the approach and using just branding changes.