Mailinglist Archive: opensuse-features (86 mails)

< Previous Next >
[openFATE 311039] Review of openSUSE Trademark Guidelines
Feature changed by: Vincent Untz (vuntz)
Feature #311039, revision 10
Title: Review of openSUSE Trademark Guidelines Unconfirmed
Requester: Important

Requested by: Bryen Yunashko (byunashko)
Partner organization:

This feature request is meant to collect the comments of the community
at large The current guidlines can be found here
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.

#1: Alberto Passalacqua (greengeeko) (2011-01-06 17:54:32)
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 ;-)

#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
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.

#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
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:

< Previous Next >
List Navigation
This Thread