Skip to content


Xen.org Trademark Policy For Review

Xen.org Community:

The newly created Xen.org Trademark Policy is now available for review from the Xen Advisory Board. This new policy defines the rules of how the Xen trademark can be leveraged by members of the community as well as commercial offerings. It is available for community review from today, April 1 until April 16, 2008 at which time all comments will be taken into account and the final Trademark Policy published. Please direct all comments to this blog posting or send to legal@xen.org.

FIT Comment – The document refers to the FIT or “Faithful Implementation Test.” This is not yet complete within the Xen Advisory Board but we are actively taking feedback on what would be considered “Xen” as many people take different parts of the hypervisor and use it for their benefit, thus making it difficult to state exactly what “Xen” is.

Format: Microsoft Word – Xen Trademark Policy
Format: Open Office – Xen Trademark Policy


Be Sociable and Share!

Posted in Community, Xen.org Promotion.

Tagged with , , , .


5 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. creilly says

    I like the overall approach you are taking to protect the quality of the Xen Brand and the FIT requirement so that Xen based solutions continue to deliver on the mission of the community.

    I believe you have gone too far with the product naming portion of the proposal. If you look at typical usage of Open Source technology by services and technology companies, you will notice the following usage of the Linux brand in product names

    • Red Hat Enterprise Linux
    • SuSE Linux Enterprise

    SuSE has products that are Xen based but appear to have worked around the trademark by using ZEN rather than Xen. I believe you could create a branding issue with more companies taking a similar approach resulting in a competitive branding situation between ZEN and Xen.

    Xen competes with proprietary solutions and this alone is a steep hill to climb. Companies have the right to use the open source Xen hypervisor in their commercial products and the more who do so will result in more feature rich and higher quality code that can compete with the likes of IBM’s z/VM, VMware, and Hyper-V.

    If this policy is intended to protect the Xen brand for the Xen.org community, one would assume that no commercial offering would be able to use the Xen brand in their product name, including any Citrix Xen based product. Alternatively, if Citrix is the only commercial company allowed to use the Xen brand in a product name, they would effectively have taken the brand for themselves that was built on the backs of the open source community.

  2. Stephen Spector says

    I have received additional feedback on the Trademark Policy and wanted to share the comments with everyone in the community. I will add each item in a separate comment post. Thanks.

    Comment #1 –
    Firstly, the `community-focused offering’ option is not available to major actual community-focused offerings like Debian. This is because Free Software / Open Source Software (aka FLOSS) packages and operating systems are also distributed for a fee by a variety of
    people: if nothing else, there are commercial CD vendors who offer for-fee distribution of FLOSS releases.

    I think this wording arises from what is sadly a common misunderstanding amongst those not entirely familiar with Free Software / Open Source. For software to be Open Source, it is specifically necessary for it to permit commercial use including for-fee distribution. This is one of the criteria in the Open Source Definition, the FSF’s Free Software Defintion, the Debian Free Software Guidelines, and so on.

    There is nothing wrong with distributing Free Software for a fee. Indeed the Free Software Foundation’s stated intent certainly used to be that they wanted to be the most expensive provider of GNU CDs :-) .

    What Open Source does not allow is preventing onward sharing: this naturally imposes a limit on how much a distributor can charge because they can always be undercut (by their own customers if need be); this is prevented in proprietary software by the imposition of license fees (backed by copyright law’s prohibition of unauthorized sharing).

    So this issue could be resolved by replacing the words
    … that is distributed without any fee, …
    with
    … that is distributed without any license fee, …
    in the Definitions (near the top of page 2 of the OpenOffice file).

    Without the above change, a serious Free Software project which ships a version of Xen is dependent on the item no.1 in the list of Usage Guidelines, which says that Users are always permitted to use, nominatively, the word XEN to
    truthfully refer to the presence of Xen technology in products without permission from Citrix

    This provision is important and useful but it is somewhat difficult to understand whether any of the other restrictions in the document apply. By my reading they do not (after all, it says `always’). But doubt is not helpful and may lead to difficulty.

  3. Stephen Spector says

    Comment#2:
    There is a problem with the new restriction on using `Xen’
    for related products. There are two kinds of such uses which I think are relevant:

    The first kind of use is best exemplified by the names of Linux dom0 and domU kernel packages for operating systems. These are invariably called `linux…xen…’ or some such. As I read the policy, such a use is nowadays completely excluded.

    In the case of the kernel it is currently technically essential to have a special version of the kernel patched and configured specifically to run with Xen at least for dom0, and this will be the case for some time. These kernels, and the special domU kernels, are called by everyone `Xen kernels’.

    There has also been a requirement at times to run a special libc. Likewise, those libc packages are called glibc…xen… or the like.

    There have also been adaptations of (or supplements to) existing software to make them work with Xen. For example, I don’t know much about libvirt but it will have an adaptation module or layer which talks to Xen; and that module should have `xen’ in its name to avoid confusion. In this case there is no actual Xen contained in the adaptation packages (so the nominative use permission does not apply), although when they are installed and working the whole system certainly does contain Xen.

    It is important for users that these packages retain the word `xen’ in the name. That makes it much more likely that they will be found when needed. Without them, Xen won’t work at all or will perform very poorly, or will not interoperate with the user’s application, so it is in our interests to ensure that they are found.

    So I would suggest writing a specific exception for these cases, even if it is felt that dropping the restriction entirely (for the reasons I’m about to give) is a bad idea.

    The second kind of use, which is what the provision is actually aimed at, is all of the existing and contemplated projects called `Xen Foo’ which are some kind of enhancement or extension for Xen, or an application which uses Xen, or some such.

    There are two problems with the new rule that these programs can’t be called `Xen Foo’. The problems are easily exemplified by the position of the Debian `xen-tools’ package, which is a collection of utilities for installing and managing Xen guests on Debian systems.

    The first problem is that the new policy is asking Debian to rename their xen-tools package. This kind of thing is very annoying. It is pointless effort: the package maintainer has to change the name and manage the transition, the users have to change their wrapper scripts and move their configuration files, perhaps even Xen domains and LVM volumes will end up being renamed, and so on. Asking for this kind of change generates great irritation and badwill.

    Also, since Debian has been using the name xen-tools for all of this time without any explicit permission, Debian may well feel that Xensource and Citrix have lost the right to demand now that they desist. So there may be a messy dispute too (more badwill).

    The second problem is that there is no good alternative name. It is best, for people to be able to find programs which are extensions to Xen or intended to be used with it, for those programs have some key word in their names. That key word should be the same for all such programs and should be clearly identified with the Xen hypervisor itself. Currently the word `Xen’ is used for this.

    If the plan is indeed to require that the word `Xen’ not be used in this way, what are developers of programs like xen-tools supposed to do ?

    Even if the Advisory Board picks a new word for the purpose and promulgates it we’re left with a painful process of renaming.

    So I think this new restriction is a mistake and will cause problems.

    It could be solved for the existing users by having either those projects explicitly blessed, or by having a grandfather clause (`all projects which were using the name before 1 Nov 2007 …’).

  4. Stephen Spector says

    Here are my thoughts on the two comments that I just posted from a community member:

    Comment #1 Thoughts:
    I agree with the thinking and believe that the agreement should be modified as suggested or in a similar manner to ensure that the intention of FLOSS is not broken. I have asked legal to update the policy based on this concept.

    Comment#2 Thoughts:
    The intention is not to interfere with the use of Xen within code as described. I have asked legal to modify the policy to ensure that there is no confusion on this point.

    As for the initial comment from creilly I have asked legal to respond and will post that information once it arrives in my email box.

    Thanks again for all the great community response and I will continue to be transparent in all feedback.

  5. mark says

    First of all, thanks for opening up the trademark policy for review.

    I agree with the other commenters, that it will be a huge hassle and point of confusion if community-based projects and packages can no longer include the Xen name. There simply isn’t another name to substitute for Xen that would be widely understood at this point.

    Its hard to comment on the rest of the trademark policy because most of it hinges on the Faithful Implementation Test, which is not yet available. To me it seems overly-complicated for so many provisions in the trademark policy to refer to the FIT, I hope that the FIT can be simple enough to be merged into the trademark policy itself.

    For comparison’s sake, I tried to find the OpenVZ trademark policy but could not find one. This leads me to believe that there isn’t one, and SWSoft/Parallels allows any commercial or community offering to use the name OpenVZ. Their situation is a bit different since their open source project and commercial product have names that are more distinct. Maybe Citrix will do something similar and allow free use of a new name such as “OpenXen” or “XenCommunity”

You must be logged in to post a comment.