From Official Kodi Wiki
Jump to: navigation, search
Home icon grey.png   ▶ XBMC Foundation ▶ Trademarks ▶ TrademarkGuidance

1 Trademark - Best Practice Guidance

This document is a companion to our main official trademark policy, and serves as some guidance on the application of that policy. It is strongly recommended that interested parties read the main policy and the other documents in the reference list below. The policy laid out in those may be considered official Foundation policy and supercedes any other material.

2 References

3 General Key Points

  • Any proposed usage of the Kodi brand marks must be clear and not misleading to customers in relation to who is offering products, support, services or any other resource. We do not want any public confusion caused.
  • Any usage must not imply partnership, representation, endorsement or affiliation with the XBMC Foundation or the Kodi brand without specific written agreement and permission from the Foundation board.
  • The Kodi brand marks may only be used for marketing and other publicity materials relating to the XBMC Foundation and its direct products.
  • The use of modified or altered versions of our brand marks is not allowed without prior agreement and approval from the Foundation board.
  • Redistribution of unmodified Kodi binaries (including any installer) obtained directly from our download page is acceptable, as long as no fee is charged nor any tie to a subscription, ongoing service or collection of personal information is made.
  • The preferred method of redistribution is by linking to the download section of our main website.
  • Any distribution of modified binary files or associated installers would only be accepted if all useage of Kodi marks and support services (including access to our servers and links to our official addon repository and content) are replaced and the product fully rebranded with no association or link to our brand.
  • No Kodi brand mark may be used in association with media piracy or any other illegal activity.

In case of any question not covered by the reference documents above, please contact the Foundation board via our contact email address - [email protected]

4 Guidance Examples

4.1 Example 1 -

Acceptable - I want to build the official version of Kodi and include it without pre-configured as part of the standard OS image used on all my company laptops. The user will then configure it themselves to their own requirements.

Not Acceptable - I want to build the official version of Kodi and install it onto a batch of generic boxes, set them up including popular addons relevant to the target market and sell them.

Explanation - We do not allow unapproved distribution of pre-configured or modified Kodi installations, even if the modifications are Kodi settings or including addons from the official repo.

4.2 Example 2 -

Acceptable - I want to build the official version of Kodi and include an addon to simplify the set-up networking, shares and other OS level functionality.

Not Acceptable - I want to build and distribute a fork of the official version of Kodi with 3rd party sources enabled by default, without changing anything else.

Explanation - Any configuration add-on should only be for the underlying OS features (beneath and outside of Kodi), and not for modifying Kodi settings themselves. The changing of default settings can easily confuse users as to who is delivering addons and services that they are installing and what source they are using to obtain them. As we do not know who is maintaining such external sources and what their content may be, this is explicitly forbidden and against our policy.

An add-on for manipulating network connections, Bluetooth settings and supporting server-type features like Bonjour, Samba, NFS etc would be acceptable. An add-on which presets sources within Kodi or enabled 3rd party sources by default would not.

4.3 Example 3 -

Acceptable - I want to fork the official version of Kodi and add a new feature/fix. This version will then be distributed for testing purposes, and the modification submitted upstream to for possible PR inclusion into the core code.

Not Acceptable - I want to fork the official version of Kodi and add a new feature/fix and then release fork under the Kodi brand name. This feature/fix will only be included in this version and will not be submitted upstream to

Explanation - We obviously do not want fragmentation to occur, and it is in the open source culture on which Kodi is founded that changes and fixes should be shared upstream with the official maintainers of the code. We aim to provide a cross-platform player with as much of a common feature set as possible.

4.4 Example 4 -

Not acceptable - I want to fork the official version of Kodi and revert or change a fundamental behaviour of the vanilla Kodi version.

Explanation - Again we do not want fragmentation of the code base, nor can we properly support Kodi if there are altered variants available which work in unexpected ways compared to our own version. If we did not make the changes and are unaware of them, we cannot properly support the code in relation to the effects and repercussions of those changes. This can of course also lead to the introduction of issues and resulting negative criticism about which we are entirely innocent.

4.5 Example 5 -

Not acceptable - I want to fork the official version of Kodi and ship it with newer or different versions of its dependent open source libraries.

Explanation - Kodi is reliant on a number of such libraries such as FFMPEG, libdvd and others. The functionality available via their API interfaces can heavily change between versions, and in some cases the distributed binaries have been patched and/or optimised to work most efficiently with the Kodi binary. Hence Kodi can only support those specific versions, and the use of any others may cause unpredictable results or crashes. Any rebranded version of the code released is advised to also use these versions as well.