Feature changed by: Bryen Yunashko (byunashko) Feature #311039, revision 11 Title: Review of openSUSE Trademark Guidelines openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Bryen Yunashko (byunashko) Partner organization: openSUSE.org Description: 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 (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. Discussion: #1: Alberto Passalacqua (greengeeko) (2011-01-06 17:54:32) Hello, 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 ;-) Best, Alberto #2: Pascal Bleser (pbleser) (2011-01-06 23:54:52) (reply to #1) 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. #5: Alberto Passalacqua (greengeeko) (2011-01-07 16:13:00) (reply to #2) 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. + #8: Bryen Yunashko (byunashko) (2011-01-09 00:30:13) (reply to #2) + 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. :-) #3: Vincent Untz (vuntz) (2011-01-07 15:24:02) (reply to #1) FWIW, Cornelius is working on improving this section :-) #4: Alberto Passalacqua (greengeeko) (2011-01-07 16:01:14) (reply to #3) 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 ;-) #6: Stanley Miller (stan_qaz) (2011-01-07 20:23:48) 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. #7: Vincent Untz (vuntz) (2011-01-07 21:47:24) (reply to #6) 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 :-) -- openSUSE Feature: https://features.opensuse.org/311039