They did not copy any of Sun's code. They started off with the Harmony version of the Java API, and followed the terms of the Apache license it was released under.
At the time they started, the Sun source code was not under the GPL. Sun wanted them to use Java ME, and wouldn't agree to let them use Java SE.
The license that Harmony was developed under allowed for development of an independent version of the Java API, under whatever license they wanted to release it as. The sticking point for the Apache Foundation was that the TCK, used to validate an implementation as conforming to the interface specification, couldn't be released as open source. Without that, you can't use the Java trademark on your product.
So Apache decided to just not get it certified as conforming.
Google never used the Java trademark. Their implementation of individual methods, and the documentation (as javadoc comments) was also found to be non-infringing.
What the CAFC found to be protected, that Google had copied, was the interface itself, the hierarchy of names and the structure of the relationships (e.g. class and interface inheritance). They also found that Google had infringed on the declarations from the Java API source code (which can only be written one way in Java if you want to describe the same API).
Why would you think that in a full implementation, taxes would stay the same? Add a flat tax income tax of 8.4% (not including the UBI itself, of course), and the $700/month would effectively be decreased to zero by the time you got to $100,000 annual income. You can adjust the UBI and rate to set the point where you want it to be neutral to an individual's tax rate.
With total individual income, you can also figure out where to set those values to make it revenue neutral (after taking into account the savings from replacing some of the safety net programs and, hopefully, reducing administrative overhead). You can also reduce the current tax rate by a fixed percentage while adding on a larger flat tax. That's also a way to phase in a UBI, e.g. set a target UBI and flat tax rate, then start off with 10% of each, increasing by 10% every year, for example.
So, first year with a $1000 UBI with 10% flat tax, you'd receive $100/month and a flat tax of 1% on all other income.
You could also go much bigger, $2000/month, flat tax of 50% (break-even point at $48000), but phase it in while phasing out the current tax. Fully phased in, you'd effectively pay no taxes with $48000 income, effective rate at $75000 would be 18%, and 40% at $250000.
Why on earth do you think the supreme court will decide to grant the request this time?
a) the question is much better; b) the case has ripened considerably; c) the CAFC didn't fix their mistakes.
So this:
"public final class String extends Object implements Serializable, Comparable, CharSequence {"
Is not code?
Sure, that's code. It describes a portion of an API, a class definition.
While the code can be copyrighted, Google's question asks if the API itself is copyrighted, or is it a functional "system or method of operation" and excluded from copyright protection by 102(b) (including the names).
If it is excluded by 102(b), then the code you wrote would also not be protected, because of merger (the 97% of the code that isn't declarations would still be protected).
It's not that "declarations" have some special powers, but that declarations in Java are, by design, required to be almost identical when describing the same API.
Google was a bit sloppy, Harmony less so. Ultimately, it didn't matter, the one method that was inadvertently copied (rangeChevk) was the ONLY code that was found to infringe, other than the declarations, and the damages were found to be $0.
Properly done, AFC would filter out the declarations from consideration, assuming Google is correct and the (abstract) Java API is not protected by copyright.
The fair use defense is for doing reverse engineering (which involves copying protected expression) for the purpose of discovering the "functional requirements for compatibility", which are not protected by copyright. 102(b), Sega
If you can find out the information another way, such as if the specifications are published and freely available, there's no need to do reverse engineering, and any copying of protected expression for reverse engineering purposes would not be fair use any longer.
What you do with that information is not restricted to creating compatible software, nor is it even about fair use at that point. That information is simply not protected by copyright.
If the Java API is a "system or method of operation", and is excluded from copyright protection by 102(b), why wouldn't I be allowed to re-implement the Java API if I want to?
If I rewrite Linux from scratch, without copying any source code, copying only the functional requirements, I won't be infringing even if I ignore the GPL.
If you make a movie with the characters Han Solo and Yoda from Star Wars, you'd be infringing on the copyrights on those two characters. They are not excluded from copyright protection by 102(b). It wouldn't matter if you used real actors or virtual actors.
No, you're describing scenes a faire, which is related but different.
Oracle agreed in court that Google can freely use the Java language. That was not part of this case. Google's bytecode interpreter was not accused off copyright infringement. There were some patent issues, but those were resolved in Google'a favor.
The only other issue was the Java API, and in particular, the names. Are the names part if the unprotected functionality in the Java API?
"Authorship", which is what you can copyright, is predicated on choice. Choosing to write a program in Java is not a copyrightable choice Having made that one choice, the declarations for the Java API now can only be written one way.
102(b) excludes "systems" and "methods of operation" from copyright protection. If the Java API itself (the abstraction, apart from any specific description) is a "system or method of operation", then the declarations merge with that and are themselves excluded from copyright protection.
The lawsuit with Microsoft was about trademark and breach of contract. Sun failed in a copyright action against MS.
The case against Google is copyright, not trademark. Google never claimed that their platform was Java, as in the Java Platform, using the Java trademarks.
The linked page says Google uses the Java programming language (which they do) and implements parts of the Java API (which they do). None of that is claiming to be Java, nor do they use any Java trademarks.
No, they only provided a portion of the Java API, then added much more of their own (and created independently the other 97% of the source code of the portions of the API they did copy, the actual implementation).
The claim is that the API as a whole is a "system or method of operation", so those parts necessary to describe that API (the declarations) are not protected (because 102(b) says that "systems" and "methods of operation" are excluded from protection).
Thousands of names are not needed to make something copyrightable. The threshold is quite low. The one part of the Java API source code that Google actually (unintentionally) copied was only nine almost trivial lines, yet that was long enough to be found infringing. The difference was that those weren't declarations, they were the body of a method (a "function" or "procedure" or "subroutine" in other languages), so there were many ways it could have been written and have the exact same function, so the description of the function is copyrightable, even though the function itself isn't.
There are several aspects to this. What you seem to be talking about is "substantial similarity", to show that copying occurred, because it's unlikely that it would happen just by chance.
To be infringing, there must be copying, since independent creation is allowed. However, some aspects of a copyrighted work are not protected by copyright, and even if you do copy those parts, there is no infringement.
102(b), that Google references, says that various specific abstractions can't be copyrighted (as opposed to something like a plot or a story). If an "idea" is too abstract, it can't be owned. Processes and procedures, concepts, discoveries, systems , and methods of operation are also excluded from protection.
If you copy a story, even if you use completely different words, even if you tell it in a different style, you can still be infringing on the story (if the story was original AND you copied it rather than come up with it independently). That's because "story" isn't excluded by 102(b). In particular, it isn't so abstract("idea") that it is no longer "expression" (and maybe has become "concept").
An algorithm is excluded ("process" or "procedure"). Facts are excluded ("discovery"). Recipes are excluded ("procedure", and a list of ingredients isn't considered to be creative). The descriptions of all of these can be copyrighted, but that can't block someone from using your work to create new descriptions of the same thing.
Google's claim is that the abstract Java API is a "system or method of operation", and that it includes the specific names as part of that. That means you can write a book (in your own words) describing the Java API, and you can include the actual names used in that API when describing it.
If you can't describe something that is excluded by 102(a) without using specific language, even that literal language isn't protected by copyright (this principle is called "merger"). In the Java language, there is only one way to declare a function (a "method signature"), a class, a constant, so if those elements (including the names) are excluded by 102(b), then the declarations are, by merger, unprotected by copyright.
The only parts of the Android API and Java API source code that are the same are those parts of the declarations that can't be changed without changing the API. If you were to start off with that book describing the Java API, even if it has no source code in it, you'd end up with the exact same declarations even if you had no access to the Java API source code and thus had no way to copy it. The only thing you'd be copying is the abstract Java API itself (including the names). If that is excluded from copyright protection by 102(b), then there is no infringement.
That's one of the questions Google asks of the Supreme Court, if the Java API is excluded from copyright protection by 102(b).
Note that a list of names, if it can be protected by copyright at all, has a very weak copyright. Unless you copy the exact same list, with only "trivial" changes, there is no infringement Google copied only a portion of the Java API, and added a lot more of its own. The differences between them is significantly more than "trivial".
Perhaps if occupancy was close to 100%, and no one anticipated an increase in demand (due to the UBI), prices might increase temporarily, to the extent that people who already had rental housing get an increase in income.
We're not at 100% occupancy, though. If some landlords raise rates, others will undercut them. With more people able to afford a place to stay, more units will be built. Supply will increase, to match the demand. The only constraint is the number of people who can afford to pay a rent (or a sale price) that makes it profitable to build new units or houses.
A UBI should be phased in gradually to avoid sudden imbalances that would lead to any disruption.
One effect of a UBI will be more mobility. If you don't have a good job, you could more easily move to an area with lower costs without having to worry about immediately getting a job in order to survive. With people moving in to an area like that, the local economy will improve and jobs will become more available, more housing will be built. People won't be locked in as much to a bad situation.
UBI of $2000/month (less for dependent children) can be paid for by changing to a 50% flat tax with a 25% VAT. The UBI itself is not taxed. The UBI combined with a flat tax and VAT is not regressive (remember, everyone gets the UBI payment, which reduces the higher taxes at a rate depending on your income).
You eliminate all other forms of social welfare, eliminate minimum wage as well, reduce bureacracy. You'd still need Universal Health Care.
You control inflation by adjusting the tax rate. If you need to inject money into the system, reduce the tax rate - you're "printing" money and distributing it through the UBI, rather than giving it to banks. If you need to remove money, increase taxes and "unprint" the excess.
This could be implemented gradually, shifting from the current system - pay 90% of your current taxes, get 90% of current benefits, minimum wage is 90% of current, pay 10% of the flat tax and VAT, get 10% of the UBI. Increase by 10% a year.
If most people would stop working and accept the life that $24000/yr gets you, most people wouldn't be working so hard to get ahead, but more "stuff", etc. Yes, there will be some layabouts - wouldn't this be a good way to get them to stop working, where they most likely are reducing overall productivity, give their jobs to people who actually want it?
We're not far from the point where having a job will not be the norm. With a UBI, though, jobs will still be desirable, allowing you to get extra income, get more "stuff. It will also free you to be creative, innovative, useful, rather than spending all your time looking for a non-existent job so you can continue receiving benefits, hiding income so you don't lose benefits, or turning down opportunities because they might not bring in as much money as the benefits you'd lose.
Nonsense. The demand doesn't change, just the ability to pay for it. That means there will be MORE competition for a newly expanded market, a company that raises prices when their competition can undercut them will simply lose market share.
The "increased demand" leads to a larger supply, not higher prices.
I've been trying to figure out what the term "blockchain" (as a "technology") is supposed to mean in a non-bitcoin context (or similar proof-of-work system) since it started being hyped.
What I think it really means, and what I think Amazon is providing here, is not distributed work, but distributed trust.
Specifically, the blocks and hashes (which includes the hash from the previous block) are published, and all interested parties have access. All they really need to record is the hash of the last block they saw, then confirm the chain after that point and record the final hash. For efficiency, they can also record hashes from the past (to make it easier to validate a range of earlier blocks).
Signing hashes would not be necessary, but can be used to assign responsibility for the content of a range of blocks (e.g. the accountant who did an audit).
The contents of a block are arbitrary. It can be signed, encrypted, plain text, what the blockchain aspect does is make it easy for others to verify that it hasn't been changed.
It's not very different from a Git repository with only one branch.
That's what I imagine it to be. Nothing to do with finding a value to be inserted into a block that makes the hash meet specific criteria (which is what bitcoin is about).
I don't know the specifics of EU copyright law, but US law requires that a copyrighted work be "fixed in a tangible medium of expression".
Recorded sound waves, written notes and lyrics, those are fixed. The taste or smell of cheese is not fixed, even if you could argue that cheese is a medium of expression.
It would only be copyright violation if he'd tasted someone's copyrighted food or drink. Independent creation is a defense against copyright violation.
US precedent is that recipes are not copyrightable, I don't see any way that the courts here would allow an end run by allowing taste to be copyrighted.
From several articles, it appears the actual problem is that the T2 chip also acts as the SSD controller, and Linux doesn't have a driver that recognizes it yet.
It isn't that "turning off Secure Boot disables the internal drive", but that the internal drive isn't recognized by Linux at all.
Can you boot MacOS or Windows (from internal drive) with Secure Boot disabled? Can you install MacOS with Secure Boot disabled? Can you boot MacOS from an external drive with Secure Boot disabled and see the internal drive?
Apple should definitely allow you to add your own certificates, the issue is how to allow that without reducing security. It needs to be complicated enough that my dad can't be talked through it by a scammer over the phone, and it needs to be protected from the babysitter installing his own certificate without being noticed.
Possibly allow modification of the certificate list only if a firmware password is active, and require a full wipe to enable or disable the firmware password.
Starting a tractor company is one thing. What about a tractor controller company, though?
As long as you own the tractor, not lease it (which opens up many cans of worms with regard to reverse engineering and modifying or even running software or firmware), you should be able to write your own software to control the tractor and attached devices.
DMCA and copyright in general protects the copyrighted code, not the actual processes carried out by the code, and reverse engineering to find the information required to control hardware and communicate with attached devices should be found to be fair use (despite Oracle v Google).
Slashdot Mirror
They did not copy any of Sun's code. They started off with the Harmony version of the Java API, and followed the terms of the Apache license it was released under.
At the time they started, the Sun source code was not under the GPL. Sun wanted them to use Java ME, and wouldn't agree to let them use Java SE.
The license that Harmony was developed under allowed for development of an independent version of the Java API, under whatever license they wanted to release it as. The sticking point for the Apache Foundation was that the TCK, used to validate an implementation as conforming to the interface specification, couldn't be released as open source. Without that, you can't use the Java trademark on your product.
So Apache decided to just not get it certified as conforming.
Google never used the Java trademark. Their implementation of individual methods, and the documentation (as javadoc comments) was also found to be non-infringing.
What the CAFC found to be protected, that Google had copied, was the interface itself, the hierarchy of names and the structure of the relationships (e.g. class and interface inheritance). They also found that Google had infringed on the declarations from the Java API source code (which can only be written one way in Java if you want to describe the same API).
Why would you think that in a full implementation, taxes would stay the same? Add a flat tax income tax of 8.4% (not including the UBI itself, of course), and the $700/month would effectively be decreased to zero by the time you got to $100,000 annual income. You can adjust the UBI and rate to set the point where you want it to be neutral to an individual's tax rate.
With total individual income, you can also figure out where to set those values to make it revenue neutral (after taking into account the savings from replacing some of the safety net programs and, hopefully, reducing administrative overhead). You can also reduce the current tax rate by a fixed percentage while adding on a larger flat tax. That's also a way to phase in a UBI, e.g. set a target UBI and flat tax rate, then start off with 10% of each, increasing by 10% every year, for example.
So, first year with a $1000 UBI with 10% flat tax, you'd receive $100/month and a flat tax of 1% on all other income.
You could also go much bigger, $2000/month, flat tax of 50% (break-even point at $48000), but phase it in while phasing out the current tax. Fully phased in, you'd effectively pay no taxes with $48000 income, effective rate at $75000 would be 18%, and 40% at $250000.
Why on earth do you think the supreme court will decide to grant the request this time?
a) the question is much better;
b) the case has ripened considerably;
c) the CAFC didn't fix their mistakes.
So this:
"public final class String extends Object implements Serializable, Comparable, CharSequence {"
Is not code?
Sure, that's code. It describes a portion of an API, a class definition.
While the code can be copyrighted, Google's question asks if the API itself is copyrighted, or is it a functional "system or method of operation" and excluded from copyright protection by 102(b) (including the names).
If it is excluded by 102(b), then the code you wrote would also not be protected, because of merger (the 97% of the code that isn't declarations would still be protected).
It's not that "declarations" have some special powers, but that declarations in Java are, by design, required to be almost identical when describing the same API.
Google was a bit sloppy, Harmony less so. Ultimately, it didn't matter, the one method that was inadvertently copied (rangeChevk) was the ONLY code that was found to infringe, other than the declarations, and the damages were found to be $0.
Properly done, AFC would filter out the declarations from consideration, assuming Google is correct and the (abstract) Java API is not protected by copyright.
The fair use defense is for doing reverse engineering (which involves copying protected expression) for the purpose of discovering the "functional requirements for compatibility", which are not protected by copyright. 102(b), Sega
If you can find out the information another way, such as if the specifications are published and freely available, there's no need to do reverse engineering, and any copying of protected expression for reverse engineering purposes would not be fair use any longer.
What you do with that information is not restricted to creating compatible software, nor is it even about fair use at that point. That information is simply not protected by copyright.
If the Java API is a "system or method of operation", and is excluded from copyright protection by 102(b), why wouldn't I be allowed to re-implement the Java API if I want to?
If I rewrite Linux from scratch, without copying any source code, copying only the functional requirements, I won't be infringing even if I ignore the GPL.
If you make a movie with the characters Han Solo and Yoda from Star Wars, you'd be infringing on the copyrights on those two characters. They are not excluded from copyright protection by 102(b). It wouldn't matter if you used real actors or virtual actors.
The names are not copyrighted, though the characters are, and the names can be trademarked.
No, you're describing scenes a faire, which is related but different.
Oracle agreed in court that Google can freely use the Java language. That was not part of this case. Google's bytecode interpreter was not accused off copyright infringement. There were some patent issues, but those were resolved in Google'a favor.
The only other issue was the Java API, and in particular, the names. Are the names part if the unprotected functionality in the Java API?
"Authorship", which is what you can copyright, is predicated on choice. Choosing to write a program in Java is not a copyrightable choice Having made that one choice, the declarations for the Java API now can only be written one way.
102(b) excludes "systems" and "methods of operation" from copyright protection. If the Java API itself (the abstraction, apart from any specific description) is a "system or method of operation", then the declarations merge with that and are themselves excluded from copyright protection.
The lawsuit with Microsoft was about trademark and breach of contract. Sun failed in a copyright action against MS.
The case against Google is copyright, not trademark. Google never claimed that their platform was Java, as in the Java Platform, using the Java trademarks.
The linked page says Google uses the Java programming language (which they do) and implements parts of the Java API (which they do). None of that is claiming to be Java, nor do they use any Java trademarks.
Yes, really. They use the " Java programming language", which Oracle agrees that anyone can use.
They neve claim they are using the Java API.
"Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language."
The issue of reverse engineering and whether it is allowed is purely a copyright issue, that's the only thing that could prevent it.
Microsoft lost because they tried to call it "Java", without having a license to use the trademark.
Google never called it Java, never claimed it was Java, only tried to make the core of the API compatible.
No, they only provided a portion of the Java API, then added much more of their own (and created independently the other 97% of the source code of the portions of the API they did copy, the actual implementation).
The claim is that the API as a whole is a "system or method of operation", so those parts necessary to describe that API (the declarations) are not protected (because 102(b) says that "systems" and "methods of operation" are excluded from protection).
Thousands of names are not needed to make something copyrightable. The threshold is quite low. The one part of the Java API source code that Google actually (unintentionally) copied was only nine almost trivial lines, yet that was long enough to be found infringing. The difference was that those weren't declarations, they were the body of a method (a "function" or "procedure" or "subroutine" in other languages), so there were many ways it could have been written and have the exact same function, so the description of the function is copyrightable, even though the function itself isn't.
There are several aspects to this. What you seem to be talking about is "substantial similarity", to show that copying occurred, because it's unlikely that it would happen just by chance.
To be infringing, there must be copying, since independent creation is allowed. However, some aspects of a copyrighted work are not protected by copyright, and even if you do copy those parts, there is no infringement.
102(b), that Google references, says that various specific abstractions can't be copyrighted (as opposed to something like a plot or a story). If an "idea" is too abstract, it can't be owned. Processes and procedures, concepts, discoveries, systems , and methods of operation are also excluded from protection.
If you copy a story, even if you use completely different words, even if you tell it in a different style, you can still be infringing on the story (if the story was original AND you copied it rather than come up with it independently). That's because "story" isn't excluded by 102(b). In particular, it isn't so abstract("idea") that it is no longer "expression" (and maybe has become "concept").
An algorithm is excluded ("process" or "procedure"). Facts are excluded ("discovery"). Recipes are excluded ("procedure", and a list of ingredients isn't considered to be creative). The descriptions of all of these can be copyrighted, but that can't block someone from using your work to create new descriptions of the same thing.
Google's claim is that the abstract Java API is a "system or method of operation", and that it includes the specific names as part of that. That means you can write a book (in your own words) describing the Java API, and you can include the actual names used in that API when describing it.
If you can't describe something that is excluded by 102(a) without using specific language, even that literal language isn't protected by copyright (this principle is called "merger"). In the Java language, there is only one way to declare a function (a "method signature"), a class, a constant, so if those elements (including the names) are excluded by 102(b), then the declarations are, by merger, unprotected by copyright.
The only parts of the Android API and Java API source code that are the same are those parts of the declarations that can't be changed without changing the API. If you were to start off with that book describing the Java API, even if it has no source code in it, you'd end up with the exact same declarations even if you had no access to the Java API source code and thus had no way to copy it. The only thing you'd be copying is the abstract Java API itself (including the names). If that is excluded from copyright protection by 102(b), then there is no infringement.
That's one of the questions Google asks of the Supreme Court, if the Java API is excluded from copyright protection by 102(b).
Note that a list of names, if it can be protected by copyright at all, has a very weak copyright. Unless you copy the exact same list, with only "trivial" changes, there is no infringement Google copied only a portion of the Java API, and added a lot more of its own. The differences between them is significantly more than "trivial".
Perhaps if occupancy was close to 100%, and no one anticipated an increase in demand (due to the UBI), prices might increase temporarily, to the extent that people who already had rental housing get an increase in income.
We're not at 100% occupancy, though. If some landlords raise rates, others will undercut them. With more people able to afford a place to stay, more units will be built. Supply will increase, to match the demand. The only constraint is the number of people who can afford to pay a rent (or a sale price) that makes it profitable to build new units or houses.
A UBI should be phased in gradually to avoid sudden imbalances that would lead to any disruption.
One effect of a UBI will be more mobility. If you don't have a good job, you could more easily move to an area with lower costs without having to worry about immediately getting a job in order to survive. With people moving in to an area like that, the local economy will improve and jobs will become more available, more housing will be built. People won't be locked in as much to a bad situation.
UBI of $2000/month (less for dependent children) can be paid for by changing to a 50% flat tax with a 25% VAT. The UBI itself is not taxed. The UBI combined with a flat tax and VAT is not regressive (remember, everyone gets the UBI payment, which reduces the higher taxes at a rate depending on your income).
You eliminate all other forms of social welfare, eliminate minimum wage as well, reduce bureacracy. You'd still need Universal Health Care.
You control inflation by adjusting the tax rate. If you need to inject money into the system, reduce the tax rate - you're "printing" money and distributing it through the UBI, rather than giving it to banks. If you need to remove money, increase taxes and "unprint" the excess.
This could be implemented gradually, shifting from the current system - pay 90% of your current taxes, get 90% of current benefits, minimum wage is 90% of current, pay 10% of the flat tax and VAT, get 10% of the UBI. Increase by 10% a year.
If most people would stop working and accept the life that $24000/yr gets you, most people wouldn't be working so hard to get ahead, but more "stuff", etc. Yes, there will be some layabouts - wouldn't this be a good way to get them to stop working, where they most likely are reducing overall productivity, give their jobs to people who actually want it?
We're not far from the point where having a job will not be the norm. With a UBI, though, jobs will still be desirable, allowing you to get extra income, get more "stuff. It will also free you to be creative, innovative, useful, rather than spending all your time looking for a non-existent job so you can continue receiving benefits, hiding income so you don't lose benefits, or turning down opportunities because they might not bring in as much money as the benefits you'd lose.
UBI is a very capitalistic idea.
Nonsense. The demand doesn't change, just the ability to pay for it. That means there will be MORE competition for a newly expanded market, a company that raises prices when their competition can undercut them will simply lose market share.
The "increased demand" leads to a larger supply, not higher prices.
I've been trying to figure out what the term "blockchain" (as a "technology") is supposed to mean in a non-bitcoin context (or similar proof-of-work system) since it started being hyped.
What I think it really means, and what I think Amazon is providing here, is not distributed work, but distributed trust.
Specifically, the blocks and hashes (which includes the hash from the previous block) are published, and all interested parties have access. All they really need to record is the hash of the last block they saw, then confirm the chain after that point and record the final hash. For efficiency, they can also record hashes from the past (to make it easier to validate a range of earlier blocks).
Signing hashes would not be necessary, but can be used to assign responsibility for the content of a range of blocks (e.g. the accountant who did an audit).
The contents of a block are arbitrary. It can be signed, encrypted, plain text, what the blockchain aspect does is make it easy for others to verify that it hasn't been changed.
It's not very different from a Git repository with only one branch.
That's what I imagine it to be. Nothing to do with finding a value to be inserted into a block that makes the hash meet specific criteria (which is what bitcoin is about).
I don't know the specifics of EU copyright law, but US law requires that a copyrighted work be "fixed in a tangible medium of expression".
Recorded sound waves, written notes and lyrics, those are fixed. The taste or smell of cheese is not fixed, even if you could argue that cheese is a medium of expression.
It would only be copyright violation if he'd tasted someone's copyrighted food or drink. Independent creation is a defense against copyright violation.
US precedent is that recipes are not copyrightable, I don't see any way that the courts here would allow an end run by allowing taste to be copyrighted.
From several articles, it appears the actual problem is that the T2 chip also acts as the SSD controller, and Linux doesn't have a driver that recognizes it yet.
It isn't that "turning off Secure Boot disables the internal drive", but that the internal drive isn't recognized by Linux at all.
Can you boot MacOS or Windows (from internal drive) with Secure Boot disabled? Can you install MacOS with Secure Boot disabled? Can you boot MacOS from an external drive with Secure Boot disabled and see the internal drive?
Apple should definitely allow you to add your own certificates, the issue is how to allow that without reducing security. It needs to be complicated enough that my dad can't be talked through it by a scammer over the phone, and it needs to be protected from the babysitter installing his own certificate without being noticed.
Possibly allow modification of the certificate list only if a firmware password is active, and require a full wipe to enable or disable the firmware password.
The processor family was never a big deal. PowerPC, X86, ARM, Alpha are/were all "standard hardware".
The real issue with Apple systems that requires "hacks" is almost always boot firmware and small but critical bits of hardware magic.
Mercedes Benz, the Cadillac of cars.
(Red Wriggler, the Cadillac of worms)
Starting a tractor company is one thing. What about a tractor controller company, though?
As long as you own the tractor, not lease it (which opens up many cans of worms with regard to reverse engineering and modifying or even running software or firmware), you should be able to write your own software to control the tractor and attached devices.
DMCA and copyright in general protects the copyrighted code, not the actual processes carried out by the code, and reverse engineering to find the information required to control hardware and communicate with attached devices should be found to be fair use (despite Oracle v Google).
Unless you've examined the "ransomware" in question, and seen the smart contract, I'm not sure how you can properly make such an analysis.