Talk:Trademark usage and Branding guideline

From Genunix

1 OpenSolaris Trademark Usage Guidelines DISCUSSION
2 What is the output of the community?
3 What is Sun's productization of the community's distro like?
4 What about remixes?
5 What about Nevada, SXCE and SXDE?
6 What about Schillix, Martux and Belenix?
7 What about Nexenta and other commercial distros?
8 Parking Lot issues

OpenSolaris Trademark Usage Guidelines DISCUSSION

Document Version History

   Draft 0.16 - Move FAQ/Background/rationale to Trademark_usage_and_Branding_Background
   Draft 0.15 - Added outline of ecosystem
   Draft 0.14 - Rewrite with style and phrasing input from the Mozilla and Ubuntu policies
                while keeping the key issues, points and goals of Draft 0.13  
   Draft 0.13 - Updated with comments from John S concerning a minimalist core.    
   Draft 0.12 - Updated with comments from John S and Shawn W.    
   Draft 0.11 - Updated with comments from Justin Erenkrantz.    
   Draft 0.10 - Updated to reflect Sun's policies regarding the OpenSolaris brand.    
   Draft 0.09 - Simplified page by moveing context and background to the Trademark_and_Branding_Project_Proposal page.
   Draft 0.08 - moved commentary and discussion to the associated Talk page
   Draft 0.07 - Added BillS's comments on "why branding" and overuse of the word distro
   Draft 0.06 - Added operational definition for OpenSolaris, move trademark observations
   Draft 0.05 - incorporate Brandor's comments - no single OpenSolaris distro, no binary package reuse requirements
   Draft 0.04 - added Joerg's comments re: OpenSolaris := ON, simplified wording, removed "___ OpenSolaris" because it would violate trademark requirements if used as 'IBM OpenSolaris'

The following use-cases need to be addressed:

[edit]

What is the output of the community?

Assertion: A base distro that contains a minimum of

A mechanism to boot the OS
A mechanism to enumerate and configure whatever hardware devices are in the system that will be used to access storage (disks) and the network
A mechanism to install the OS and related/chosen software from the distribution media and/or the network repositories that make up the OpenSolaris ecosystem.
an (optional) set of cached packages as found in the official OpenSolaris repositories.

[edit]

What is Sun's productization of the community's distro like?

Assertion:

it will either be an EXACT COPY of the community release, or
it will be a "remix" style derivative of the community's work product in that it will contain
- some cached set of packages from the OpenSolaris repository
- some cached set of packages from other repositories
- some configuration, artwork and installation choices that differ in some way from the Community distribution.
- it will be named in a way that will differentiate it from the community's release

[edit]

What about remixes?

Open Issues:

CLARIFY: What do we do between NOW and the time the new distro constructor technologies are ARC'd, integrated into one of the OS.o consolidations and are generally available?

[edit]

What about Nevada, SXCE and SXDE?

[edit]

What about Schillix, Martux and Belenix?

I assume these will either follow the remix path or the "don't choose to use the OpenSolaris brand name" path.

[edit]

What about Nexenta and other commercial distros?

I presume they will either pursue a license with Sun to use the trademark or will choose to not use it at all.

Open Issues:

CLARIFY: What is Sun's position on commercial distributions using one of the OpenSolaris trademarks?
Question: Would Sun's product be made from exactly the bits in "The Official

   OpenSolaris repository" (no less but definitely also no more)? 
   This touches on a naming conundrum :
     * If Sun takes the output of Indiana and produces a distribution that 
       is a superset, how are the two things going to be disambiguated?
     * If someone else takes the output of Indiana and produces a distribution 
       that is a superset, how is their artifact disambiguated?
     * If parts of OpenSolaris are not OpenSource/redistributable, how can others
       legally redistribute copies?
   This still needs thought and an answer: there are some choices to make, not dictated by TM law

[edit]

Parking Lot issues

These issues need to be addressed before this set of guidelines can be considered "final draft" form

[edit]

Parking lot item: Define Distro as a reference platform

AlanC suggests

If we are going to endorse a distro as our reference or blessed or whatever distro, what are the requirements it has to meet? Here's a list of ones I can think of to start discussing from:
100% Open Source: The OpenSolaris Constitution, as approved by the voting members of the community and the Solaris management at Sun, requires that All software produced by the OpenSolaris Community shall be licensed to the public free of charge under one or more open source licenses approved by the Open Source Initiative.
Decisions about the distro will all be made by an OpenSolaris community group in accordance with the constitution (which can be oversimplified down to "just do it" for simple/obvious things, "quick e-mail consensus" when the answer isn't so clear, "formal vote" for the important things. See Article VIII for the full details).
All components architecturally reviewed in the open by the process and groups established by the OpenSolaris Architecture Process and Tools community.
Supports the platforms designated as Core Platforms by a community process TBD (initially SPARC 4u/4v & x86/x64).
At the moment, I don't know of any distro that meets all of these, not even Indiana, though it and a couple others may be able to achieve them with a bit of work. Software that didn't meet those rules (closed source binaries, NDA covering ARC review) could still be installed on the distro, but couldn't be a core part of it.

Jörg added:

a reference distribution needs to include everything that allows a self hosted compilation and porting to new platforms.

[edit]

Parking lot item: Define Core

We need to define what is in this Core. We don't need the definition right now, but we will before we can actually use the mark on a distro.

Joerg suggests that it may be worthwhile to start with the definition of "Core := ON" and evolve from there.

John thinks that we will quickly find that we need Core to include more than simply ON+bootloader+shell. He also feels that a definition that utilizes the new packaging system, recipes and repositories would be a good thing.

Brian feels that an extreme minimalist definition would be useful for appliance and device style distros.

It may be that the practical definition (... the base that ISVs can count on...) is a superset comprised out of precise technical ones (= kernel + libc + ...?...)

Kupfer wants to know if we can just ask a bunch of ISVs what they'd like to see in a core, and what variations do they expect to have to deal with (e.g., GNOME vs KDE).

Need to deal with edge cases such as "x64 doesn't use SPARC OpenBoot, PowerPC uses different/modified low level kernel files", yet all should be able to be in the Core

[edit]

Parking lot item: Define Compatibility Test Suite

As above, presume that this is something like "did you build it with the Core recipe using the official OpenSolaris packages?", but with actual for the actual behaviors.

Brandorr wrote: A compatibility test might consist of a installing and running a given set of SYSV packages, plus running a slew of OS commands to verify that the behavior came out as expected. Need to work in SLau & SPhipps comments re: being able to install and run packages fount in OpenSolaris repositories on all opensolaris distros...

[edit]