OpenCore Development

[vit9696]

OpenCorePkg / Documentation / Configuration Template / Bugtracker

 

Discussion and installation should be done in a separate thread! This thread is for development only!

Current status as of April 2019:

• Support for UEFI and DuetPkg (legacy) booting
• APFS and HFS+ compatibility
• ACPI patcher (adding, dropping, binary patching, relocation)
• Apple-compatible bless implementation
• DeviceProperties injection
• DataHub and SMBIOS generation
• Symbolic kext and kernel patcher
• Direct kext injection/patching/blocking within prelinkedkernel
• Installation/Recovery/FileVault 2 support 
• Configuration in config.plist with open documentation
• Simple boot picker for quick launch
• Direct boot from dmg images

 

Known defects live here.

 

For those, who are not familiar with the history, OpenCore is a project initially born in HermitCrabs Lab that unfortunately almost died before its birth. This release is both a rebirth and a complete rewrite of OpenCore, which brings a number of new ideas, and tries to preserve the smart moves incorporated by iNDi and his team. Other than that, I wish to express my deepest words of gratitude to Acidanthera and WWHC members: your participation was and remains the key for project success, and you are simply the best.

Edited June 12, 2019 by vit9696

[apianti]

Hey vit, I've been looking through all you guys' stuff, there's some really smart stuff in here but also some weird things. Is there any reason why memory configuration is not fixed? I am not sure if it is available still but there was a large thread about memory at projectosx before, I rewrote chameleon's memory configuration to work better (clover's code is a disaster now though). It makes a large difference in the behavior and performance of the memory because most PC firmwares put the table in physical order, while apple places them in logical (and some don't even work at all so they much be fixed). Is there a reason that the boot strap application doesn't just boot strap itself (and uninstall when exited) if the driver is not found or can't be loaded for some reason? Also is there any reason why a static configuration structure was used? In clover this has become a huge problem, since I'm assuming you guys wanted to stay modular, why is the configuration not more flexible and available via a protocol? So that other drivers could be added to expand the capabilities?

 

EDIT: One more thing, you've listed the product license as BSD-3 and commercial use. There is no way that this can be used commercially. That would then explicitly violate international copyright of Apple's SLA to which there would not be a defense and because of the wording they can go after anyone who develops or distributes software to facilitate commercial damages/loss.

 

EDIT2: I guess actually it says that automatically for every license on github.... I'm not sure you can change it now that I have looked more.... That's quite dumb.

Edited April 27, 2019 by apianti

[vit9696]

Hi apianti,

 

Let me try to address your questions in order.

 

Quote

Is  there any reason why memory configuration is not fixed? I am not sure if it is available still but there was a large thread about memory at projectosx  before , I rewrote  chameleon's memory configuration  to work better (clover's code is a disaster now though). It makes a large difference in the behavior and performance of the memory  because  most  PC firmwares put the table in physical order , while apple  places  them in logical (and some don't even work at all so they much be fixed ).

I am not particularly sure whether this refers to memory configuration available in SMBIOS or not, as presently memory performance is not affected anyhow regardless of what is present in SMBIOS. Firmware is responsible for memory training, and thus the operating system can do almost nothing but use what is given. Neither the amount of memory slots, nor their order, not even their channels, nothing of that really affects the operating system. This is pretty much cosmetics except useable memory size. You might think differently potentially due to some legacy, yet I will need code proofs in case you think it is important.

 

Perhaps, I misunderstood you, and what you meant under memory configuration performance was rather building performance and the quality of the tables provided. This is not a big concern either, as OpenCore simply provides what is created by the firmware with little to no modifications. So far it seems to work most reliably on all modern computers (2008 or so) and virtual machines. Additionally it provides good results in "About my Mac".

 

The only "real" issue, that we are aware of, are very rare motherboards, which contain incorrect information in their SMBIOS tables. We do not have such boards, but believe this may be addressed with a dedicated MemorySMBIOS section in PlatformInfo, where one could describe his memory (as I mentioned on applelife), yet the issue has low priority, and we do not have plans to work on it in the considerable future. If this worries you, you can try to write a design document and create an issue in the bugtracker. After we come to some consensus, I suppose you could contribute a useful feature to OC.

 

Quote

Is there a reason that the boot strap application doesn't just boot strap itself (and uninstall when exited) if the driver is not found or can't be loaded for some reason?

There is, as boot strap application is not meant to be the only way to start OpenCore. OpenCore should generally be bootable from Drivers#### NVRAM variables (currently not fully implemented), from shell, or from firmware. Bootstrap is a way to ensure that target firmware definitely does see the image as defined by UEFI spec, it may be removed if otherwise not required.

 

Quote

Also is there any reason why a static configuration structure was used? In clover this has become a huge problem, since I'm assuming you guys wanted to stay modular, why is the configuration not more flexible and available via a protocol? So that other drivers could be added to expand the capabilities?

The modular approach behind OC is primarily that OcSupportPkg libraries can be used to build whatever necessary in whatever configuration, not particularly for building a bootloader, but implementing other entirely unrelated projects. On the contrary, the front end is defined by the spec (named instruction manual), and while it is extensible, a spec change is needed to bring any new functionality. For this reason the written spec in human language translates 1:1 into config.plist, which then transparently translates 1:1 into OcConfigurationLib. We believe that conformance and unification are necessary here to actually ensure predictability and reliability for the end user, who always knows how the target system behaves, and what is actually happening. Indeed, this made configuration monolithic, but we consider it a benefit not a downside. We have some internal plans to expose the configuration for read and potentially modification for drivers (like UI or external providers) as a part of some protocol, but we do not have plans to let drivers add anything bypassing the spec.

 

Quote

EDIT: One more thing, you've listed the product license as BSD-3 and commercial use. There is no way that this can be used commercially. That would then explicitly violate international copyright of Apple's SLA to which there would not be a defense and because of the wording they can go after anyone who develops or distributes software to facilitate commercial damages/loss.

 

EDIT2: I guess actually it says that automatically for every license on github.... I'm not sure you can change it now that I have looked more.... That's quite dumb.

OpenCore is and will remain an open source project. There are quite a number of opensources licenses (see this page), and BSD 3-clause license is one of them. I think you might confuse GPL or something alike with an open source license. One of the key benefits of BSD 3 clause license contrary to GPL (and several others) is to ensure that the code does not "disown" your patents and does not prohibit code usage in closed source projects. This is very important, as you probably noticed, that OpenCore has a lot of code that has nothing to do to macOS or bootloaders in general, it is just generic UEFI code we wrote. For these very reasons, primarily to be able to contribute our code in similar or reworked form to upstream, such as TianoCore EDK II, we do not use licenses prohibiting commercial use. This is the same with all projects hosted at Acidanthera unless specified otherwise.

 

Cheers,

Vit

[apianti]

Thanks for the explanations, still a few questions/clarifications

 

2 hours ago, vit9696 said:

I am not particularly sure whether this refers to memory configuration available in SMBIOS or not, as presently memory performance is not affected anyhow regardless of what is present in SMBIOS. Firmware is responsible for memory training, and thus the operating system can do almost nothing but use what is given. Neither the amount of memory slots, nor their order, not even their channels, nothing of that really affects the operating system. This is pretty much cosmetics except useable memory size. You might think differently potentially due to some legacy, yet I will need code proofs in case you think it is important.

 

Perhaps, I misunderstood you, and what you meant under memory configuration performance was rather building performance and the quality of the tables provided. This is not a big concern either, as OpenCore simply provides what is created by the firmware with little to no modifications. So far it seems to work most reliably on all modern computers (2008 or so) and virtual machines. Additionally it provides good results in "About my Mac".

 

The only "real" issue, that we are aware of, are very rare motherboards, which contain incorrect information in their SMBIOS tables. We do not have such boards, but believe this may be addressed with a dedicated MemorySMBIOS section in PlatformInfo, where one could describe his memory (as I mentioned on applelife), yet the issue has low priority, and we do not have plans to work on it in the considerable future. If this worries you, you can try to write a design document and create an issue in the bugtracker. After we come to some consensus, I suppose you could contribute a useful feature to OC.

 

I am referring to the SMBIOS tables, and know 100% for a fact it indeed does affect memory, because without the correct tables geek bench scores are lower than with them. I showed this like six or seven years ago on projectosx, which is why I referred to that but I don't know how much of that actually survived. Although you are correct that the memory is setup by firmware, it does not always setup those tables correctly, and those tables contain memory ranges with which the DIMMs are associated. Also, some firmwares erroneously set the error field when the memory is fine, as I recall this causes either a panic or a dead hang, although that may have changed.

 

2 hours ago, vit9696 said:

There is, as boot strap application is not meant to be the only way to start OpenCore. OpenCore should generally be bootable from Drivers#### NVRAM variables (currently not fully implemented), from shell, or from firmware. Bootstrap is a way to ensure that target firmware definitely does see the image as defined by UEFI spec, it may be removed if otherwise not required.

 

I get what a boot strap application does, and as you point out it literally does the exact same thing but in the case of booting from an unknown device, I don't see why you would spend the time to boot strap the driver when you could just already do it in the application. Nowhere in the spec does it specify design of any component beyond it's basic structure needed for initialization/usage because that would be ludicrous, you can write it anyway you want, look at how windows boot manager or boot.efi behave, lol. I was just wondering what the point of loading an entirely different file was if you knew that you were booting already from that application? Also, what happens if you already have a ESP with the driver loaded with Driver#### and you want to boot from a USB with newer OC installed? It appears as though the older driver will make the newer one unbootable without removing the Driver#### or the driver itself. So testing is more difficult as you may not get working system after on newer and may have no way to put the removed thing back. So I guess maybe the driver needs to check that it is newer than the current one if already installed? Then uninstall and unload the previous, and install itself? Otherwise, how can you possibly test? Constantly replace drivers back and forth?

 

2 hours ago, vit9696 said:

The modular approach behind OC is primarily that OcSupportPkg libraries can be used to build whatever necessary in whatever configuration, not particularly for building a bootloader, but implementing other entirely unrelated projects. On the contrary, the front end is defined by the spec (named instruction manual), and while it is extensible, a spec change is needed to bring any new functionality. For this reason the written spec in human language translates 1:1 into config.plist, which then transparently translates 1:1 into OcConfigurationLib. We believe that conformance and unification are necessary here to actually ensure predictability and reliability for the end user, who always knows how the target system behaves, and what is actually happening. Indeed, this made configuration monolithic, but we consider it a benefit not a downside. We have some internal plans to expose the configuration for read and potentially modification for drivers (like UI or external providers) as a part of some protocol, but we do not have plans to let drivers add anything bypassing the spec.

 

I agree with the modular approach. I don't get the static 1:1, you can easily do that with a dynamic structure in pretty much the way you did it by ensuring certain values are always present through a schema. I was only suggesting the last part there, but I don't know what bypassing the spec means. I just meant so other drivers can read the configuration so that you don't have to write a configuration file for every driver that might need configuring since it is intended to be modular (and you may choose whether or not to have something, no need to configure it if it's not there). This can be pretty easily achieved through your configuration library's initialization.

 

2 hours ago, vit9696 said:

OpenCore is and will remain an open source project. There are quite a number of opensources licenses (see this page), and BSD 3-clause license is one of them. I think you might confuse GPL or something alike with an open source license. One of the key benefits of BSD 3 clause license contrary to GPL (and several others) is to ensure that the code does not "disown" your patents and does not prohibit code usage in closed source projects. This is very important, as you probably noticed, that OpenCore has a lot of code that has nothing to do to macOS or bootloaders in general, it is just generic UEFI code we wrote. For these very reasons, primarily to be able to contribute our code in similar or reworked form to upstream, such as TianoCore EDK II, we do not use licenses prohibiting commercial use. This is the same with all projects hosted at Acidanthera unless specified otherwise.

 

I'm sorry, the BSD-3 really had nothing to do with it, I just said that because I was looking at it. I guess that it wasn't you that set it to say commercially usable but all licenses on github, the only way to say it's not commercially usable is to provide no license and retain all rights, instead of reserving them. That is very bad for a team project though. When you provide a license you are actually giving up rights, that is what the all rights reserved clause is for, however that clause has never been used in court and I don't think it would stand up as you willingly gave those rights to users. This is important because software can only be copyrighted, not patented, which does allow for this explicit protection. I was more pointing out that you should not allow anything that allows macOS to be run on non-apple hardware to be used in commercial products. This is very thoroughly covered in apple's SLA and you can be brought into a copyright infringement based on developing or distributing software that allows you to run macOS on non-apple hardware. There is no protection for a commercial product in this sense, as they could easily prove that the commercial product has become a direct competitor using their own software. This is commercial damage either through monetary loss or brand harm, I only know of one instance where the copyright holder did not win, it was microsoft, and they then won on appeal....

 

As always, thanks for the great response.

 

EDIT: Should clarify, if apple products are sold in a country then it is protected by international copyright law because they only sell in countries that are in agreements. This is like 177 countries out of 195.

Edited April 27, 2019 by apianti

[vit9696]

Quote

I am referring to the SMBIOS tables, and know 100% for a fact it indeed does affect memory, because without the correct tables geek bench scores are lower than with them. I showed this like six or seven years ago on projectosx, which is why I referred to that but I don't know how much of that actually survived. Although you are correct that the memory is setup by firmware, it does not always setup those tables correctly, and those tables contain memory ranges with which the DIMMs are associated. Also, some firmwares erroneously set the error field when the memory is fine, as I recall this causes either a panic or a dead hang, although that may have changed.

We are aware of the error field issue, and do disable it actually. As for correct table setup, we believe ours is done properly, except for the case I mentioned, where I believe manual memory configuration is the only reliable solution. Geekbench results are basicslly equivalent to throwing dice, which means I consider the problem to be reraised only when actual problematic hardware appears and an incorrect behaviour is confirmed in the code, not in some magic numbers.

 

In any case I will keep your worries in mind, and will once again suggest you to create a design document & a pull request afterwards that can be used to manually specify memory configuration in config.plist. This should beneficial for all kinds of debugging, and make a good step forward, in case the issue concerns you.

 

Quote

I get what a boot strap application does, and as you point out it literally does the exact same thing but in the case of booting from an unknown device, I don't see why you would spend the time to boot strap the driver when you could just already do it in the application. Nowhere in the spec does it specify design of any component beyond it's basic structure needed for initialization/usage because that would be ludicrous, you can write it anyway you want, look at how windows boot manager or boot.efi behave, lol. I was just wondering what the point of loading an entirely different file was if you knew that you were booting already from that application? Also, what happens if you already have a ESP with the driver loaded with Driver#### and you want to boot from a USB with newer OC installed? It appears as though the older driver will make the newer one unbootable without removing the Driver#### or the driver itself. So testing is more difficult as you may not get working system after on newer and may have no way to put the removed thing back. So I guess maybe the driver needs to check that it is newer than the current one if already installed? Then uninstall and unload the previous, and install itself? Otherwise, how can you possibly test? Constantly replace drivers back and forth?

Driver#### boot is currently not supported, though is in plans as I mentioned. I will not go into details how exactly it should be implemented right now, since all the peculiarities are yet to be taken into account. I will keep in mind the reinstall suggestion, as it does make some sense under certain conditions.

 

As for separating BOOTx64.efi and OpenCore.efi, one of the key reasons is to ensure that there is only one bootloader, not two, like with Clover, which caused numerous confusing situations, where the wrong code was used to boot. I will repeat that BOOTx64.efi is best viewed as an optional hack necessary to make firmwares happily load OpenCore automatically.

 

Quote

I agree with the modular approach. I don't get the static 1:1, you can easily do that with a dynamic structure in pretty much the way you did it by ensuring certain values are always present through a schema. I was only suggesting the last part there, but I don't know what bypassing the spec means. I just meant so other drivers can read the configuration so that you don't have to write a configuration file for every driver that might need configuring since it is intended to be modular (and you may choose whether or not to have something, no need to configure it if it's not there). This can be pretty easily achieved through your configuration library's initialization.

Now I see the understanding issue here. The point of "bypassing the spec" is to let no other drivers *create* entirely new options in the configuration, as if it was a generic map-like (key-value based) structure.

 

As for the rest you are right that other drivers should be able to read and potentially modify the configuration, and like I said exposing it is in the works. As currently drivers do not eagerly need this and configuration is not fully standardised, the feature has low priority.

Quote

I'm sorry, the BSD-3 really had nothing to do with it, I just said that because I was looking at it. I guess that it wasn't you that set it to say commercially usable but all licenses on github, the only way to say it's not commercially usable is to provide no license and retain all rights, instead of reserving them. That is very bad for a team project though. When you provide a license you are actually giving up rights, that is what the all rights reserved clause is for, however that clause has never been used in court and I don't think it would stand up as you willingly gave those rights to users. This is important because software can only be copyrighted, not patented, which does allow for this explicit protection. I was more pointing out that you should not allow anything that allows macOS to be run on non-apple hardware to be used in commercial products. This is very thoroughly covered in apple's SLA and you can be brought into a copyright infringement based on developing or distributing software that allows you to run macOS on non-apple hardware. There is no protection for a commercial product in this sense, as they could easily prove that the commercial product has become a direct competitor using their own software. This is commercial damage either through monetary loss or brand harm, I only know of one instance where the copyright holder did not win, it was microsoft, and they then won on appeal....

 

As always, thanks for the great response.

 

EDIT: Should clarify, if apple products are sold in a country then it is protected by international copyright law because they only sell in countries that are in agreements. This is like 177 countries out of 195.

I am afraid we have different understanding of how the copyright law works, and I have no plans to discuss it. In short, it will be easiest for you to simply forget about it, as it does not affect you directly, and it is out of the scope of OC development. If you still want to help, you can consult with a lawyer with a reliable background in international copyright law in IT, and provide us with the relevant papers. All other options are pretty much pointless, as I believe my understanding of the matter is good enough for this case.

 

For informational purposes I can tell you the following:

— The stuff you mentioned only applies to a person that has a commercial product, the right to sell it (e.g. by being a company), a commercial offer or some other means of commercial action… etc.

— Anybody who includes OpenCore in commercial products may be sued if he violates any copyright. Since we do not have commercial products, the issue does not apply to us.

— For the good, BSD, unlike GPL, does not grant any patent or trademark rights, so while we let any commercial company use our code, and this intended, we do not give away the rights to use any patented or trademarked technology we potentially wrote or used.

— The last paragraph of the license, containing the disclaimer provides an answer that most likely concerns you most. OpenCore team is not anyhow responsible for inadequate third-party actions. To give you a simple analogy: the authors of libressl are not anyhow responsible for the use of their library in computer virus X.

 

Hope all that helps, and does not raise more questions  I know that we should be more open about the plans and continue to use our public bugtracker, but presently it is how it is. Mainly due to the amount of contributors in charge and our free time limitations.

[apianti]

2 hours ago, vit9696 said:

We are aware of the error field issue, and do disable it actually. As for correct table setup, we believe ours is done properly, except for the case I mentioned, where I believe manual memory configuration is the only reliable solution. Geekbench results are basicslly equivalent to throwing dice, which means I consider the problem to be reraised only when actual problematic hardware appears and an incorrect behaviour is confirmed in the code, not in some magic numbers.

 

In any case I will keep your worries in mind, and will once again suggest you to create a design document & a pull request afterwards that can be used to manually specify memory configuration in config.plist. This should beneficial for all kinds of debugging, and make a good step forward, in case the issue concerns you.

 

I'm just asking general questions, whats and whys. Not really concerned just wondering.

 

EDIT: I forgot to say, why do you think I'm saying something about the memory, I already know this problem exists. And while geekbench scores vary, they stay within a reasonable range so a vast change that then doesn't return is clear indication of better performance. I'm not sure why you would think benchmarks are like throwing dice, that really defeats the entire purpose of a benchmark.

 

2 hours ago, vit9696 said:

Driver#### boot is currently not supported, though is in plans as I mentioned. I will not go into details how exactly it should be implemented right now, since all the peculiarities are yet to be taken into account. I will keep in mind the reinstall suggestion, as it does make some sense under certain conditions.

 

As for separating BOOTx64.efi and OpenCore.efi, one of the key reasons is to ensure that there is only one bootloader, not two, like with Clover, which caused numerous confusing situations, where the wrong code was used to boot. I will repeat that BOOTx64.efi is best viewed as an optional hack necessary to make firmwares happily load OpenCore automatically.

 

Nah, I just wanted to know why. Also, because I saw the issue of booting and was wondering about that.

 

2 hours ago, vit9696 said:

Now I see the understanding issue here. The point of "bypassing the spec" is to let no other drivers *create* entirely new options in the configuration, as if it was a generic map-like (key-value based) structure.

 

As for the rest you are right that other drivers should be able to read and potentially modify the configuration, and like I said exposing it is in the works. As currently drivers do not eagerly need this and configuration is not fully standardised, the feature has low priority.

 

I don't see how that bypasses the spec at all to have dynamic configurations, there is nothing in the spec that says you can't have a configuration registry and this is how windows boot manager works: 

https://en.wikipedia.org/wiki/Windows_NT_6_startup_process#Boot_Configuration_Data

 

2 hours ago, vit9696 said:

I am afraid we have different understanding of how the copyright law works, and I have no plans to discuss it. In short, it will be easiest for you to simply forget about it, as it does not affect you directly, and it is out of the scope of OC development. If you still want to help, you can consult with a lawyer with a reliable background in international copyright law in IT, and provide us with the relevant papers. All other options are pretty much pointless, as I believe my understanding of the matter is good enough for this case.

 

For informational purposes I can tell you the following:

— The stuff you mentioned only applies to a person that has a commercial product, the right to sell it (e.g. by being a company), a commercial offer or some other means of commercial action… etc.

— Anybody who includes OpenCore in commercial products may be sued if he violates any copyright. Since we do not have commercial products, the issue does not apply to us.

— For the good, BSD, unlike GPL, does not grant any patent or trademark rights, so while we let any commercial company use our code, and this intended, we do not give away the rights to use any patented or trademarked technology we potentially wrote or used.

— The last paragraph of the license, containing the disclaimer provides an answer that most likely concerns you most. OpenCore team is not anyhow responsible for inadequate third-party actions. To give you a simple analogy: the authors of libressl are not anyhow responsible for the use of their library in computer virus X.

 

I'm afraid we do and you are incorrect. My brother is a lawyer and I have discussed this with him many, many times. You can absolutely be held accountable for writing code that is used for its intended purpose, what you suggest about libressl is not the same as there is no intended use that is going to be misused, instead there is misintent, using the library as it was not intended, i.e. cracking some key through brute force. Now say if I write a piece of malicious software, intending it to do such a function and distribute it to someone who commits a crime with it, I have then committed a crime. You can only trademark a name, and only if you explicitly apply and are granted the trademark. You cannot patent software but non-obvious algorithmic processes can be patented. This is extremely rare. You can look here:

https://en.wikipedia.org/wiki/Software_patent

https://en.wikipedia.org/wiki/Software_copyright

Specifically, these will be of interest:

https://en.wikipedia.org/wiki/Software_patent#Russian_Federation

https://en.wikipedia.org/wiki/Software_patents_under_United_States_patent_law

 

As for the responsibility, please refer to this section of the apple SLA for macOS which has jurisdiction under US copyright law, and that jurisdiction is backed by international copyright agreements (emphasis mine):

 

Quote

J. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so. Except as otherwise permitted by the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at a time, and (ii) you may not make the Apple Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Apple Software.

 

If a commercial product is created using your software then you can be held liable for this along with the initial offender. You are able to use this for personal use because of the fair use exception:

https://www.copyright.gov/fair-use/more-info.html

 

2 hours ago, vit9696 said:

Hope all that helps, and does not raise more questions  I know that we should be more open about the plans and continue to use our public bugtracker, but presently it is how it is. Mainly due to the amount of contributors in charge and our free time limitations.

 

Just wondering what you guys were thinking and everything. I'd like to know there is still going to be forward progress.... I've been thinking lately that I just don't have enough time for coding this stuff anymore......

Edited April 28, 2019 by apianti

[vit9696]

Quote

I don't see how that bypasses the spec at all to have dynamic configurations, there is nothing in the spec that says you can't have a configuration registry and this is how windows boot manager works: 

https://en.wikipedia.org/wiki/Windows_NT_6_startup_process#Boot_Configuration_Data

I meant our spec, the one we created for OpenCore, and put into docs section.

 

apianti, as for the for the law question, I can repeat that it does not work this way.

 

1. I have a Mac, and I can run OpenCore on my Mac in VMware as permitted by Apple SLA. I also have another computer, and the ownership of Mac gives me the right to use any Mac software, including macOS and OpenCore, on any computer by Russian law (similar laws exist in e.g. Germany, but maybe not in US). There exist precedents of court attempts regarding the matter, and Apple SLA was null and void by the law, and that is why hackintosh is sold in Russia.

— Therefore I have the right to use OpenCore, and so do many others. For those who do not have law protection, like in Russia, you can still use OpenCore on your Mac to power virtual machines or on your legacy Mac to support new operating systems.

2. Creating a commercial product based on OpenCore and using it for whatever matter clearly is a misuse, so even if we read the law your way (although I believe we should not, but I do that to help us resolve the question quickly), the authors cannot be considered liable for any such misuse, as the software is clearly and obviously written with different purpose. And even if it was not clear, the license explicitly states the disclaimer.

— If anybody managed to violate Apple SLA and got legally accused, it is entirely his matter, no ours.

[apianti]

5 hours ago, vit9696 said:

I meant our spec, the one we created for OpenCore, and put into docs section.

 

Yes, I was also referring to that spec as well, I read it, no where does it limit the scope of implementation, only the physical limitations such as size, node count, and depth. If you intended to limit such a thing, it is not specified, or clear that's what you meant. I also don't know why you would...? What benefit would this provide? What is a driver going to do? Make a bunch of configuration options? Even if it acts badly, the user would just remove it as it would cause issues. So I am unsure why?

 

EDIT: Also you would be able to identify the misbehaving driver easily by including ways to either limit a driver's ability to do that, or to track configuration operations. I however think basically saying your configuration overflowed, it may be one of these drivers and print out every driver that initialized using the configuration protocol, i.e. registering for it (which also gives you the ability to have change callbacks) would probably be enough to change drivers to see what's causing issues. Also permissions... So I expect that you are just trying to limit to the simplest solution? That doesn't make it the best solution or even easiest, just the simplest. But really, I just don't see how this will be an issue in anyway, who is going to write a driver that just fills up your configuration for no reason? That's pointless.

 

5 hours ago, vit9696 said:

apianti, as for the for the law question, I can repeat that it does not work this way.

 

1. I have a Mac, and I can run OpenCore on my Mac in VMware as permitted by Apple SLA. I also have another computer, and the ownership of Mac gives me the right to use any Mac software, including macOS and OpenCore, on any computer by Russian law (similar laws exist in e.g. Germany, but maybe not in US). There exist precedents of court attempts regarding the matter, and Apple SLA was null and void by the law, and that is why hackintosh is sold in Russia.

— Therefore I have the right to use OpenCore, and so do many others. For those who do not have law protection, like in Russia, you can still use OpenCore on your Mac to power virtual machines or on your legacy Mac to support new operating systems.

2. Creating a commercial product based on OpenCore and using it for whatever matter clearly is a misuse, so even if we read the law your way (although I believe we should not, but I do that to help us resolve the question quickly), the authors cannot be considered liable for any such misuse, as the software is clearly and obviously written with different purpose. And even if it was not clear, the license explicitly states the disclaimer.

— If anybody managed to violate Apple SLA and got legally accused, it is entirely his matter, no ours.

 

The law applies in the US because that is the jurisdiction of the copyright, so the laws of other countries are irrelevant except for the fact that there is an agreement between 177 countries (Russia and all the EU are included in this) that copyright enforcement is the jurisdiction of the copyright, in this case the US. Which is how Apple has already sued companies outside of the US in the US (and in the EU) and those cases were resolved in Apple's favor. Can you point me to one instance of a commercial product not being destroyed by apple? I can find many instances where companies tried to do this but did not succeed, even in Russia. Also there is no way that the Apple SLA was invalidated, that would allow you to straight up sell macOS as your own OS. Also there's agreement which directly disproves you:

 

Quote

The Berne Convention for the Protection of Literary and Artistic Works is the most important international treaty that addresses international protection for copyright. The United States acceded to that treaty in 1989. With the accession of China in 1992 and the Russian Federation in 1995, almost all of the world’s most important countries now belong to the Berne Union. ... The central feature of the Berne Convention is that it prohibits member countries from imposing “formalities” on copyright protection, in the sense that the enjoyment and exercise of copyright cannot be subject to any formality except in the country of origin.

 

You are also incorrect on the second point, it is the exact intended use of OpenCore to boot macOS, just like it is for clover. I'm not saying this because I'm full of it, I'm saying it because I have already wanted to know what my liability is. I want you to realize your liability too. I want to make sure that you know you cannot allow anyone to commercially use this, if you find someone does, you should immediately issue a DMCA take down against them. It would be the first step in protecting yourself. I just showed you where the SLA puts liability on you as well so how do you think that you are not violating it currently? We all are. We are only able to because of the fair use exception which I mentioned earlier, this exception is not applicable to commercial uses. In fact, after reading some sections my brother pointed me to and it is included in the link below, fair use exception may only apply to US residents... In fact, this agreement is pretty brutal to non-copyright holders. You can read more about the Berne Convention if you do not think I'm correct:

https://en.wikipedia.org/wiki/Berne_Convention

 

I don't understand why you would ask me to give you the jurisprudence of international copyright from a lawyer who has done this, then when I do, just repeat the same thing. I may be an a s s h o l e but I always have the same intention, and it's certainly not malicious in anyway.

Edited April 28, 2019 by apianti

[vit9696]

Quote

Yes, I was also referring to that spec as well, I read it, no where does it limit the scope of implementation, only the physical limitations such as size, node count, and depth. If you intended to limit such a thing, it is not specified, or clear that's what you meant. I also don't know why you would...? What benefit would this provide? What is a driver going to do? Make a bunch of configuration options? Even if it acts badly, the user would just remove it as it would cause issues. So I am unsure why 

invalid value — valid  plist object of  OC config described in this document that is of other  plist type,
does not conform to additional requirements found in specific  plist object description (e.g. value range), or
missing from the corresponding collection.  Invalid value is read with or without an error message as any
possible value of this  plist object in an undetermined manner (i.e. the values may not be same across the
reboots). Whilst reading an  invalid value is equivalent to reading certain defined  valid value, applying
incompatible value to the host system may yield to  undefined behaviour.

 

Quote

I don't understand why you would ask me to give you the jurisprudence of international copyright from a lawyer who has done this, then when I do, just repeat the same thing. I may be an a s s h o l e but I always have the same intention, and it's certainly not malicious in anyway.

 

The legal talk with you will take a lot of my time with little to no benefit, and while I feel personally sorry for doing this, I will simply pass explaining the details or continue this kind of discussion in any format. Thank you very much for your concern, perhaps it even helped us to better understand some nuances. The project will only change its license if we internally have the reasons to do it, and we will also ensure that we use DMCA or any other instrument as we consider fit.

[apianti]

2 minutes ago, vit9696 said:

invalid value — valid  plist object of  OC config described in this document that is of other  plist type,
does not conform to additional requirements found in specific  plist object description (e.g. value range), or
missing from the corresponding collection.  Invalid value is read with or without an error message as any
possible value of this  plist object in an undetermined manner (i.e. the values may not be same across the
reboots). Whilst reading an  invalid value is equivalent to reading certain defined  valid value, applying
incompatible value to the host system may yield to  undefined behaviour.

 

 

Ok, I guess but I do not think that is narrowly defined enough for what you mean. To me, that just means that you expect a well formed plist, so I guess the intention behind it is unclear. I don't see how that limits the addition of objects, especially since the last two sentences basically say there is no consequence except that there is then a wrong value. If I write extra stuff into the configuration, does it fail or is it parsed and discarded? Because I don't understand otherwise, it seems that you allow any objects but the implementation limits to a schema. This is basically root only permission.

 

5 minutes ago, vit9696 said:

The legal talk with you will take a lot of my time with little to no benefit, and while I feel personally sorry for doing this, I will simply pass explaining the details or continue this kind of discussion in any format. Thank you very much for your concern, perhaps it even helped us to better understand some nuances. The project will only change its license if we internally have the reasons to do it, and we will also ensure that we use DMCA or any other instrument as we consider fit.

 

There is no need for a license change, and you cannot limit commercial use through any available public license, so you would have to create a private license which is much harder. You just need to be vigilant, especially that you do not explicitly give consent to someone to use commercially.

[vit9696]

apianti, I suspect that very careful reading of the pdf is needed to understand what it means. In short, the addition of any property that is not described in the configuration as well as the removal of any property that is not explicitly marked as optional yields undefined behaviour. I.e. OpenCore is permitted to induce permanent damage to your hardware as an example (even though we will never do it intentionally).

[apianti]

11 minutes ago, vit9696 said:

apianti, I suspect that very careful reading of the pdf is needed to understand what it means. In short, the addition of any property that is not described in the configuration as well as the removal of any property that is not explicitly marked as optional yields undefined behaviour. I.e. OpenCore is permitted to induce permanent damage to your hardware as an example (even though we will never do it intentionally).

 

I just read it for the third time, lol. I'm asking because I don't understand the intent. I'm aware of the damage that may be caused by doing this stuff, I've done it to myself before, haha. All of these objects are still parsed though right? So I guess my confusion is why can you not allow the registration of unknown values if they don't affect the operation of the core components, especially when incorrect values appear to not be enforced, so I'm not sure what that clause exactly achieves. It appears to be contradictory to itself, the first part saying that something is expected and the second saying that it doesn't really matter because it won't fail even if it's not but the result may not be what is intended. So why can a driver not register it's own schema to enforce? I just don't see where the preclusion of extra objects occurs.

[vit9696]

The main reason is enforcement of our policy as well as transparency and simplicity for the end user. This is the decision we made, and for now we want to keep it. Thanks for the suggestion though.

[apianti]

I feel like I'm talking to a wall sometimes guys. I never get answers to questions I ask and I am ignored when I point out when there are issues. It took me literally taunting DF for him to get something I was talking about for like five years, and no one would discuss with me, which was protecting all runtime and reserved regions (and actually the latter still does not happen so firmwares that use reserved regions for integrated graphics like mine cannot use integrated graphics without weird side effects, random artifacts, and crashes). Then you said that aptiofix was stagnating because it was inside clover and no one could contribute. Like seriously? I asked people all the time to discuss stuff and openly invite people to contribute all the time. I feel like because I am brash, you think I'm trying to insult you. I am not, I just want the knowledge and the best possible solutions.

[apianti]

I forgot about this for a minute but I wanted to talk about something I said in the AptioFix topic a while back about only moving some of the regions so that there would be two copies, one that was in the kernel and one that wasn't. I mean sets of regions here btw, probably unclear.... I think currently there is now a way of doing this manually, right? I was trying to do it automatically by finding any memory access in a runtime region that wasn't a call and then marking that as a 'do not move' region. I just wanted to say something about that if you guys might be interested in seeing if that is viable.