Re: ASL2 and artistic compatibility

[Nathanael Nerode]

Andres Salomon wrote:

> It would appear that the new upstream release of libapache2-mod-perl2 has
> been relicensed; from the ASL 1.1 to the ASL 2.0.  As has already been
> discussed, the ASL (both 1.1 and 2.0) and GPL are
> incompatible (at least, the FSF claims they are).  What has previously
> been used w/ modperl (1 and 2, under the ASL 1.1) has been perl's Artistic
> license.  The question is, does the change to ASL 2.0 introduce any
> incompatibilities with the Artistic license?  Is it safe to upgrade
> libapache2-mod-perl2 to the latest version?
No idea; we'll have to look at both clause-by-clause and I'm not up to it
today.  :-)

> 
> As a side note, there was a d-l thread in Feb. about the Apache group and
> the FSF talking about resolving their disagreement regarding the patent
> termination clause in the ASL 2.0 rendering both licenses incompatible.
> Does anyone know if an agreement has been reached?
No, nobody knows.  :-)

The ASL 2.0 was designed specifically to be GPL-compatible.  The
incompatibilty believed present by the FSF is very subtle; they believe
that the GPL grants *implicit* patent licenses and that the ASL's
revocation of explicit patent licenses under certain circumstances is
therefore an additional restriction.

There is, as far as I can tell, no consensus on whether the GPL in fact does
grant implicit patent licenses, or indeed whether the revocation of the
explicit patent licenses in the ASL would also revoke such implicit patent
licenses.

-- 
There are none so blind as those who will not see.

Re: Bug#248782: abuse-sfx: violation of license terms

[Nathanael Nerode]

Andrew Saunders wrote:
> An even greater worry is a clause that appears to make the Project
> responsible for enforcing compliance with the license terms:
> 
>> You agree to use your best efforts to see that any user of the
>> Software licensed hereunder complies with this Agreement.
> 
> First of all, does the Project really agree to that? If not:
> 
>> If you fail to comply with any terms of this Agreement, YOUR LICENSE
>> IS AUTOMATICALLY TERMINATED.
> 
> And if OTOH we *do* agree to that ridiculous condition, we are already
> in violation of this policeman clause due to our own policy regarding
> the US Export Administration Act.

> 

I agree.  Stop distributing it.

-- 
There are none so blind as those who will not see.

Re: IBM Public License (again)

[Nathanael Nerode]

MJ Ray wrote:

> On 2004-05-13 18:09:47 +0100 Josh Triplett <[EMAIL PROTECTED]>
> wrote:
> 
>> MJ Ray wrote:
>>> Why should this software's licence, not directly involved in the
>>> cases
>>> above, terminate?
>> This software's license doesn't terminate.  The patent license from
>> all
>> of the software's contributors not to sue you over patents terminates.
> 
> I already wrote I'm only considering the patent licence, so let's drop
> the wording defence. We agree that the patent licence terminates.
> Therefore, the patent licence is non-free.
> 
>> A license that gives no indication about patents at all would give you
>> fewer rights than this license
> 
> Sure, but a patent licence might not be needed because there are no
> patents covering the software. If there are patents covering it, then
> having no patent licence => non-free.
> 
> Can we reasonably expect that anyone licensing us some patents in
> order to use their software has such patents?
Not when it's written that generally.

> If not, why don't they 
> declare that instead of licensing a nothing to us?
IBM has too damn many patents and probably didn't want to bother determining
which ones might apply to what software.  :-/

>> Given that our standard position on patents is to ignore them unless a
>> particular patent holder is threatening us with lawsuits, I see no
>> reason why we shouldn't apply the same policy here.
> 
> Our standard position on patents is usually for the case where we have
> no patent licence and don't know that we require one. This is a case
> where we are being offered a non-free patent licence and a free
> copyright licence. Why aren't these two seperate licences? Then we
> would know whether we require a patent licence by whether it is
> offered, which would make it easier to spot software non-free for
> swpat lands ;-)

---

I just spotted a clause which I *really* don't like, however:
"Each party waives its rights to a jury trial in any resulting litigation."

That's not a legitimate requirement of a free software license, is it?

-- 
There are none so blind as those who will not see.

Re: IBM Public License (again)

[Nathanael Nerode]

MJ Ray wrote:

> On 2004-05-13 16:54:36 +0100 Raul Miller <[EMAIL PROTECTED]> wrote:
> 
>> For example, if IBM begins initiates some patent litigation, it looks
>> like
>> the license still stands -- even if that litigation winds up
>> nullifying
>> the patent in question. [...]
> 
> What if you want to enforce some other patent applicable to software
> against IBM? What if IBM initiates against you and you want to use
> such a patent in a counterclaim?

The vagueness and broadness of "applicable to software" is a particular
problem.  Suppose I want to enforce my bicycle patent against IBM's new
bicycle-with-builtin-laptop, and IBM claims that my patent is "applicable"
to software?

If this referred to patents "applied to" software, I would be much happier.  

> Why should this software's licence, not directly involved in the cases
> above, terminate?

I think my summary of the patent clause goes something like this:

"If Recipient institutes patent litigation against a Contributor with
respect to a patent applicable to software (including a cross-claim or
counterclaim in a lawsuit), then any patent licenses granted by that
Contributor to such Recipient under this Agreement shall terminate as of
the date such litigation is filed."

We're worried that this is overly broad and could attack legitimate patents.

However, it only affects patent license grants.  Therefore, it may be OK
because most licenses apparently don't grant any patent licenses at all,
and this is no worse than that.

The policy on patents has been: if we know of no actual, legitimate,
enforced patents, we assume no patent grants are necessary.  (The wisdom of
this policy is questionable and can be debated.)

" In addition, If Recipient institutes patent litigation against any entity
(including a cross-claim or counterclaim in a lawsuit) alleging that the
Program itself (excluding combinations of the Program with other software
or hardware) infringes such Recipient's patent(s), then such Recipient's
rights granted under Section 2(b) shall terminate as of the date such
litigation is filed. "

This is OK, because this is a program self-protection clause.  If the
Recipient alleges that the Program infringes Recipient's patents, then
according to Recipient, nobody but Recipient has rights to do anything with
the program.  It seems reasonable to deny Recipient those rights as well,
since otherwise Recipient could *literally* take the program proprietary,
and effectively steal the work of the authors.


-- 
There are none so blind as those who will not see.

Re: Bug#248782: abuse-sfx: violation of license terms

[Nathanael Nerode]

Benjamin Cutler wrote:

> Does it make any difference that the company is question has been
> dissolved and they basically dropped everything into the public domain?

Yes, it *would*

>  From http://www.loonygames.com/content/1.10/guest/
> 
> ---
> Around July, Crack first missed payroll. August came and we moved out
> of the office. September offered no new news, so we decided to call it
> quits. Rather than letting all that hard work sit around and rot, we
> released it to the public domain.

But we would need clear evidence that they actually *did* release it into
the public domain.  This is a little too vague given that many people are
confused about what the public domain is.  For instance, a statement saying
"Crack.com, the former copyright holders of these files, release all of
them into the public domain, with no restrictions."

> After doing the same with Abuse and 
> getting a tremendous response, we had to. Some people have said "Aren't
> you worried someone else could pick it up, finish the game and sell it".
> The answer is no. I don't mind if someone makes a profit off this work,
> which is a definite possibility. I think the engine can be used to make
> many different games, and I hope someone does just that. The soundtrack
> could be sold to a record, game, or movie company for 100k or more, and
> the textures have a fair value as well. But with debt that Crack dot Com
> accrued, even these sales would not have helped. We would much rather
> see other people learn from our work and our mistakes.
> ---
> 
> It sounds like perhaps the maintainer of the package should email
> Jonathan Clark and get a clarification?

-- 
There are none so blind as those who will not see.

Re: IBM Public License (again)

[Nathanael Nerode]

Raul Miller wrote:

> On Thu, May 13, 2004 at 05:17:30PM +0100, MJ Ray wrote:
>> What if you want to enforce some other patent applicable to software
>> against IBM? What if IBM initiates against you and you want to use
>> such a patent in a counterclaim?
> 
> What does this have to do with free software?
> 
>> Why should this software's licence, not directly involved in the cases
>> above, terminate?
> 
> Software patents make software less free.

Right, but this clause is not narrowly targeted at, for instance,
"patents on mathematical algorithms"
"patents applied to computer programs"
"patents invalid under general pre-1970 law"
"patents made without publishing a working model"

Instead, it uses the vague and broad phrase "patent applicable to software". 
As far as I know the breadth of that phrase has not been tested in court,
but it sounds quite broad.

-- 
There are none so blind as those who will not see.

Re: IRAF package license

[Nathanael Nerode]

Justin Pryzby wrote:


> Are the UCAR routines copyright of the type that will expire (this
> year?)?

In the US, no copyrights will actually expire for twenty years or more.

-- 
There are none so blind as those who will not see.

Re: IBM Public License (again)

[Nathanael Nerode]

Raul Miller wrote:

> * The license doesn't discrimate against people, groups or fields of
> endeavor.  [We do not recognize "people wanting to enforce particular
> intellectual property claims" as a field of endeavor, or the GPL wouldn't
> be free.]
It's the lack of particularity which makes this different.  "applicable to
software"?  What does that mean?  It's not particular at all.

-- 
There are none so blind as those who will not see.

Re: Is SystemC license compatible with the GPL ?

[Nathanael Nerode]

Andrew Suffield wrote:

>> No.  GCC has different parts under different licenses (although all are
>> GPL-compatible).  Parts are GPL, parts are LGPL, parts are GPL with
>> special libgcc exception, etc.
> 
> I don't believe there are any LGPL parts.

libf2c/libU77
portions of libiberty
portions of libjava
some test cases

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Sun, May 09, 2004 at 12:08:56PM -0400, Anthony DeRobertis wrote:
>> The GFDL could requires us not to fix factual inaccuracies.
> 
> How so?
> 
> [A] These would have to be factual inaccuracies in a secondary section
> (which rather limits the scope of any such inaccuracy).
Well, perhaps that does limit the scope in some cases, but so what?

> [B] Nothing in the GFDL prohibits us from adding additional context or
> content to make the facts (or differing points of view) clear.

It prohibits it from being put in the right place.  The result would the
infamous "Invariant Section Wars" which have already been suggested, with
counter-Invariant-Sections, etc.

> [C] If the inaccuracies are, in fact, fraud, then the license terms
> can't legally require that they be repeated.

But the GFDL has a clause along the lines of "If you cannot comply with this
license and other requirements, you can't distribute at all."

> Maybe there are serious problems with the GFDL, but this doesn't look
> like one of them.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> The DFSG does not mandate good editorial practice, good coding style or
> any of a variety of other virtues.
But does it allow a license to prohibit such virtues?

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Henning Makholm wrote:

> Scripsit Raul Miller <[EMAIL PROTECTED]>
>> On Mon, May 10, 2004 at 05:15:12PM +0100, Henning Makholm wrote:
> 
>> > It is a factual accuracy that FSF makes money by selling hardcopies of
>> > my derivate.
> 
>> I'd call this hypothetical.  And, tangential.
> 
> Only if you consider the possibility of deriving derivates from
> DFSG-free stuff hypothetical and tangential in general.
> 
>> > No. Cover texts has to go on the cover.
> 
>> Of the GFDL licensed component, not on the work as a whole.
> 
> The work as a whole inherits the GFDL license of the manual I derived
> it from.
Unless it is "mere aggregation", and that's defined by law.

> 
>> And, as I said in the message you were responding to, while the GFDL
>> approach is unwieldy, it's less so than a "patches only" license could
>> be.
> 
> A patches-only license that does not allow distribution of
> ready-to-run versions of modified works is not DFSG-free either. If we
> apply that criteria to human-readable documentation, a free license
> should allow distribution of modified ready-to-read documents. It may
> require that everyone who receives such a ready-to-read documents can
> also opt to receive machine-readable source of the original and a
> machine-readable description of the differences.
> 

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Mon, May 10, 2004 at 04:36:27PM -0400, Anthony DeRobertis wrote:
>> Even worse, at some point this becomes a Lanham Act violation,
>> rendering the document undistributable.
> 
> If a work uses trademarks illegally, we can't distribute that work.
We can, however, perhaps distribute a modified version.  And we probably
should.

> But that's not a DFSG issue.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> Some licenses (the GPL is a good example) include requirements which
> are relevant to the copyright as a whole.  In the case of the GFDL,
> however, it's not that specific.

You're just wrong here.  It is that specific.

>From the GFDL:

A ``Modified Version'' of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

>From later on in the GFDL:

MODIFICATIONS

You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it.  In addition, you must do these things in the Modified Version:

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 09:22:11PM +0100, Henning Makholm wrote:


> That's not my claim.  You can provide some additional context indicating
> the temporal nature of the claim and your beliefs about the situation.

On the COVER?  This is not practical.  And it still doesn't deal with the
problem that my XCC manual just isn't "A GNU Manual".

Give a practical solution for the example given.

>> > > That is the only way to avoid putting the cover text in a context
>> > > where it is not literally false.
>> 
>> > And this, my friend, is an example of a lie.
>> 
>> Rubbish. The only context in which thne statement is not literally
>> false is the original context. Therefore the only way to avoid making
>> the statement into a lie is not th modify the context at all.
> 
> Here's another example of how this sentence that bothers you so much
> can be made to be true: send the FSF $1 dollar for their permission to
> print the book.
> 
> I maintain that this example is not necessary, that there are plenty of
> other ways of dealing with the issue.
You haven't come up with one.

>> However, I also claim that this 
> example is sufficient to show that your "the only way" statement is false.
> 

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 08:01:16PM +0100, Henning Makholm wrote:
>> That is a non-solution. Telling a lie and then saying, "oops, the
>> above statement is a lie, but a previous author requires me to tell
>> it" will (1) not make the lie go away, (2) help nobody, and (3) make
>> everyone involved look silly. Plus, there may not be space for that
>> much deliberation on the cover.
> 
> And calling a statement which is true a lie doesn't do anyone any
> good either.
What the hell?

> 
>> > Your hypothetical "factual incorrectness" is purely contextual,
>> 
>> Yes. So?
> 
> Your entire example is based on taking a statement which is true in one
> context and creating another context where it is incorrect.  This works,
> as long as you're not willing to go to the minor effort of fixing the
> second context.

The license makes it IMPOSSIBLE to fix the context.

>> > and it's probably possible to fix the context that the statement is
>> > no longer incorrect.
>> 
>> Sure - by not making a derived work at all. That is the only way to
>> avoid putting the cover text in a context where it is not literally
>> false.
> 
> And this, my friend, is an example of a lie.

No, it's not.  You haven't presented a way to "fix the context".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> >  For example: you can't take code from gcc and code from metafont and
>> >  combine them to build a new compiler -- at least not under the
>> >  current licenses of those programs.
> 
> On Tue, May 11, 2004 at 05:00:49PM -0300, Humberto Massa wrote:
>> It's not forbidden to make copies, just to redistribute the copies of
>> the derived works.
> 
> What's your basis for making this statement?
> 
>> You can combine gcc and metafont and make a new compiler; you can even
>> make a script that combines them, apply some patch to the combination,
>> and compiles the result to get to your invention; what you can't do
>> is to redistribute the resulting binary nor the resulting source.
> 
> Perhaps there's some part of the GPL that gives this permission which
> I've overlooked?  If so, please quote this.

GPL section 2 grants the right to modify and redistribute modified versions
(in source code form), under three conditions.  (2a) and (2b) apply to all
copies, private or not; but look at (2b).

(GPL section 2b)
b) You must cause any work that you distribute or publish, that in
   ^^
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

You are not required to licence your derived work under the GPL if you do
not distribute or publish it.  If you *do* distribute or publish it, you
are.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> > [A] These would have to be factual inaccuracies in a secondary section
>> > (which rather limits the scope of any such inaccuracy).
> 
> On Mon, May 10, 2004 at 08:13:05AM +0100, Henning Makholm wrote:
>> It could also be Cover Texts. The documentation currently distributed
>> by the FSF require the cover text "a GNU manual" and a notice that
>> implies that the FSF sells copies of the text. Both of these turn into
>> factual inaccuracies if I modify the manual to become documentation of
>> the BSD implementation of the tool in question.
> 
> I agree that this is bulky and akward.
> 
> I don't agree that this requires any factual inaccuracy.  You can create
> a derived copy of the work which eliminates the content you don't want,
> and wrap the remainder in the required cover and include that as a
> chapter or appendix in some other manual.

Huh?  I don't follow this paragraph at *all*.

> 
> Note that content under a "patches only" license will give you much
> worse problems when incorporating it (perhaps as examples, or perhaps
> pulling documentation from a help menu item) into other documentation.
> 

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> Raul Miller wrote:
>> > On Mon, May 10, 2004 at 09:44:27AM -0700, Josh Triplett wrote:
>> > 
>> >>Unless the derived document falls under section 7, "AGGREGATION WITH
>> >>INDEPENDENT WORKS" (which requires that more than half of the document
>> >>consists of independent work not derived from the GFDLed document), you
>> >>must put the covers around the entire derived work, not just part of
>> >>it.
>> > 
>> > This is a solvable problem.
> 
> On Mon, May 10, 2004 at 11:55:28AM -0700, Josh Triplett wrote:
>> How would you suggest solving it, given that you should be able to make
>> a derived work of the document as a whole without just referencing it?
> 
> There are at least three solutions:
> 
> [1] Add more original content
That's an interesting, if certifiably bad, solution; add more junk to fill
the page count.  Ow.

> [2] Let the document be referenced under its original title.

We accept licenses which require retitling. I do not think we can accept a
license which prohibits retitling, as that would require inaccuracy
(again).

> [3] Strip out more of the bulk from the GFDL document.
Only works if there's strippable bulk.

>> (Also note that even if this "workaround" works and you only need to
>> include the Cover Texts and Invariant Sections in an appendix, that
>> would still be non-free; this "workaround" only solves the inaccuracy
>> problem, not the Freeness problem.)
> 
> I agree that this is independent of the freeness issue.
> 
>> > Exactly.
>> 
>> A Free license should allow you to create a derivative work of the
>> document, instead of just referring to it.
> 
> It does.

It should allow you to create most any derivative work you want, with very
limited restrictions.  These do not seem like limited restrictions.  :-P

>> For example, you should be
>> able to write a manpage for "ls" based on the coreutils documentation,
>> without including the entire document in an "appendix" of the manpage,
>> or including the Cover Texts on the "front and back covers" of the
>> manpage.
> 
> Coreutils documentation is not at all structured like a man page.
> I think it would be better to copy the ideas and not the content.

Fine.  To do that, you don't need free documentation; that can be done with
*any* documentation.  Ideas are not copyrightable.

Please do this so that we will have a Free coreutils manpage.

For the documentation to be *free*, you need to be able to make a derivative
work.

> 
>> It should also be possible to take the entire GNU coreutils
>> manual, and modify it to document a different implementation of the same
>> commands, without having to include inaccurate Cover Texts or Invariant
>> Sections (or accurate ones either, for that matter).
> 
> This line of thought has potential, but a concrete practical instance

How is the one he just mentioned not concrete or practical?  Alternate BSD
implementations of most of GNU coreutils exist.  I would like to modify the
GNU coreutils manual to document them, but I would have to include these
Cover Texts and Invariant Sections.

> (with some specific reference to some DFSG clause(s)) would probably help.
> 


-- 
There are none so blind as those who will not see.

Re: Draft Debian-legal summary of the LGPL

[Nathanael Nerode]

Humberto Massa wrote:


> Yeah, but if they require forced co-distribution, I understand that they
> are considered generally non-DFSG-free.
You can require that the source be distributed to the person to whom you are
distributing the binary.  You can't require that it be distributed to
anyone *else*.

You also have to accept "making the source available on the same site as the
binary", without requiring the user to actually download the source, as
sufficient, but that's a technical restriction due to the way Debian
packages operate.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 02:57:51PM +0100, Henning Makholm wrote:
>> Your copy of the DFSG must be missing clause 3.
>> 
>> | 3. Derived Works
>> |
>> | The license must allow modifications and derived works, and must
>> | allow them to be distributed under the same terms as the license of
>> | the original software.
> 
> My copy of the DFSG does not say "The license must allow all modifications
> and derived works, ..."
> 
> The issue I've been addressing is the distinction between what the DFSG
> actually says, and how it is interpreted.
> 
> What it actually says isn't enough for our purposes -- you could say
> it's too tolerant of licensing problems.
OK.  I would interpret it as meaning "must allow most modifications and
derived works".

> Unfortunately, the way that 
> we express how it's interpreted is also inadequate -- what we say we do
> is actually less tolerant than what we actually implement.

What we say we do is something like this:

* prohibit most substantive restrictions on the content of derived works
* allow restrictions which appear not to be substantive
* allow requirements which prohibit things which would be illegal even if
the original work were in the public domain
* allow requirements that certain things accompany the distribution of the
derived work, but not (in general) requirements that those things be *in*
the derived work.
* allow requirements that certain accurate legal notices be present in the
derived work, provided that they don't substantively obstruct the ability
to make the derived work serve whatever purpose you want
* allow requirements that certain attributions be present in the derived
work, provided that they don't substantively obstruct the ability to make
the derived work serve whatever purpose you want

Does that sound reasonable?

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Anthony DeRobertis wrote:

> On Thu, May 06, 2004 at 10:07:10AM -0400, Raul Miller wrote:
>> On Thu, May 06, 2004 at 09:18:00AM -0400, Nathanael Nerode wrote:
>> > Oh.  Well, the GFDL with Invariant Sections requires bloat in
>> > distributed binaries.
>> 
>> Where the GFDL is used to license programs, it's not something that we
>> can distribute under the DFSG.  [As this could require us to not fix
>> security problems.]
> 
> The GFDL could requires us not to fix factual inaccuracies.

Does, actually.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> > So, in essence, you think that the DFSG says we must disallow the
>> > distribution of gcc if its license prevents you distributing copies
>> > which have been functionally modified to better integrate with
>> > microsoft's palladium?
> 
> On Tue, May 11, 2004 at 05:22:11PM +0100, Henning Makholm wrote:
>> Yes.
> 
> That's in direct, literal conflict with the DFSG (clause 10).

No, it's not.  See below.

> The GPL specifically disallows creation of copies with changes -- no
> matter how functional -- which include restrictions on the rights of
> other users of derivatives.

No, it doesn't.  Please read the GPL more carefully.

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License.  (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)

Nowhere in here is there a prohibition of the sort you think there is. 
Where do you think the GPL "disallows" what you're describing?

Of course, this hypothetical version of GCC which was designed to better
integrate with Palladium would have to be either:
(1) Not distributed or published
or
(2) Licensed under the GPL

If it's impossible to make such a version and license it under the GPL
because of *Palladium* copyrights, patents, or trade secrets, that's
another matter.  But the GPL lets you create such a version, and if you
somehow manage to create such a version, the GPL lets you distribute it
(although Microsoft may not).

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 02:16:35PM +0100, Henning Makholm wrote:
>> These are three non-solutions with respect to the freedom to make
>> arbitrary functional modifications to the work - which lies that the
>> very core of the DFSG.
> 
> Given that "arbitrary functional modifications" would include illegal
> activities and "arbitrary legal functional modifications" would not 
> include activities which are disallowed by the copyright statement,
> and that "arbitrary functional modifications which would be legal if it
> were not for the copyright" has an additional set of problems (without
> the copyright statement no copying is legal, and with any other example
> statement this is a requirement for that exact copyright)...

"arbitrary functional modifications which would be legal if the work were in
the public domain"

> I don't think that "arbitrary functional modifications" is a very accurate
> representation of what the DFSG is really trying to allow for.
Or is it?  :-)

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:


>> Making copies of the derived work is *not* forbidden by the GPL.
> 
> You mean because it's outside the scope of the GPL?

No, because clause (2b) only applies to distribution.  Copying of modified
versions in source form is allowed provided the conditions in (2a), (2c),
and (1) are satisfied.  Furthermore, 3a, 3b, and 3c are no-ops if you don't
distribute, so copying in object form is allowed under the same conditions.

Of course, 2c is widely disliked on this list and considered to be on the
margin of non-free.  And 2a is more honored in the breach than in the
observance; even the FSF doesn't try to follow it to the letter.

> After all, the 
> GPL says:
> 
>Activities other than copying, distribution and modification are not
>covered by this License; they are outside its scope.
> 
> Oh, wait, it talks about copying there... hmm...
> 
> Oh well, you must be right.  After all, you said so.  And you used
> asterisks.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 05:23:21PM +0100, Henning Makholm wrote:
>> Nothing prevents them from doing so. That, however, does not affect
>> the *fact* that, for whatever reasons, they do not *actually* do
>> so. Hence a claim that they do is *factually incorrect*.
> 
> I'm very dubious about this concept.

Well, deal with it.

> You've proposed a license for a work [which I've never seen, so have
> not examined]
The official manual for GCC.

(a) The FSF's Front-Cover Text is:

 A GNU Manual

(b) The FSF's Back-Cover Text is:

 You have freedom to copy and modify this GNU Manual, like GNU
 software.  Copies published by the Free Software Foundation raise
 funds for GNU development.

> makes some claim about making money, and that you have a 
> hypothetical derivative work where that claim would be false.

Well, first of all, I don't believe I have freedom to copy and modify the
manual "like GNU software".

Now, suppose I make a derivative work; a manual documenting some other CC. 
Or indeed, one documenting GCC, but one the FSF doesn't accept.  Is it "A
GNU Manual"?  Certainly not.  Are there copies published by the Free
Software Foundation?  No.

> Even if I grant that a particular work might have this flaw, it seems
> to me that this is a flaw in that work.

OK.  Whether it's a flaw with the work or with the license doesn't matter. 
If you call it a flaw with the 'work', accept that this is a flaw with
every work which contains Cover Texts which could be inaccurate for
reasonable derived works.

This includes all FSF-distributed GFDL-licensed manuals with Cover Texts,
and every other Cover Text I've actually seen used.  Which makes it a very
real problem.

> Also, a patches only license 
> can put us in exactly the same state of factual incorrectness.
> 
> That said, for the cases I can imagine involving such work -- if I
> cared about it at all -- it would be easy enough to add a statement of
> the form "while the free software foundation made money from earlier
> editions to this work, I don't think they will be making any money from
> this edition for some time."  Your hypothetical "factual incorrectness"
> is purely contextual, and it's probably possible to fix the context that
> the statement is no longer incorrect.

Do you think that adding your own text on the cover would *really* be
sufficient?  Then all copies might say:

(on the front cover)
Using XCC

A GNU Manual
except it isn't really

(and on the back cover)
 You have freedom to copy and modify this GNU Manual, like GNU
 software.  Copies published by the Free Software Foundation raise
 funds for GNU development.  Except the Free Software Foundation doesn't
 publish copies, because this isn't an official GNU Manual, although
 it's based on one.

This is insane.  I consider it an unacceptable "solution".

> Then again, if your primary concern is not "presenting the facts clearly",
> but "expressing righteous indignation", I can see why you wouldn't like
> this approach.
> 

Stop insulting people.  I think we have presented the facts quite clearly.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 05:44:05PM -0600, Joe Moore wrote:
>> "keep intact" does not mean the same as "unmodified".
> 
> But we're still talking about a case where not all derived works are
> allowed.

Duh!  We have stated that certain restrictions on derived works are OK.  But
only a few, specific restrictions. 

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Wed, May 12, 2004 at 03:21:53AM +0100, Henning Makholm wrote:
>> > I was not proposing "make gcc work on that OS", I was proposing
>> > functional modifications to GCC to make it integrate better with that
>> > environment.
>> 
>> There is nothing in the GPL that forbids functional modifications to
>> GCC to make it integrate better with the environment.
> 
> Treat palladium as a meta-syntactic variable standing for an environment
> where reverse engineering is illegal and where proprietary code and 
> proprietary features are present.  Treat "integrate better" as something
> which specifically requires those proprietary features.

If you use them according to the free interface, then you have a "contrib"
program.  If you use the proprietary code, then you've created something
non-free regardless of the GPL.  What's your point?

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 09:35:02PM -0500, Steve Langasek wrote:

>> With the exception of a very narrow set of restrictions
>> related to copyright acknowledgement and warranty disclaimers, the
>> nature of changes to the code is not restricted by the GPL.
> 
> Eh?

He means what he says: read that carefully, then read the GPL again
carefully.

The restrictions to modification of code licensed under the GPL are the
following:

>From clause 2:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

Also from clause 2:
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License.  (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)

>From clause 1:

"...provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program."

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 05:37:51PM -0400, Glenn Maynard wrote:
>> This is allowed by the GPL and required to be allowed by the DFSG, of
>> course, as long as the resulting gcc binary can be distributed under the
>> terms of the
>> GPL.  The GPL doesn't care what kinds of changes you make (with very
>> limited exceptions, such as the license blurb).
> 
> Only if the resulting work (including the implementation of the support
> for those keywords) is distributable under the terms of the GPL.


> Or, maybe you're saying that when integrating with foo it's reasonable
> to ask the programmer doing the integration to reimplement foo under the
> terms of the GPL?  [Let's say that the programmer in question isn't the
> author of foo.]

What are you saying here?

It is reasonable to require that the programmer does not look at the
copyrighted implementation of foo, and only looks at the freely
implementable interface documentation for foo.  That way the "GCC
integrated with foo" work is not a derivative work of foo.

Or are you talking about "integrating" something in a way which would
involve a merger of two code bases to the point where they were not
separable?  Well, in that case, indeed, we might find that
GCC-integrated-with-foo cannot be distributed without relicensing of one or
the other.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 09:33:52AM -0700, Josh Triplett wrote:

> Being unmodifiable violates the usual "fully general" interpretation of
> the DFSG.  Unfortunately, that interpetation isn't really fully general
> (and, if carried to the limit, would only allow us to distribute public
> domain software).

The usual interpretation is

"The creation of modifications and derivative works must be allowed in
general, though a few specific, narrow restrictions may be placed on what
may be created, if they do not seem to harm freedom significantly".

Got it?  :-)


> Perhaps it's worth noting that, as it was originally written, the DFSG
> did not stand on its own but was a part of the social contract.
Wait, I thought it predated the Social Contract.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> > So, in essence, you think that the DFSG says we must disallow the
>> > distribution of gcc if its license prevents you distributing copies
>> > which have been functionally modified to better integrate with
>> > microsoft's palladium?
> 
> On Tue, May 11, 2004 at 09:13:13AM -0700, Josh Triplett wrote:
>> Yes.  From DFSG 6:
>> > The license must not restrict anyone from making use of the program
>> > in a specific field of endeavor. For example, it may not restrict the
>> > program from being used in a business, or from being used for genetic
>> > research.
>> ... or for being used to promote Treacherous Computing.
> 
> And what about DSFG 10?
> 
> Because that's exactly the license gcc is distributed under.

No, it doesn't.  Perhaps you don't understand the GPL?  Or perhaps you don't
understand copyright, licensing, and the meaning of "derivative work"?

Or are you trying to make a point which you haven't managed to clearly make
yet?

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:
> Sure, it's "all programs except ___" or "not everything".  That's pretty
> much my point.

Yeah, we accept that certain *very limited* restrictions on modification are
Free.  So why do you keep going on about this stuff?  There's a short list
of OK restrictions we've already accepted, and anything beyond that is
"guilty until proven innocent".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Tue, May 11, 2004 at 04:18:22PM -0400, Brian Thomas Sniffen wrote:
>> as the GFDL.  The parenthetical is false.  The GPL does not require
>> that it be included in the distributed work, merely with the
>> distributed work.
> 
> I don't think this is a very meaningful distinction, for the context I
> was discussing.

In the context of the GPL and the GFDL, this is a *very* meaningful
distinction.

The GFDL requires that Invariant Sections be retained unmodified with the
same section titles (and presumably listed in the Table of Contents).  It
requires that Cover Texts be placed in a certain size on the cover of all
derived works.  These are painful functional requirements.

The GPL requires that a copy of the license accompany the work.  This is
not.

"Patch-only" licenses must allow distribution of modified binaries.  For
source, they require distribution in a funny form, but one which is easily
and losslessly convertable with free tools to the desired source form; so
this doesn't impact the functionality much if at all.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> On Thu, May 06, 2004 at 09:57:41AM -0400, Nathanael Nerode wrote:
>> > Now, again, some restrictions on creating derived works are generally
>> > considered acceptable.  But required inclusion of arbitrary lumps of
>> > text in a particular manner certainly isn't one of them (even with the
>> > oft-ignored GFDL restriction that they must be 'off topic').
> 
> On Sun, May 09, 2004 at 12:41:52PM -0400, Anthony DeRobertis wrote:
>> The oft-ignored restriction that invarient sections must be off-topic
>> probably just makes the DFSG 3 problems worse: It also limits derived
>> works to not covering certain topics (or, at least makes their status
>> *very* unclear if they do cover those topics).
> 
> Huh?  This would be true if the rules about secondary sections applied
> to the document as a whole.
> 
> But they don't.
Um, are you listening?

>> I can't use part of the GNU Emacs manual in my essay on software
>> freedom, because I'd have to include an invarient section about that
>> subject (but I can't because invarient sections have to be off-topic...)
> 
> They have to be about the relationship between the authors and the
> document.  They're clunky.  But that's not the same thing as forbidding
> them.

Perhaps you missed the point?

He would have to include the GNU Manifesto in order to use part of the GNU
Emacs manual (beyond what's allowed by fair use).  He plans to license his
essay under the GFDL, same as the GNU Emacs manual.  But in his essay on
software freedom, the GNU Manifesto would not be a Secondary Section.  So
he couldn't use part of the GNU Emacs manual for this purpose at all
(beyond what's allowed by fair use).  Or at least we haven't figured out a
way to do so.

> You'd be much worse off trying to include example code from some "no
> changes, only patches" source code license.
(1) Is a selection actually a change?
(2) He could simply license his whole manual (source code) under that
license, and supply it in the bizarre form of a patch to the original
source code; to be free, the license must permit the creation and
redistribution of the derivative object code, so the manual viewed by the
enduser (object code) wouldn't have any of this oddity left.

> You'd havr even worse problems if you tried to include examples from
> two sources which had incompatible licenses.
Well, there's that -- there really is specific language in the DFSG which
indicates that we don't care about that, however, as others have pointed
out.

> In other words, this is ugly, but it's not even close to the most serious
> issue with stuff we do distribute.
Au contraire, it is very close.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Wed, May 12, 2004 at 03:25:16AM +0100, Henning Makholm wrote:
>> No. If I create any variation of the context, then the statement
>> immediately stops being true when placed in the variated context.
> 
> Except that you can easily create varied contexts where the
> statement is true.

No, you can't.  Go ahead and try it.

Call this a problem with the statements rather than a problem with the
license; it's still a problem.

>> > Here's another example of how this sentence that bothers you so much
>> > can be made to be true: send the FSF $1 dollar for their permission to
>> > print the book.
>> 
>> No. That would have nothing to do with the factual correctness of the
>> claim that the FSF publishes copies.
> 
> That also has several solutions -- become a part of the FSF,
Not always an option, and it doesn't actually mean that the FSF publishes
copies.

> or provide 
> a disclaimer describing the issue.
Would have to go on the cover, and the original statement would still be
false.

> 
> That said, is this statement one that's in use on any books provided
> by the FSF?
Yes.  I gave the GCC example earlier.  :-)

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Sun, May 09, 2004 at 09:01:54AM -0400, Michael Poole wrote:
>> The exception is in 17 USC 117(a); it allows copying by the _owner of
>> a copy_ if it is either "an essential step in the utilization of the
>> computer program" or a backup copy.
> 
> Which, in the context of the GFDL covers a lot of ground (since anyone
> can become an owner, and the question is what happens after the person
> has lost copyright priviledges on copies they own).
No, it doesn't cover a lot of ground.  

First of all, these rights might not be allowed at all for something ruled
to not be a "computer program".

Second, "an essential step in the utilization of the computer program" is
very, very limited.  Creating a backup copy permits a little bit more, but
probably many reasonable uses (mirroring to hundreds of secure sites)
wouldn't qualify.

> There probably are scenarios where a reasonable person doing reasonable
> things could get in trouble from the GFDL's overly broad statement about
> technical measures on copying, but I've yet to see one that I consider
> a clear problem.
Well, we have.  :-)

> Nor have I been sufficiently clever to think one 
> up myself.

> The way I see it, if a person is going to get in trouble for using
> technical measures to prevent other people from making copies of some GFDL
> documentation there must be something systematic about this control --
> random efforts and random effects don't seem to constitute control.
It doesn't say that.  Or anything close to that.

Certainly, intent might matter.  Isolated, unsystematic efforts would almost
certainly count, though.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:


> On Mon, May 10, 2004 at 04:32:36PM -0400, Anthony DeRobertis wrote:
>> WTF? Have you read the GFDL?
> 
> Yes.
> 
>> "A 'Secondary Section' is a named appendix or a front-matter section of
>> the Document that deals exclusively with the relationship of the
>> publishers or authors of the Document to the Document's overall subject
>> (or to related matters) AND CONTAINS NOTHING THAT COULD FALL DIRECTLY
>> WITHIN THAT OVERALL SUBJECT." (emphasis added)
> 
> So?
> 
> There's nothing that says that the entire document must be composed
> of only secondary sections -- and near as I can tell this point you're
> trying to make would only make sense if the entire document could only
> be composed of secondary sections.

Huh?  Please try to think clearly, Raul.

The GNU Emacs Manual contains an Invariant Section -- a "Secondary Section"
-- called the "GNU Manifesto".

He wishes to make a derivative work, based on the GNU Emacs Manual, where
the overall subject is software freedom.

In order to legally make and distribute this derivative work under the GFDL,
(1) the derivative work must include the Invariant Section
(2) the derivative work must not include any Invariant Sections which are
not Secondary Sections (because no work licensed under the GFDL may do
that)

But the GNU Manifesto is not a Secondary Section for the derivative work. 
So these two conditions contradict each other, meaning that distribution of
the derived work is not permitted.

In other words, for the GNU Emacs Manual, no derived works whose main topic
is software freedom are permitted.  An accidental but extremely obnoxious
result.


-- 
There are none so blind as those who will not see.

Re: databases not copyrightable in the USA (was: CA certificates)

[Nathanael Nerode]

Humberto Massa wrote:

> Branden, in Brasil, the copyrights law (9610/98) makes databases
> copyrighted, IF and only if "their selection, organization, or the
> disposition of their content" is a novel intellectual creation. The CDDB,
> for example, would not be covered by this definition (its selection,
> organization and disposition content are automatically-generated). CA
> certificates (the original topic) aren't covered either because they are
> not novel intellectual creations (they also are automatically-generated).
> 
> In another topic, I prefer the term "copyrighted". "Copyrightable" is an
> ugly, ugly term... and everything that is copyrightable is copyrighted by
> default...

Well, except for those works for which copyright has expired or for which it
has been renounced?

This wasn't always the case, anyway; it used to be that you had to *do*
something to claim copyright on a published work.  That was a better
system.  :-/

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Sun, May 09, 2004 at 05:30:28AM -0400, Nathanael Nerode wrote:
>> Well, making a copy in RAM is making a copy, legally; this is apparently
>> the
>> caselaw in the US.  I'm sorry that I don't have the reference.
> 
> Loading a register might also also constitute copying, but in the
> U.S. that's already covered under fair use.  But then there's L1 cache,
> and the L2 cache which wouldn't be covered under fair use.
Well, they probably would be covered by the "essential step in the
utilization of the computer program" clause.

> And, in at least some cases, making a copy in RAM is equivalent to making
> a copy on disk (because of swap).  And then there's any cache on the
"essential step in the utilization of the computer program"

> It's conceivable that playing a sound recording could constitute making
> a copy in air.  Or that playing a video recording could constitute making
> a copy in light.
Nah, they don't.  The question in the US is whether something is "fixed in a
medium of expression".  That's settled.


> I maintain that any jurisdiction which allows for the execution of a
> propietary program (one which makes no provision for the user to make
> further copies) must have some sort of concept of reasonableness which
> grants the same sort of freedoms implicitly.

We wish.  :-)  Well, it has some concept of reasonableness, but it's very,
very, narrow.

-- 
There are none so blind as those who will not see.

Re: copyrightable vs. copyrighted (was Re: databases not copyrightable in the USA)

[Nathanael Nerode]

Andrew Suffield wrote:

> On Wed, May 12, 2004 at 02:36:14PM +0200, Martin Dickopp wrote:


> The proper terms for what you describe here are "copyright does not
> subsist in this work", where the verb is "subsist" (alternatively
> "copyright protection does not subsist", but even lawyers don't
> usually go that far).
"This work is not covered by copyright"?

>> It may, however, be
>> copyrightable, i.e. if another entity had created it, this entity would
>> have had the copyright w.r.t. the work.
> 
> This one isn't a word either. I don't think there is a formal name for
> this one, as it's not very interesting.

Actually, I think it's extremely interesting.

We need to refer to two different distinctions:

1. There is a valid copyright on the work. ("copyrighted")
2. The work is of a class or works for which copyright "protection" is
potentially available.  ("copyrightable")

Nowadays, nearly everything in class 2 is also in class 1.  However, it used
to be that being in class 1 depended on many additional things beyond the
nature of the work itself.

In the US, determining whether something is in class 2 depends on various
tests ("original work of authorship", not "facts", etc.), and then
determining whether it's in class 1 depends on further things (did the
copyright expire, was it created by the US Government, etc.).

-- 
There are none so blind as those who will not see.

Re: Theoretical Library License

[Nathanael Nerode]

Humberto Massa wrote:

> @ 10/05/2004 16:44 : wrote Benjamin Cutler :
> 
>>Humberto Massa wrote:
>>  
>>
>>>@ 10/05/2004 16:26 : wrote Benjamin Cutler :
>>>
>>>
>>>
>> >> **The library itself would be GPL.**
>>  
>>
> See below :-)
> 
>>I just added some additional freedoms/terms for people who want to make
>>commercial/proprietary/closed source programs with it, as the GPL as I
>>understand it requires programs using GPL libraries to be GPL
>>themselves.
>>  
>>
> But only if those are non-commercial... I think I understand what you
> want, some of the extra LGPL freedoms,  but in a narrower way. You can
> make it a GPL'd with exceptions, like:
> 
> "this library is distributed under the terms of the GNU GPL [[ , v2 or
> later at your option ]]; as an exception, you can link any proprietary
> program with this library or a modified version, PROVIDED said program
> is distributed ABSOLUTELY GRATUITOUSLY,
Please don't use this wording; it means something very funny (but not
useful) in ordinary English.

> and not under any other 
> circumstances, AND the distribution of the library continues to abide
> the terms of the GNU GPL. If you want to link your proprietary program
> with this library, contact cutler(at)something, that is the original
> copyrights holder, and ask for other terms of licensing". the part in
> [[]] is optional.
> 
> I hope this helps you, but my recommendation is still... go GPL pure and
> simple. I don't know if there is any good in making the library
> available to the "freeware" gratuitous, non-DFSG-free software hordes...
> :-)
> 

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Glenn Maynard wrote:

> On Fri, May 14, 2004 at 05:13:41PM -0400, Nathanael Nerode wrote:
>> volumes
> 
> Are you having a spooling problem?  Eighteen (and counting?) mails just
Maybe I am, actually.

> arrived in rapid succession, mostly to messages that are several days old.
> 
> If you're really churning out mails this fast, I'd strongly ask you to
> stop.  Joining a conversation late and replying to every post in the
> thread does not further the discussion; it's just mail flood.  Sum up
> your replies in one or two larger posts, especially considering you're
> mostly replying to the same person.  
It's hard.

> Mailbombs aren't helpful. 

-- 
There are none so blind as those who will not see.

Re: sendmail X license (fwd)

[Nathanael Nerode]

Richard A Nelson wrote:

> 
> I've been asked to run this by a larger audience...
> 
> They honestly want feedback, so I'll collect any
> thoughts/gripes/whathaveyou and send them back.
> 
"Use, modification and redistribution (including distribution of any
modified or derived work) of the Software in source and binary forms is
permitted only if each of the following conditions are met:"

Consider saying "...permitted provided all of the following..."

"...permitted only if each of the following..." is a restriction, but
doesn't actually grant permission.  I suspect courts would be kind and rule
that it was meant to, but you might as well get it right.

Moving on, clause 4 doesn't really belong in a copyright license, though
it's OK.

4. Neither the name, trademark or logo of Sendmail, Inc. (including
   without limitation its subsidiaries or affiliates) or its contributors
   nor the University of California or its contributors names may be
   used to endorse or promote products, or software or services derived
   from this Software without specific prior written permission. The
   name "sendmail" is a registered trademark and service mark of
   Sendmail, Inc.

Apparently none of these rights are granted regardless of whether you
specify this.  This belongs next to the disclaimers.

Clause 5 is problematic.
"We reserve the right to cancel this license if you do not comply with
   the terms."
Fine.

"This license is governed by California law"
OK.

"and both of us
   agree that for any dispute arising out of or relating to this Software,
   that jurisdiction and venue is proper in San Francisco or Alameda
   counties."
No we don't.  This is non-free.

-- 
There are none so blind as those who will not see.

Re: Should ipw2100-source be in contrib?

[Nathanael Nerode]

Josh Triplett wrote:

> Guido Trotter wrote:
>> The code for ipw2100 is free software. To load the driver you'll need a
>> firmware which is non-free and subject to an EULA (for details see
>> http://ipw2100.sourceforge.net/firmware.php?fid=2). Debian cannot thus
>> distribute this thing (the firmware), neither in main nor in non-free.
>> 
>> Now the point is: the source code itself doesn't need the firmware to
>> be built, but the resulting modules are completely useless without it.
>> 
>> So should this package go in contrib, or is it allowed to stay in main?
> 
> If the modules without the firmware are usable for any hardware (such as
> a version of the hardware that has the firmware permanently stored in
> it), the modules can stay in main, since at least some users can use it
> without installing non-free software.  If the modules cannot operate any
> piece of hardware without the non-free firmware, the modules must go in
> contrib.

Um, "what he said", just so you know it's not just his opinion.
I think there's consensus on this; it's basically what 'contrib' was
invented for.

-- 
There are none so blind as those who will not see.

Re: DFSG#3 (was Re: The draft Position statement on the GFDL)

[Nathanael Nerode]

Raul Miller wrote:

>> > What it actually says isn't enough for our purposes -- you could say
>> > it's too tolerant of licensing problems.
> 
> On Fri, May 14, 2004 at 05:59:25PM -0400, Nathanael Nerode wrote:
>> OK.  I would interpret it as meaning "must allow most modifications and
>> derived works".
>> 
>> > Unfortunately, the way that
>> > we express how it's interpreted is also inadequate -- what we say we do
>> > is actually less tolerant than what we actually implement.
>> 
>> What we say we do is something like this:
>> 
>> * prohibit most substantive restrictions on the content of derived works
>> * allow restrictions which appear not to be substantive
>> * allow requirements which prohibit things which would be illegal even if
>> the original work were in the public domain
>> * allow requirements that certain things accompany the distribution of
>> the derived work, but not (in general) requirements that those things be
>> *in* the derived work.
>> * allow requirements that certain accurate legal notices be present in
>> the derived work, provided that they don't substantively obstruct the
>> ability to make the derived work serve whatever purpose you want
>> * allow requirements that certain attributions be present in the derived
>> work, provided that they don't substantively obstruct the ability to make
>> the derived work serve whatever purpose you want
>> 
>> Does that sound reasonable?
> 
> That seems like very good coverage of this issue.
> 
> Do we say this somewhere?  [I've seen other people say things which would
> contradict these points, and would like to have something to refer to
> in the future.]

Huh.  Thinking about it, we don't.  :-/  Thanks very much for pointing that
out, Raul.

Um, whoever did the debian-legal web page (since my memory is terrible),
would you consider putting this summary on a page linked to it?

I release all copyright interests in that summary to the public domain, so
as to clear up any potential problems there.

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> Raul Miller <[EMAIL PROTECTED]> writes:
>> 
>> > On Tue, May 11, 2004 at 04:18:22PM -0400, Brian Thomas Sniffen wrote:
>> >> as the GFDL.  The parenthetical is false.  The GPL does not require
>> >> that it be included in the distributed work, merely with the
>> >> distributed work.
>> >
>> > I don't think this is a very meaningful distinction, for the context I
>> > was discussing.
> 
> On Tue, May 11, 2004 at 07:36:04PM -0400, Brian Thomas Sniffen wrote:
>> The distinction is very important when discussing the freeness or
>> non-freeness of the GFDL.
> 
> But this was the GPL, not the GFDL.
> 
>> > Given that the GPL applies only when a notice is contained in the
>> > work,
>> 
>> That is not true.  For example, I have next to me a watercolor
>> painting licensed under the GPL.  The work itself does not contain a
>> notice; rather, there is a tag next to it which gives its title,
>> copyright information, and the fact that it is licenses to all those
>> who receive a copy -- though not all viewers -- under the terms of the
>> GNU GPL, version 2.
> 
> If the work doesn't contain a notice, the GPL doesn't say that it applies.
It does anyway, if my notice says it applies.

> Of course for copyright purposes it might be reasonable to say that the
> painting and the notice together are contained in the work.
No.  That's not right; it would imply that the copyright over the work
applied to the notice, which it doesn't.

>> Similarly, I could hand you a book and tell you that I license to you
>> all my rights in that book under the terms of the GPL, and the GPL
>> would apply.
> 
> And if you lied?
> 
> Or changed your mind?
> 
> Or if I lied?
> 
> How could a judge know that I wasn't lying when I tell him you said it
> was a GPLed work?

You kept a copy of the notice, didn't you?  :-)  Perhaps you recorded
Brian's verbal statement?

>> > and given that you must keep that notice intact, ... well you still
>> > have the notice (or notices), which you must leave intact, that's still
>> > -- in the fully general sense that some people seem to want to use --
>> > a restriction on modifications to the work.
>> 
>> You are incorrect due to overgeneralization.  You must leave a notice
>> iff there was a notice.  But, for a start, that is only a mark on the
>> source code.  It need not impact the compiled program at all.  That
>> is, it must be visible to one inspecting the program, but not to one
>> using the program.  You must also leave the notice on an interactive
>> program intact, but that is also a much weaker limitation -- it does
>> not apply to noninteractive programs, for example.
> 
> Are you trying to argue that a GPLed binary is a work independent from
> the sources it's built from?

No, he isn't.  Why would you think that?

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

> On Wed, May 12, 2004 at 08:55:21PM +0100, Henning Makholm wrote:
>> I really don't see where you are getting at. Can you explain in little
>> words and with lots of intermediate results why you think that a GCC
>> modified for you hypothetical environment would be non-distributable?
> 
> Because it incorporates functionality implemented in proprietary code.
> [This would be functionality you're not legally allowed to reverse
> engineer.]

Either it
(1) incorporates the proprietary code.  Here it is a derivative work of the
proprietary code.  In this case, you need a license from the copyright
holder of the proprietary code in order to distribute.  If you have an
appropriate one, you can distribute under the GPL.  If not, you can't.
(2) doesn't incorporate the proprietary code, instead connecting to it at an
published, freely usable interface.  Here it is not a derivative work of
the proprietary code.  In this case, it's free and freely distributable,
but it depends on non-free software to function, so it's "contrib".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> On May 10, 2004, at 07:16, Raul Miller wrote:
>> > Note that content under a "patches only" license will give you much
>> > worse problems when incorporating it (perhaps as examples, or perhaps
>> > pulling documentation from a help menu item) into other documentation.
> 
> On Mon, May 10, 2004 at 04:37:49PM -0400, Anthony DeRobertis wrote:
>> Not really, because we can distribute "compiled" versions of that
>> (which don't have all the sillyness).
> 
> Even if that code includes a class browser and allows introspection into
> its implementation?
> 
>> [BTW: A lot of folks here want to get rid of that clause of the DFSG]
> 
> After the recent experience with "cleaning up the language in the social
> contract", I expect to eventually find out that those folks haven't
> thought things through very far.

That was done under the "Social Contract != DFSG" theory, and it was thought
through very far.  :-)  The DFSG also deserves some serious cleanup, though
at least it claims to be "guidelines", not a "contract".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:

>> > Given that "arbitrary functional modifications" would include illegal
>> > activities
> 
> On Tue, May 11, 2004 at 02:59:14PM +0100, Henning Makholm wrote:
>> It does. A license that tries to incorporate "you must follow the law"
>> clauses is non-free. That is a longstanding and clear consesnsus on d-l.
> 
> That's good as far as it goes.
> 
> However, that doesn't go very far when dealing with issues of
> interoperation and creation of derived works.
> 
>> > I don't think that "arbitrary functional modifications" is a very
>> > accurate representation of what the DFSG is really trying to allow for.
>> 
>> I think you're badly wrong here.
> 
> So, in essence, you think that the DFSG says we must disallow the
> distribution of gcc if its license prevents you distributing copies which
> have been functionally modified to better integrate with microsoft's
> palladium?

If it explicitly prohibited that, yes, that would be a non-free license. 
Thankfully, it doesn't.

> And, if that is what you think, perhaps you can explain how this point of
> view has our users and the free software community as its top priorities?

Because it's about whether it's free software or not.

Fine point: it's not the "free software community" which is the priority;
it's "free software".  Releasing your software under a non-free license
might conceivably help the "free software community", but does not help the
priority of "free software".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Raul Miller wrote:



> On Tue, May 11, 2004 at 09:18:28PM +0100, Henning Makholm wrote:
>> Why not?
> 
> Because palladium is a proprietary work, and it's more than just an OS.
> 
> I'll grant that if the changes were limited to what was required to get
> the OS to support it, that would probably be distributable.  But that's
> not the kind of example I was proposing.
> 
> I was not proposing "make gcc work on that OS", I was proposing functional
> modifications to GCC to make it integrate better with that environment.
> 
> As a rough idea, imagine if gcc were made to support special keywords or
> control files to make it easier to build programs which use palladium's
> proprietary encryption and digital rights management facilities object
> model.  Or, more generally, imagine any change which makes gcc into
> something that works in a proprietary fashion.

It already has special support for the Windows registry.  And support for
outputting assembly language which can only be assembled with proprietary
assemblers.  What's your point?

This would be a piece of "free software" which depended on a piece on
"non-free software" to function.  In other words, it would be "contrib".

-- 
There are none so blind as those who will not see.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Brian Thomas Sniffen wrote:

Nathanael Nerode <[EMAIL PROTECTED]> writes:



* allow requirements which prohibit things which would be illegal even if
the original work were in the public domain



The summary is overall excellent, but I disagree with this one point.
In general, choice-of-law and "you must obey the laws of Kazakhstan
with respect to this work" clauses are non-Free, as are "you may not
speed while copying this work" clauses.


Yes... I'm not actually sure we're in disagreement.

We have allowed clauses of the fairly narrow form "You must not do thing 
X with this work if it is illegal to do so in your jurisdiction" before, 
though I don't care for such stupid clauses.  (We have not allowed 
clauses which require you to follow laws not present in your jurisdiction.)


We've also allowed choice-of-law clauses, which say "This license should 
be interpreted under the laws of Kazakhstan", provided the laws of 
Kazakhstan are fairly normal.  We have not allowed choice-of-*venue* 
clauses, which say that all suits must take place in Kazakh courts.




-Brian

Re: sendmail X license (fwd)

[Nathanael Nerode]

Walter Landry wrote:
>Rather, they would file in California court, because that is where
>California law is decided.  The whole point of choice of law clauses
>is to force everything to happen in a particular place.

No; to my knowledge, this is simply wrong.  California law can be decided in 
federal court, or even New York court, and sometimes is.  It is quite 
possible to have a contract between two New York citizens which specifies 
that it is to be interpreted under Virginia law (perhaps because one of the 
contract signers was a Virginia citizen when the contract was originally 
signed); it will be interpreted in a New York court (which has jurisdiction 
and is an appropriate venue), but details of Virginia law may matter.

The point of choice of *venue* clauses is to force everything to happen in a 
particular place.  The point of choice of *law* clauses, in contrast, is to 
make the meaning of a legal document more definite.  For instance, if a 
document talked about "community property", different states have different 
definitions, and a choice of law clause would determine which definition 
would be used.

Judges don't particularly like ruling on the meaning of laws of another state 
or country, but they can and do do so.
 

Re: IBM Public License (again)

[Nathanael Nerode]

Walter Landry wrote:
>But the venue doesn't necessarily favor one party over the
>other.

Both sides waiving the right to a jury trial?  Yes, it doesn't necessarily 
favor one party over the other.  (Neither does choice of venue, which we also 
Don't Like.)  I still think it's non-free; I mean, gee, in this country, jury 
trials are a *Constitutional* right.  It fails the smell test.

Re: copyrightable vs. copyrighted (was Re: databases not copyrightable in the USA)

[Nathanael Nerode]

Andrew Suffield wrote:
>I don't see what's so interesting about the group of things in which
>copyright would subsist if the world were different.

Perhaps you've missed the point.  I'll try more detail:

Whether there exists a valid copyright on a work depends on
* aspects intrinsic to the work
* aspects extrinsic to the work

"copyrightable" is generally used to refer to a work such that all the aspects 
intrinsic to the work allow there to be a valid copyright on the work, 
without considering aspects extrinsic to it.

One task is to determine whether the aspects intrinsic to the work prevent 
there from being a valid copyright on it; this can be done with just the 
work.

Determining whether aspects extrinsic to the work prevent there from being a 
valid copyright on it is a rather different process requiring almost entirely 
different information.  Often people will do the first task and not the 
second, so they want a word for what they've figured out.

Re: The draft Position statement on the GFDL

[Nathanael Nerode]

Henning Makholm wrote:

> Scripsit Nathanael Nerode <[EMAIL PROTECTED]>
> 
>> We have allowed clauses of the fairly narrow form "You must not do
>> thing X with this work if it is illegal to do so in your jurisdiction"
>> before, though I don't care for such stupid clauses.
> 
> If we have, we shouldn't have. Such clauses fail the dissident test.
I think you're right.  I'm quite sure these have been allowed in the past. 
You have convinced me that they shouldn't be allowed.  :-)

> Imagine that the work in question is an encryption tool, and that
>  has a local law
> forbidding the possession and distribution of cryptographic
> programs. Our friend the dissident nevertheless distributes the
> program and afterwards miraculously escapes to the free world.
> 
> If the license for the work has a "you-must-follow-local-law" clause
> the dissident will now risk being sued by the author for breach of
> license terms.

Yes.  That doesn't sound free, does it?

> Free software must be free for dissidents too.
> 
> 
> (Or instead of the encryption, it could be *any* piece of software,
> and  could have a local law against women engaging in software
> distribution, or against distribution of any software not specifically
> allowed by government censors).

-- 
There are none so blind as those who will not see.

Re: IBM documentation license

[Nathanael Nerode]

Eduard Bloch wrote:

> Hello,
> 
> I have problems interpreting the following copyright statement which
> covers the documenting of the ICU library from IBM (which itself is
> free). IMHO it is non-free, however it is full of juristical english and
> may be acceptable for main if one can extract the relevant parts from
> all the blah, blah. The most interessting part is on the bottom of the
> text.
> 
> Permission to Reprint IBM Copyrighted Publications
> 
>   INTERNATIONAL BUSINESS MACHINES CORPORATION ARMONK, NEW YORK 10594
> 
>   PERMISSION TO REPRINT IBM COPYRIGHTED PUBLICATIONS
> 
>   IBM grants permission to reproduce the requested copyrighted
>   publication owned by INTERNATIONAL BUSINESS MACHINES CORPORATION
>   under the conditions specified.
Grants permission to reproduce; nothing else.  Debian needs more.

>   Such reproduction must be accompanied by the following credit
>   line: "Reprinted by permission from International Business
>   Machines Corporation copyright (year)" which should include the
>   years in the original copyright notice for publication named.
Acceptable restriction.

>   The 
>   credit line normally should appear on the page where the
>   reproduction appears either under the title or as a footnote.
Unsure, but "normally should" seems to give some broad leeway.

>   When more than one IBM publication is excerpted in the same
>   publication, a consolidated credit paragraph may be used on the
>   title page, or in a conveniently viewable manner, listing the
>   titles, corresponding copyright notices, and references to the
>   points where excerpts appear.
That's good.

>   It is the understanding of INTERNATIONAL BUSINESS MACHINES
>   CORPORATION that the purpose for which its publications are being
>   reproduced is accurate and true as stated in your attached
>   request.
So the permission only applies to a specific "attached request"?...

>   Permission to quote from or reprint IBM publications is limited to
>   the purpose and quantities originally requested and must not be
>   construed as a blanket license to use the material for other
>   purposes or to reprint other IBM copyrighted material.
...Yep, it does.  That's not a free license.  It may be distributable in
'non-free' if you write your "attached request" broadly enough.  :-)

>   IBM reserves the right to withdraw permission to reproduce
>   copyrighted material whenever, in its discretion, it feels that
>   the privilege of reproducing its material is being used in a way
>   detrimental to its interest or the above instructions are not
>   being followed properly to protect its copyright.
Non-free.

>   No permission is granted to use trademarks of International
>   Business Machines Corporation and its affiliates apart from the
>   incidental appearance of such trademarks in the titles, text, and
>   illustrations of the named publications. The appearance should not
>   be of a manner which might cause confusion of origin or appear to
>   endorse non-IBM products. Any proposed use of trademarks apart
>   from such incidental appearance requires separate approval in
>   writing and ordinarily cannot be given.
This is fine; trademark protection clauses should all look like this.

>   THIS PERMISSION IS PROVIDED WITHOUT WARRANTY OF ANY KIND, EITHER
>   EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED
>   WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>   PURPOSE.
Fine, usual disclaimer.

> Notices

These are all informational and do not actually affect the license, as far
as I can tell.

>   COPYRIGHT LICENSE:
> 
>   This information contains sample application programs in source
>   language, which illustrates programming techniques on various
>   operating platforms. You may copy, modify, and distribute these
>   sample programs in any form without payment to IBM,
This is a license grant for the 'sample programs', and it's a broader
license grant than the general grant for the 'documentation'...

>   for the 
>   purposes of developing, using, marketing or distributing
>   application programs conforming to the application programming
>   interface for the operating platform for which the sample programs
>   are written.
...and this is a non-free restriction.

>   These examples have not been thoroughly tested under all
>   conditions. IBM, therefore, cannot guarantee or imply reliability,
>   serviceability, or function of these programs.
Usual disclaimer.

>   If you are viewing this information softcopy, the photographs and
>   color illustrations may not appear.
Informational, no effect.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Henning Makholm wrote:

> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*.
Well, I like the approach a lot.

> I think that such a revision 
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.
> 
> My results so far are at
>
> 
> Comments will be appreciated - both about the general angle of attack,
> and about my specific draft. I have probably forgotten about a detail
> here and there.

Some nitpicks:

4C:
"A license text is a self-contained text that describes the authors' licence
grants. Short rationales such as the Preamble to the GNU General Public
License, version 2, are taken to be included in this concept. It is in
general a judgement call whether a legally irrelevant piece of text is
sufficiently related to the license grant to be piggy-backed onto the
license text in this way. "

I actually don't think the GPL Preamble is entirely legally irrelevant; it
would presumably color the legal interpretation of the GPL if a question of
interpretation came up.

"The license text itself may be excluded from the right to create derived
works.  (Several popular license texts explicitly forbids derivates of
 themselves. Debian strongly recommends that authors of license texts allow
them to be used by others for deriving license texts for their own works.)"

Typo, should be "derivatives", not "derivates".  But it would be better to
rewrite the sentence.

Also, it should be made clear that this exception does not apply to license
texts shipped on their own, rather than as the licenses for something.

Also, it's not just license texts which get a special break; other legal
recitations, sich as warranty disclaimers, are also allowed to be
non-modifiable.

5B:
..."A free license cannot require that the user notices the author prior
to..."

5C:
"A free license cannot require that the user takes any explicit action to
express agreements to its terms - even trivial actions such as clicking on
OK buttons."
Add clarification:
(The license can specify that exercising the rights granted by the license,
absent alternative permissions, will be interpreted as acceptance of the
license.)

5O:
"A free license cannot require that the user agrees to accept a specific
legal venue in the case that the author later decides to sue him."

Clarifications here about the exact meaning of 'venue' vs. 'law', etc, so
that the usual confusions don't pop up?

--
And a non-nitpick.

I would be quite comfortable allowing patent "retaliation" restrictions, but
only if they were very carefully tailored.  Specifically, license rights
must terminate only if the work is alleged to constitute patent
infringement (no action based on unrelated causes), and they must terminate
only for the person who alleged that it did (no harming third parties).

Well, these were just some thoughts.  Have fun with them.

-- 
There are none so blind as those who will not see.

Re: libkrb53 - odd license term

[Nathanael Nerode]

Glenn Maynard wrote:

>OpenVision also retains copyright to derivative works of the Source
>Code, whether created by OpenVision or by a third party.
This sounds completely unacceptable, if it means what it says.  It's also
probably invalid in the US.  Copyright assignments must be signed and on
paper; and OpenVision can't "retain" copyrights it never had in the first
place.

Perhaps it simply means that they retain copyright in their portions, not
that they're stealing your derivative works.  That would require a
statement from the copyright holder before I'd belive it, though.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

>> Scripsit Nathanael Nerode <[EMAIL PROTECTED]>

>> > I would be quite comfortable allowing patent "retaliation"
>> > restrictions, but
>> > only if they were very carefully tailored.  Specifically, license
>> > rights must terminate only if the work is alleged to constitute patent
>> > infringement (no action based on unrelated causes), and they must
>> > terminate only for the person who alleged that it did (no harming third
>> > parties).


Andrew Suffield wrote:
> I recommend the following:
> 
> Phrase the proposed restriction in a way that is not specific to
> patents. Then construct a scenario where you apply it to copyright. Is
> it still an acceptable restriction?

The essence of what I would accept is this:

"If you claim, legally, that my work can't be distributed/used/modified
freely by people in general, then *you* can't distribute/use/modify my work
either".  A "if you think this should happen to everyone else, it should
happen to you too" clause.

This prevents people from actually literally taking free software
proprietary (not just derivative works, but the originals) -- this could
otherwise be done using patents.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> As a brief observation unrelated to this subthread: this also implicitly
> deals with the GPL#8 problem, by not requiring any special casing for
> the GPL at all.
> 
> On Tue, Jun 01, 2004 at 12:00:03AM +0100, Andrew Suffield wrote:
>> I'd like to append something like the following:
>> 
>> The license may not place further constraints on the naming or
>> labelling of the derivative work. This includes specifying the form of
>> such notices, or the manner in which derivative works must be named.
> 
> /usr/share/doc/apache/copyright
> 
> 5. Products derived from this software may not be called "Apache",
>nor may "Apache" appear in their name, without prior written
>permission of the Apache Software Foundation.
> 
> I think that this is something that shouldn't have been allowed, but has
> since become extremely widespread, and it probably wouldn't be productive
> to start rejecting it--it's a problem, but a relatively minor one.

It's been allowed mostly because they don't really enforce it.  For
instance, Debian's modified version of Apache, which is a derived work, has
"apache" in its name.  Furthermore, they've stated that they don't intend
to enforce it strictly, and it's not present in the new license.

I certainly wouldn't accept this clause in a license without additional
assurances from the copyright holder.  We said as much to X-Oz.

>> > N. Acknowledgements in documentation
>> 
>> > The license for a free program may require that end-user
>> > documentation which accompanies the program contains a short
>> > acknowledgement that credits the author.
>> 
>> That's horrible. This could mean that we have to include the blasted
>> things in the release notes. Survey of licenses and a tighter
>> restriction before we write this one in, please. I'm not sufficiently
>> familiar with such clauses to be able to pull one out of the air.
> 
> /usr/share/doc/apache/copyright
> 
> 3. The end-user documentation included with the redistribution,
>if any, must include the following acknowledgment:
>   "This product includes software developed by the
>Apache Software Foundation (http://www.apache.org/)."
>Alternately, this acknowledgment may appear in the software itself,
>if and wherever such third-party acknowledgments normally appear.

They normally appear in /usr/share/doc/*/copyright, in Debian.  :-)  Does
that make a difference?  I think this is a "loose" clause.

> 
> (I only realized recently how horrible this license is.)
> 

-- 
There are none so blind as those who will not see.

Re: ipw2100 firmware distributable?

[Nathanael Nerode]

Sebastian Ley wrote:

> Hello legal wizards,
> 
> I need some advice about a license, my legal-english is not enough to
> determine whether the ipw2100 (popular wifi chipset) firmware by Intel
> is distributable in non-free.
> 
> The license can be found here:
> http://ipw2100.sourceforge.net/firmware.php?fid=2
> 
> My problems are:
> - Are we as Debian project a OEM or ISV?
ISV.

> - Since Intel requires an acceptance of this EULA, would I need to
>   gather that acceptance too?

It looks, in fact, like all mirror operators would have to accept it.

That makes it undistributable.

> - If it is not redistributable, may I add a downloading feature to the
>   postinst?
Legally, yes, if the downloading feature forces the end-user to go through
the EULA and all that crapola.

Technically, it seems nasty to have a postinst prompt the user to accept a
EULA; if installation is in noninteractive mode, you'd have to refuse to
download.

In conclusion: EWW!

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> On Wed, Jun 02, 2004 at 08:12:28PM -0400, Nathanael Nerode wrote:
>> It's been allowed mostly because they don't really enforce it.  For
>> instance, Debian's modified version of Apache, which is a derived work,
>> has
>> "apache" in its name.  Furthermore, they've stated that they don't intend
>> to enforce it strictly, and it's not present in the new license.
>> 
>> I certainly wouldn't accept this clause in a license without additional
>> assurances from the copyright holder.  We said as much to X-Oz.
> 
> libssl-dev/copyright: *nor may "OpenSSL" appear in their names without
> prior written

Eeeew.  Well, isn't OpenSSL well on its way to being replaced by GnuTLS in
Debian anyway?

> apache-utils/copyright: nor may "mod_ssl" appear in their names
> without prior

Ewww

> php4/copyright: may "PHP" appear in their name, without prior written

Ow.  Debian is clearly violating the PHP4 licence unless capital letters vs.
small letters are significant.  Better contact the copyright holders.

> permission subversion/copyright:nor may "Tigris" appear in their names
> without prior written

Perhaps Tigris could be contacted?  Interestingly, Debian is actually
*complying* with this license, unlike the others, since "Subversion" isn't
named "Tigris".

> and a particularly evil one,
> 
> sudo/copyright:  may "Sudo" appear in their names without specific
> prior written

Again, unless capitalization is significant, Debian is violating the terms
of this license.  Someone (not me) should contact the copyright holder.

Thanks for pointing these out.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> On Wed, Jun 02, 2004 at 09:14:23PM -0400, Nathanael Nerode wrote:
>> > php4/copyright: may "PHP" appear in their name, without prior
>> > written
> 
> I should have quoted this one in full:
> 
>   4. Products derived from this software may not be called "PHP", nor
>  may "PHP" appear in their name, without prior written permission
>  from [EMAIL PROTECTED]  You may indicate that your software works in
>  conjunction with PHP by saying "Foo for PHP" instead of calling
>  it "PHP Foo" or "phpfoo"

The big problem is that Debian's PHP4 package *is* a product derived from
that software; just look at the diff, which contains significant changes. 
And Debian's package doesn't fall under the exception in the second
sentence, because it's called "php4".  If it were called, uh, "Debian for
PHP4", I suppose it might.

I don't think the PHP copyright holders thought about what their clause
actually meant under copyright law.  :-P  (Accordingly, I'd hope they'd be
willing to clarify what they meant -- or ideally fix their license -- but
they had better be contacted.)

-- 
There are none so blind as those who will not see.

Re: libkrb53 - odd license term

[Nathanael Nerode]

MJ Ray wrote:

> On 2004-06-03 02:19:55 +0100 Walter Landry <[EMAIL PROTECTED]> wrote:
> 
>> If they really meant to "steal" the work, then the whole license may
>> be invalid.  In which case, Debian has no permission to distribute at
>> all.  So I think a clarification is definitely in order.
> 
> Why? What form should such a clarification request take? "Are you a
> gibbering fool who interprets the licence in an obscure,
> counter-intuitive, absurd manner that is impossible in any
> jurisdiction we've heard about yet?"

Well, actually, I only know that copyright assignments need to be signed and
in writing in the *US*; I have no reason to think that an "all your
derivative works are belong to us" is invalid anywhere else.  I wouldn't be
in the least surprised if it was valid.

> seems the appropriate form to me, 
> but is hardly diplomatic.

"Do you mean to claim copyright on other people's work based on yours, or
just to retain your copyright on the portions of your work which they used? 
The wording is unclear to us, sorry."

> We should seek this clarification from all holders of copyrights
> affecting debian. Any of them might interpret their licence in an
> invalid way by redefining the words.
> 
> Seriously, was there ever been a successful claim of copyright
> assignment on the basis of one of these clauses?

I don't know.  If there was even one, I would be worried.

-- 
There are none so blind as those who will not see.

Re: Bug#251983: libcwd: QPL license is non-free; package should not be in main

[Nathanael Nerode]

Carlo Wood wrote:

> On Thu, Jun 03, 2004 at 10:15:26PM -0400, Walter Landry wrote:
>> As for 6c, I am convinced by the arguments in
>> 
>>   http://lists.debian.org/debian-legal/2003/03/msg00626.html
>>   http://lists.debian.org/debian-legal/2003/03/msg00626.html
>> 
>> which render its problems moot.  As long as the original author
>> agrees with that interpretation, the only problem left is the choice
>> of venue.
> 
> Assuming the second link was ment to be
> http://lists.debian.org/debian-legal/2003/03/msg00519.html
> 
> then yes, I think that is the correct interpretation.

OK.  Since you confirm that interpretation, then that clause is fine.  :-) 
Hooray!  Perhaps a link to that specification of the interpretation and
your confirmation of it should be put somewhere.  (In the package copyright
file?  On the debian-legal page?)


> If this is agreed upon by everyone - then it makes sense to talk
> about the choice of venue versus choise of law thing.
> Provided that libcwd WILL be included in Debian, I am willing to
> change the wording of the last sentence into one that only states
> a choice of law, not venue.  But then it must be very clear that
> that is enough for making the license pass DFSG as such a change
> would be irrevocable.

Well, we went over it very carefully, and those two were the only problem
issues we saw.  I would be willing to say that that was enough, though I
obviously can't speak for everyone, let alone future generations of
debian-legal.

-- 
There are none so blind as those who will not see.

Re: Which license for a documentation?

[Nathanael Nerode]

MJ Ray wrote:

> On 2004-06-04 11:43:45 +0100 Matthieu Delahaye <[EMAIL PROTECTED]>
> wrote:
> 
>> [...] I just want to know if there is a list of
>> common license for documentation that are definitively known to be
>> DFSG
>> free.
> 
> I'm not sure about definitive, but generally most DFSG-free licences
> would work for any software and there are benefits from having your
> manuals under the same licence as your program.
> 
> Related, is the following licence DFSG-free:
> 
> "I grant permission to you to do any act with my work. Please ask me
> to link to mirrors. Please link to this site and credit the
> contributors. No warranty offered and no liability accepted."

I would assume so, because 'any act' is pretty damn broad.  This grants
permission to do anything you could do with a public domain work, read
literally.

However, there may be jurisdictions in which certain acts are assumed to be
excluded from 'any act' unless explicitly listed.  (Stuff like that happens
with warranties.)  Anyone know enough of the law to know whether there are
any 'catches' like that?

> ?  Also, does it seem legally useful?

-- 
There are none so blind as those who will not see.

Re: Which license for a documentation?

[Nathanael Nerode]

Måns Rullgård wrote:

> MJ Ray <[EMAIL PROTECTED]> writes:
> 
>> On 2004-06-04 11:43:45 +0100 Matthieu Delahaye <[EMAIL PROTECTED]>
>> wrote:
>>
>>> [...] I just want to know if there is a list of
>>> common license for documentation that are definitively known to be
>>> DFSG
>>> free.
>>
>> I'm not sure about definitive, but generally most DFSG-free licences
>> would work for any software and there are benefits from having your
>> manuals under the same licence as your program.
>>
>> Related, is the following licence DFSG-free:
>>
>> "I grant permission to you to do any act with my work. Please ask me
>> to link to mirrors. Please link to this site and credit the
>> contributors. No warranty offered and no liability accepted."
> 
> Wordings like "please" don't seem to carry much legal value, so I
> suppose it might even be GPL compatible, though I guess some would
> frown upon the request for credit.

Nobody here would do so, just so you know.  :-)

I think this license is actually legally nearly equivalent to giving the
work to the public domain.

-- 
There are none so blind as those who will not see.

Re: Which license for a documentation?

[Nathanael Nerode]

Matthieu Delahaye wrote:

> Hi,
> 
> I'm currently working on a correct debianisation of uC++ [1] with their
> author. They already provide debian packages but they are not 100%
> respecting Debian policies.
> 
> The author wrote a consistent manual for this software [2]. Currently the
> "license" is not usable to be uploaded under Debian. It says:
> 
> "Permission is granted to make copies for personal or educational use"
> 
> They are ok to change the license of this document so that it can
> be DFSG free.
> 
> Now the question is which one they should use.

He should use the same license as he uses for the program itself.  This has
a ridiculous number of advantages over any other choice.

> The problem of a 
> documentation license is not new and there is still some discussion
> about the freeness of some of them.
> 
> My aim here is not to start a discussion about should these previous
> license be free or not free. I just want to know if there is a list of
> common license for documentation that are definitively known to be DFSG
> free.
> 
> Thanks in advance,
> 
> Matthieu Delahaye
> 
> [1] : http://plg.uwaterloo.ca/~usystem/uC++.html
> [2] : ftp://plg.uwaterloo.ca/pub/uSystem/u++-5.0.ps.gz

-- 
There are none so blind as those who will not see.

Re: Which license for a documentation?

[Nathanael Nerode]

Josh Triplett wrote:

> MJ Ray wrote:
>> Related, is the following licence DFSG-free:
>> 
>> "I grant permission to you to do any act with my work. Please ask me to
>> link to mirrors. Please link to this site and credit the contributors.
>> No warranty offered and no liability accepted."
> 
> "Please link to this site" seems non-free to me.
But it's a request, not a requirement.  :-)

> What if you are making 
> a copy in a medium which does not support links?  What if the copy will
> be behind a restrictive firewall that doesn't allow access to external
> websites?  What if your site goes down, or is replaced by something
> people don't want to link to?  Also, if you copied the software from a
> mirror, does "this site" refer to the original or a mirror?
> 
> If by "Please ask me to link to mirrors." you mean "If you want me to
> put a link to your mirror on my site, ask.", then that clause is fine,
> but really shouldn't be part of the license.

Technically, the actual license is:
"I grant permission to you to do any act with my work."
The rest is not part of the license grant.

> It is not related to 
> copying the work; it just provides information about how to get your
> mirror listed on the official site.
> 
>> ?  Also, does it seem legally useful?
> 
> Depends, what are you trying to achieve?
> 
> - Josh Triplett

-- 
There are none so blind as those who will not see.

Re: Creative Commons Attribution license element

[Nathanael Nerode]

Evan Prodromou wrote:

> Making our organization's ideas known to Creative Commons could have
> meant a better suite of licenses for the 2.0 release. Instead, the
> opportunity was missed. As far as I know, the above-mentioned analysis
> wasn't forwarded to Creative Commons before today.
How disturbing.  I think we thought it had been.


> But requiring attribution to the original author does not appear to me
> to be that kind of burden. In particular, the license makes it clear
> that you must "give the Original Author credit reasonable to the
> medium or means You are utilizing". A Licensor could not abuse this
> requirement by making Attribution impractical -- say, by providing a
> 5-terabyte name or title. Licensees are only required to give
> Attribution in a reasonable way.


Actually, I think most of clause 4b is fine; it's only one little bit of it
which is troublesome.  I will now analyze it carefully:

>From clause 4b:
>If you distribute, publicly display, publicly perform, or publicly
>digitally perform the Work or any Derivative Works or Collective Works, 
>You must keep intact all copyright notices for the Work 
So far free.

>and give the Original Author credit reasonable to the medium or means You
>are utilizing by conveying the name (or pseudonym if applicable) of the
>Original Author if supplied; 
I think this is a reasonable and free requirement.  It's trivial and easy,
and amounts to nothing more than proper attribution.

>the title of the Work if supplied;
This is a stronger requirement, but I also think this is reasonable and a
free requirement.  This *does* correspond vaguely to requiring appropriate
references to prior work (as is done in scientific papers), unlike some
other things we've discusses.  Also, it's standard practice in the free
software community.

>to the extent reasonably practicable, the Uniform Resource Identifier, if
>any, that Licensor specifies to be associated with the Work, unless such
>URI does not refer to the copyright notice or licensing information for the
>Work; 
Well, I think this is barely free, though it's a little silly.

>and in the case of a Derivative Work, a credit identifying the use of the
>Work in the Derivative Work (e.g., "French translation of the Work by
>Original Author," or "Screenplay based on original Work by Original
>Author").
Likewise this is a reasonable and free requirement.

>Such credit may be implemented in any reasonable manner;
Great!  In other words, for Debian, we put it in the copyright file along
with all the other credits.  Or we put it in a CREDITS file or a
CONTRIBUTORS file or a NOTICES file.  Or next to the copyright notices in
the files.  Or whatever.  Except then there's this next clause

>provided, however, that in the case of a Derivative Work or Collective
>Work, at a minimum such credit will appear where any other comparable
>authorship credit appears and in a manner at least as prominent as such
>other comparable authorship credit.

*This* is the problem clause.  It's unclear to most of us exactly what "any
other comparable authorship credit" means.  If it means "the credit given
to any other author who wrote approximately the same amount of the
material" -- then it might possibly be a free requirement, or it might not
(I'm not sure, since I haven't thought about it); but it's ceratinly an
ugly requirement.  If it means "the credit given to any other author of the
same work", it certainly isn't.  If it means something else, I have no
idea.

With this ambiguity, the "at least as prominent" requirement is then a
potential interpretation nightmare.  Suppose, for a silly and extreme
example, you wanted to use a huge hunk of material under this license in a
version of ReiserFS, so that the code under this license needed a
"comparable authorship credit" to Reiser's.  Would that mean that the
credit would have to appear in the FS name, so as to be in the same
location and at least as prominent as Reiser's credit?  Yeech.

"Prominent" credit requirements are the specific type of credit requirements
we've been objecting to.  They cause endless trouble in a way that ordinary
credit requirements do not.

This might be fixable with a clarification, or a lawyer's opinion on what
exactly it *means*, rather than a license change.

Evan wrote:
> 2) I agree with this one. The intention appears to be to allow
> copyright holders to avoid having their name used in advertisement, a
> la the BSD, but in an opt-out rather than opt-in fashion.
> 
> However, as stated, it would indeed allow a license holder to prevent
> _any_ mention of themselves in derivative works. This could severely
> limit the licensee's freedom. An example would be an annotated version
> of a work that critiques the writer, or an autobiography that is
> revised to include critical comments or facts about the writer.
> 
> It would probably be useful to modify the license to show that the
> licensor can revoke the Attribution requirements, but not prevent
> 

Re: Mozilla Public License is non-free: stipulates court venue ?

[Nathanael Nerode]

Jim Marhaus wrote:

> 
> Hi all -
> 
> With the recent discussion about choice of venue, I was wondering about
> the Mozilla license. Specifically, the Mozilla Public License v. 1.1 [1]
> seems to contain a choice of venue clause in section 11:
> 
> | With respect to disputes in which at least one party is a citizen of, or
> | an entity chartered or registered to do business in the United States of
> | America, any litigation relating to this License shall be subject to the
> | jurisdiction of the Federal Courts of the Northern District of
> | California, with venue lying in Santa Clara County, California, with the
> | losing party responsible for costs, including without limitation, court
> | costs and reasonable attorneys' fees and expenses.
> 
> http://www.mozilla.org/MPL/MPL-1.1.html
> 
> As discussed recently, choice of venue clauses may be non-free, because
> they require parties to travel unreasonable distances to avoid summary
> decisions against them. Does this clause make the MPL non-free?

I believe so.  Doesn't Debian use Mozilla under the GPL/LGPL license option
though?  (In other words, is anyone using the MPL in a way that matters to
Debian?)

Re: license change for POSIX manpages

[Nathanael Nerode]

Andre Lehovich wrote:

> (Please cc: me on replies)
> 
> The upstream source for the manpages has received permission
> from IEEE to include text from the POSIX documentation in
> Linux manual pages.  Debian has not distributed the POSIX
> man pages because until recently the license prohibited
> modification.
> 
> The latest version (1.67, 20 May 2004) now allows
> modification, "so long as any conflicts with the standard
> are clearly marked as such in the text".  Joey Schulze,
> Debian's manpages maintainer, thinks the need for clear
> marking may be a problem.

Yeah, it's not actually free.  :-(

If it said something like "So long as no conflicts with the standard are
represented, explicitly or implicitly, as conforming to the standard", it
could be free.

As it is, it seems to quite effectively prohibit (for instance) adapting a
printf manpage for use as a manpage for weirdf, a non-POSIX command.  I see
no sane way to make sure that "conflicts with the standard are clearly
marked as such in the text" for such reuse.  Correct me if I'm wrong.

> I've attached the full text of the new license.  The other
> sentence that caught my eye is "This notice shall appear on
> any product containing this material".  Is putting it in
> /usr/share/doc sufficient?
> 
> Does this now meet Debian's criteria for distribution in
> main?

No.

> Thanks,
> --Andre

-- 
There are none so blind as those who will not see.

Re: license change for POSIX manpages

[Nathanael Nerode]

Andrew Suffield wrote:

> On Tue, Jun 08, 2004 at 04:32:11PM -0700, Andre Lehovich wrote:
>> The latest version (1.67, 20 May 2004) now allows
>> modification, "so long as any conflicts with the standard
>> are clearly marked as such in the text".
> 
> This seems to be reasonable. It's also right up against the line - a
> stronger requirement would be a problem.
I explained why I think it's non-free

> I'm not really comfortable 
> with it, and would be happier if it said something like:
> 
> "If modifications are made which conflict with the standard, then
> either these modifications must be clearly marked, or references to
> the standard must be removed, such that the resulting work does not
> misrepresent the standard."

Kudos to Andrew for coming up with such a good expression of a free version
of the same clause.  Basically, for the manpages to be Free, you should be
able to use them for totally non-POSIX purposes, and with the clause as
written, it seems that you can't.

I hope IEEE would be willing to change that, since they were willing to
change the license once.  :-)

This actually seems to be a recurring blind spot in people who think they're
writing free licenses; they only consider the most common reason for making
derivative works of their work, and accidentally prohibit or put ridiculous
restrictions on making other derivative works.  Perhaps it deserves a FAQ?

-- 
There are none so blind as those who will not see.

Re: Creative Commons Attribution license element

[Nathanael Nerode]

Evan Prodroumou wrote:
>On the Creative Commons side, I'd wonder what opportunity there is to
>get Debian's very tardy comments and critiques applied to new versions
>of the CC licenses.

Perhaps if they read their own mailing list?...

The trademark issue appears to be an issue solely with the web page 
presentation of the license, which should simply be fixed; the trademark 
clause is not supposed to be part of the license at all, but the web page 
does not make that clear.

I sent a message regarding this to them some time ago, but it seems to have 
fallen into a black hole.  Perhaps you know someone who could actually get 
something done on this point?...

Re: How to proceed with an ITP of questionably licensed software?

[Nathanael Nerode]

Andrew Pollock wrote:

> [[ Please CC me on all correspondence, I'm not subscribed ]]
> 
> Hi,
> 
> I've filed an ITP (WNPP #252999) on some software that is licensed under
> the GPL.
> 
> The source does not contain anything like a COPYING or LICENSE file or
> anything where the author asserts copyright over the work, or states that
> it's licensed under the GPL (but Freshmeat says it is) and there is a copy
> of the GPL included in the source tarball, in a file called GPL.

ecncheck/firedns/README contains a copyright assertion and licensing
statement, albeit a sloppy one.  That presumably applies only to the
firedns subdir, though.

There's a similar notice in ecncheck/firestring/README.
The rest of ecncheck, unfortunately, has no such notice.

> I've emailed the author and asked if he could add such assertions to a
> subsequent release of the software, but to date I have not received a
> reply.
> 
> What should I do at this point? Abort packaging the software?
Until you can get a proper copyright/licensing statement from the author,
yeah.  The fact that *parts* of it are licensed by him really means that he
ought to be willing to license the rest of it

> Cobble 
> together a debian/copyright file from non-existent information and upload?
> 
> regards
> 
> Andrew

-- 
There are none so blind as those who will not see.

Re: Draft Summary: MPL is not DFSG free

[Nathanael Nerode]

Edmund GRIMLEY EVANS wrote:

> Jim Marhaus <[EMAIL PROTECTED]>:


>> |  With respect to disputes in which at least one party is a citizen
>> |  of, or an entity chartered or registered to do business in the
>> |  United States of America, any litigation relating to this License
>> |  shall be subject to the jurisdiction of the Federal Courts of the
>> |  Northern District of California, with venue lying in Santa Clara
>> |  County, California, with the losing party responsible for costs,
>> |  including without limitation, court costs and reasonable
>> |  attorneys' fees and expenses.
> 
>> This clause restricts court venue to Santa Clara County, CA. Venue
>> restrictions may force licensees to travel unreasonable distances to
>> defend themselves in court, and could be used to effectively revoke the
>> license (Tentacles of Evil). For example, if the licensor filed a
>> frivolous lawsuit against a licensee, the latter would be forced to
>> travel to the licensor's home court or hire a representative, since most
>> jurisdictions summarily rule against absent defendants.
> 
> I don't know much about the US legal system. How different is this
> from the ordinary default situation? If I were "a citizen of, or an
> entity chartered or registered to do business in the United States of
> America" would I normally be able to safely ignore cases brought
> against me in Santa Clara County?

No; you wouldn't ignore it, but you also wouldn't have to travel.  You would
have to be notified of the suit locally.  Normally, you would respond to
such a case by filing a motion declaring that venue was inappropriate
there, and that any such suit should be in your local court (in Tompkins
County, New York, perhaps).  You can normally file *that* sort of motion by
going to your local court and using certified mail, without travelling out
of town.  :-)  The question of where the case would actually be held would
then be decided by who would suffer more pain by travelling.

> Also, could someone explain how this sort of condition would work in
> practice? Suppose I'm the licensee. The licensor would go to court in
> Santa Clara County and say what, exactly? I haven't signed anything,
> so how would the licensor convince the court that I have agreed to be
> sued there?
You haven't been granted any rights except under the agreement, so if you
didn't agree, you don't get any of the rights in the agreement.  Much like
the way the GPL is enforced.

> If the court is willing to take the licensor's word for 
> it, then couldn't the licensor sue me in Santa Clara even if I had
> never had anything to do with the software?

Yes, but you could then tell them and the court that they had to move the
suit to where you lived.  With this clause, you couldn't (unless the clause
was ruled to be unenforcable).

-- 
There are none so blind as those who will not see.

Re: license change for POSIX manpages

[Nathanael Nerode]

Florian Weimer wrote:

> * Josh Triplett:
> 
>> Agreed.  "In the text" could imply "right next to where you differ from
>> the standard", which would probably be unreasonable enough to be
>> non-free.  Without the "in the text", modifiers could simply add a
>> blanket notice somewhere in the distributed work saying "this has been
>> changed and may not match the POSIX standard", which is a reasonable
>> requirement.
> 
> They probably want to avoid that someone puts the markers into an
> nroff comment.
> 
> (We could actually add the markers and provide a patched groff to hide
> them again.)
> 
>> One other issue: does "and the nroff source is included" mean that if I
>> want to hand someone a printed copy of a manual page, I have to either
>> print the nroff source or supply it on an attached disk?  This seems
>> onerous for physical distribution.

Well, if you use the usual intepretation, you only have to *offer* someone
the attached disk; if they decline it, you don't have to force it on them.

Also, once you print an individual copy, first sale doctrine probably
applies (at least in the US) and you can do whatever the heck you want with
it (except copying it again).

> This is what happens if you apply the GPL to documentation, and it
> seems to be considered acceptable.
> 

-- 
There are none so blind as those who will not see.

Re: Draft Summary: MPL is not DFSG free

[Nathanael Nerode]

Matthew Palmer wrote:

> I'm pretty sure though,
> that absent a decision from a higher court, a court can choose to hear any
> case it wants to -- if that court decides to hear your case, either you
> appear or you're toast.  Different courts just have different rules about
> what constitutes a valid case for them.

Yeah, AFAIK, the court where a case is brought gets to decide whether or not
venue is appropriate there.

-- 
There are none so blind as those who will not see.

Re: Creative Commons Attribution license element

[Nathanael Nerode]

Evan Prodromou wrote:

>>>>>> "NN" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
> 
> NN> Actually, I think most of clause 4b is fine; it's only one
> NN> little bit of it which is troublesome.
> 
> Thanks for your close attention. This is really helpful.
> 
> 4b> to the extent reasonably practicable, the Uniform Resource
> 4b> Identifier, if any, that Licensor specifies to be associated
> 4b> with the Work, unless such URI does not refer to the copyright
> 4b> notice or licensing information for the Work;
> 
> NN> Well, I think this is barely free, though it's a little silly.
> 
> It's probably less silly in light of the mechanism Creative Commons
> suggests for embedding license info into artifacts with tight space
> for metadata:
> 
> http://creativecommons.org/technology/embedding
> 
> For file formats like MP3/ID3, there's only so much space for rights
> info. So, CC recommends storing an URL to the full info.
> 
> One thing that bothers me, though, is how this becomes 'barely
> free'. I realize that it may be *annoying* or *stupid*, but how is it
> *non-free*? I understand how *excessive* conditions on modifications
> may make something non-free, but requiring that a verbatim URL be
> included with the Work doesn't seem excessive to me.

What I meant was simply that many similar, but slightly different,
requirements would be non-free.  The requirement as is is certainly free. 
By 'barely free' I guess I was sloppily trying to discourage people from
taking it, making a stronger requirement loosely based on it, and then
saying "But you said the CC clause was free; why isn't this one?"

Requiring that an arbitrary verbatim URI be "conveyed" with any derived work
is potentially non-free, depending on how arbitrary the URI is.  A work
derivative of a large number of works could end up having to carry absurd
numbers of arbitrary URIs with it.

Luckily, this only requires that it be conveyed if the URI refers to the
copyright notice or licensing information for the work; and only "to the
extent reasonably practicable"; so it's free.

> I also am having a problem with understanding how putting limits on
> the modification of metadata (info about the Work) makes something
> non-free.

Well, there are at least two different issues wrapped up in this (possibly
more).  Requiring that unmodified metadata be carried around is *not* the
same as restricting the creation of modified metadata.

Requiring that unmodified metadata be carried around alongside derived works
is generally fine IMO *if* the metadata is accurate, really is metadata,
and is otherwise not legally problematic.  Many licenses have been very
sloppy about this, requiring text to be carried around which will not be
accurate for reasonable derived works, or which is wholly irrelevant to
some reasonable derived works.

If the creation of certain types of modified metadata is restricted, the
metadata may itself be non-free.  The question then becomes (a) whether is
is, and (b) how much, if any, non-free metadata is an acceptable load for a
free work.

> This seems to be standard issue with most free licenses (you 
> have to keep copyright notices,
When interpreted to include only accurate copyright notices, this is free.

> you have to distribute the license 
> with the work,
The correct license for the work?  This is free.

> you have to keep a change history,
This is one of those where it depends on exactly how the requirement is
written.  "You must note your changes"?  Free.  "You must reproduce an
unmodified, and potentially inaccurate and irrelevant, copy of the upstream
ChangeLog?" Not free.

> yadda yadda). I see  
> where restrictions on the content (can't change function names, can't
> change the ending of the short story) are non-free, but I'm not sure I
> grok why metadata "invariance" is.
> 
> I really need some help getting this straight in my head. What am I
> missing, here?

Hope what I said above helps at least clarify thos issues a little.

Now on to the actual nub of the problem at hand.

> 4b> provided, however, that in the case of a Derivative Work or
> 4b> Collective Work, at a minimum such credit will appear where any
> 4b> other comparable authorship credit appears and in a manner at
> 4b> least as prominent as such other comparable authorship credit.
> 
> NN> *This* is the problem clause.  It's unclear to most of us
> NN> exactly what "any other comparable authorship credit" means.
> 
> Yes, I see that. Is it "credit for comparable authorship", or "comparable
> credit for authorshi

Re: Creative Commons Attribution license element

[Nathanael Nerode]

Evan Prodromou wrote:

>> "AS" == Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> Me> One thing that bothers me, though, is how this becomes 'barely
> Me> free'.
> 
> AS> Freedom is a binary test; a work is either free, or it is
> AS> not. There is no "partially free" or "semi-free". So "barely
> AS> free" is "free, but very close to the line; make this any
> AS> stronger and it will be non-free".
> 
> I understood that part. The part I don't understand is, what line does
> the URL requirement get close to? What is the line between acceptable
> modification restrictions and unacceptable ones?
> 
> I'll try to present one dimension of modification restrictions, being
> what type of content those restrictions require to remain in the
> modified version:
> 
>   1. No restrictions on modifications whatsoever.
> 
>   2. Restrictions to make sure that downstream users get the following
>  4 things: copyright notices, license notification, changelogs,
>  warranty disclaimers.

If accurate for the derived work, only. :-)

>   3. Restrictions to make sure that downstream users get general
>  information about the work (metadata), including the above 4
>  things, but maybe perhaps some others. Examples: original author
>  name, original work title, original metadata URL, bug-reporting
>  site or address, main download site URL.

If accurate for the derived work, only. :-)

>   4. Restrictions that "protect" certain parts of the work itself
>  (e.g., invariant sections).
> 
>   5. Restrictions that prevent any modification of the work
>  whatsoever.
> 
> I'd posit that our line for free-vs.-non-free is between 3 and 4 here.

If accurate for the derived work, only. :-)

You might look at the Apache License 2.0 for the language about NOTICES
which was put in specifically to avoid requiring the presence of inaccurate
and irrelevant notices.

> Me> Would it be non-free because it's not possible for the licensee
> Me> to comply because the license is vague?
> 
> AS> Licenses which are vague are particularly nasty, because you
> AS> can go with the "obvious" interpretation, and then get sued by
> AS> the copyright holder who turns out to have a different
> AS> one. Certainly we've had some copyright holders applying
> AS> strange interpretations to apparently free licenses before
> AS> now. To provide reasonable assurance to our users that
> AS> everything in main is free, we have to take the most
> AS> pessimistic interpretation, and see if that is free.
> 
> Cool. So, if I can redirect back to the Attribution license, we have a
> worst-case interpretation with the Attribution license, where the
> author's credits have to be listed in _every_ place other credits are
> given, even if those places are possibly inconvenient (file name, work
> title).

Don't forget prominence.  They have to be listed just as prominently as any
other credits, in those places, as well.  The only safe way, given the
licence vaguesness, is to list all credits with precisely equal prominence,
regardless of the contributions of the different people.

> Even though it's vague (could mean "some" places, could mean 
> "all" places), our New Math set theory teaches us that if we give
> credit in all places, we will have also have given credit in some
> places. So, by giving credit in _all_ places, we can comply.
> 
> Now, given the "all places" idea: is that non-free? It may suck, but
> is it non-free?

Yes, because it a requirement which causes a prohibitive burden on the
creator of derivative works.  It actually prevents giving appropriate
credit; it may forbid reasonable titles for the work; etc.

-- 
There are none so blind as those who will not see.

Re: Draft Summary: MPL is not DFSG free

[Nathanael Nerode]

Lex Spoon wrote:

> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
*snip*
>> Almost all free licenses are not contracts.  I cannot think of any
>> Free license which *is* a contract, but there might, I suppose, be one
>> out there.  Given American law requires an exchange, I can't see how.
> 
> What do you mean?  In order to gain the licenses GPL grants you, you
> must comply with all of the terms.  Some of those terms require that you
> perform in some way, e.g. by distributing source code.

Actually, as far as I can tell, they don't.  They grant permission to do
specific things which you otherwise have no permission to do (such as
distributing source code).  Interestingly, every restriction in the GPL I
could find is merely a restriction on what activities it permits you to do;
they do not restrict your outside activities.  If you accept the license,
the things you are then permitted to do are a *strict superset* of the
things you were permitted to do before.

It restricts redistribution.  Without the license, you have no permission to
distribute at all.  It restricts creation of derivative works.  Without the
license, you have no permission to create any.  And their distribution. 
Without the license, you have no permission to distribute any.

(There might be a different situation if you already had the GPL-licensed
work under a *different* license which granted different permissions,
neither a superset nor a subset of the GPL permission; the interaction
might be tricky to work out and might mean that the GPL required you to
give up some of the other permissions, though I doubt it.)



> Agreement is necessary for you to gain the grant(s). Interestingly,
> GPL states this explicitly, even though it doesn't need to:
> 
> "You are not required to accept this License, since you have not signed
> it. [...] Therefore, by modifying or distributing the Program (or any
> work based on the Program), you indicate your acceptance of this License
> to do so, and all its terms and conditions [...]"

Yeah, that's contract-like language, true.

-- 
There are none so blind as those who will not see.

Re: Unfortunate Licence Mix

[Nathanael Nerode]

Joachim Breitner wrote:

> Hi,
> 
> I was just about to package "psybnc"[1], a popular irc bouncer.
> 
> A closer look into the src/ dir revealed that the author seems to have
> followed the Free Software spirit by not re-inventing a lot of wheels,
> but didn't pay close attention to legal stuff...
> 
> His own works are GPLed, and have correct copyright notes. But there are
> two files that worry me:
> 
> snprintf.c:


> And the second file, bsd-setenv.c:


> If I payed attention, both of these contain the "bad" advertising clause
> that make them incompatible with the GPL, and thus the psybnc
> distribution impossible. Is that right?
Yes.

> Is it also right that finding re-licenced versions of bsd-setenv.c
> (without the Advertising Clause) would solve the problem for this file?
Yes.

> Or can I just re-licence the file myself, since BSD officially changed
> the licence for all their works (or something)?
Well, Berkeley's relicensing statement is here:
ftp://ftp.cs.berkeley.edu/ucb/4bsd/README.Impt.License.Change

As long as the file is a "BSD Unix" file or part of the "Berkeley Software
Distribution", it seems to be relicensed.  You can determine whether it is
by looking at *BSD for the file; I'd guess, offhand, that it is.

--
The Apache team has been trying to switch to a GPL compatible license.  It's
likely that you can find a relicensed version of the original Apache
snprintf.c file under the Apache License 2.0, but unfortunately it's not
clear yet whether that's GPL-compatible; eventually some version of the
Apache license should be though.

Given what this Apache-licensed file actually is, I'd suggest finding a
GPL-compatibly-licensed snprintf implementation and tweaking it to behave
like the one in psybnc (which appears to simply *remove* functionality).

-- 
There are none so blind as those who will not see.

Re: license change for POSIX manpages

[Nathanael Nerode]

Francesco Poli wrote:

> Moreover, the GPL requires that *source code* be accompanied or offered.
> This POSIX license requires that *nroff source* be included.
> 
> What if I created a derivative work by
> step 0) converting it from nroff to some other typesetting language
> (e.g. DocBook XML, LaTeX, XHTML, ...)
> step 1) then applying lots of modifications to it
> ?
> 
> In that case, I'd say the new source code is in the other language (say,
> DocBook): with the GPL I'd have to accompany or offer the new source
> code in order to distribute my derivative work.
> 
> But what should I do in order to distribute my derivative work *and* to
> comply with the POSIX license?
> No nroff source would exist for my derivative work...
> Such a derivative work would be undistributable, correct me if I'm
> wrong.

You're quite right, and that certainly renders it non-free.  :-P

-- 
There are none so blind as those who will not see.

How aggressively should non-distributability bugs be dealt with?

[Nathanael Nerode]

I ask because of #242895.  In the Linux kernel, drivers/usb/misc/emi26_fw.h
has a specific proprietary rights statement which does not give permission
to distribute.  The previous kernel maintainer merged it with other bugs
(IMO incorrectly) and proceeded to ignore it for at least four uploads.  The
new kernel uploaders appear to be ignoring it as well.

Personally, I would think that anything which exposes Debian to lawsuits for
wilful copyright infrignement should be removed as soon as humanly possible.
However, I'm not willing to do the necessary badgering of the kernel
maintainers alone this week, so I'm asking what other people think, and if
anyone else (perhaps a DD) would like to take point on this.

-- 
There are none so blind as those who will not see.

Re: Summary Update: MPL inconclusive, clarifications needed

[Nathanael Nerode]

MJ Ray wrote:

> On 2004-06-23 19:12:41 +0100 Andrew Suffield <[EMAIL PROTECTED]>
> wrote:


>> Stock objection to choice of venue clauses is that they force people
>> to travel at their own expense. In essence they attempt to bypass the
>> legal system by making it prohibitively expensive for somebody to
>> defend themselves.
> 
> This doesn't seem to be a stock choice of venue clause, though. It
> only applies when there is a US party and some have claimed that the
> choice of venue clause would not necessarily prevent a US defendant
> being heard in their local court, such as Nathanael Nerode in
> http://lists.debian.org/debian-legal/2004/06/msg00237.html

I think you might have been confused by what I said.  I was describing, in
that message, how things work if there is *no* choice of venue clause.

If there is a choice of venue clause (and it's considered valid, which it
likely would be), it's likely that it would require a US defendant to go to
Santa Clara to avoid summary judgement.

-- 
There are none so blind as those who will not see.

Re: Summary Update: MPL inconclusive, clarifications needed

[Nathanael Nerode]

Mahesh T. Pai wrote:

> MJ Ray said on Wed, Jun 23, 2004 at 05:18:22PM +0100,:
> 
>  > If there are no active patents covering the software,
> 
> Patent  owners' policies  may  change. Patents  are patents,  actively
> enforced or  not. If the  license does not  grant a patent  license in
> respect  of the  software released,  people can  very easily  sneak in
> patent time bombs into the codebase.

If the patents are crap patents which should never have been issued in the
first place, and the owner is not litigious, there is no reason to pay any
attention to them.  The current situation is that the majority of patents
on software are clearly garbage, and the majority of software is "covered"
by various garbage patents of this sort.  If the owner later becomes
litigious in such a situation, the proper response is to contact PubPat and
the EFF and fight to break the patent.

Unfortunately, under current US case law, you are in a *better* defensive
position in court if you haven't done *any* patent research at *all*. 
That's one reason why it's better to ignore all patents than to try to
determine on your own which ones are potentially legitimate.  :-P

-- 
There are none so blind as those who will not see.

Re: Draft Summary: MPL is not DFSG free

[Nathanael Nerode]

Lex Spoon wrote:

> Nathanael Nerode <[EMAIL PROTECTED]> wrote:
>> > What do you mean?  In order to gain the licenses GPL grants you, you
>> > must comply with all of the terms.  Some of those terms require that
>> > you perform in some way, e.g. by distributing source code.
>> 
>> Actually, as far as I can tell, they don't.  They grant permission to do
>> specific things which you otherwise have no permission to do (such as
>> distributing source code).  Interestingly, every restriction in the GPL I
>> could find is merely a restriction on what activities it permits you to
>> do;
>> they do not restrict your outside activities.  If you accept the license,
>> the things you are then permitted to do are a *strict superset* of the
>> things you were permitted to do before.
> 
> Sort of, but please consider it more closely.
> 
> First, the GPL states explicitly that you must "accept" the terms or
> that you do not get permission to do anything with the code.  Should we
> argue with a statement that the text says itself?
> 
> Second, while acceptance alone does not obligate anything of you, some
> obligations do kick in if you try to use some of the rights you have
> been granted.  For example, if you take the option to distribute
> binaries of modifications and then post the source code separately, then
> you are *obliged* from then onwards to keep the source code available to
> whoever has received the binary distribution.  This is a restriction on
> your behavior, and that restriction has arisen because you agreed to the
> terms of the GPL.  You have gained the right to distribute binary-only
> copies, but in compensation you have agreed to post the source code
> somewhere.

Ah yes.  There are potential contracts which you may agree to by doing
certain things, embedded in the license.  You might say the license gives
you perpetual offers to enter into certain contracts.  That doesn't make
the license itself a contract.  I think Brian Thomas Sniffen mentioned that
when a license has multiple "options", you only need one free "path"
through the license.

The GPL preamble, also, specifically says that it does not intend to
restrict any of your existing fair use or other rights.  Most licenses
don't say that.  :-)

> IANAL, but calling this anything but a contract seems to really confuse
> matters.  Let's try and focus on what the real issue is, which is not
> some technical legal distinction.
OK, agreed.  Now what was the issue at hand again?  :-)

> Further, the general principle has 
> not been established to my satisfaction that a reasonably free license
> must have absolutely no strings attached.  If it's only minor
> requirements, along the same annoyance level as advertising clauses,
> then surely the license agreement is still okay.

The idea is this: It must only restrict activities which you would otherwise
be unable to do.

For instance, the BSD advertising clause restricts advertising of products
containing the software.  Without a license, you can't even *make* such
products, let alone distribute them, so you can't (legally) advertise them
either.

The various requirements of ChangeLogs, NOTICE files, distribution only as
patches, etc., all are restrictions on activities otherwise prohibited by
copyright law.  In fact, there are *lots* of restrictions you can have in a
license -- many which we think are non-free, many which seem to be free --
which only touch activities which are impossible without a license.  

Prohibiting, in the license, activities which you could legally do if you
had no license at all -- that is what we considered non-free because of
this issue.  Given that the collection of things you're allowed to do
without any copyright license is *remarkably* small, I don't think it's
acceptable to give up any of them.

-- 
There are none so blind as those who will not see.

Re: Free Linux Kernel

[Nathanael Nerode]

.jareeN. wrote:

> 
> Sorry if this is a really silly/of_topic question.
It's not.

> I am a LFS user and I want to use free Linux kernel for my GNU/Linux
> system, by free I mean which is free from binaries and non-free code.
> Does such a kernel exists ?
> 
> I mean some kind of patch.

At the moment, such a kernel does not, to my knowledge, exist.  :-P
Debian is supposed to be distributing one, but it's (still) full of non-free
junk.

I had been working on cleansing it, but have gotten depressed by the hostile
response from some of the Debian kernel maintainers and the dead silence
from upstream.  If you would like to help, please email me.  :-)

Note that the non-free junk is almost exclusively in drivers for
peripherals.  The 'core kernel' is fine.

-- 
There are none so blind as those who will not see.

Re: scummvm dependent games: non-free?

[Nathanael Nerode]

Joachim Breitner wrote:

> Hi,
> 
> Am Fr, den 25.06.2004 schrieb Gerfried Fuchs um 12:11:
>>   3) You may not charge a fee for the game itself. This includes
>>  reselling the game as an individual item.
>> 
>>  Doesn't this violate point 1 of the DFSG?
> 
> AFAIK it is ok, as long as it is allowed to distribute it as part of
> something (like Debian). Similar situation as with Bitstream's Vera
> font: (quote from doc/copyright):
> 
>>The Font Software may be sold as part of a larger software package but
>>no copy of one or more of the Font Software typefaces may be sold by
>>itself.
> 
> Basically the same it, and seems to be free.

This is basically a trick of wording.  If the license lets you ship it with
the one-character shell script containing the letter 'w' and charge for
that, then that's good enough.

>>  At least the splash screen of "Flight of the Amazon Queen" when you
>> start it is misleading at large, too:
>> 
>>   Unauthorized copying, reproduction, adoption, rental, public
>>   performance, broadcast or other exploitation of this product is
>>   strictly prohibited and constitutes a violation of applicable laws
>>   which may give rise to both civil liability and criminal penalties.
>> (hand typed and thus typos might be in it)
> 
> Should be fixed, but it's not RC. Feel free to file a bug.

Technically, it's true; it's just there's a *lot* of authorized uses!

-- 
There are none so blind as those who will not see.

Re: Bug#254596: jftpgw: Several license problems

[Nathanael Nerode]

Romain Francoise wrote:

> Package: jftpgw
> Version: 0.13.5-1
> Severity: serious
> 
> The jftpgw package currently distributed in Debian has two license
> problems:
> 
> 1. The source contains a file named snprintf.c that doesn't contain any
>copyright notice or license header.  It appears to be copied verbatim
>from the Mutt distribution, which it itself under the GPL, so it may
>be a non-issue, but I think a clarification could be useful.
> 
>(Moreover, I think the libc functions could be used instead.)
Should be used instead.  Unless snprintf.c is functionally different from
the libc version, it's just a waste of space for Debian.

> 2. The source contains a file named rel2abs.c under the 4-clause BSD
>license (copied here in full):
> 


>Clause #3 (advertising clause) is not compatible with the GNU GPL
>under which the rest of the program is distributed, hence making the
>whole thing impossible to distribute.  Please ask the original author
>to relicense the file under a 3-clause BSD license,
Or 2-clause BSD. (For that, drop clause 3 *and* drop clause 4, which is
redundant with the 'right of publicity' in all known jurisdictions).

>or replace the 
>offending code with replacements under a compatible license.
> 
> Both files provide functions used elsewhere in the program and don't
> constitute mere source aggregation.
> 
> CC'ing upstream author and debian-legal for comments.

Your analysis is correct.  :-)

-- 
There are none so blind as those who will not see.

Re: How long is it acceptable to leave *undistributable* files in the kernel package?

[Nathanael Nerode]

Michael Poole wrote:

> Brian Thomas Sniffen writes:



>> It's a unilateral license.  It can't mean anything but what he intends
>> it to mean.
> 
> Reference, please?  That is Alice in Wonderland logic ("Words mean
> exactly what I want them to mean, neither more nor less.").  I hope
> that a license means what is written.

With a unilateral license, the license grantor's interpretation is given a
great deal of weight by the courts (because he is granting something out of
the goodness of his heart and receiving no compensation).  The license
recipient is getting a free gift, so his interpretation is generally given
very little weight (provided the grantor has made the grantor's
interpretation clear).  Obviously the grantor can't claim that the license
means something totally contrary to what it says, but any interpretation
within reason will probably be accepted.

This is in contrast to interpretation of contracts, where neither party is
preferenced.  But note that if all parties to the contract agree, a third
party's interpretation is likely to be ignored, even if technically more
correct.

Sorry I don't have the references, but you can look them up for yourself.

-- 
There are none so blind as those who will not see.

Re: gens License Check - Non-free

[Nathanael Nerode]

Michael Poole wrote:

> Raul Miller writes:
> 
>> Because the linux kernel does not represent mere aggregation of one part
>> of the kernel with some other part on some storage volume.
>>
>> It's not a coincidence that the parts of the kernel are there together.
> 
> The usual contention is that having some helper function load the
> firmware is sufficient to resolve the concern.  That suggests to me
> that the parts being together -- at least in that case -- is a matter
> of convenience, not of necessity.  That is what I would use to test
> for "mere aggregation" (when one is not a derivative work of the
> other).

In some of the cases, rewriting the driver to have a helper function load
the firmware is actually a complicated process involving major changes to
the driver to 'detangle' the firmware.  The 'tangled' version doesn't seem
like mere aggregation.

-- 
There are none so blind as those who will not see.

Re: RFC: moving from BSD to GPL

[Nathanael Nerode]

Francesco P. Lovergine wrote:

> Is it possible for an upstream to change license from a BSD-old to GPL?
> Consider the hypothesis that the product is a derivative work with a
> few old contributors. I see no reasons to do not relicense after adding
> a credits note as required in the BSD license.
> 
> Comments?

4-clause BSD has a requirement in clause 3 which applies to all derived
works and is not required in the GPL.  The GPL does not allow distribution
of GPL-licensed works with requirements which go beyond the requirements of
the GPL.

Accordingly, you need to get all the old copyright holders to relicense
under 3-clause BSD (at a minimum).

-- 
There are none so blind as those who will not see.

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Nathanael Nerode]

Ryan Rasmussen wrote:

> Is the following compliant with Debian's Free Software Guidelines?

No.  It seems pretty close, but there are a few deadly clauses.  Gah, this
is a lawyerly monstrosity


> ---
> APPLE PUBLIC SOURCE LICENSE
> Version 2.0 - August 6, 2003


So, in the part I snipped, it grants most of the right rights.  However, it
has a *lot* of patent language, and I'm not quite sure exactly what it
grants in that regard.

> 9. LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO
> EVENT SHALL APPLE OR ANY CONTRIBUTOR BE LIABLE FOR ANY INCIDENTAL,
> SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING
> TO THIS LICENSE OR YOUR USE OR INABILITY TO USE THE COVERED CODE, OR
> ANY PORTION THEREOF, WHETHER UNDER A THEORY OF CONTRACT, WARRANTY,
> TORT (INCLUDING NEGLIGENCE), PRODUCTS LIABILITY OR OTHERWISE, EVEN IF
> APPLE OR SUCH CONTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGES AND NOTWITHSTANDING THE FAILURE OF ESSENTIAL PURPOSE OF ANY
> REMEDY. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF LIABILITY OF
> INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION MAY NOT APPLY
> TO YOU. In no event shall Apple's total liability to You for all
> damages (other than as may be required by applicable law) under this
> License exceed the amount of fifty dollars ($50.00).
Is this OK?  Probably, but I'm not clear.

> 10. Trademarks. This License does not grant any rights to use the
> trademarks or trade names "Apple", "Apple Computer", "Mac", "Mac OS",
> "QuickTime", "QuickTime Streaming Server" or any other trademarks,
> service marks, logos or trade names belonging to Apple (collectively
> "Apple Marks") or to any trademark, service mark, logo or trade name
> belonging to any Contributor.
This is good.

> You agree not to use any Apple Marks in 
> or as part of the name of products derived from the Original Code or 
> to endorse or promote products derived from the Original Code other
> than as expressly permitted by and in strict compliance at all times
> with Apple's third party trademark usage guidelines which are posted
> at http://www.apple.com/legal/guidelinesfor3rdparties.html.

This is not good, because it may go beyond trademark law.  This is
acceptable if and only if Apple's trademark usage guidelines allow
everything which is normally permitted under trademark law.  I think they
do, but the fact that they could change at any time may make this
unacceptable.  This should be considered a fixable license bug, frankly.


> 12. Termination.
> 
> 12.1 Termination. This License and the rights granted hereunder will
> terminate:
> 
> (a) automatically without notice from Apple if You fail to comply with
> any term(s) of this License and fail to cure such breach within 30
> days of becoming aware of such breach;
Fine.

> 
> (b) immediately in the event of the circumstances described in Section
> 13.5(b); or
Fine.

> 
> (c) automatically without notice from Apple if You, at any time during
> the term of this License, commence an action for patent infringement
> against Apple; provided that Apple did not first commence
> an action for patent infringement against You in that instance.

Not acceptable.  Suppose you, a hardware designer, sue Apple for infringing
your microchip patent?



> 13.1 Government End Users. The Covered Code is a "commercial item" as
> defined in FAR 2.101. Government software and technical data rights in
> the Covered Code include only those rights customarily provided to the
> public as defined in this License. This customary commercial license
> in technical data and software is provided in accordance with FAR
> 12.211 (Technical Data) and 12.212 (Computer Software) and, for
> Department of Defense purchases, DFAR 252.227-7015 (Technical Data --
> Commercial Items) and 227.7202-3 (Rights in Commercial Computer
> Software or Computer Software Documentation). Accordingly, all U.S.
> Government End Users acquire Covered Code with only those rights set
> forth herein.
What the heck does this do?


> 13.4 Waiver; Construction. Failure by Apple or any Contributor to
> enforce any provision of this License will not be deemed a waiver of
> future enforcement of that or any other provision.
Yeah, that's fine.

> Any law or 
> regulation which provides that the language of a contract shall be
> construed against the drafter will not apply to this License.
What the heck does this do?  I don't like the look of it.

> 13.5 Severability. (a) If for any reason a court of competent
> jurisdiction finds any provision of this License, or portion thereof,
> to be unenforceable, that provision of the License will be enforced to
> the maximum extent permissible so as to effect the economic benefits
> and intent of the parties, and the remainder of this License will
> continue in full force and effect. (b) Notwithstanding the foregoing,
> if applicable law prohibits or restricts You from

appropriate trademark licensing (was Re: GUADEC report)

[Nathanael Nerode]

Josh Triplett wrote:

> I believe the issue is that unlike patents and copyrights, unenforced
> trademarks become "diluted" and no longer enforcable.
Terminology confusion here; "dilution" is a separate concept from
enforcability.  Look up "trademark infrignment" and "trademark dilution".

Indeed, an unenforced trademark may (or may not!) become "generic" and
thereby lose its trademark status; this has nothing to do with dilution, as
far as I can tell.  If a trademark is unenforced for too long, someone else
may establish it as their trademark as well (and you would then be unable
to enforce it against them).

> To some lawyers 
> (especially those not overly familiar with Free Software), a
> freely-licensed trademark might be seen as unenforced.  However, given
> that most free licenses do place _some_ restrictions on the use of the
> trademark (much like many businesses have "trademark usage guidelines"),
> then I believe this fear is probably unfounded, as long as those
> restrictions are enforced.  (IANAL, TINLA.)

Precisely what I think.  Any lawyer who thinks that a trademarked item
licensed under a free copyright license inherently has an "unenforced"
trademark simply doesn't know what they're talking about.

Here are some possible trademark clauses; let's think about them and come up
with a model clause, OK?  I think a model clause would go a long way; if we
had such clauses to present to people to present to their lawyers, the
lawyers would at least have to explain what they thought was wrong with
them.

(in copyright license)
"This copyright license does not grant any trademark license, express or
implied, in any trademarks."

(separate from copyright license)
"You may use the trademarks 'Foo', the Foo logo, etc. in the ways which are
allowed under trademark law; for instance, to refer to the original,
unmodified 'Foo' product.  Any use which is resricted under trademark law
is prohibited (unless allowed under a separate trademark license)."

(as a separate trademark license, or as part of a copyright license)
"You may use the trademarks 'Foo', the Foo logo, etc., in any way which does
not constitute trademark infrignement; that is to say, any way which does
not create a likelihood of confusion, mistake and/or deception with the
public.
(This one would specifically permit trademark dilution)

IANAL, but any of these look OK with me.

-- 
There are none so blind as those who will not see.

Re: DRAFT: debian-legal summary of the QPL

[Nathanael Nerode]

Josh Triplett wrote:

> Here is a proposed summary of the QPL 1.0, based on the relevant threads
> on debian-legal.  Suggestions are welcome, as well as statements of
> whether or not this DRAFT summary accurately represents your position.
> 
> Please note that until other debian-legal participants indicate their
> position on this DRAFT summary, it does not necessarily represent the
> debian-legal consensus.  For this reason, I am sending this only to
> debian-legal, for further discussion.
> 
> --- Begin DRAFT debian-legal summary of the QPL 1.0 ---
> 
> The members of the debian-legal mailing list have examined the Q Public
> License (QPL), version 1.0, and determined that software licensed solely
> under this license is not Free Software according to the Debian Free
> Software Guidelines (DFSG).
> 
> * Clause 6c requires modified versions that are not distributed to the
> public to be provided to the original developer on request.  This
> requirement fails the "Desert Island" test and the "Dissident" test (see
> sections 9a, 9b, and 12o of the DFSG FAQ at
> http://people.debian.org/~bap/dfsg-faq.html).  DFSG-free licenses must
> allow non-distributed or privately-distributed modifications, and cannot
> require distribution to anyone, except for requiring that source be
> distributed to those who receive a binary.

What I would say is
"... must not require distribution to anyone, except as part of a
distribution already being made (such as the requirement that you
distribute source when you distribute a binary, or that you distribute the
unmodified version when you distribute the modified one).

Essentially, I agree.

> * The license contains a "choice of venue" clause, which states that
> "Disputes shall be settled by Amsterdam City Court.".  Since in many
> legal jurisdictions, a party that fails to appear and defend themselves
> in the courts of the given jurisdiction will automatically lose such a
> dispute, such "choice of venue" clauses place an undue burden on the
> recipient of the software in the face of any legal action (whether
> legitimate or not), and are therefore considered non-free.  Such clauses
> also fail the "Tentacles of Evil" test (see section 9c of the DFSG FAQ
> at http://people.debian.org/~bap/dfsg-faq.html), since the original
> developer
^^^
...or his successors in copyright...
> can bring many unfounded legal actions against distributors 
> and force them to travel to a given location to defend themselves, which
> would effectively remove the right to distribute the software.

I agree.

> For software currently licensed under the QPL 1.0 whose authors desire
> its inclusion in Debian, debian-legal recommends licensing that software
> under a Free Software license such as the GNU GPL, either in place of or
> as an alternative to the QPL 1.0.

I agree.  :-)

> 
> --- End DRAFT debian-legal summary of the QPL 1.0 ---
> 
> - Josh Triplett

-- 
There are none so blind as those who will not see.

Re: DRAFT: debian-legal summary of the QPL

[Nathanael Nerode]

Josh Triplett wrote:

> MJ Ray wrote:
>> Josh, Good summary. I think you've taken recent discussions about them
>> into account a bit. I've a few comments...
> 
> Thanks.  You had mentioned that it would be better to word summaries in
> terms of software covered by the license, rather than the license itself.
> 
>> On 2004-07-09 22:59:18 +0100 Josh Triplett <[EMAIL PROTECTED]> wrote:
>>> * Clause 6c requires modified versions that are not distributed to the
>>> public to be provided to the original developer on request.  This
>>> requirement fails the "Desert Island" test and the "Dissident" test (see
>>> sections 9a, 9b, and 12o of the DFSG FAQ at
>>> http://people.debian.org/~bap/dfsg-faq.html).
>> 
>> I think it would be better to refer to the DFSG directly if we can.
> 
> Agreed.  Unfortunately, I couldn't think of anything in the DFSG that I
> could point to which would directly cover the right to make private
> modifications.  Given that this issue seems to be one of the most common
> Freeness issues that isn't covered in the DFSG, at some point it should
> be added as an additional Guideline.

Agreed.  Personally, I think it's implicit in DFSG 6; it discriminates
against the field of making modifications to the program, by forcing them
to be distributed before their authors are ready.




>>> Since in many legal jurisdictions, a party that fails to appear and
>>> defend themselves in the courts of the given jurisdiction will
>>> automatically lose such a dispute, such "choice of venue" clauses
>>> place an undue burden on the recipient of the software in the face
>>> of any legal action (whether legitimate or not), and are therefore
>>> considered non-free.
>> 
>> "non-free by some." Or maybe many. At least I hope for a Smart Person
>> explaining why we're wrong on these, as they are in a couple of painful
>> places and I have trouble believing that Mozilla, OSI and FSF all slept
>> through this problem.
> 
> Recall that the IBM Common Public License contains "Each party waives
> its rights to a jury trial in any resulting litigation.", and it is
> listed as free by both the OSI and FSF.
Right, and I would never accept that as free in my life.

> I suspect that people are not 
> used to the "guidelines"/"case law" approach and the level of detailed
> license analysis on debian-legal, and expect something more like the
> OSI's "checklist" approach.
> 
> I suspect that one of the major objections to choice of venue clauses
> (as opposed to choice of law clauses) is that they place more of a
> burden on those being sued.  I also suspect that "If you sue us over
> this software, you must do so in this jurisdiction" would be far less
> problematic than "If we sue you over this software, you must defend
> yourself in this jurisdiction".  After all, we are much more concerned
> about being sued than about the ability to sue the author.
Precisely.  I believe we could be quite happy with the first sort of
statement, if phrased very carefully (I think compulsory counterclaims
would belong in the 'defense' category, and that must be carefully noted). 
What we want to prevent is the possibility of the copyright holder
preventing exercise of the license rights by nuisance tactics carried out
across the ocean.  In general, this would mean the copyright holder
initiating a suit against the user.  (If you can think of a situation where
it would mean the user initiating the lawsuit, except for counterclaims
after the copyright holder sued, please correct me.)


IANAL, TINLA.  Frankly, these days *everyone* has to have a lawyer's
knowledge of copyright law to write *anything*.  Blech.

-- 
There are none so blind as those who will not see.

Re: DRAFT: debian-legal summary of the QPL

[Nathanael Nerode]

MJ Ray wrote:


> Unfortunately, FSF is mostly a black box to outsiders like me.
To almost everyone.

> I have 
> asked them questions sometimes, but the answers so far have been slow,
> incomplete and/or cautious first-line responses, rather than involving
> any words from the decision-makers. This has been a problem I've had
> with FSF, Inc for a long time. We all know that they have good lawyers
> involved, but I can't figure out the reasoning myself and the people
> who have answered questions fully get offended that you even ask the
> question. The Europeans are more accessible, but seem not to want to
> duplicate the US FSF licensing team, so I don't have any official
> channel for questions there. 
> Further, if FSF front-line volunteers connect a request with anything
> sent to this list, I get bloody suspicious questions back and I think
> it gets tagged as "low priority, answer before next ice age". Why
> can't you all get over stuff and take each case as it comes? Learn
> from it, but get over it. Gah!
Indeed.


>> I suspect that one of the major objections to choice of venue clauses
>> (as opposed to choice of law clauses) is that they place more of a
>> burden on those being sued. [...]
> 
> Is this hindering cost-free distribution by being able to demand
> payment to represent the licensee in that venue? Or do we regard this
> as discrimination by denying foreign defendants the right to be heard
> in a local court using their residency's law and language, as normally
> would happen?

Both?


-- 
There are none so blind as those who will not see.

Re: DRAFT: debian-legal summary of the QPL

[Nathanael Nerode]

Glenn Maynard wrote:

> On Sat, Jul 10, 2004 at 11:35:58AM -0700, Josh Triplett wrote:
>> That should be mentioned, yes.  It should also be noted in such a
>> suggestion that this alternative would be GPL-incompatible.  Also, such
>> a license takes advantage of the deprecated DFSG 4, which may or may not
>> be removed in the future; should that be noted as well?
> 
> I believe he has essentially said that he wants to only allow patches, in
> order to prevent forking, so I think any approach that he'll accept will
> have to use DFSG#4.
> 
> (I personally consider the patch element of DFSG#4 bogus.  Patch clauses
> prevent forking and code reuse almost entirely, both of which are
> critical,
> fundamental elements of Free Software.

Patch clauses, just as a note, must *only* apply to *distribution*; one
which applied to non-distributed copies would be entirely unacceptable.
As such, they are essentially a silly and stupid hoop on distribution.

It's plausible, even, to construct an 'auto-patchifier' for a revision
control system which allows all the code reuse and forking to be done
normally, and whenever it's distributed, converts it to the stupid 'patch'
form automatically, and converts it back at the recipient's end.

> I tend to suspect that people 
> using them want the individual benefits of Free Software--of free
> contributed work, bug fixes, code review, distribution--without the only
> reciprocation of placing the work in the pool of reusable code.)

-- 
There are none so blind as those who will not see.