Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
>> The answer to the question in the subject is simple: NO.
>
> Thankyou for your opinion. I note you seemed to neglect to mention that
> you're not a lawyer.

So, do you have anything to say about what Nathanael said?  How does
his not being a lawyer make his statement false?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Sven Luther]

On Wed, Oct 18, 2006 at 08:06:19AM +1000, Anthony Towns wrote:
> On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
> > The answer to the question in the subject is simple: NO.
> 
> Thankyou for your opinion. I note you seemed to neglect to mention that
> you're not a lawyer.

Anthony,

Could you use some of the trunkloads of money available at SPI for debian, in
order to consult a lawyer on these issues, instead of making such comments ? 

This should have been done months ago, and would have avoided probably much
dispute of no-lawyer person trying to argue stuff.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: License review request

[Nathanael Nerode]

Arnoud Engelfriet wrote:

> Sean Kellogg wrote:
>> Just a quick chirp from a d-l lurker with a JD that the above is a pretty
>> common concept in consumer protection type laws and, as referenced, the
>> UCC.
> 
> Thanks for your input.
> 
>> I did some focus group research for Microsoft a few years back where
>> they were experimenting with converting their licenses to regular
>> text and using boxes for "conspicuous" text.  I, and the research
>> group, felt they were pretty effective.
> 
> Did you check with the Legal group? I've seen lots of common-senes
> solutions to this type of legal issue, and somehow it is very hard
> to get beyond the "but everyone's been doing it for 20+ years".

Probably you'd have to have a court case proving that all-caps does not make
for conspicuous.  :-(

> I once tried something like: "This program is WITHOUT ANY WARRANTY
> and is provided AS-IS, with ALL LIABILITY to be assumed BY YOU."
> The other side's lawyer just put it in all caps "because you're
> not supposed to have lowercase in disclaimers". Well, that at
> least takes care of their "all caps is unreadable" argument.

Yeah, actually your version is much more conspicuous, using the ordinary
meaning of the word, than the unreadable all-caps version.  :-/

Huge all-caps hunks make my eyes slide right over; it looks sort of like bad
ASCII art.

> 
> Arnoud
> 

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Don Armstrong]

On Tue, 17 Oct 2006, Roberto C. Sanchez wrote:
> So what? Distributing GPL works *with* sources is also not clear of
> legal liability.

Those liabilities occur in either case, so they're not particularly
interesting to discuss. Doing something that is against the letter and
spirit of a software license is just not a position that we should put
ourselves in.


Don Armstrong

-- 
Miracles had become relative common-places since the advent of
entheogens; it now took very unusual circumstances to attract public
attention to sightings of supernatural entities. The latest miracle
had raised the ante on the supernatural: the Virgin Mary had
manifested herself to two children, a dog, and a Public Telepresence
Point.
 -- Bruce Sterling, _Holy Fire_ p228

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: License review request

[Nathanael Nerode]

Arnoud Engelfriet wrote:

> Andrew Donnellan wrote:
>> Of course that doesn't mean it's not required, just that the evidence
>> given was irrelevant. I've seen most places do it and lawyers
>> recommending it and so on, and as it is a legal disclaimer I think it
>> would be wise to use emphasised text, at least put asterisks around it
>> or something to draw attention.
> 
> Laws like the Uniform Commercial Code do require that disclaimers
> of warranty be "by a writing and conspicuous".
> http://www.law.cornell.edu/ucc/2/article2.htm#s2-316
> 
> I suppose you could be equally conspicuous with boldface or
> differently colored text.

Hmm.  I'd really think conspicuous is more about *placement* than emphasis.
A warranty disclaimer in ALL CAPS subtly located on the bottom of the
package is inconspicuous; one in any form of text located front and center
on the package is conspicuous.

Sigh.  Thinking about this, this means putting your warranty disclaimer in
the license, which only a small percentage of recipients even read, is
probably inconspicuous by nature.

> The problem is, as far as the lawyers 
> are concerned, all caps seems to work just fine. Why use
> something different? At best, the court will rule it's just
> as good as all caps. At worst, they'll say you deviated from
> common industry practice, which confuses consumers, and therefore
> your disclaimer was *not* conspicuous.

Well, when someone wins a court case invalidating a disclaimer because all
caps are unreadable it'll change then, I guess.  :-/

> So it's not just monkey-see, monkey-do, but more like
> monkey-worry-about-malpractice.

So "common industry practice" is the reason -- that sort of makes sense, 
even though it's unutterably stupid.

It seems like any disclaimer in the *MIT* license would be relatively
conspicuous, seeing as how it's more text than the whole rest of the
license.  In contrast, I'd expect any disclaimer tucked on page nine of a
ten-page-long license to be found inconspicuous.  And lawyers do *THAT* all
the time.

:-P

> Arnoud
> 

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conquer relicensing

[Nathanael Nerode]

Juan M. Mendez wrote:

> On 10/9/06, Arnoud Engelfriet <[EMAIL PROTECTED]> wrote:
> 
>> Without a piece of paper with Adam's signature saying otherwise,
>> the copyright remains with him. So Ed should ensure he does not
>> change the copyright notice.



> So, I have been investigating.
> 
> It seems Adam Bryant developed a new version 5 of conquer:
> http://www.cs.bu.edu/ftp/fs/pub/adb/beta/
> 
> where all the files hold notices disallowing redistribution of the
> code with a notice
> starting with.
> 
> /* conquer : Copyright (c) 1992 by Ed Barlow and Adam Bryant */

Oh, great.  Reading out of order sucks.  It looks like Adam *didn't* make a
all-new version, he made a *mess*.

You do need to contact him or get rid of the Adam Bryant code.  Arnoud is 
right in his reply -- it's not clear what Adam Bryant's statement 
transferring rights to Ed Barlow means in the context of this later 
information.

> Some people managed to talk with Adam in 1997 where he said he
> licensed conquer to a commercial developer, saying title would revert
> back to him if the company didn't release anything in two years.
> http://members.aol.com/heiska/ecframe/future.html
> 
> A press release in 1997 also seems to cerfify that:
>
http://web.archive.org/web/20020804001252/http://www.mythicentertainment.com/conquerpr.html
> 
> My doubt is, how this license transfering of the Adam Bryant code
> could affect the old code of version 4 of conquer released in 1988 in
> USENET, the one that Ed allowed me to relicense as Free Software.
> 
> Sorry for the sudden burdening of information, I tried to give all the
> information I can.
> 
> -- Juan

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conquer relicensing

[Nathanael Nerode]

Joe Smith wrote:

> 
> "Juan M. Mendez" wrote in message
> news:[EMAIL PROTECTED]
> 
>> So, I have been investigating.
>>
>> It seems Adam Bryant developed a new version 5 of conquer:
>> http://www.cs.bu.edu/ftp/fs/pub/adb/beta/
>>
>> where all the files hold notices disallowing redistribution of the
>> code with a notice
>> starting with.
>>
>> /* conquer : Copyright (c) 1992 by Ed Barlow and Adam Bryant */
>>
>> Some people managed to talk with Adam in 1997 where he said he
>> licensed conquer to a commercial developer, saying title would revert
>> back to him if the company didn't release anything in two years.
>> http://members.aol.com/heiska/ecframe/future.html

I would expect that the new code was completely different, which would
explain this.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Yahoo! DomainKeys license

[Nathanael Nerode]

Magnus Holmgren wrote:

> OK, another stab at this beast!
> 
> I've been in contact with Mark Delany, the Yahoo! engineer that wrote the
> draft and administrates the DomainKeys SourceForge project. HINAL though,
> AFAIK.
> 
> On Saturday 17 June 2006 19:41, Joe Smith took the opportunity to say:


>>
>> Below is my initial analysis of the licence. The licence url is:
>> http://domainkeys.sourceforge.net/license/softwarelicense1-1.html, and I
>> have included a complete copy at the end of this message.
>>
>> Ok, 1.1 does not seem to grant the right to sell the code/program. 
>> Section 1.2 grants the right to sell "for the sole purpose of
>> implementing a sender verification solution in connection with e-mail.".
>> I'm not sure if limiting the scope of Sale is allowed by the DFSG or not.
> 
> But section 1.1 grants the right to modify and distribute the code.
> Without an explicit limitation that must mean that one can charge any
> consideration for it. Section 1.2 grants the right to infringe on the
> patents with the code (and modifications to it) insofar it's needed to
> implement a sender verification solution etc. But that's a patent license,
> and that can't be directly connected to the code. They also license their
> patent claims under their Patent License v 1.2, which says nothing about
> any particular code. Anyway, section 1.2 can't limit the ways the code can
> be used with respect to copyright, you can't expect them to completely
> waive their patents, and the impact of patents on DFSG-freeness has
> already been discussed at length.
> 
>> I'm slightly concerned that the "specification" is an Internet-Draft.
>> More distubing is that the Licence give a URL for the Draft, but the URL
>> does not work.
>> Section 3.3 says "You must create Your own product or service names or
>> trademarks for Your Licensed Code and You agree not to use the term
>> "DomainKeys" in or as part of a name or trademark for Your Licensed
>> Code.". This may be a problem, considering the name of the package.

Actually this is a weird restriction.  Suppose I don't want *any* product
or service names or trademarks, and I want to use the code in an anonymous
fashion.  Must I invent a trademark?  :-/

> According to Mark Delany it's OK to call the package that as long as the
> source code is unmodified. The DFSG specifically allows licenses that
> require name changes if the code is modified.
> 
>> Section 3.5 is a you must obey the laws section.
>>
>> Section 3.8 is choice of law and venue.
> 
> Yes, those are the problematic ones. Instances of both have been discussed
> here and are disliked by many,

We're all OK with choice of law if it seems to be a reasonable legal system
(we'd probably be disturbed by "This license shall be interpreted under the
laws of the Taliban").  Choice of venue is generally considered
unacceptable because it allows nuisance lawsuits by the license issuer, and
specifically allows the license issuer to drag the licensee to strange
faraway courts to defend him/herself.

> but was there consensus as to whether such 
> clauses go against the DFSG? DFSG 6 perhaps, if "breaking the law" is
> a "Fields of Endeavor".

"civil disobedience" perhaps would be a better description.  I don't know
whether this is DFSG-free or not.  It probably is, but it's not very
friendly.

> OK, choice of venue can be nasty, but at least one 
> is entitled to get legal notice and a chance to respond in writing before
> having to physically appear before the court for oral deliberations?

Is that true everywhere?  I hope so but I don't know.

>> It looks like Yahoo was indeed trying to create a a Free licence, or at
>> least an Open-Source licence. However, it clearly fails the part 10 of
>> the OSD (it is not technology nutral, as it is specific to e-mail), and
>> is quite likely to be running afoul of the DFSG.
> 
> It should at least be uploadable to non-free. But in that case Exim can't
> be linked with it unless Exim is moved to contrib, which is unacceptable.
> Seeing as DomainKeys is experimental and even obsolete already, but still
> not replaced with DKIM at Yahoo (for instance), the value of these
> packages can be questioned. OTOH, DKIM is still experimental too. I think
> it can make sense to include DomainKeys packages in Etch and drop them
> again for the next release.

I found one more problem, a big one.

>> 3.4. You may choose to distribute Licensed Code or modifications under
>> this Agreement or a different agreement, provided that:
>>
>> (a) a copy of this Agreement or the different agreement is included with
>> each copy of the Licensed Code or modifications along with the following
>> prominently displayed statement: "By using, reproducing, modifying,
>> publicly displaying, publicly performing, distributing, and/or
>> sublicensing this code as permitted, you agree to the terms and
>> conditions of the Yahoo! DomainKeys Public License Agreement or other
>> agreement contained herein."; and

Not OK.  I

Re: compatibility of bsd and gpl

[Nathanael Nerode]

Matthew Wala wrote:

>> And people can copy&paste
>> that code out of your project and reuse it elsewhere under
>> the original (BSD) terms.
> Doesn't section 2b say that projects reusing BSD code from a GPL'd
> project have to be GPL'd?

No.  This is a matter of identifying the individual works making up
a composite work; the tail end of section 2 applies:

"If identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in themselves,
then this License, and its terms, do not apply to those sections when you
distribute them as separate works."

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conquer relicensing

[Nathanael Nerode]

The title of this thread made me think, "Gee, I'd love to conquer
relicensing."  I'm certainly not a relicensing master yet.  :-)

[EMAIL PROTECTED] wrote:

> Hi all,
> 
> I'm new dealing with licenses and I've been trying to catch up, however
> I need advice.
> 
> Edward M Barlow wrote "conquer", a middle earth multi-player curses
> based game, and posted it in USENET at comp.sources.games around 1987
> and 1988. Later Adam Bryant contributing with code and patching the
> original sources.
> 
> Recently I managed to contact Ed Barlow and asked him for permission to
> relicense conquer as free software. My concerns are around the
> contributed code of Adam Bryant who I didn't manage to contact.
> Please check the original C source code of conquer v4.11 at  [1] and
> look that three files (navy.c, sort.c, and trade.c) specially the
> latter have a notice like this:
> 
> /*conquer : Copyright (c) 1988 by Ed Barlow.*/
> /*
> * The following file "trade.c" was written by Adam Bryant who
> * gives all rights to this code to Ed Barlow provided that this
> * message remains intact.
> */
> 
> Could the code be relicensed as GPL v.2 or any compatible license with
> this notices?

Yeah, Adam Bryant's intent seems extremely clear.  I'm not a lawyer and I'm
not sure exactly how the clause would be interpreted, but it pretty clearly
lets Ed Barlow license the code however Ed wants.  Unless Adam Bryant comes
back and complains, don't worry about it.

> Thanks,
> 
> Juan
> 
> [1]. http://vejeta.no-ip.org/conquerv4/

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Creative Commons 3.0 Public draft -- news and questions

[Nathanael Nerode]

MJ Ray wrote:

> and maybe some other bits too (CC3.0 is a long licence).  The Scotland
> one is far briefer, especially when viewed in context, and it has the
> apparently crucial difference of including 'effect or intent'.

I'm actually curious as to why this is apparently crucial; I haven't seen a
good explanation of this.  It seems to be a better formulation (applies to
cases where technology effectively restricts rights by accident, and to
cases where it was intended to restrict rights but doesn't), but I'm not
sure why it's crucial.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: compatibility of bsd and gpl

[Nathanael Nerode]

Matthew Wala wrote:

> The new BSD
(meaning, without the forced-advertising clause)

> and GPL licenses are considered compatible,  but how are the 
> requirements of the BSD license satisfied when BSD licensed code is
> included in GPL projects (eg, the Linux kernel)?

(1) Include the copyright notice, BSD license text, and disclaimer.
(2) Don't use the specified names to endorse or promote products.

> Is clause 3 of the BSD license ("The name of the author...")
> GPL-compatible?

So the question is, is that clause an additional restriction, prohibited by 
the GPL?  Good question.  Traditionally it's considered not to be.

Probably because it falls in the "You already can't do that" category --
it's a stupid and redundant clause prohibiting something which is illegal
everywhere.  Prohibiting something which is already prohibited is not *in
practice* a restriction, I guess.

I recommend avoiding that clause for new works -- heard of the "two-clause
BSD license"?  You have to be careful with that sort of clause because
sometimes it turns out that the prohibited practice is not prohibited
everywhere, and then it really is a restriction for that jurisdiction.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Nathanael Nerode]

Anthony Towns wrote:

> On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
>> The answer to the question in the subject is simple: NO.
> 
> Thankyou for your opinion. I note you seemed to neglect to mention that
> you're not a lawyer.

Yes, I'm not a lawyer.  Do not rely on anything I say as a legal opinion. 
Even if I *were* a lawyer, my postings here would not constitute legal 
advice.  Please, I don't want to be sued for practicing law without a 
license!  I'm just describing what little I've learned, which is far more 
than I should have to know under a sane copyright law system.  :-/

Actually, you're the frickin' DPL.  Go get a real legal opinion already.
Call SPI's lawyer.  I will be extremely surprised if he says "Yeah, sure,
this stuff is totally legal to distribute", but who knows?

> Cheers,
> aj

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CC's responses to v3draft comments

[Nathanael Nerode]

MJ Ray wrote:

> How can anyone discuss decisions made by a secret process for secret
> reasons in any useful way?  If that decision is to be changed, it helps
> to know how and why it was made, but we simply have almost no data on it.

This is the part which is really frustrating about CC, actually.  Frankly,
if we had some more data on it, we might well conclude "Oh, they rejected a
separate clause just because they wanted to keep the license simple, they
have no problem with the parallel distribution concept."  And then we
wouldn't be discussing this.

I think we have to go with the text as written at this point: any
distribution method which doesn't restrict the rights granted in the
license is OK.  If individual licensors assert a different interpretation,
we'll deal with that then.



> I remember being criticised for taking these comments to wider communities
> in the past, but this is why I do that: CC's discussion forums seem
> damped, narrow and impotent, which I think will only change when enough
> prominent CC supporters like Evan start to question that problem.

Whereas I do it because I'm sick of being told I can't post unless I
subscribe to the mailing list.  :-P

OK.  Let's declare victory and move on.  Proposed statement:

We believe that the draft CC-BY and CC-BY-SA licenses appear to be Free 
Licenses, so that most works licensed under them will probably satisfy the 
DFSG.  Please note that Debian evaluates the freeness of each work 
independently. Issues beyond copyright licensing sometimes come into play. 
And particular licensors may specify different interpretations of the 
license text.  So this statement does not mean that Debian will 
automatically consider every work licensed under these licenses to be free.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CC's responses to v3draft comments

[Nathanael Nerode]

Evan Prodromou wrote:

> On Sun, 2006-24-09 at 12:06 -0400, Nathanael Nerode wrote:
>> Worse, the PDF description of the parallel distribution amendment appears
>> to describe an amendment which is less restrictive than necessary for
>> Debian's purposes (see comment 11).  (Proper parallel distribution
>> requires the unencumbered to be distributed to every recipient of the
>> encumbered: though not technically "with" the encumbered, it's
>> effectively the same,
>> and that's not mentioned in the response.)  Given this
>> (mis)interpretation,
>> I would probably oppose such an amendment too.  :-/
> 
> If there is a mistake there, it is probably my fault. I'm confused as to
> why the unencumbered version must be _distributed_ to each recipient,
> rather than just _made available_ to each recipient. (I differentiate
> here between packaging the two versions inseparably together, versus
> putting the unencumbered version on a public Web site, say.)

Erp, that's correct.  You just stated it even better.  The way the PDF
description from CC stated it it seems to imply that the copies must be
physically bundled.

> I believe it's immaterial to the DFSG-compatibility of the license, but
> I wonder why you think it's required for "proper" parallel distribution
> otherwise.

Clarification above.

>> > Hence, it seems that CC refuses to disclose the intended meaning of the
>> > clause...
>>
>> I think the plaintext meaning should be assumed unless the licensor
>> specifies otherwise (reference UW-Pine case), and we know that the
>> plaintext meaning allows "parallel distribution".  (Of course, if there
>> is a court case, we'd have to defer to that, but until there is, I'd
>> go by the plain meaning.)
> 
> My guess is that Mia's response is a political one. Their international
> affiliates have opposed additional parallel distribution language; we've
> said that the language in the 3.0 draft may be enough to allow parallel
> distribution anyways. Rather than getting them upset, she's given us a
> barely-qualified yes. I think we should take our victory as gracefully
> and discreetly as we can.

OK.

> 
> ~Evan
> 

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: License review request: LinuxMagic FSCL

[Nathanael Nerode]

Ryan Finnie wrote:

> Walter,
> 
> Thank you for your comments (everybody else too).  Sorry for not
> following up sooner; please see question below.
> 
> On 9/27/06, Walter Landry <[EMAIL PROTECTED]> wrote:
>> MJ Ray <[EMAIL PROTECTED]> wrote:
>> > Ryan Finnie <[EMAIL PROTECTED]> asked for help with:
>> > > (c) You must make Source Code of all Your Deployed Modifications
>> > > publicly available under the terms of this License, including the
>> > > license grants set forth in Section 3 below, for as long as you
>> > > Deploy the Covered Code or twelve (12) months from the date of
>> > > initial Deployment, whichever is longer. You should preferably
>> > > distribute the Source Code of Your Deployed Modifications
>> > > electronically (e.g. download from a web site); and
>> >
>> > This looks like forced *public* availability and a 12-month retainer,
>> > which I think is both a significant cost (so not free redistribution)
>> > and maybe a practical problem.
>>
>> If you need to make any modifications, then with this clause, I don't
>> think that it can even be uploaded to non-free.  Debian does not
>> insure that every version ever distributed will be available for 12
>> months.
> 
> How does this differ for the GPL's section 3(b) three-year clause?

Debian doesn't distribute under 3(b), it distributes under 3(a).

> At this point, the feeling seems to be that software that uses this
> license cannot even be uploaded to non-free.

Yes.  :-(

> If that is the case, I 
> will make an effort to contact LinuxMagic and ask them if they can
> re-license magic-smtpd under the GPL (it looks like some of their
> other software is GPL-licensed), and/or ask them to contact
> debian-legal to discuss what can be done to make it possible to
> include magic-smtpd with Debian.
> 
> Again, thanks for the input.
> 
> Ryan Finnie

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: License review request: LinuxMagic FSCL

[Nathanael Nerode]

Ryan Finnie wrote:

> Greetings,
> 
> I responded to an RFP[0] for packaging magic-smtpd[1], and need some
> help on the legal side.  I see 3 issues here:
> 
> 1. The license[2], also included below, has not been reviewed by the
> OSI, and is not used in any existing Debian package.  The company
> itself considers it "open source", but I feel I am not qualified to 
> make a determination.

My GOD.  It's EXTREMELY LONG.

It has several non-free requirements:
(1) Forced distribution.  If you Deploy to anyone, you must make changes
publicly available.  Fails dissident test.
(2) Choice-of-venue.  Fails "force people to fly to Vancouver" test.
(3) The notice in exhibit A is false: you do not agree to this license by
"using" the software.  Forces the display of false notices.

There are several requirements, like the "Wizards get the right to use all
your modifications" one, which are free requirements but obnoxious.

Incidentally, the license text itself seems to be a copyright violation,
since it lifts text from the Apple Public Software License, which IIRC
isn't licensed for modification.

> 2. The software is designed to replace certain components of qmail,
> which is wholly non-free.  Even if the license is clean, does this
> make the software part of the non-free archive as well?

That would make it 'contrib', but it's non-free, so don't worry about it.

> I guess 
> theoretically you could write Free software that would interface with
> magic-smtpd...
> 
> 3. More of a technical packaging question, but as long as I'm here...
> Since magic-smtpd basically requires qmail, and qmail technically
> doesn't exist within Debian (you get the qmail-src package and run
> build-qmail to build your own local qmail .deb), will having a
> Depends: qmail (but it doesn't Build-Depends: qmail) be a problem to
> the Debian package system?  Would I have to Recommends: qmail instead?

No, you can Depends: on out-of-Debian stuff if your package is "contrib"
or "non-free".

> Thank you for your time,
> Ryan Finnie


-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbtctl: two questions regarding use of LGPL and GPL in source files

[Nathanael Nerode]

Øystein Gisnås wrote:

> I've gone through license considerations of RFP-marked package
> libbtctl lately, and have questions about two concerns:
> 
> * 7 source files are have LGPL license in their headers, but link
> against bluez-libs, which is licensed under the GPL. One such file
>
ishttp://cvs.gnome.org/viewcvs/libbtctl/src/btctlimpl.c?rev=1.20&view=markup.
> The overall license of libbtctl is GPL. Shouldn't the license in each
> of the 7 source files be changed to GPL since they link against a
> GPL'ed library?

No.  LGPL is approximately equivalent to GPL+LGPL.  The source files are
LGPL (in case someone takes them out and uses them for some other project).
The combination is GPL.

Basically, whenever you add a bit of GPL to an LGPL thing, you get GPL --
but the LGPLed bits remain LGPL in case someone wants to separate them out
and use them for something else.

> 
> * Some source files are LGPL and some are GPL. The end-result library
> is GPL. My conclusion is that this is DFSG compatible. Am I right?
> 
> Cheers,
> Øystein Gisnås

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...

Re: Vicam driver appears to contain misappropriated code

[Nathanael Nerode]

Michael Poole wrote:

> Nathanael Nerode writes:
> 
>>> Do you have any evidence to indicate that these byte streams contain
>>> any copyrightable or otherwise protected content?
>>
>> They look creative to me.  I certainly couldn't write them independently,
>> on
>> my own.  Under modern copyright law, everything is copyrighted by
>> default,
>> unless it falls in one of the standard uncopyrightable categories.  It's
>> not a "fact" and it's not an "idea".
>> 
>> If you show me evidence that it's a multiplication table, I'll retract
>> that
>> statement.  It appears to be executable code based on the way it's loaded
>> into the camera.  Given the date of the camera's creation, it's not
>> pre-1988, so it's not public domain by lack of notice.
> 
> setup4[] and setup5[] could conceivably be firmware; the others are
> pretty clearly some other kind of device command, or alternatively are
> not copyrightable if they embody executable code.
  

Where on Earth do you get this idea?  This is completely contrary to
everything I have ever heard about copyright law, so I'd really like to see
some legal references.

To my knowledge, executable code is copyrightable in general provided it is
not the only possible (or only reasonable) way to express the needed
execution steps.

If it is the only reasonable way, then idea/expression merger makes it
non-copyrightable.  If it is not, then that is not the case -- it contains
creative elements, and it is copyrighted material.

> In the absence of 
> an indication from the manufacturer or vendor (or from inspection of
> the device), I tend to assume sequences of that size are configuration
> writes rather than small firmware.  Given a particular mode of
> operation, configuration writes are non-creative fact.
> 
>>> (It might be what
>>> the U.S. Copyright Act calls a "useful article".)
>> That category doesn't provide any relevant exceptions to the exclusive
>> distribution right.  (It does restrict action to 1977 law.  Perhaps you
>> know
>> something about 1977 law.)  In any case, the same exceptions do not apply
>> worldwide.
> 
> The US Copyright Office disagrees[1] about the impact of "useful
> article" status.  Insofar as the device is pretty nearly useless
> without these programs,

"Copyright does not protect the mechanical or utilitarian aspects of such
works of craftsmanship. It may, however, protect any pictorial, graphic, or
sculptural authorship that can be identified separately from the
utilitarian aspects of an object"

Ah.  You're suggesting that the programs are *purely* utilitarian and have
*no* non-utilitarian elements.  I don't know about this.  From what I've
seen, the vast majority of programs have non-utilitarian elements even in
object code form.  I'm inclined to assume they have them unless there's some
evidence that they don't.

That's interesting.  It seems like an arguable case.  I am not aware of any
courts which have used the "useful article" distinction in a software case,
but you probably know something I don't.

> and even European governments are realizing 
> that similar kinds of fair use are necessary for interoperability,

Would be nice.  Interoperability exceptions are where we should be looking
here.

The scope of interoperability exceptions is something about which I do not
know very much.  I *do* know that the reverse engineering lawsuits which
were successfully defended involved "Chinese wall" methodology, which
attempts to guarantee (and if done correctly, does guarantee) that the only
replicated material is the *essential* material.

This was not done by this method.

> I 
> do not see a problem with treating these bits as copyright-free until
> someone demonstrates (or asserts under oath, such as in a legal
> complaint) that they are copyrightable.
> 
> [1]- http://www.copyright.gov/circs/circ40.html#useful
> 
>>> Why do you say it
>>> is non-distributable in the first place?
>>
>> Copyrighted material without license from the copyright holder is
>> non-distributable unless it is fair use/fair dealing.
> 
> You have made a rather large assumption to reach this conclusion, but
> you did not identify it earlier.

Oh, the "this is copyrighted material" and "this is not fair use"
assumption?  Yes.

> Also, if you are going to exclude "useful article" status from
> consideration, why include fair use or fair dealing, which are
> similarly neither uniform nor universal?

The parts of that status to which you are referring appear to be part of the
question of what is eligible for copyright, actually.  I'm happy to
consider them, but it seems unlikely to cover anything not covered by the
idea/expression merger doctrine.

> Michael Poole

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Roberto C. Sanchez]

On Tue, Oct 17, 2006 at 03:35:26PM -0700, Don Armstrong wrote:
> On Wed, 18 Oct 2006, Anthony Towns wrote:
> > On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
> > > The answer to the question in the subject is simple: NO.
> > 
> > Thankyou for your opinion. I note you seemed to neglect to mention
> > that you're not a lawyer.
> 
> That should be abundantly apparent to anyone who has been paying
> attention. Regardless, it doesn't dismiss the crux of the argument:
> baring competent legal advice to the contrary,[1] distributing
> sourceless GPLed works is not clear of legal liability. Doing
> otherwise may put ourselves and our mirror operators in peril.
> 
So what?  Distributing GPL works *with* sources is also not clear of
legal liability.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: public domain, take ?$B!g

[Nathanael Nerode]

Arnoud Engelfriet wrote:

> Ben Finney wrote:
>> Perhaps the statement should be granting the recipient "all rights
>> otherwise reserved to the copyright holder".
> 
> Maybe it's better to reformulate it as a non-assert instead of
> a license. There's more than just the exclusive rights.
> 
> To the extent permitted by law, the copyright holder of this work
> hereby declares he will not, now or at any time in the future, exercise
> any right under copyright, related rights or moral rights applicable to
> the work against any person or legal entity. This declaration shall be
> construed to the detriment of the copyright holder to the maximum
> extent permitted by law. Invalidity or unenforceability of any part of
> the above shall not affect any other part.

Finally an actual lawyer steps in.  :-)

Nice draft.  I think that's an excellent idea

Only one quibble, but it's an important one: it doesn't waive the rights of 
heirs or assignees.  To the extent possible, we want to do that *too*.  Any 
ideas?

> (You can't waive your right to protest against mutilation of
> your literary work, and software is a literary work according
> to Berne and WIPO.)
> 
> Arnoud
> 

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: public domain, take ∞

[Nathanael Nerode]

Daniel Gimpelevich wrote:

> Greetings! I'm fully aware that the opinions stated on this list have no
> bearing on anything, but I would still like to ask whether anyone here
> might have any ideas for improving the wording of the following license
> header:
> 
> #!bin/bash
> #
> # Let this be known to all concerned: It is the specific intent of the
> # author of this script that any party who may have access to it always
> # treat it and its contents as though it were a work to which any and all
> # copyrights have expired.
> #
> 
> I thought about "s/author/sole author/" but decided against it as not
> generic enough. I can see how deciding against it may make it rather
> unclear as to whose intent is being expressed, but I think that would be
> rather moot anyway in the event of any dispute. I now cut the ribbon
> opening this to the free-for-all of opinions...

"irrevocable intent" is probably better.  :-/

Also, intent doesn't mean action.  :-)

"The author of this script hereby grants irrevocable permission to any party
who may have access to it to treat it as though it were a work to which any
and all copyrights have expired."

I think that would be an improvement.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...

Re: Releasing a software implementation of a board game as Free Software

[Nathanael Nerode]

Ben Finney wrote:

> "Dr. ERDI Gergo" <[EMAIL PROTECTED]> writes:
> 
>> [Please CC replies to [EMAIL PROTECTED]
> 
> Done.
> 
>> I have no idea where I could get questions like this answered, so I
>> thought Debian-Legal would be a good place.
> 
> You should definitely seek experienced legal opinion in your
> jurisdiction before doing what you propose.
> 
> It might be polite to ask the holder of any trademark, copyright, or
> patent in the board game what their attitude is toward this kind of
> derivative.
> 
>> I'm a European software developer and I'd like to release a GNOME
>> software implementation of a commercial board game.
> 
> Whether it's commercial (traded for money) or not, doesn't really
> matter. What matters is any rights held to concepts in the board game.
> 
>> The game in question is Gobblet
>> (http://www.blueorangegames.com/gobblet.php). Can I release the game
>> as Free Software (if I don't use the trademark Gobblet anywhere in
>> its description)?
> 
> If some party holds any trademark to the game's name or image, you
> can't legally use that name or image (or anything confusingly similar)
> for your game without license.
> 
> If some party holds any copyright in any of the game's creative
> content (rules, images, text, etc.), you can't legally base your work
> on that content without license. You can, though, generate entirely
> new content of your own, or from work for which you do have license to
> derive.
> 
> If some party holds any patent in the game's mechanics, you can't
> legally implement those mechanics in your game without license. I
> don't know how far this extends to abstract mechanics; European
> legislations have historically been to be relatively sensible on the
> topic of patenting abstract methods and algorithms, though this is
> certainly a disputed topic.
> 
> 
> Yes, unfortunately board games can be restricted by all three of these
> disparate bodies of law. This may be part of why it's so expensive to
> produce a board game.

Not really -- board game producers pretty much always use custom artwork,
and new names (so no trademark issues), and game mechanics patents are 
generally construed very narrowly as far as I can tell (so it's hard to 
violate them by accident).  The expense in producing a board game is mostly
in parts, it turns out: pawns and dice cost money, color printing costs
money, box assembly costs money, cardstock costs money, board stock costs
money, etc.  Cheapass Games is an example of a company which avoids most
of these costs.

For sufficiently old games intellectual property law is rarely a serious
problem:
(1) patents on game mechanics have usually expired, since they last 20 years 
or less in most jurisdictions.
(2) trademarks can be handled by renaming.  A reference to the trademark
of the form "This game has similar rules to the game X" is always allowed. 
In some cases the commercial manufacturer used a preexisting generic name 
for a game which they didn't invent: 'monopoly' and 'parcheesi' are very 
weak trademarks for this reason, and quite a lot of uses of them are 
permitted.
(3) copyright issues can be avoided by writing a clean-room description of
the rules and making entirely fresh artwork; usually there isn't enough
material for this to be difficult.  You will almost certainly want to do
this for a computer implementation of *any* board game, unless you can get
the author of the rules or artwork to license the rules/artwork as free 
software.

Game mechanics patents are the most common method of protecting games
from 'cloning', in the jurisdictions which allow them (the US does).  This
generally affects games invented within the last 20 years.

> On the other hand, many board game companies are aware of the fact
> that fan-based derivative works only serve to drive up interest in
> their games, so you may find the company quite helpful.

Right.  It's considered best practice to talk to the game's creator
*anyway*, even if he holds no copyright, patent, or trademark claims (which
he probably does).

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: compatibility of bsd and gpl

[Matthew Wala]

And people can copy&paste
that code out of your project and reuse it elsewhere under
the original (BSD) terms.

Doesn't section 2b say that projects reusing BSD code from a GPL'd
project have to be GPL'd?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Don Armstrong]

On Wed, 18 Oct 2006, Anthony Towns wrote:
> On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
> > The answer to the question in the subject is simple: NO.
> 
> Thankyou for your opinion. I note you seemed to neglect to mention
> that you're not a lawyer.

That should be abundantly apparent to anyone who has been paying
attention. Regardless, it doesn't dismiss the crux of the argument:
baring competent legal advice to the contrary,[1] distributing
sourceless GPLed works is not clear of legal liability. Doing
otherwise may put ourselves and our mirror operators in peril.


Don Armstrong

1: And frankly, I'd be suspicious of the source of any legal advice
claiming that violating the letter of the GPL was something that could
be done without any concern for liability.
-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Anthony Towns]

On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
> The answer to the question in the subject is simple: NO.

Thankyou for your opinion. I note you seemed to neglect to mention that
you're not a lawyer.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Why TPM+Parallel Distribution is non-free

[Nathanael Nerode]

Terry Hancock wrote:

> I have been a Debian user for several years now, an occasional free
> software developer, and a user of the Creative Commons By-SA license, so
> I have been following the effort to make the CCPL3.0 comply with the
> Debian Free Software Guidelines with some interest. I used to post here
> on debian-legal occasionally, and I've rejoined to discuss this issue.
> I am not a lawyer.  I apologize for the length of this post, but it is
> summarizing the conclusions of quite a large discussion (which I
> promised to the Debian folks who joined the conversation there that I
> would provide here).
> 
> The case has been made that CCPL3.0 is DFSG-non-free because it does not
> allow the distribution of content in TPM'd format[0].  I assert that not
> only is this argument false, it is actually reversed: allowing TPM
> distribution, even with parallel distribution of non-TPM versions of the
> same content actually permits a violation of the DFSG, specifically item
> 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.
> """[1]
> 
> I interpret this to be an alternate wording of the same rule described
> as "Freedom 1" of the Free Software Definition:
> 
> """
> The freedom to study how the program works, and adapt it to your needs
> (freedom 1). Access to the source code is a precondition for this.
> """[2]
> 
> Debian's determination that parallel distribution of non-TPM files
> alongside TPM files will solve this problem is based on the FALSE idea
> that binary/source distribution is analogous to TPM/non-TPM distribution.
> 
> This analogy has been cited multiple times in the discussion on
> debian-legal, but I am not able to find much serious analysis of this
> assumption.  It is a seductive idea, and I have to admit that I was sold
> on it myself for quite some time.
> 
> However it misses the most critical point about TPM systems, which is
> that they acquire their force not from "technology" (despite the name),
> but from "law".  It is not truly the fact that TPM is difficult to
> reverse that is the problem, but rather that it is ILLEGAL to do so.

The point here is that parallel distribution obviates any need for the
recipient to reverse the TPM.  If parallel distribution does not do that,
then it is not the sort of parallel distribution we are trying to
allow.  :-)

> Moreover, it turns out that the most serious problem occurs not because
> it is difficult/illegal to *remove* TPM, but because it is
> difficult/illegal to *apply* TPM (counter-intuitive as that may seem).

That is an important point which has not been brought up before.  I'm not
sure how relevant it is though.

*Prohibiting applying a TPM system to a work* is something which can be done
by someone controlling the rights to use the TPM system, regardless of the 
work.  Nothing in the work's license can prevent this, ever.

It's difficult to put a copy of my favorite perl one-liner on the side of a 
blimp.  However, under a free license I am allowed to do so.
The fact that it will be very difficult for anyone to put their modified 
version on the side of the blimp is rather irrelevant.  The fact that I,
or anyone else, need special permission from the blimp owner to do so is
also irrelevant.  Even if the blimp owner is evil and using the blimp for
his own nefarious purposes, the license for my one-liner would be non-free
if it prohibited distribution by means of blimp.

> A system which applies encryption, but is not enforced under law is NOT
> a "TPM" in the legal sense of the word, and is therefore not "being used
> to restrict" a work (legally).

This is why we want to be very specific.  If a system is genuinely being
used to restrict the rights given to work's recipient, we want that to be
disallowed.  If it is not actually restricting rights, we want it to be 
allowed.

The CC-Scotland licenses were written to allow exactly that. The actual 
current text of the proposed CC license is likewise fine, provided it's 
interpreted straightforwardly.

> For example, any "TPM" system licensed under the new GPLv3 (d2), will
> not actually be a TPM in the legal sense, because the license expressly
> declares that it is not. This *technically identical* software is
> nevertheless *legally distinct*. We might call this a "Non Legal
> Technological Protection Measure" or NL-TPM system.

OK.  This is exactly what we're looking to allow.  So this is just a matter
of terminology.

> For such an NL-TPM, Debian's parallel distribution idea *might* apply
> (there is still a subtle problem, but it is much less severe), but this
> is not what "TPM" is under law.  TPM is something that has the force of
> law backing it up.  In the United States, this means that circumventing
> the TPM is a violation of the DMCA. Other countries are adopting similar
> rules, which is, of course, the basis for so much

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Sven Luther]

On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote:
> The answer to the question in the subject is simple: NO.
> 
> This is a matter of copyright law.  If we do not have permission to 
> distribute, it is illegal to distribute.  GPL grants permission to 
> distribute *only* if we distribute source.  So, GPLed sourceless == NO 
> PERMISSON.
> 
> I will list the usual caveats so that nobody else brings them up.
> 
> (1) Obviously if we have an alternate license (dual-licensing) which doesn't 
> require source we can use that license.
> (2) If the material is so trivial it is uncopyrightable we can obviously 
> distribute it.  (The classic example is CRC tables, which contain no 
> creative content beyond the CRC polynomial which is generally public 
> domain.)  Likewise if it was published prior to 1988 in the US without
> copyright notices, or is in the public domain for some other reason.
> (3) If the copyright holder for the firmware donated the firmware to Linux
> with the understanding that it would be redistributed by Debian and other 
> distributors, this may constitute an implicit license to distribute.  This 
> would be a case of dual-licensing, but an unpleasant one because we'd be
> relying on an *implied* license.  This requires tracing down the donation of
> the material to the Linux kernel and ascertaining the state of mind of the
> donor (perhaps by reading press releases).  This clearly applies only to 
> some of the firmware; other pieces have no such 'paper trail'.  Also, this
> implicit license *does not* include a license to modify, because I've never 
> seen any indication that any firmware donor intended that their
> firmware be modified.
> (4) If the hex lumps really are the preferred form for modification, then
> we have the source and this is not a case of 'sourceless firmware'.  I have
> not yet seen a case where there is any evidence that this is true.  It is,
> however, theoretically possible.  If the firmware author came forward and 
> said "Yes, that's the form in which we modify the firmware", this would be 
> the case.

Thanks Nerode for this complete reply.

It seems thay 3) is probably the best way we have to be able to distribute
sourceless de-facto GPLed firmwares, but as you say, it will be a mess.

I suppose the firmwares resolutions, both the one voted, and the one i
proposed, both allow to include those firmwares into main under these
conditions, for etch only, altough the resolution voted upon is probably much
less clear in its wording. It is regretable that Manoj losed patience suddenly
after more than a month an a half of discussing the issues. But we will see.

I think we all now await impatiently the statement of the RMs on what will
happend with the tg3 and acenic firmwares, and if we need a new vote or not.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Nathanael Nerode]

The answer to the question in the subject is simple: NO.

This is a matter of copyright law.  If we do not have permission to 
distribute, it is illegal to distribute.  GPL grants permission to 
distribute *only* if we distribute source.  So, GPLed sourceless == NO 
PERMISSON.

I will list the usual caveats so that nobody else brings them up.

(1) Obviously if we have an alternate license (dual-licensing) which doesn't 
require source we can use that license.
(2) If the material is so trivial it is uncopyrightable we can obviously 
distribute it.  (The classic example is CRC tables, which contain no 
creative content beyond the CRC polynomial which is generally public 
domain.)  Likewise if it was published prior to 1988 in the US without
copyright notices, or is in the public domain for some other reason.
(3) If the copyright holder for the firmware donated the firmware to Linux
with the understanding that it would be redistributed by Debian and other 
distributors, this may constitute an implicit license to distribute.  This 
would be a case of dual-licensing, but an unpleasant one because we'd be
relying on an *implied* license.  This requires tracing down the donation of
the material to the Linux kernel and ascertaining the state of mind of the
donor (perhaps by reading press releases).  This clearly applies only to 
some of the firmware; other pieces have no such 'paper trail'.  Also, this
implicit license *does not* include a license to modify, because I've never 
seen any indication that any firmware donor intended that their
firmware be modified.
(4) If the hex lumps really are the preferred form for modification, then
we have the source and this is not a case of 'sourceless firmware'.  I have
not yet seen a case where there is any evidence that this is true.  It is,
however, theoretically possible.  If the firmware author came forward and 
said "Yes, that's the form in which we modify the firmware", this would be 
the case.

Sven Luther wrote:

> Hi debian-legal, ...
> 
> It seems the firmware kernel issue has reached a deadpoint, as there is
> some widely different interpretation of the meaning of the GPL over
> sourceless code.
> 
> For some background, the kernel/firmware wiki page includes both a
> proposed GR, the draft position statement by the kernel team, as well as
> an analysis of how we stand :
> http://wiki.debian.org/KernelFirmwareLicensing.
> 
> But this is beside the point. The real problem is that there are a certain
> amount of firmware in the kernel, embedded in the drivers, which have no
> license notice whatsoever, and as thus fall implicitly under the common
> GPL license of the linux kernel. The audit from Larry lists some 40+ such
> firmware blobs.

Actually, I have to split this into two categories:
* hex lumps explicitly licensed under the GPL by the copyright holder
  (e100 for instance)
* hex lumps with no license notice
  - these may be implicitly under the common GPL license for the kernel
  - but they may also be present inappropriately, with stripped copyright
notices and no license at all, if they were inserted into the kernel
by someone other than the copyright holder.  This has happened at least
once already.

> There is some claims that some of those blobs represent just register
> dumps, but even then one could argue that the hex blobs doesn't in any way
> represent the prefered form of modification, but rather some kind of
> register name/number and value pair.
(Well, perhaps the registers are numbered "0,1,2,3,4,5..."
and the values are listed in that order)

> So, the RMs are making claims that those sourceless GPLed drivers don't
> cause any kind of distribution problem,

This is a case of the RMs not thinking clearly, perhaps.

> while i strongly believe that the 
> GPL clause saying that all the distribution rights under the GPL are lost
> if you cannot abide by all points, including the requirement for sources.

Yep.

> Since i am seen as not trusthy to analyze such problems, i think to
> deblock this situation, it would be best to have a statement from
> debian-legal to back those claims (or to claim i am wrong in the above).
> 
> Friendly,
> 
> Sven Luther

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why TPM+Parallel Distribution is non-free

[MJ Ray]

I spent far too long crafting a reply to this, then a pair of ISP/SMTP
errors sent it to /dev/null - this is a rushed rewrite.  If you are in
a rush, points 17.1, 17.8, 17.13, 17.15 and 17.18 are most repeated
and you can get the gist from them.

Terry Hancock <[EMAIL PROTECTED]> wrote
> MJ Ray wrote:
> >  Since when has CC-By been a copyleft anyway?
> 
> CC-By is a separate issue and whether it is or is not a "copyleft" isn't 
> relevant.

17.1 One cannot argue that allowing being non-copyleft is a problem
for CC-By.

> The terms in question ARE DFSG free, as they exist in CCPL3.0, 
> for By and By-SA.

17.2 That seems circular reasoning: the terms follow DFSG, as they
exist in CCPL 3.0; and CCPL 3.0 follows DFSG, as the terms follow DFSG.

> FWIW, Mia Garlick notes that, unlike copyright, TPMs are not limited by 
> "fair use" or "fair dealing".  Thus TPMs have the capacity to render a 
> work even less free than "all rights reserved".

17.3 That is a problem that I am working on, but as far as I can see
from the treaties, there's no assurance that "fair use" or "fair dealing"
exists in any meaningful form everywhere.

> The platform monopoly issue creates a problem for the original work, as 
> well as derivatives, so it is still a problem for CC-By licensors.
> 
> More importantly, from my PoV, the provision *is* DFSG free, so it 
> doesn't matter.

17.4 Either it is a problem or it doesn't matter.  Pick one.

> > > Not only is this untrue, but it is in fact reversed. Allowing TPM
> > > distribution allows a platform-owner to obstruct redistribution of
> > > the work.
> >
> >  It is true. Also, allowing TPM distribution while prohibiting a
> >  platform-owner to obstruct redistribution of the work would not allow
> >  a platform-owner to obstruct redistribution of the work.
> 
> Now, who's using the confusing phrasing? ;-)
> 
> TPM is such an obstruction.  Hence "allowing TPM distribution while 
> prohibiting a platform-owner from obstructing redistribution of the 
> work" is contradictory.

17.5 Only if one assumes that TPM must be such an obstruction.
That assumption may be wrong.  The legislative definitions of TPM are
not great and there's not much case law yet.

> > >> the restrictions of a licence that permits parallel distribution
> > >> need not be non-copyleft;
> > >
> > > The anti-TPM clause is part of the copyleft. It is essential to
> > > preserve the freedom of the work, hence it is essential to
> > > copyleft.
> >
> >  However, blanket anti-TPM is not the only way to preserve that
> >  freedom and arguing about copyleft does little to argue for why it's
> >  in CC-By.
> 
> There is no "blanket anti-TPM". There is a requirement that distribution 
> not occur in TPM'd form.  All free licenses have some kind of 
> distribution requirement. Many (including the GPL) make requirements 
> about the form of distribution of derivatives (e.g. "you must include 
> the license").

17.6 The existance of some acceptable restrictions does not make all
restrictions acceptable.  Some discriminate against fields or groups.

> I've already pointed out that it is technically possible to design a TPM 
> that triggers on the presence of GPL license statements, thus rendering 
> the GPL non-free by your argument. 

17.7 I do not see how it is possible to twist my argument into that
conclusion.  Has it been misunderstood?

[...]
> BTW, this is NOT a new freedom of the CC-By-SA, as you keep suggesting. 
> The wording has been improved, but CC-By-SA 2.5 provided this freedom as 
> well (and it may go back further).  Mia Garlick addresses this point in 
> #6 of her "responses" document:
> http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060908/da9db6a3/attachment-0001.pdf
>  

17.8 I am not online, I do not have that URL cached and IIRC it doesn't
convert neatly anyway.  As with other URLs, I neither accept nor reject
their arguments - it is merely citing inaccessible material.  If it is
important, please quote relevant excerpts or summarise the substance, and
give an unambiguous reference. This isn't rocket science - it's research.

> > >> 1. one particular problem with TPMs overruling all other
> > >> arguments;
> > >
> > > It's not so much "one particular problem" as it is "THE problem".
> >
> >  Really? Fantastic! So prohibit "THE problem" instead of
> >  carpet-bombing whole fields of endeavour.
> 
> The only "field of endeavour" being restricted is the same one that ALL 
> free licenses restrict: namely, the process of distribution.  As with 
> ALL free licenses, requirements are set on the form and methods of 
> distribution.

17.9 If the TPM field of endeavour were restricted, that might be fine.
It's not: any public use of TPM is prohibited, if I believe the claims.

> > > The entire purpose of TPMs is to preserve monopolies.
> >
> >  I thought the entire purpose of copyright was to grant monopolies,
> >  even if that's not what we use it for today. I wonder whether TPMs
> >  will be subject to s

Re: Why TPM+Parallel Distribution is non-free

[MJ Ray]

Terry Hancock <[EMAIL PROTECTED]> wrote:
> [...] It's very frustrating to have to 
> repeat the same points over and over again, because some people don't 
> apparently read them before replying.

Amen.

> I can appreciate of course, that Debian legal folk, having discussed 
> this already, and having amongst themselves already reached a consensus, 
> find it difficult to have to revisit the same question. [...]

Please check the prejudice in at the door.

> On the other hand, some of the responses on this list have been very 
> rude, which does make it difficult to have an intelligent conversation.  
> I don't find that hurling insults or airing conspiracy theories is 
> particularly helpful.

FWIW, I don't find the finger-jabbing, confrontational style of this:

> However, in respect for your request, I've eliminated all stylistic 
> emphasis from this post.  IMHO, this makes it harder to read, but I 
> trust you are prepared to make the extra effort. [...]

this:

> (Once again, here's the binary/source to TPM/non-TPM analogy that MJ Ray 
> insists isn't being used to support parallel distribution... being used 
> to support parallel distribution!)  [...]

and this:

> Okay, but what part did you not understand? [...]

at all helpful.  What responses were rude?

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why TPM+Parallel Distribution is non-free

[MJ Ray]

Terry Hancock <[EMAIL PROTECTED]> wrote:
> Okay, fine. Let's consider the case in which TPM is "hard" to apply:
> Then isn't it an effective barrier to further modification and 
> redistribution (i.e. non-free)?

It's a practical problem, not necessarily something non-free.

[...]
> I stand by my opinion that TPM is intrinsically simpler than binary 
> compilation.
> [...] After all, there is a standing assumption that programs are 
> written by expert "developers" who are not regarded as being in the same 
> class as mere "users".
> [...] But content creation is not a technical specialty. [...]

The above assumptions are flawed, in my experience (I've used TPM
more complex than compilation; I was no expert when I started
writing programs; and putting out a radio magazine show is surely
a technical specialty - well, if you want to do it right).

> [...] It creates an incentive to keep the TPM simple to apply.

While noble, that is not necessarily any more free than requiring
distribution to always be in a shar.

> [...] So the anti-TPM 
> clause is necessary to preserve copyleft, and Debian really needs to 
> recognize that in order to remain the flagship free software 
> distribution that it is.

Yeah, and Debian really needs to recognise patent-poison-pill clauses,
anti-commercial clauses and distributing Netscape in main(!)

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-free IETF RFC/I-Ds in source packages

[Francesco Poli]

On Mon, 16 Oct 2006 11:49:48 +0200 Simon Josefsson wrote:

> Francesco Poli <[EMAIL PROTECTED]> writes:
[...]
> > I don't know whether I'll have enough time to do it personally.
> > Let's do as follows: I see if I can modify the wiki page on Sunday;
> > you look at the wiki page on Monday and, if it's not already
> > updated, you do the changes.
> > OK?
> 
> I've updated it, thanks!

You're welcome!  :)

> 
> >> Btw, one variant of the "MIT License" is described at:
> >> http://www.opensource.org/licenses/mit-license.php
> >
> > That is the Expat license, word for word identical.
> 
> I used that link instead of the one above, this one seems more
> authorative.

That seems to be a valid choice[1], taking into account that
 recently began to refuse
connections on TCP port 80...
We are really beginning to have a problem with vanishing URLs for
widespread non-copyleft licenses.  :-(
I'm more and more convinced that my wishlist bug #284340 is a good
suggestion...  :-|


[1] except for the minor drawback of (mis)leading people to consult the
OSI list of approved licenses, as if it were anything meaningful...  :-(

[...]
> > The fact is that it's *one* of the licenses historically used by
> > MIT. But MIT used many other licenses as well, so referring to it as
> > the "MIT license" is a bit vague.  Moreover the X11 license is also
> > known as the "MIT license" as well; hence the name "MIT license" is
> > an ambiguous label.
> > As already explained, "X11 license" is also vague...
> 
> It's a mess, agreed.  I can't think of a better name than "Expat/MIT"
> though, and since the URL is present, the risk of confusion seems
> small.

The clearest and least ambiguous name for that license, is "Expat
license", AFAICT.
It has the only drawback of being less widespread and known than "MIT
license", which, on the other hand, is ambiguous, as already explained.

Using the compound name "Expat/MIT license" or "Expat a.k.a. MIT
license" is, IMHO, the best way to be clear and understandable, while
disambiguating the reference to MIT...

> 
> > P.S.: Please do not Cc: my personal address when replying to the
> > list, as I didn't ask to be copied.  Thanks.
> 
> Sorry, I'm reading this list through gmane.org and pressed 'F' in
> Gnus, which apparently ended up being the wrong thing.

Don't worry, nothing serious happened!  :)

> I changed the headers manually this time.

It worked!

-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpYyyaXzVGf3.pgp
Description: PGP signature