[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian trademark [was: Debian GNU/w32, may ready to be started?]

On Mon, Dec 03, 2001 at 06:48:09PM -0500, Dale Scheetz wrote:
> On Mon, 3 Dec 2001, Steve Langasek wrote:

>> You ask this question as if you believe it's self-evident that running
>> on a propietary OS should be a non-issue when it comes to using the
>> Debian trademark, or at the very least that any objections are
>> surmountable.  I think you will learn -- if you have not already -- that
>> this is not an opinion that enjoys anything even close to universal
>> acceptance within the Debian community.  And even if it were, there are
>> legal reasons why we should not allow the trademark to be used for
>> projects not directly attached to Debian without an explicit license.

> Thank you for your condecending tone. I was a developer before there was a
> DFSG, and am painfully aware of the disfunctional fear of anything
> non-free that is prevalent with DDs in general. I have always been, and
> will continue to be in favor of maximal freedom without neurotic fear of
> non-free contact. If you don't know this by now -- I think you will learn.

I'm sorry, it was not my intention to be condescending here or imply
that you were ignorant of the state of Debian at large; I only intended
to point out that you appeared to be glossing over /the/ central point
of contention in this particular discussion, and that this thread would
bear out my belief that I'm not alone in disagreeing with you.  In fact,
I've come to learn that my own views are mild in comparison to those of
some others. ;)

>>> So, where is the license for the arm, sparc, alpha, or for that matter the
>>> i386 port? These are all Debian projects that are supported to one degree
>>> or another by actual Debian developers who do the work. To argue that this
>>> port is somehow different for it's target OS non-freeness is just silly.

>> These ports are all operated under the oversight of the DPL, the ftp
>> masters, and the Debian system administrators; as far as activities of
>> the Debian project are concerned, they're about as official as you can
>> get.  Has there been any indication so far that the cygwin port will be
>> integrated into the Debian archive?  Frankly, I don't see how I could've
>> missed /that/ decision: I would expect a thread at least as long as this
>> one to result from such a controversial ruling.  Rather, the cygwin port
>> seems to be a self-hosting effort at the moment and for the foreseeable
>> future.

> There IS a license for the trademark, although I can't put my finger on it
> at the moment.  (actually I believe that the only license that was written
> was for the Debian Logo...)

The only thing the SPI website says is 'The Debian trademark is managed
by Debian'.  That's not particularly helpful in sorting things out. :)

> The only criterion I know for the use of the Debian Logo/Trademark is that
> the "product" be "largely" Debian. I would submit that any product that is
> DFSG free is a candidate for Debian distribution. The "packages" in
> question are all already distributed by Debian with complete freedom to
> modify and redistribute.

Here I think we're starting to creep towards the other issue of whether
or not a cygwin port should be included in Debian ("candidate for Debian
distribution").  This is separate from the question of whether a DD
operating independently can use the Debian logo or trademark for such a

>> Debian[1] doesn't need to give itself a license to use its own
>> trademark.  An individual or group of individuals acting /outside/ the
>> scope of Debian /do/ need a license, even if they are Debian developers.

> If there is a license, its conditions apply to everyone uniformly,
> whether DDs or not. As I understand the "license" conditions for this
> trademark (well, the Logo anyway) only require that Debian packages
> comprise the major portion of the delivered product.

> So, this "port" could be delivered with the Debian Logo, but not be called
> Debian? That's weird ;-)

Well, it's not clear to me that they could use the Debian Logo, either;
at least, not from the logo license posted on the website. The license
on the open use logo says:

  This logo or a modified version may be used by anyone to refer to the
  Debian project, but does not indicate endorsement by the project.

... so no one is granted a license to use this logo for branding of
products that don't originate with Debian (it can be used for referring
to the Debian project, not for referring to other products); and the
official use logo license says:

  [This logo may] be used if an official part of debian (decided using
  the rules in I) is part of the complete product, if it is made clear
  that only this part is officially approved

which to me indicates that the logo could be used for a source CD that
shipped /with/ a cygwin port, but could not be used for the port itself
without express approval.

If there are other standing licenses that I've been unable to find
traces of on the website, I'll happily modify my position when they

> > No, because except where binary compatibility between Linux and SunOS
> > make this an implicit result of porting software to Linux on this
> > operating system, Debian does *not* supply software that runs on SunOS.
> > We provide source code that could be *compiled* for SunOS, but the use
> > of the trademark is not automatically transferrable from one to the
> > other.

> Sparc Debian packages will install just fine on a SunOS Sparc that has the
> proper libraries built against the Sun kernel, and has dpkg installed.

> So, what keeps this from becoming part of Debian? Certainly not the DFSG,
> and, as far as I know that is the only restriction on a package's entry
> into Debian.

You would need a glibc compiled for SunOS.  Such a package doesn't
belong in the binary-sparc directory; this is the directory for the
Linux-Sparc port.  So where would it be uploaded?  And although glibc is
non-free software, the rules for the Debian archive are that any free
package that depends on non-free or unpackaged software -- the SunOS
kernel would qualify as both, and this is definitely a dependency of a
glibc package compiled for this architecture -- goes in contrib.

And contrib/non-free are not part of Debian, or so goes the mantra.

I think it would be interesting if the ftpmasters did create a
contrib-only, sparc-sunos archive directory.  But because it's contrib,
it's not really Debian; it wouldn't be handled by an autobuilder[1]; it
would have to have a separate source package from the main libc package
in Debian.  This is in keeping with the same standards that are applied
to /all/ software which is packaged and uploaded to the archive.
Ignoring these rules because the non-free dependency is a kernel instead
of another user-space package seems illogical to me.

> So, those developers working on this "port" need some special dispensation
> for inclusion of the packages into the distro? In other words, what is the
> difference between these packages coming into the distro as
> cygwin-<package>, or going into a special tree named for the "port"?

> Don't the developers doing the packaging get to decide whether it is
> proper to upload it? I've never heard of the ftp manager rejecting a DFSG
> compliant package uploaded by a DD. Why reject this port with less reason?

The ftpmasters have jurisdiction over the overall archive structure.
Where do the binaries for these hypothetical cygwin-packages go?
They're not binary-i386, that's the directory for the Linux-x86 port.
Unless you upload a cygwin-libc6 package that Depends: on wine; that
would be an interesting exercise for someone with a lot of time on
their hands, but it wouldn't further the stated goal of providing a
Debian port for Windows users.

If you shoehorn the packages in as arch: i386, you have to provide for
the installation of these packages on a Linux-i386 system.  If you
create a full port with a separate arch name that's actually an
installable distribution, then you have a dependency on a non-free
kernel and the whole port has to go in contrib / non-free, with no main/
section.  Which means dynamically altering the Section: of free packages
besides.  Any way you slice it, it just doesn't fit the definition that
has traditionally been used to demarcate what is and isn't part of

Steve Langasek
postmodern programmer

[1] Ok, an autobuilder is useless if the only package in there is libc,
but still.

Attachment: pgpLFWOnoxmKb.pgp
Description: PGP signature

Reply to: