[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ken Fuchs]

      I haven't spend much time working with ACPI tables, but there may be
copyright issues with decompiling these on a COTS BIOS and using the
result in LinuxBIOS.  Does anyone agree there may be a copyright
concern here?  I don't think there is, but I'm not a copyright lawyer.

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com>

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ronald G. Minnich]

On Thu, 28 Jul 2005, Ken Fuchs wrote:

  I haven't spend much time working with ACPI
tables, but there may be
 copyright issues with decompiling these on a COTS BIOS and using the
 result in LinuxBIOS.  Does anyone agree there may be a copyright
 concern here?  I don't think there is, but I'm not a copyright lawyer.
that's a good question. we don't know. On the one hand, ACPI describes 
hardware, and the OSes read it all the time. Seems like public info. 

OTOH, there's a copyright notice in there. 

I don't know the answer.

ron

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Josiah England]

      On Thu, 2005-07-28 at 15:23 -0600, Ronald G. Minnich wrote:
  
 On Thu, 28 Jul 2005, Ken Fuchs wrote:
 
  I haven't spend much time working with ACPI
tables, but there may be
 copyright issues with decompiling these on a COTS BIOS and using the
 result in LinuxBIOS.  Does anyone agree there may be a copyright
 concern here?  I don't think there is, but I'm not a copyright lawyer.
 
 that's a good question. we don't know. On the one hand, ACPI describes 
 hardware, and the OSes read it all the time. Seems like public info. 
 
 OTOH, there's a copyright notice in there. 
 
 I don't know the answer.
 
 ron
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios
Since there's a copyright notice in it, we would be safer off by
duplicating that copyright notice if at all possible and putting it in
our code.
Since there is no (direct) financial gain from us not selling the
software, there is little chance of repercussions.

Josiah

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ronald G. Minnich]

On Thu, 28 Jul 2005, Josiah England wrote:

  Since there is no (direct) financial gain from us not
selling the
 software, there is little chance of repercussions.
I don't think that will work, 
All Rights Reserved

ron

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Russell Whitaker]

On Thu, 28 Jul 2005, Ronald G. Minnich wrote:

 

 On Thu, 28 Jul 2005, Josiah England wrote:

  Since there is no (direct) financial gain from us
not selling the
 software, there is little chance of repercussions.
 I don't think that will work,
 All Rights Reserved
Try google using the words "copyright fair use"

While you might be able to claim "fair use" the safest way is to
get permission from the copyright holder.

   Russ

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ronald G. Minnich]

On Thu, 28 Jul 2005, Russell Whitaker wrote:

  While you might be able to claim "fair use"
the safest way is to
 get permission from the copyright holder.
yeah, I doubt that putting a copyright item in the linuxbios tree on an 
svn server would qualify for fair use.

ron

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Greg Lindahl]

      On Thu, Jul 28, 2005 at 03:29:54PM -0600, Josiah England wrote:

  Since there is no (direct) financial gain from us not
selling the
 software, there is little chance of repercussions.
It is commonly believed that non-commercial use of copyrighted
material is safer, but this isn't true. You're still liable for $$
penalties.

Facts can't be copyrighted. But it's not easy to use that to convince
someone to stop labeling a fact as being copyrighted.

-- greg

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Janek Kozicki]

  Facts can't be copyrighted. But it's not easy
to use that to convince
 someone to stop labeling a fact as being copyrighted.
but current linux kernel has to decompile ACPI tables too, right? and BSD also?

or am I wrong?

-- 
Janek Kozicki                                                         |

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Stefan Reinauer]

      * Janek Kozicki <janek_listy(a)wp.pl> [050731 09:46]:
  Facts
can't be copyrighted. But it's not easy to use that to convince
 someone to stop labeling a fact as being copyrighted.
 
 but current linux kernel has to decompile ACPI tables too, right? and
 BSD also?
But the ACPI tables don't have to be part of Linux for the whole thing
to work. If you flash LinuxBIOS, you _include_ a set of ACPI tables, or
no ACPI tables are available..

Stefan

[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ronald G. Minnich]

On Sun, 31 Jul 2005, Janek Kozicki wrote:

  Facts
can't be copyrighted. But it's not easy to use that to convince
 someone to stop labeling a fact as being copyrighted.
 
 but current linux kernel has to decompile ACPI tables too, right? and BSD also?
sure it does. Now what happens if it decompiles tables and mails them to 
world, I just don't know. 

ron

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

      "Ronald G. Minnich" <rminnich(a)lanl.gov> writes:

  On Sun, 31 Jul 2005, Janek Kozicki wrote:

  Facts
can't be copyrighted. But it's not easy to use that to convince
 someone to stop labeling a fact as being copyrighted.
 
 but current linux kernel has to decompile ACPI tables too, right? and BSD
 also?

 sure it does. Now what happens if it decompiles tables and mails them to 
 world, I just don't know.
I don't know where we should get the information.  But
we should generate all of our tables from our native
LinuxBIOS device tree.  The MP table is about half way
there now.

That will both keep our information consistent.  And placing
the information in our own format means we are simply using
the information and not copying something.

Eric

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[yhlu]

      So everyone agree to put acpi support to LinuxBIOS?

An the way that we need to create our own acpi tables dynamically. (
in case user add pci bridge .....)

YH

On 8/4/05, Eric W. Biederman <ebiederman(a)lnxi.com> wrote:
  "Ronald G. Minnich"
<rminnich(a)lanl.gov> writes:
 
  On Sun, 31 Jul 2005, Janek Kozicki wrote:

  Facts
can't be copyrighted. But it's not easy to use that to convince
 someone to stop labeling a fact as being copyrighted.
 but current linux kernel has to decompile ACPI tables too, right? and BSD
 also?

 sure it does. Now what happens if it decompiles tables and mails them to
 world, I just don't know.
 
 I don't know where we should get the information.  But
 we should generate all of our tables from our native
 LinuxBIOS device tree.  The MP table is about half way
 there now.
 
 That will both keep our information consistent.  And placing
 the information in our own format means we are simply using
 the information and not copying something.
 
 Eric
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Ronald G Minnich]

      we all agree on it. Now we need someone with time to do it :-)

ron

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[yhlu]

      I just look at stefan's code, it looks good.
it only missed dsdt table creating...

SRAT?

YH

On 8/2/05, Ronald G Minnich <rminnich(a)lanl.gov> wrote:
  we all agree on it. Now we need someone with time to
do it :-)
 
 ron

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Stefan Reinauer]

      * yhlu <yinghailu(a)gmail.com> [050804 23:23]:
  I just look at stefan's code, it looks good.
 it only missed dsdt table creating...
 
Yepp. It does not do DSDT, since I created the APIC entries while the
system is running, by detecting the devices. The DSDT is compiled byte
code, so since we probably don't want to cope with creating it during
runtime, we will have to provide a much more complete hardware
description in Config.lb so we can create ASL source code.

And lots of things are hand crafted (Power Management tables). I bet
with a little more ACPI knowledge we can generate them from nice
looking, easily readable config files.

I'm not sure why we need IRQ overrides, it doesn't really seem to make a
difference in Linux. 

  SRAT?
SRAT is not there either.. IIRC the problem was that the LinuxBIOS table
does not hold a description of which memory belongs to which CPU, but
rather linear chunks, which was why I didn't do it.

   Stefan

[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Stefan Reinauer]

      * yhlu <yinghailu(a)gmail.com> [050804 18:28]:
  So everyone agree to put acpi support to LinuxBIOS?
It's there already ;-) 

But the question is how do we want to create the information ..

  An the way that we need to create our own acpi tables
dynamically. (
 in case user add pci bridge .....)
I'm not sure how far we get with this approach, since we'd quickly need
a DSDT for basically everything. 

Look at the island/aruma - it won't find any devices on bus!=0 unless 
the dsdt is there and it needs to be patched online with the bus numbers
(that may vary, dependent on the cards that are connected)

As soon as you start with ACPI in the Linux kernel you need to provide
a pretty complete set of it, since the ACPI code is not very modular.

And it does not interact well with the other tables. So basically, if
you have ACPI enabled, Linux will ignore the mptable and the pirq table.

This is probably due to inconsistent tables of different kinds in
awkward and ashes bios, so you can't really blame the linux code. It's
not really a clean modular parallel implementation of the standards but
an empirical answer to the real world.

To make sure we don't run into problems, LinuxBIOS should create all
tables from a single internal representation, to make sure they are
consistant. This will bloat the configs noticably so I am not sure
whether it is a good idea to head here before another set of config
mechanism changes. The next step then would be to provide all
information in the config that can not be autoprobed. ie. the board's
IRQ wiring.

Then pack all this information into the internal device representation.
Possibly in the LinuxBIOS table. 

Most ACPI tables will then be pretty easy to produce:
 * MADT  (APICs and IRQ routing, overrides, NMIs) ..
   see mainboard/island/aruma/acpi_tables.c:acpi_dump_apics()
 * HPET (timers)
 * FACS, RSDT, RSDP
 * FADT

The most nasty one is definitely the DSDT. Maybe this one can be
generated from the config.lb files. The result would have to be passed
through iasl or your favourite ASL compiler, and linked in the bios
image. 

Generating mp and pirq from the internal representation seems pretty
trivial once acpi is working, since both are a lot less complex.

   Stefan