Home_greyopenFATE - openSUSE feature tracking > #311039
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Review of openSUSE Trademark Guidelines

Feature state



This feature request is meant to collect the comments of the community at large The current guidlines can be found here
http://en.opensuse.org/OpenSUSE_Trademark_Guidelines The openSUSE Board will review comments posted here along with concerns and considerations collected elsewhere and find ways to strengthen/clarify the guidelines.

Please review the current guidelines and post comments on language. (Giving specific language change suggestions is helpful) and if you have specific cases where current guidelines have been a problem, please post here as well.


icons/user_comment.png A. P. wrote: (7 years ago)


first of all, thank you for bringing this problem up. I feel it blocks contributions concerning derivatives, or, at least, it did with me.

My major concern is the section "Distributing openSUSE With Project-Based Modifications". According to this section, a distribution with only openSUSE packages created in Studio must be de-branded, if one package has been added to the default installation. This basically translates in de-branding all the distributions created in Studio, since they do not reflect the default installation pattern.

I would also suggest to create a review process for the "Distributing openSUSE With All Other Modification" section. I try to explain this with an example. Let us assume I create a default openSUSE system, and I add an open source (GPL or compatible) application with file overlay, and I would like to create a derivative within the openSUSE project (like, for example, openSUSE medical, which did it, but it is not clear how). This could be very positive marketing for openSUSE, and would potentially help in attracting more user, and pay back a bit of the resources offered through Studio and OBS.

The review process should be simple: a set of a few clear requirements the contributor has to follow (for example: only GPL, no profit, no copyright infringment, ...), and the approval should be granted by the board or automatically, with the possibility of ask for changes to comply. Please, no long lists of rules, because it just would not cut it ;-)



icons/user_comment.png P. B. wrote: (7 years ago)

Couldn't agree more on all those points, and the current rules are often in the way as well as not precise enough. But when they have been set up initially, it was clear that they were just a "first version" which would have to be perfected in the future. We've failed to do so up to now.

I believe that even more than "good" use cases, it would be even more interesting to scratch our head about "bad" use cases (anti-patterns, if you will, to use software development language) because as much as all of us want it to be as clear, permissive and simple as possible, we must also think of the cases of abuse those rules must prevent.

icons/user_comment.png A. P. wrote: (7 years ago)

I agree in finding "bad cases". There are borderline situations too, which is not clear to me how to manage.
Among obvious "bad cases":
- The distribution contains software that does not comply with GPL.
- The distribution uses a name, theme or has a goal that might be offensive.
- The distribution includes software that might infringe patents/copyrights. This brings to the question: can we include codecs? graphical drivers? flash? adobe reader?
Some borderline situation:

- The distribution is a duplicate of another effort. In other words, we want derivatives, but we do not want to favour the multiplication of distributions if not necessary. In this case we should provide some example to be more specific. For example: if a distribution uses different software stacks to achieve the same task, then it is probably fine. If it is just a duplication, at that point it does not make much sense to me, and it is not promotion for openSUSE. Probably it would fall in the copyright violation anyway, if the authors of the first distribution achieving the task put a copyright on it.

icons/user_comment.png C. S. wrote: (7 years ago)

License violations, copyright infringements, patents all don't fall under the trademark question. These are separate issues and should be handled separately. I don't think it would be good to cover that in the trademark guidelines.
Offensiveness I think is already covered by the trademark guidelines, or can you think of an offensive way to use the openSUSE trademark, which is compatible with the current guidelines?

Duplication of efforts really is borderline, and probably out of the scope of the trademark guidelines as well. This is more a culture and process problem. To some degree duplication can also be a good thing.

icons/user_comment.png B. Y. wrote: (7 years ago)

Bad use of wording on my part. When I said good use cases, I meant good examples of both bad and good instances. :-) it's the BAD ones we really want to hear about more than the GOOD ones. :-)

icons/user_comment.png V. U. wrote: (7 years ago)

FWIW, Cornelius is working on improving this section :-)

icons/user_comment.png A. P. wrote: (7 years ago)

Yes, but since we are the "consumers" of the section, it would be nice to know what's going on, and help where possible. This way we avoid repetition of work ;-)

icons/user_comment.png B. Y. wrote: (7 years ago)

Yes. Already reached out to each other and hoping we can incorporate our findings.

icons/user_comment.png C. S. wrote: (7 years ago)

As I said in my other comment, I'm working on a proposal, how to make it more easy to use openSUSE branding for derivatives.

It still would be nice to have a review process for cases, where this is not enough yet, e.g. when a derivative wants very close association with openSUSE. like for example the openSUSE Education project. But I would consider the process itself to be out of the scope of the trademark guidelines itself and leave it to the judgement of the group which grants special permission to the trademark. It still would be nice to document it, of course, but I suppose it can be done in a little bit less formal and more flexible way than the actual trademark guidelines.

icons/user_comment.png S. M. wrote: (7 years ago)

My main concern is that the OpenSUSE official distribution be easily recognized as such and any derivatives, subsets or supersets be easily distinguished from the official version. Alberto's suggestions on targeted distributions like Medical and Education is worth considering.

Would it be possible to make de-branding a distribution a simple process where the creator could switch out the official branding for pre-configured branding for some of the variations ("Uses openSUSE","Compatible with openSUSE", "Powered by openSUSE") so that branding changes weren't much of a problem?

If debranding could be automated in the build service so that any build that didn't follow the official rules for using it that might also help enforce the policy.

icons/user_comment.png V. U. wrote: (7 years ago)

We do have branding-openSUSE packages, and the idea would be to not use those packages but some others that would basically say "Powered by openSUSE".

Cornelius will be able to share more details :-)

icons/user_comment.png R. D. wrote: (7 years ago)

I think what we need here is a visible chart showing where this organization stands. I know we belong to Novell, but we also have to delineate our openSUSE organization with offshoots such as education, medical, etc.

As for other software entering the openSUSE fold, yeah, "Powered by openSUSE" would be great. Also, that they abide by the official rules already in place.

Making money comes to mind. What are we going to be selling under the openSUSE brand name? We could use business shirts, laptops, coffee mugs, instruction manuals. I'm beginning to think you guys like being poor. I for one would buy business shirts with openSUSE logo, supped up laptops with the latest SUSE, etc.

Rod Donovan

icons/user_comment.png C. S. wrote: (7 years ago)

The proposal I'm working on is to have a distinct "powered by openSUSE" branding, which can liberally used by openSUSE derivatives. This way we keep the unique official openSUSE brand for the official distribution, but allow distributions and appliances based on openSUSE to identify and promote the relationship with openSUSE using the "powered by openSUSE" branding.
The rules for the "powered by openSUSE" branding would be much more relaxed than the ones we currently have in the trademark guidelines, so that people actually can easily use it without needing to manually get permission to use it for everything. Of course there still would be limitations, like not using the branding in a confusing way or for purposes going against the openSUSE project, etc.

In addition to that there are a couple of clarifications and simplifications which can be done to the guidelines, but that's mostly minor stuff.

icons/user_comment.png S. C. wrote: (7 years ago)

With every new release we all see the boot screen change colour and shape. Image association with product is currently a nightmare for the best marketing agent to fix. We are not consistent with Font, Colour, Graphics and their maintenance. Have a look at the boxed version of 10.1-10.2 - The beautiful Lizard on the boxed set should have been kept - It was seriously good.
From a marketing perspective we don’t have a recognisable brand, images, colour, fonts, layouts,slogans and once we either adopt trademarks or not, we need serious marketing and graphic designers help.
I know this is not a big deal but I would love the default installation of ANY browser, from the OpenSuse ISO, to carry a selection of OpenSuse stationery. Likewise I would like to see all our mainstream email clients all carry a selection of our stationery. We truely are in a mess as far as product branding and associated slogans and naming conventions. We have no Identity for market because we keep changing everything and there is no continuity
Email Stationery, Browser Stationery

Last change: 7 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint