debian-project
[Arriba] [Todas las Listas]

Re: Licencias de marca y DFSG

To: debian-project@xxxxxxxxxxxxxxxx
Subject: Re: Licencias de marca y DFSG
From: Stefano Zacchiroli <leader@xxxxxxxxxx>
Date: Sat, 18 Feb 2012 19:32:02 +0100
Delivered-to: lists-debian-project@xxxxxxxxxxxxxxxx
Delivery-date: Sat, 18 Feb 2012 13:32:29 -0500
Envelope-to: listas@xxxxxxxxxxx
In-reply-to: <20111010002841.GB3594@virgil.dodds.net>
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> <20111010002841.GB3594@virgil.dodds.net>
Resent-date: Sat, 18 Feb 2012 18:32:51 +0000 (UTC)
Resent-from: debian-project@xxxxxxxxxxxxxxxx
Resent-message-id: <tUCQL4saRlE.A.PeB.T7-PPB@liszt>
Resent-sender: debian-project-request@xxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
En Sol, *Oct 09, 2011 en 05:28:41PM -0700, Steve *Langasek escribió:
> Tiene el proyecto recibido el consejo legal competente que declara que un nombre de paquete
> sería interpretado como *infringing una marca, y que lo podríamos
> tener que rebautizar?

Ahora hemos recibido #un consejo tan legal. De hecho conseguíamos dos que
(increíblemente bastante) está de acuerdo. Considero ambos de ellos para "ser piezas"
competentes de consejo cuando vienen de SPI actual y anterior abogados que
*routinely trabajo en asuntos de marca en *behalf de proyectos de Software Libre.
Ambos abogados eran *knowledgeable en ley de marca de los EE.UU., y han puesto
adelante que sesgo.

Abajo puedes encontrar un resumen de lo que tenemos. El Texto citado es un
esbozo de las consultas he entregado. Todo más es mi comprensión
propia de abogados' las respuestas y yo tomarán la culpa para cualquier
*inaccuracy en el resumen. Cuando a menudo pasa con abogados (y para
razones buenas), es muy difícil de conseguir *definitive respuestas, así que tendrías que imaginar un grande *flashing "LO DEPENDE, PERO" antes de que cada respuesta.

-----------------------------------------------------------------------
> - Puede políticas de marca restringen:
>   - nombres de paquete en el *Debian *archive?
>   - Nombres de programa en las cartas mostradas al usuario?
>   - Más abajo-detalles de nivel como *executable nombres o instalación
>     de programa caminos?

El principio general es que todo que podría causar confusión
entre los usuarios sobre el "producto" están consiguiendo o utilizando podría
inducir marca *violations. *Instantiating El principio al encima
tres ejemplos da:

- nombres de paquete  fácilmente *violate marcas, cuando son los nombres utilizados
  por *Debian usuarios para encontrar e instalar software
- igual va para nombre y *logos en cartas
- *ditto para el principal *cmdline el nombre utilizado para invocar algunos *CLI software
  (a pesar de que esto empieza para ser *uncharted territorio)
- el riesgo que otros detalles de implementación / de nivel bajo, que no son
  significado para ser la interfaz de usuario primaria, *violate la marca es muy abajo
  (*yeah, nunca sabes...)

> - Entendemos que para vivir en el seguro *harbor de *nominative uso de marcas,
>   necesitamos distribuir un producto de software libre en
>   el *Debian *archive "cuando es". Pero lo que  que la idea significa en
>   el contexto de software libre?
>   - Dado que nosotros  no  redistribución de río arriba *binaries, pero
>     *compile nuestro propio,  *recompiling un programa de fuente sin
>     *patching lo beneficia del seguro *harbor de *nominative uso?
>   -  *patching La fuente lo hace acontecida un producto diferente?
>   - Si tan, es todo "*patches" igual o es, dice, *patches que cambia el
>     aspecto visual de un programa más *risky, copyright-sensato, que
>     otros?
>     (Nuestra preocupación principal aquí está siendo capaz de aplicar seguridad *patches,
>     sin teniendo que conseguir el acuerdo del dueño de marca, o sin
>     teniendo que rebautizar el paquete justo para aplicar la seguridad
>     *patch, el cual es difícil de hacer puesto que un paquete que es parte de una
>     cuadra *Debian liberación)

Los abogados consultamos considera que sería bastante fácil de hacer
un convenciendo argumento en tribunal que $producto + $*patch != $Producto, abriendo
hasta el riesgo de marca *infringement. El "*default" interpretación
de *nominative el uso parece para ser bastante conservador.

Más y más políticas de marca para proyectos de Software Libre están empezando
para preocuparse sobre explicar qué cambios serían considerados como crear un
producto diferente y que  no. Para quienes , *recompilation es
normalmente concedido el seguro *harbor de *nominative uso. Algunos dejan seguridad
*patches explícitamente, algunos  no. En la ausencia de tal *guidance de políticas
de marca específica, tenemos que mejores ser conservador si queremos
ser en el lado seguro.

Es *unclear si mero *recompilation, ningún asunto lo que una política
de marca dice, podría beneficiar de *nominative uso. Parece para ser *uncharted
territorio, al menos en tribunales. (He sido investigación más lejana
en este tema específico; conseguiré atrás a ti si/cuándo consigo más noticia.)

> - Finalmente, nos preguntamos lo que es las extensiones del *constraints que una
>   política de marca puede imponer. En particular: puede una regla de política
>   de la marca a qué cambios sería aceptable o no para quedarse en el lado
>   seguro?
>   - Sabemos que muchas políticas de marca hacen aquello, pero no somos seguro
>     que lo que tales políticas  es de hecho *permitted por políticas de Marca

de ley de marca explican la interpretación oficial, en un punto
específico en tiempo, por el titular de marca del cual las prácticas son dejadas
con la marca y que no es. No es necesariamente una *interpretación*
válida, pero pueden ir bastante lejos, cuando mucho tiempo cuando no inhiben
*nominative uso. Dado el alcance bastante estrecho de *nominative uso en
ley de marca, aquello no es tan útil cuando, dice, el uso justo es para ley
de copyright.
-----------------------------------------------------------------------

Espera estas ayudas.

Considerando todo el encima, yo  por separado correo un *tentative resumen de esta
discusión.
-- 
*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 »
On Sun, Oct 09, 2011 at 05:28:41PM -0700, Steve Langasek wrote:
> Has the project received competent legal advice stating that a package name
> would be interpreted as infringing a trademark, and that we might have to
> rename it?

We have now received such a legal advice. Actually we got two that
(incredibly enough) agree. I consider both of them to be "competent"
pieces of advice as they come from current and former SPI lawyers that
routinely work on trademark issues on behalf of Free Software projects.
Both lawyers were knowledgeable in US trademark law, and they've put
forward that bias.

Below you can find a summary of what we've got. Quoted text is an
outline of the inquiries I've submitted. Everything else is my own
understanding of lawyers' answers and I shall take the blame for any
inaccuracy in the summary. As it often happens with lawyers (and for
good reasons), it's very difficult to get definitive answers, so you
should imagine a big flashing "IT DEPENDS, BUT" before each answer.

-----------------------------------------------------------------------
> - can trademark policies restrict:
>   - package names in the Debian archive?
>   - program names in menus shown to the user?
>   - more low-level details such as executable names or program
>     installation paths?

The general principle is that everything that could cause confusion
among the users about the "product" they are getting or using could
induce trademark violations. Instantiating the principle to the above
three examples gives:

- package names would easily violate trademarks, as they are names used
  by Debian users to find and install software
- the same goes for name and logos in menus
- ditto for the main cmdline name used to invoke some CLI software
  (although this starts to be uncharted territory)
- the risk that other low-level / implementation details, that are not
  meant to be the primary user interface, violate trademark is very low
  (yeah, you never know...)

> - we understand that to live in the safe harbor of nominative use of
>   trademarks, we need to distribute a free software product in the
>   Debian archive "as it is". But what does that notion mean in the
>   context of free software?
>   - given that we don't do redistribution of upstream binaries, but
>     compile our own, does recompiling a program from source without
>     patching it benefit from the safe harbor of nominative use?
>   - does patching the source make it become a different product?
>   - if so, are all "patches" equal or are, say, patches that change the
>     visual appearance of a program more risky, copyright-wise, than
>     others?
>     (our main concern here is being able to apply security patches,
>     without having to get the agreement of the trademark owner, or
>     without having to rename the package just to apply the security
>     patch, which is difficult to do for a package which is part of a
>     stable Debian release)

The lawyers we consulted consider that it'd be quite easy to make a
convincing argument in court that $product + $patch != $product, opening
up to the risk of trademark infringement. The "default" interpretation
of nominative use seems to be pretty conservative.

More and more trademark policies for Free Software projects are starting
to care about explaining which changes would be considered as creating a
different product and which wouldn't. For those who do, recompilation is
usually granted the safe harbor of nominative use. Some allow security
patches explicitly, some don't. In the absence of such guidance from
specific trademark policies, we should better be conservative if we want
to be on the safe side.

It is unclear whether mere recompilation, no matter what a trademark
policy say, could benefit from nominative use. It seems to be uncharted
territory, at least in courts. (I've been promised further investigation
on this specific subject; I'll get back to you if/when I get more news.)

> - finally, we wonder what are the extents of the constraints that a
>   trademark policy can impose. In particular: can a trademark policy
>   rule upon which changes would be acceptable or not to stay on the safe
>   side?
>   - we know that many trademark policies do that, but we aren't sure
>     that what such policies do is actually permitted by trademark law

Trademark policies explain the official interpretation, at a specific
point in time, by the trademark holder of which practices are allowed
with the trademark and which are not. It is not necessarily a *valid*
interpretation, but they can go quite far, as long as they don't inhibit
nominative use. Given the rather narrow scope of nominative use in
trademark law, that's not as helpful as, say, fair use is for copyright
law.
-----------------------------------------------------------------------

Hope this helps.

Considering all the above, I'll separately post a tentative summary of
this discussion.
-- 
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>
  • Re: Licencias de marca y DFSG, Stefano Zacchiroli <=