Charles Plessy | 3 Mar 2012 12:08
Picon
Favicon

Re: trademark licenses and DFSG: a summary

Le Sun, Feb 19, 2012 at 05:57:54PM +0100, Stefano Zacchiroli a écrit :
> 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

> Proposal
> ========
> 
> - 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
(Continue reading)

Stefano Zacchiroli | 3 Mar 2012 19:40
Picon
Favicon

Re: trademark licenses and DFSG: a summary

On Sat, Mar 03, 2012 at 08:08:57PM +0900, Charles Plessy wrote:
> sorry to be difficult, but after reading again your proposal, I do not
> understand whether you propose to apply the DFSG to trademark licenses and to
> have a more liberal interpretation of DFSG #4 for copyright licenses which
> attempt to implement trademark-like restrictions on distinguishing marks
> (images, sounds, ...), or only to change our interpretation of DFSG #4 for
> copyright licenses.

I don't think you're being difficult :) It's important that people are
on the same page on this, so let me try to clarify that again.

1) as many have pointed out in the thread, DFSG should apply to the
   freedoms of a specific piece of software, rather than to a specific
   kind of licenses/policies. So either options of your dichotomy above
   are incorrect

2) what I'm proposing is in essence the second part of the first choice
   in your dichotomy, i.e. extend interpretation of DFSG §4 to other
   distinguishing marks (I notice that you mention sounds, but I do not
   think they are in the realm of trademark protection; although I
   haven't checked)

> If DFSG does not apply to trademark license, isn't it an invitation to switch
> from non-free license to free license plus trademark restrictions, and accept
> in our archive some software that was considered non-free before, and that in
> practice do not give extra freedom for the user unless they rebrand?  In
> particular, the restrictions on commercial use come to mind.

On this, once more, please check out some more information on trademarks
(the wikipedia entries alone are already quite informative). You cannot
(Continue reading)

Russ Allbery | 3 Mar 2012 22:15
Picon
Favicon

Re: trademark licenses and DFSG: a summary

Stefano Zacchiroli <leader <at> debian.org> writes:

> 2) what I'm proposing is in essence the second part of the first choice
>    in your dichotomy, i.e. extend interpretation of DFSG §4 to other
>    distinguishing marks (I notice that you mention sounds, but I do not
>    think they are in the realm of trademark protection; although I
>    haven't checked)

Sounds can be trademarked if they perform the function of a trademark
(uniquely identifying a company or product), but the rules around them
vary tremendously between jurisdictions.  According to Wikipedia (so more
investigation would be required for full reliability), the EU restricts
trademarks to things that can be represented graphically, so only sounds
that can be written in, for example, musical notation could be
trademarked.  The US applies a different strict test and has allowed
trademarking of, for example, the lion's roar used by MGM in introducing
their movies, but Harley Davison was not able to trademark the sound of
their motorcycle engines.

> IANAL, but AFAIR fact *collections* might be under some circumstances.

Yes, it depends on how much creative editorial judgement was applied.  In
the US, it's well-settled case law that phone books cannot be copyrighted,
since they are comprehensive and hence have no creative editorial
judgement, but cookbooks can be copyrighted because they do involve
creative editorial judgement.  (Individual recipes cannot be copyrighted
because they are facts.)

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>
(Continue reading)

Charles Plessy | 4 Mar 2012 05:12
Picon
Favicon

Re: trademark licenses and DFSG: a summary

Hi again,

I have more questions and comments.

Le Sat, Mar 03, 2012 at 07:40:04PM +0100, Stefano Zacchiroli a écrit :
> 
> 1) as many have pointed out in the thread, DFSG should apply to the
>    freedoms of a specific piece of software, rather than to a specific
>    kind of licenses/policies. So either options of your dichotomy above
>    are incorrect
> 
> 2) what I'm proposing is in essence the second part of the first choice
>    in your dichotomy, i.e. extend interpretation of DFSG §4 to other
>    distinguishing marks (I notice that you mention sounds, but I do not
>    think they are in the realm of trademark protection; although I
>    haven't checked)

Does 1) means that you propose that the DFSG apply to copyright licenses,
trademark licenses and anything else that shapes the freedom of a piece of
software ?

Then, in the case of trademarks, what would be the evaluated items : the
trademark license itself, or its impact on the freedom of the piece of
software.  Let's take a concrete example.

 - Currently, a work is non-free if it contains a program where the copyright
   license forbids to make commercial use without sharing the benefits with
   the authors.

 - If such a program is trademarked by its name, will it be free if it has a
(Continue reading)

Russ Allbery | 4 Mar 2012 05:30
Picon
Favicon

Re: trademark licenses and DFSG: a summary

Charles Plessy <plessy <at> debian.org> writes:

>  - If such a program is trademarked by its name, will it be free if it has a
>    free copyright license, plus restrictions on commercial use through a
>    trademark license, because it can be escaped by rebranding ?

I believe such a program would only be acceptable in the archive if it
were rebranded to remove the trademark.

DFSG#4 specifically applies to restrictions on redistributing source code
in a modified form, not to restrictions on use of the compiled binaries.
If the compiled binaries carry restrictions applicable to the user of a
Debian distribution, such as no commercial use, I think we would need to
rebrand to avoid the trademark restrictions in that case for the software
to be acceptable in main.

Even if it's possible to avoid restrictions via rebranding, I don't
believe it's acceptable for Debian to distribute binaries that can't be
used for particular purposes.  That would be a direct violation of DFSG#6.

>  - What is the case of works that by essense can not be rebranded, like
>    logos for instance.  If the copyright license allows modification,
>    but the trademark license disallows commercial exploitation (like
>    printing on T-shirts sold for profit, etc), can we distribute this
>    file in Debian ?

If the *entire work* constitutes the logo, then I don't think DFSG#4 could
possibly apply even by analogy, since changes are not possible via patch
files or by renaming the work (since in this case there is no meaningful
renaming of the work).  So if the *entire work* is the logo, then that
(Continue reading)

Ben Finney | 4 Mar 2012 09:03
Picon

Re: trademark licenses and DFSG: a summary

Charles Plessy <plessy <at> debian.org> writes:

> Le Sat, Mar 03, 2012 at 07:40:04PM +0100, Stefano Zacchiroli a écrit :
> > 1) as many have pointed out in the thread, DFSG should apply to the
> > freedoms of a specific piece of software, rather than to a specific
> > kind of licenses/policies.
>
> Does 1) means that you propose that the DFSG apply to copyright
> licenses, trademark licenses and anything else that shapes the freedom
> of a piece of software ?

As Stefano said (and I hope he'll correct me if necessary): the DFSG
apply not to licenses but to software works. The freedoms in the work as
distributed to Debian recipients are what matters for the DFSG, no
matter what license or law grants those freedoms.

-- 
 \        “I knew it was a shocking thing to say, but … no-one has the |
  `\        right to spend their life without being offended.” —Philip |
_o__)                                              Pullman, 2010-03-28 |
Ben Finney

--

-- 
To UNSUBSCRIBE, email to debian-project-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/87obscn67h.fsf <at> benfinney.id.au

Ben Hutchings | 4 Mar 2012 23:59
Picon

Unofficial repositories on 'debian' domains

On Sun, 2012-03-04 at 23:27 +0100, Gergely Nagy wrote:
> Sergio Cipolla <secipolla <at> gmail.com> writes:
> 
> > I'm not sure if you're a Debian Maintainer or not (or worse, Debian
> > Developer) but this kind of big mouthing shouldn't be accepted from a
> > DM/DD.
> 
> I don't see a problem. Someone has a strong opinon, and perhaps the way
> it came across was a bit harsh, but I don't believe in papering over bad
> things by trying to dress them up in fancy words.
> 
> As far as I see it, here's how things went: someone installed a package
> from a third party repository, that kinda screwed up his system in one
> way or the other. So he reported a bug against the Debian package
> (despite the recommendation of the 3rd party repository's maintainers,
> who clearly stated in the FAQ not to do this), and it got
> closed. Perhaps a few strongers words were used than neccessary, but
> honestly "crap" is not a word one should be afraid to see.
> 
> Some packages - be them in Debian or in third-party repositories - are
> far worse than crap. We should not be afraid to call them out on that.
> 
> But alas, the story goes further! The reporter does not reopen the
> original bug, but files another, with an insult. Further down the
> thread, we see this someone using a third party repository, without
> seemingly being able to tell it from a normal debian mirror.
> 
> I find it strange that someone who edited his own sources.list, would
> not take the time to have a look at the site he copied the sources.list
> line from, and notice that is by far, not a Debian mirror at all.
(Continue reading)

Stefano Zacchiroli | 5 Mar 2012 12:06
Picon
Favicon

Re: DEP-5: Patches pushed to the Debian Policy repository

On Mon, Feb 27, 2012 at 09:22:37AM +0100, Stefano Zacchiroli wrote:
> Answering to self, I hereby propose the following patch for the DEP-5
> repository. It implements the "(not so) big fat warning" suggestion
> above. Unless there are objections, I'll push it to the repository a
> week for now, together with the change of state from CANDIDATE to
> ACCEPTED of DEP-5.

DONE.
(Implementing Ben suggestion, thanks.)

--

-- 
Stefano Zacchiroli     zack <at> {upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......    <at> zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »
Paul Wise | 7 Mar 2012 00:03
Picon
Favicon
Gravatar

Re: Questions about Debian materials/topics for NorthEastLinuxFest

On Wed, Mar 7, 2012 at 1:12 AM, Yaroslav Halchenko wrote:

> It is nice indeed but not quite the message I wanted to deliver...
>
> I had more of
>
> http://www.onerussian.com/tmp/distro-ecosystem-new2012.svg
>
> in mind ;)   Having hundreds of nice derivatives with a well setup
> workflow Zack illustrated is nice, BUT it is inferior imho to simply
> having those efforts within Debian proper in various regards.  Yes -- we
> could offer more for such customized solutions which require a
> derivative now, e.g. extended flavors exposed within official debian
> installer, but we also have already working solutions (e.g. blends)
> for a field-specific representation of Debian.

In the ideal world that would be the case, but we don't live in an ideal world.

Bringing derivatives closer to Debian is one of the goals of the folks
working on derivatives related stuff, we would love to have more folks
involved in that.

http://wiki.debian.org/Derivatives
http://wiki.debian.org/DerivativesFrontDesk

If you would like to help out with that, we could definitely use some
new people. For a concrete way to help, you could summarise the recent
thread we had about upsides/downsides of contributing back to Debian
and add that to our FAQ.

(Continue reading)

Yaroslav Halchenko | 7 Mar 2012 00:57
Picon
Favicon
Gravatar

Re: Questions about Debian materials/topics for NorthEastLinuxFest

> > installer, but we also have already working solutions (e.g. blends)
> > for a field-specific representation of Debian.
> In the ideal world that would be the case, but we don't live in an ideal world.

"we" might not -- but I do:
       http://neuro.debian.net
       http://www.debian.org/devel/debian-med
       http://wiki.debian.org/DebianScience
       http://wiki.debian.org/Python
it is

> Bringing derivatives closer to Debian is one of the goals of the folks
> working on derivatives related stuff, we would love to have more folks
> involved in that.
> http://wiki.debian.org/Derivatives
> http://wiki.debian.org/DerivativesFrontDesk
> If you would like to help out with that, we could definitely use some
> new people. 

;-) And I did a little contribution already by initiating
http://wiki.debian.org/Derivatives/Guidelines

> For a concrete way to help, you could summarise the recent
> thread we had about upsides/downsides of contributing back to Debian
> and add that to our FAQ.

Yeah -- I could do many things... if only I had more time to spare for
even more "concrete" things

Seriously though -- I actually thought that we had such a summary
(Continue reading)


Gmane