debian-project
[Arriba] [Todas las Listas]

Licencias de marca y DFSG: un resumen

To: debian-project@xxxxxxxxxxxxxxxx
Subject: Licencias de marca y DFSG: un resumen
From: Stefano Zacchiroli <leader@xxxxxxxxxx>
Date: Sun, 19 Feb 2012 17:57:54 +0100
Delivered-to: lists-debian-project@xxxxxxxxxxxxxxxx
Delivery-date: Sun, 19 Feb 2012 11:58:24 -0500
Envelope-to: listas@xxxxxxxxxxx
In-reply-to: <20111009180201.GA11566@upsilon.cc>
List-help: <mailto:debian-project-request@lists.debian.org?subject=help>
List-id: <debian-project.lists.debian.org>
List-post: <mailto:debian-project@lists.debian.org>
List-subscribe: <mailto:debian-project-request@lists.debian.org?subject=subscribe>
List-unsubscribe: <mailto:debian-project-request@lists.debian.org?subject=unsubscribe>
Old-return-path: <zack@xxxxxxxxxx>
References: <20111009180201.GA11566@upsilon.cc>
Resent-date: Sun, 19 Feb 2012 16:58:45 +0000 (UTC)
Resent-from: debian-project@xxxxxxxxxxxxxxxx
Resent-message-id: <yFpEsdTljdH.A.sIB.FpSQPB@liszt>
Resent-sender: debian-project-request@xxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
Dejado ver si, una vez otra vez, podemos hacer "un un hilo" de resumen un orden de la
magnitud más grande que el hilo original. Para más contexto (y comparación!)
Puedes encontrar el hilo original en

  *http://listas.*debian.*org/*debian-Proyecto/2011/10/*msg00028.*html

En Sol, *Oct 09, 2011 en 08:02:01PM +0200, *Stefano *Zacchiroli escribió:
> […] necesitamos hablar nuestro general *stance en marcas y el impacto
> que licencias de marca (tener que) tiene en el contenido del *Debian
> *archive.

Varios puntos importantes han sido levantados en la discusión, dejado inicio
con:

un) si o no *Debian las prácticas podrían causar marca *infringement
*b) la función de marca-como restricciones en el *DFSG

Con respecto a (un), he buscado y consejo legal obtenido. He informado
sobre él en [1]. Si confiamos en tal consejo---y no veo ninguna razón no
a---*Debian las prácticas podrían causar marca *infringements en varias
maneras que incluyen: nombres de paquete, usuario nombres de aplicación visible, iconos,
*logos, *etc. *OTOH En la mayoría de casos parece seguro de considerar detalles de implementación
"de nivel bajos", como caminos de instalación, para ser fuera del
*realm de lo que ley de marca es significada para proteger.

En (*b), sabemos que *DFSG §4 "Integridad de la Fuente del Autor el Código"
explícitamente deja autores para requerir nombre o cambio de versión para
distribuir trabajos derivados. Según Bruce *Perens [2], el
*underlying el principio era para dejar autores para dirigir y defender sus
marcas, *cuando mucho tiempo tan* hay una manera fuera de (*e.*g. Un *re-*branded versión
de software) que es libre según el otro *DFSG requisitos. La letra
de *DFSG §4, desafortunadamente, sólo menciona nombre de software y versión.
Si aceptamos el propuesto *underlying principio, haría
sentido para extender la interpretación de *DFSG §4 a también cubrir los
otros elementos típicamente protegidos por marcas como *logos, iconos, imágenes,
y diseños visuales.

A la vez, incluso cuándo somos *#dejar* para mantener algo marca
*encumbered en el *archive sin *rebranding (tampoco porque lo distribuimos *unchanged, o porque la política de marca asociada es
bien con la clase de cambios somos #interesar), todavía podríamos tener
interés en *rebranding. En particular, tenemos que muy cuidadosamente evaluar
el riesgo de teniendo que hacer el *rebranding más tarde en durante el marco de tiempo
del apoyo de una liberación de cuadra (cuál es una cosa dolorosa para hacer), y decidir
qué para hacer *accordingly.

[1] *http://listas.*debian.*org/*debian-Proyecto/2012/02/*msg00071.*html
[2] *http://listas.*debian.*org/*debian-Proyecto/2005/08/*msg00069.*html
    Gracias a *MJ Rayo para señalar esto fuera de la


Propuesta
========

Basada en todo el *feedback recibió así lejos y en las consideraciones
encima, aquí es un diferente (mejorado?) Propuesta en cómo para tratar
marca *encumbered software en el *Debian *archive.

- Estamos de acuerdo que *DFSG §4 deja licencias para pedir cambios de nombre,
  versión, también cuando otro distinguiendo marcas para distribuir
  trabajos derivados

  (yo.*e. Aceptamos la interpretación del *underlying principio de *DFSG
  §4 propuesto en [2]. Nota "que la licencia" encima es utilizada en plazos
  generales, porque muchos de ti correctamente señalado fuera de aquel *DFSG cuidado sobre
  libertades bastante que monopolio mundial específico derechos.)

- A la vez, *DFSG §4 no *deja licencias para pedir cambios
  en detalles de implementación que  no impacto en el autor o el software que
  distinguen marcas, ningún asunto lo que publicó políticas de marca dicen.

  (Sugerido por *MJ Rayo.)

- *Debian Tampoco tendría que buscar ni aceptar licencias de marca que son
  específico al *Debian Proyecto.

  (Sugerido por Steve *Langasek. Además del razonamiento de Steve, pienso que haciendo *otherwise iría contra el *underlying principio
  de *DFSG §8 "Licencia No Tiene que Ser Específica a *Debian".)

- Para marca *encumbered software que podría en un punto dado en tiempo
  ser distribuido sin *rebranding, *maintainers cuidadosamente tendría que
  evaluar el riesgo de teniendo que *rebrand les más tarde encima, y buscar consejo
  de los equipos que serían *impacted por *impromptu *rebranding (*e.*g.:
  Equipo de seguridad, equipo de liberación, *ftp-maestros).


La Discusión que
==========

Pasa por el encima, sospecho que la primera provisión (extendiendo
*DFSG §4) podría ser *controversial. Pero el más pienso de él, el más
convencido soy que sería en el espíritu del actual *wording de *DFSG
§4, cuando *hinted por el título de *DFSG §4. De hecho, rebautizando sólo es
ya la mayoría de caso común de marca-como restricción y estando de acuerdo
extenderlo a las marcas visuales no cambiarían cualquier cosa en plazo de restricciones
reales en nuestros usuarios.

La segunda provisión es lo que garantizará no sencillamente aceptamos cualquier
exageración que los autores podrían ser *willing para escribir abajo en políticas
de marca. Ya tenemos algunos consejo general sobre lo que es aceptable
y lo que no es; si la necesidad surge, podemos imaginar pedir más
software-consejo legal específico antes de proceder.

Formalmente, mientras podríamos votar en todo esto, todavía espero podemos converger
por discusión y consenso. Si nosotros , podríamos puesto que caso *summarize
todo esto en una declaración de posición y publicarlo *somewhere en el *Debian
*website.


Seré *eagerly esperando para vuestros comentarios!
Aclama.
-- 
*Stefano *Zacchiroli     *zack#unknown{^*upsilon.*cc,*pps.*jussieu.*fr,*debian.*org} . *o .
*Maître *de   *conférences ......   *http://*upsilon.*cc/*zack   ......   . . *o
*Debian Dirigente de proyecto    .......   @*zack En *identi.*ca   .......    *o *o *o
« La primera regla de *tautology el club es la primera regla de *tautology club »
Let's see if, once again, we can make a "a summary" thread an order of
magnitude larger than the original thread. For more context (and
comparison!) you can find the original thread at

  http://lists.debian.org/debian-project/2011/10/msg00028.html

On Sun, Oct 09, 2011 at 08:02:01PM +0200, Stefano Zacchiroli wrote:
> […] we need to discuss our general stance on trademarks and the impact
> that trademark licenses (should) have on the content of the Debian
> archive.

Several important points have been raised in the discussion, let's start
with:

a) whether or not Debian practices could cause trademark infringement
b) the role of trademark-like restrictions in the DFSG

Regarding (a), I've sought and obtained legal advice. I've reported
about it in [1]. If we trust such advice---and I see no reason not
to---Debian practices could cause trademark infringements in various
ways including: package names, user visible application names, icons,
logos, etc. OTOH in most cases it seems safe to consider low level
"implementation details", such as installation paths, to be outside the
realm of what trademark law is meant to protect.

On (b), we know that DFSG §4 "Integrity of The Author's Source Code"
explicitly allows authors to require name or version change for
distributing derived works. According to Bruce Perens [2], the
underlying principle was to allow authors to manage and defend their
marks, *as long as* there is a way out (e.g. a re-branded software
version) that is free according to the other DFSG requirements. The
letter of DFSG §4, unfortunately, only mentions software name and
version. If we accept the proposed underlying principle, it would make
sense to extend the interpretation of DFSG §4 to also cover the other
elements typically protected by trademarks such as logos, icons, images,
and visual designs.

At the same time, even when we are *allowed* to keep something trademark
encumbered in the archive without rebranding (either because we
distribute it unchanged, or because the associated trademark policy is
fine with the kind of changes we're interested), we might still have
interest in rebranding. In particular, we should very carefully evaluate
the risk of having to do the rebranding later on during the support time
frame of a stable release (which is a painful thing to do), and decide
what to do accordingly.

[1] http://lists.debian.org/debian-project/2012/02/msg00071.html
[2] http://lists.debian.org/debian-project/2005/08/msg00069.html
    thanks to MJ Ray for pointing this out


Proposal
========

Based on all the feedback received thus far and on the considerations
above, here is an different (improved?) proposal on how to deal with
trademark encumbered software in the Debian archive.

- We agree that DFSG §4 allows licenses to request changes of name,
  version, as well as other distinguishing marks for distributing
  derived works

  (I.e. we accept the interpretation of the underlying principle of DFSG
  §4 proposed in [2]. Note that "license" above is used in general
  terms, because many of you correctly pointed out that DFSG care about
  freedoms rather than specific world-wide monopoly rights.)

- At the same time, DFSG §4 does *not* allow licenses to request changes
  in implementation details that do not impact on author or software
  distinguishing marks, no matter what published trademark policies say.

  (Suggested by MJ Ray.)

- Debian should neither seek nor accept trademark licenses that are
  specific to the Debian Project.

  (Suggested by Steve Langasek. In addition to Steve's reasoning, I
  think that doing otherwise would go against the underlying principle
  of DFSG §8 "License Must Not Be Specific to Debian".)

- For trademark encumbered software that could at a given point in time
  be distributed without rebranding, maintainers should carefully
  evaluate the risk of having to rebrand them later on, and seek advice
  from the teams that would be impacted by impromptu rebranding (e.g.:
  security team, release team, ftp-masters).


Discussion
==========

Going through the above, I suspect that the first provision (extending
DFSG §4) might be controversial. But the more I think of it, the more
convinced I am that it'd be in the spirit of the current wording of DFSG
§4, as hinted by the title of DFSG §4. In fact, renaming alone is
already the most common case of trademark-like restriction and agreeing
to extend it to visual marks wouldn't change anything in term of actual
restrictions on our users.

The second provision is what will guarantee we won't simply accept any
exaggeration that authors might be willing to write down in trademark
policies. We already have some general advice about what is acceptable
and what is not; if the need arises, we can imagine asking for more
software-specific legal advice before proceeding.

Formally, while we could vote on all this, I still hope we can converge
by discussion and consensus. If we do, we could for instance summarize
all this in a position statement and publish it somewhere on the Debian
website.


I'll be eagerly waiting for your comments!
Cheers.
-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

<<signature.asc>>

<Anterior por Tema] Tema Actual [Siguiente por Tema>