I can see why you thought it was, but "Open Price" in Japan means that the manufacturer has forgo setting the price themselves, unlike the previous policy that the price is dictated by Nintendo (in this case). The wholeseller's price... is simply not disclosed here, there's an NDA on that one (even with other companies such as Sony).
I won't dispute you or even cassianoleal, but compared to how was US in 2005 (just barely finishing check/que digitalization), Brazil is indeed faster in this forefront (and it enabled the creation of Pix in the first place).
As already stated multiple times here, the CRLF is actually the "correct" way (at least in the telex days, where CR and LF have actual meanings of "Return Carriage to home" and "Feed a new Line"), while the LF-only one is a Unix "hack"/abstraction (which was actually converted back into CRLF if fed to a telex or a terminal). It is not really a surprise that DOS, which was inspired by CP/M, simply copied what was supposed to be a physical signal. This is the reason the ASCII/ANSI code has a BEL indicator for ringing a bell. In short, CRLF is the way to handle newlines at the time that DOS was designed. You will expect that CRLF is the ending because that's how terminals work (unlike with the magicking Unix which smooshes two differing things into a character).
If you are writing a developer suite, whether you're Delphi developing for MS-DOS or Microsoft developing for Apple II, you kinda have the idea of how things should work (because you have the reference book for the platform, not the compiler/language). It is not the assumption that the OS provides abstraction for text - in thise days, everyone just implement it from scratch, really ("code page" was from literal code pages, where each character has a well-defined byte). This is manifested in command-line handling on Windows: the platform convention is that it is just a flat string, and the C runtime determines how to chop that up (MSVC and Intel C has historically disagreed heavily here) The abberation of Windows only having CRLF is because Unix-based designs took over the world: macOS is Unix, Linux was insiped by Unix, *BSD was Unix-derived.
MTA-STS, a very recent standard (RFC 8461), only allows CRLF as the line terminator (to the chagrin of *nix lovers, and to the fact that a majority of mail systems are being operated on *nix systems)
a) It still affects their bottom-line: the issuer might still try to dispute this using a different code despite payment scheme (formal term for Visa et al.) rules, and the merchant targeted is prone for fraud (for example, airlines have been hit with this by exploiting tourists looking for cheaper tickets by offering them suspiciously cheap tickets on seemingly-trustworthy websites by fraudsters and funding them by insecure cards)
b) Misinterpretation of mandatory rules: PDS2 is applicable only for EEA customer - EEA merchant, but some extended it for whole world despite the rules literally dictating the limits
c) Soft friction for encouraging domestic card usage: because of accept-all rules by payment schemes (and no local rules that allowed merchants in a region to reject international payments), this is a way to block US cards by guise of fraud prevention (because international cards are expensive for merchants to process)
Wow, c) never occured to me but makes total sense.
b) can probably explain this happening for EU merchants, but I've also seen this in Japan and Central America, and I think even before PSD2 in the EU.
That's what I love about the payments space: While you're absorbed in your own game of checkers, you never know if your opponent is actually playing 1d or 10d chess :)
I think this is in the sense of needing a modern-ish hardware with VT-x/AMD-V support (instead of the already-contemporary v8086 which is already in use by Windows at this time).
TLDR: you're basically applying the US standard to something that has been released worldwide, and US intellectual property law is known to be one of the most lax when dealing on derivatives (Feist Publications, Inc. v. Rural Telephone Service Co.). Without saying that the original broadcaster/s do not held any copyright (because, of course, there is a reasonable claim for their copyright), there are two good candidates for the Conet Project's case, both hinging on European IP laws.
The first one is the "sweat of the brow" concept, where effort (not originality, or at least not significant originality) is the determiner. Because this was released in 2001, most European jurisdictions (like Britain's "skill and labour" and Germany's Leistungsschutzrecht) still had this concept. Because the collaborators of the Conet Project did exert significant effort here (they didn't just tune, but significantly denoised and made it reasonably intelligible), it could be argued that they held a new copyright on these works. New laws now significantly tilt towards the creativity/originality concept, but this is usually not a retroactive claim.
The second claim (and the reason that I said IP laws, not specifically copyright laws) is that Europe (incl. UK and Russia) has database rights which does not exist under US law (again, Feist v. RTS). Even if the Conet Project release is ineligible for copyright in most European jurisdictions (and I doubt it due to the non-retroactivity of these laws), they can still point out that the curation of the work provided for enforcement of database rights.
There is actually a third claim (although weak), based on the first publication of a recording of a performance (phonogram rights). This also exists under US laws, although I will be sure that the first "publication" is the broadcast, especially if it was also aimed in the US. (This is the reason why "sampling" some music is considered an IP infringement.)
P.S. If you think that US IP laws are bonkers, try to navigate European IP laws (it's not even harmonized inside EU). There's even a "Copyright in Typographical Arrangement" (UK) where even assuming that the text itself is not copyright, scanning the page might put you into a lawsuit (https://cdn.nationalarchives.gov.uk/documents/copyright-typo...)
Since no-one bothered to answer, the way the license was written did not disclaim any warranty. Sure, US jurisprudence might beg that there is no implied warranty, but most jurisdictions would interpret that as having unlimited warranty. In most places, what-you-pay is not the default to warranty claims, but instead focuses on what are the actual damages to the user. Notably, Australian/NZ and EU (especially Germany and Austria) has extremely strong consumer protection laws which also covers software, and WTFPL didn't even attempt to limit liabilities.
NB: For reference, here's the disclaimer for several popular licenses:
MIT:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
GPLv3:
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
CC0 (just to drive the point home):
4. Limitations and Disclaimers.
(Subsection a (which focused on trademarks and patents) omitted for brevity.)
b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.
For context, this was proposed way back in 2013 (https://meta.wikimedia.org/wiki/Abstract_Wikipedia), when machine translation is just plain bad (and LLMs are only known in academic circles). Surprised that AWiki is now active though.
I have even heard of a major cloud service mandating absurd earthquake-proofing (to prevent any movements inside the datacenter and triggering an HSM reset) but I cannot find any verification regarding this (maybe this is ultimately an urban legend).
reply