[LinuxBIOS] Potential copyright issues with decompiling ACPI tables?
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@winternet.com>
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
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@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
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
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
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
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
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 |
* Janek Kozicki <janek_listy@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
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
"Ronald G. Minnich" <rminnich@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
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@lnxi.com> wrote:
"Ronald G. Minnich" <rminnich@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@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
we all agree on it. Now we need someone with time to do it :-) ron
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@lanl.gov> wrote:
we all agree on it. Now we need someone with time to do it :-)
ron
* yhlu <yinghailu@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
* yhlu <yinghailu@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
participants (10)
-
ebiederman＠lnxi.com -
Greg Lindahl -
Janek Kozicki -
Josiah England -
Ken Fuchs -
Ronald G Minnich -
Ronald G. Minnich
-
Russell Whitaker -
Stefan Reinauer -
yhlu