Re: Microcode license [#3]

[Thomas Bushnell, BSG]

Anthony Towns  writes:

> It's not able to be modified, it's not going to be a part of Debian
> anyway. What's your point?

Ok, perhaps I misunderstood.  Please forgive me...I was assuming that
it was being discussed here precisely because it might be part of
Debian.  What exactly is its current status and its proposed new
status, then?

Re: Microcode license [#3]

[Edmund GRIMLEY EVANS]

Giacomo Catenazzi <[EMAIL PROTECTED]>:

> But there is annother difficult. To write BIOS we use assembler because
> we have much control to hardware, to write microcode I think they don't
> use any language, to be more direct. They write (maybe) directly the bit
> or byte. Thus there exists only binary files, so for DFSG: no source.

There probably is a source, but the compiler is probably top secret
and proprietary, so the source wouldn't be very useful to people
outside Intel.

> But: I can convince Intel to change the microcode license in a more
> liberal way, but I would never convince Intel to put documentation
> on microcode and to put microcode DFSG.
> Thus I think the first step is to have microcode so much free
> that it can be included in debian non-free.

Yes, definitely. The microcode will probably never be DFSG-free, but
please do try and get it into non-free.

> Then we must improve Linux (kernel) and Open Source enought to
> convince hardware manufacters to release microcodes and documentations
> in a DFSG compatible manner.

Maybe, but there would be very little practical benefit from having
DFSG-free microcode. Most of the arguments for free software don't
really apply to microcode. I work for a company that designs
microprocessors, so I might be interested in reading the microcode
source, if I could get my hands on it legally without signing an NDA,
but I very much doubt anyone would want to distribute modified
versions of it, for example.

Edmund

Re: Microcode license [#3]

[Giacomo Catenazzi]

Anthony Towns wrote:
> 
> On Thu, May 31, 2001 at 10:13:22AM +0200, Giacomo Catenazzi wrote:
> > The license (for non-FREE section):
> > /   Copyright  Intel Corporation, 1995, 96, 97, 98, 99,
> > 2000, 2001.
> > /
> > /   These microcode updates are distributed for the sole
> > purpose of
> > /   installation in the BIOS or Operating System of
> > computer systems
> > /   which include a Genuine Intel microprocessor sold or
> > distributed
> > /   to or by you. You are not authorized to use this
> > material for
> > /   any other purpose.
> 
> Is this all of the license?

Yes

> 
> If so, it doesn't appear to give us permission to distribute it, simply
> to use it. Which would mean we can't distribute it.

The sentence:
"These microcode updates are distributed for the sole purpose of"
don't mean "You can distribute the microcode with the conditions:" ?
Only on last sentence they restrict the use.

> 
> Adding something like: ``In addition, you may freely distribute copies of
> this microcode'' would be fine. Adding something like ``Special permission
> is given for this microcode to be distributed by the Debian project.''
> would probably also be fine.
> 
> Note that Intel's claims as to what you can and can't do with the
> microcode aren't necessarily legally binding.

I don't undertand this sentence. If you mean the email I receive from
Intel: yes. The email are from a developer, so probably he is not
authorized to give/sell Intel property (and licenses).
But the license is legally binding AFAIK.


giacomo

Re: Microcode license [#3]

[Anthony Towns]

On Fri, Jun 01, 2001 at 11:41:26AM +0200, Giacomo Catenazzi wrote:
> Anthony Towns wrote:
> > On Thu, May 31, 2001 at 10:13:22AM +0200, Giacomo Catenazzi wrote:
> > > The license (for non-FREE section):
> > > /   These microcode updates are distributed for the sole
> > > purpose of
> > > /   installation in the BIOS or Operating System of
> > > computer systems
> > > /   which include a Genuine Intel microprocessor sold or
> > > distributed
> > > /   to or by you. You are not authorized to use this
> > > material for
> > > /   any other purpose.
> > If so, it doesn't appear to give us permission to distribute it, simply
> > to use it. Which would mean we can't distribute it.
> The sentence:
> "These microcode updates are distributed for the sole purpose of"
> don't mean "You can distribute the microcode with the conditions:" ?

Not really. It just means it's distributed by someone. Intel is someone.
So it doesn't say anything about whether Debian can or should or is
distributing it.

> Only on last sentence they restrict the use.

Modificating and redistribution aren't allowed unless explicitly permitted.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

Have you been hacked by f*ck PoizonBOx?

[L@@K dont throw away!]

I've created an online community called "Have you been hacked by f*ck 
PoizonBOx?". 

http://www.delphi.com/PoizonBOx/start/

Please join the discussion! 
With the message board, you can view discussion folders quickly in the 
left-hand column and read up to 20 messages at a time. You can even attach 
files (such as pictures and programs) directly to messages -- just like 
e-mail. It's fast, easy, and efficient. 

As the Forum "Host," I control the specific features of the Forum. The 
other options include real-time Chat, voice chat, and polls. I can also 
choose to make it public or private. 

I've chosen to make this Forum public so anyone can participate, so feel 
free to tell your friends. 

The best way into my Forum is at the following URL: 
http://www.delphi.com/PoizonBOx/start/

I'm eager to hear comments and suggestions. Let's get the conversation 
started! 

Best regards, 

Re: Microcode license [#3]

[Thomas Bushnell, BSG]

Edmund GRIMLEY EVANS <[EMAIL PROTECTED]> writes:

> Maybe, but there would be very little practical benefit from having
> DFSG-free microcode. Most of the arguments for free software don't
> really apply to microcode. I work for a company that designs
> microprocessors, so I might be interested in reading the microcode
> source, if I could get my hands on it legally without signing an NDA,
> but I very much doubt anyone would want to distribute modified
> versions of it, for example.

That's crazy.

The most famous use of microcode in Unixland was the Vax 11/750.  DEC
had unfortunately changed the way floating point errors were signalled
due to a microcoding bug.  (The Vax 11/780 had them as traps [so that
the PC would skip after the failing instruction], but due to a
microcoding bug, the 11/750 had them as faults [so that the PC would
repeat the failing instruction.)  When the bug became well known, DEC
said they wouldn't fix it, and instead altered the VAX architecture
description to say that it was processor dependent whether floating
point errors were faults or traps.

This is a significant issue for users.  Fortunately, the 11/750 also
had an experimental "programmable control store" (that is, a
user-loadable microcode).  DEC would provide the specs to anyone who
wanted them, and so BSD could produce that nice little file
"pcs750.bin" which came with BSD Unix.  This was a little microcode
patch BSD wrote to convert the floating point errors on the 750 back
into traps, providing architectural consistency.

If you think there is never any need to modify the microcode, then I
ask you: why does Intel make it user-loadable in the first place?

Thomas

Re: Microcode license [#3]

[Raul Miller]

Um.. just to reiterate what's going on here:

For Debian to distribute the microcode at all, we need permission to
distribute it[1].

For Debian to distribute the microcode *as a part of Debian*, we'd need
the microcode to meet the DFSG.

[No one (other than Thomas Bushnell) is advocating that the microcode
be distributed under the DFSG.]

For the microcode loader to be distributed *as a part of Debian* the
microcode loader, of course, needs to meet the DFSG.

However, note that if the only use for the microcode loader is to load
the non-free microcode, we'll wind up putting it into contrib.  Contrib is
an official part of Debian, but it's a part that is useless without some
non-free element (which Debian might or might not distribute).

Which brings us back to the first point:  If Debian is to be allowed
to distribute the microcode then Debian has to be granted permission to
distribute it.

It's really not any more complicted than that.

-- 
Raul

[1] different people have different ideas of what Debian is -- and that
none of them are likely to be relevant in any legal context[2]

[2] except maybe in a court such as Delaware's Chancery Court
(http://courts.state.de.us/chancery), which in some senses is more of
a moral court than a legal court.  But most of Debian is outside the
jurisdiction of this court, so this is a fairly trivial comment.

libfpx licensing

[Filip Van Raemdonck]

Hi,

I am working on a package for libfpx - the FlashPIX toolkit. I'm not sure
about the license of the library though.
Is it DFSG free?

Regards,

Filip

PS. Please CC me on replies, I am not subscribed to this list.

-- 
 I only get 13M/sec off my wide LVD 10k rpm scsi drive
 well, obviously you need to replace that 10k rpm drive with a 10k
deb drive...
 it will integrate much better...
* Overfiend hides
/* COPYRIGHT NOTICE:
*
* * Permission is hereby granted to use, copy, modify, and distribute this
* source code, or portions hereof,  with or without modifications, for any
* purpose and without fee or royalty, subject to the following
* restrictions: 
*
* 1. The origin of this source code or any portion of this source code must
*be attributed to the Digital Imaging Group Inc. and the contributors of
*the Flashpix toolkit source code -- Eastman Kodak Company.
*
* 2. Altered versions must be plainly marked as such and must not be
*misrepresented as being the original source.
*
* 3. This Copyright notice may not be removed or altered from any source or
*altered source distribution.
*
* 4. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:  "This product includes
*   software developed by the contributors and Digital Imaging Group, Inc.
*(http://www.digitalimaging.org/) for use in the Flashpix Toolkit
* Project." 
*
* 5. The names "Digital Imaging Group", "DIG", and any other marks
*identified as trademarks or service marks of DIG must not be used to
*endorse or promote products derived from this software without prior
*written permission. For written permission please contact
*[EMAIL PROTECTED] Certification marks owned by DIG may only be
*used in connection with a signed certification agreement.  The term
*   "Flashpix Toolkit" may only be used to refer to the specification owned
*by the DIG.
*
* 6. AS IS - NO WARRANTY
*The Software is provided "AS IS" and without warranty. Neither DIG
*nor its contributors warrant that the functions contained in the
*Software will meet your requirements or that the operation of the
*Software will be uninterrupted or error free. Neither DIG nor its
*contributors makes any representation or warranty as to whether the
*Software, or the operation of the Software, infringes any patent,
*copyright, trademark or other right of any third party. You assume
*responsibility for operation of the Software to achieve your intended
*results, and for the installation,use,and results obtained from the
*Software. 
* 
* 7. Subject to any applicable legislation which prohibits the following
*exclusions, NEITHER DIG NOR ITS CONTRIBUTORS MAKE
*ANY OTHER WARRANTIES OF ANY KIND, EITHER
*EXPRESS OR IMPLIED, INCLUDING THE IMPLIED
*WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
*PARTICULAR PURPOSE OR NONINFRINGEMENT. Some
*jurisdictions do not allow the exclusion of implied warranties, or have
*legislation that imposes certain statutory warranties that cannot be
*excluded, so the above exclusion may not apply to you. This warranty
*gives you specific legal rights and you may also have other rights.
* 
* 8. LIMITATIONS OF REMEDIES
*IN NO EVENT WILL DIG OR ITS CONTRIBUTORS OR
*SUPPLIERS BE LIABLE TO YOU FOR ANY INCIDENTAL OR
*CONSEQUENTIAL DAMAGES, INCLUDING ANY LOST
*PROFITS, LOST SAVINGS, OR OTHER DAMAGES ARISING
*OUT OF THE USE OR INABILITY TO USE THE SOFTWARE
*EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
*DAMAGES. 
* 
* 9. You will be responsible for complying with all applicable laws relating
*to your use of the software including, without limitation, export laws.
*   
* This Agreement constitutes the  entire agreement between you and DIG
* with reference to this transaction. If the Software was acquired
* in the United States, this Agreement is governed by the laws of the State
* of New York. If acquired outside the United States, this
* Agreement is governed by the laws of the country in which it
* was acquired. 
*
* The contributing authors and Digital Imaging Group specifically permit,
* without fee, and encourage the use of this source code as a component to
* supporting the Flashpix file format  in commercial products.  If
* you use this source code in a product, acknowledgment is not required  but
* would be appreciated.
*/


pgpfwmLHDlGjH.pgp
Description: PGP signature

Re: libfpx licensing

[Walter Landry]

> Hi,
> 
> I am working on a package for libfpx - the FlashPIX toolkit. I'm not sure
> about the license of the library though.
> Is it DFSG free?
> 
> Regards,
> 
> Filip

It looks like the BSD with the (obnoxious) advertising clause.  It
also has the choice of law clause.  It is DFSG free and can go in
main.  Just don't try to meld it with GPL code.

Regards,
Walter Landry
[EMAIL PROTECTED]

Re: Microcode license [#3]

[Giacomo Catenazzi]

"Thomas Bushnell, BSG" wrote:
> 
> Giacomo Catenazzi <[EMAIL PROTECTED]> writes:
> 
> > 2) It is difficult to say that microcode is a program:
> >there are surelly many entry points (one per instruction),
> >many exit point. Instruction are executed partly in parallel,...
> >It is too hardware dependent. You can see it also as a immage for
> >a chip. Then the electric flow are influenced by this immage (like
> >photocopy machines), but relly it is not a program (AFAIK, the
> >intel microcode is a list of changes of order of u-instructions
> >in instruction). But until we have not full (or also some) Intel
> >microcode and CPU internal build documentation, we cannot know
> >if it is software...
> 
> Oh, please!  We know it's software.  They call it *microcode*.

hmm. They don't call it officially 'microcode'. On official documents
you will found other names (but I don't remember the official names.
In the errata they wrote: corrected via BIOS).
The name 'microcode' is an historic one, when there was programmable
instructions, and the developer at Intel wrote either 'microcode'
and 'data file'.

> 
> Having many entry points, parallel processing, hardware dependencies:
> all these are characteristics of it, but it is still software.

OK

> 
> It isn't hardware, precisely because you can upload *different*
> microcodes and get different behavior.  And Intel (IIUC) is preventing
> people from having the liberty to change and alter how that
> *programmable* function gets programmed.

True! (I expected that some hacker will found the microcode structure/
language, but I think it is too difficult because: the microcode (
but the header) is encrypted, and it is too hardware specific)

 
> > 3) You should be more contructive. Intel already changed the license
> >because of Debian need. If you point to me exactly what is wrong
> >and what changes should be taken, I can tell Intel to improve the
> >license for the second time.
> 
> They should conform to the DFSG.  How hard is that?  Relabeling a
> dog's tail to be a leg doesn't make it a leg.  They need to make it
> *free software*, not just try and redefine terms so that it isn't
> software.
> 
> Thomas

True! But until the microcode will become DFSG, adding microcode to
debian add some freedom to us: the hardware that we buy will conform
more to the standard. Thus it is simple to make working program without
adding the exception for the various CPU.

But there is annother difficult. To write BIOS we use assembler because
we have much control to hardware, to write microcode I think they don't
use any language, to be more direct. They write (maybe) directly the bit
or byte. Thus there exists only binary files, so for DFSG: no source.


But: I can convince Intel to change the microcode license in a more
liberal way, but I would never convince Intel to put documentation
on microcode and to put microcode DFSG.
Thus I think the first step is to have microcode so much free
that it can be included in debian non-free.
Then we must improve Linux (kernel) and Open Source enought to
convince hardware manufacters to release microcodes and documentations
in a DFSG compatible manner.

giacomo