There is nothing particularly interesting, most is just their customised WebKit. MK8 uses a bluetooth library, only modified to compile with MSVC. DS emulation uses Nanojit, but I couldn't figure out the snapshot they used to run a diff against.
Now, I'm not a lawyer but the Mario Kart 8 package contains code that is GPL (not LGPL) - look at the bluetooth audio codec stuff. Does this mean that Nintendo is legally bound to release the whole source code of Mario Kart 8 now? :)
IIRC, only if it's statically linked. If it's on the disc as two different binaries that only talk to each other through the OS at runtime, then no, MK8 isn't required to be GPL.
(It's the same principle that allowed Apple to include GCC with Xcode before LLVM came along.)
GPL code you CANNOT link in anyway without your code being infected by the GPL license terms, dynamically or statically. You CAN invoke tools written in GPL just not the code (unless that GPL license has something like a classpath exception).
The are also exceptions for libraries provided by OS. (Which is why you can GPL code on Windows which links a proprietary libc from Microsoft).
Apple gets away with calling GCC because it's a different application being invoked by it's natural interface in the same way that Xcode invokes git internally. (And also why people use the libgit2 project when they need to call git as a library which licensed under LGPL with the classpath exception).
Now LGPL is an entirely different story. LGPLv2 was intended that you be able to replace dynamically linked libraries in an application. The changes you made the library must be open sourced and I should be able to replace that library as a user.
In theory you satisfy the requirements of the LGPL license if you wanted to statically link though if provide the objects and archives of your code if you wanted to statically link with LGPL code, but doing this was not really well defined in the license as valid. In LGPLv3 they clarified this is totally valid and allowed.
The interesting thing is that LGPL was a license best written for C libraries at dynamical library level and breaks down in a few cases for different languages. It also breaks down where you have inlining and code getting embedded from headers that would break the ability in some cases for you to be able to change the library and relink. Implementation details of vtables, etc can get embedded too that would make it impossible to change the library.
This is why during the GNU Classplath project (to replace the Java Classpath before Java went GPL anyways), they added the "classpath exception" to GPL itself instead of using LGPL. See here for details: https://en.wikipedia.org/wiki/GPL_linking_exception
But what exactly is a "link"? If I write e.g. a piece of software that enables combining and running arbitrary code from any library, GPL or otherwise (think of something like rundll32 on Windows), and use that instead, via parameters that the user somehow has to supply in order to get the right libraries and symbols, does that also become GPL? I can thus use any GPL (or otherwise) library in the same way that Xcode uses GCC.
This and other "how long is a piece of string" type of issues is why I think licensing is overall a horrible ridiculous convoluted mess.
Linking is simply a simplification of "what defines a derivative work" that FSF think helps developer. It is by no means final, and one can always hope that the court system will find the definition of derivative work at some other point.
I would however call it a bad bet to incorporate someone else code into a proprietary product, on the off chance that the general known line of "linking" can be invalided by the courts. The lack of case files should be a strong hint towards that.
I didn't downvote, but it's incorrect. They're confusing the GPL (which requires release regardless of static or dynamic linking) vs LGPL (which allows no release if only dynamically linked).
As someone who's still learning about licenses. Does this mean that since they waited so long to release their OSS that they've been violating the terms of the licenses they've used to ship products for years (potentially)?
I think you also have to provide details of the licence/licensed components alongside your distributed software, so that users know they can actually request the source-code.
Nintendo games all have manuals, they're just not physical. For example, if you put a 3DS Game Cart into a 3DS, there's a Manual button to bring up a nice HTML-style manual.
Keep in mind this isn't a new page; I don't know the history of each package, but at least the Wii U browser WebCore distribution has been there since Wii U release.
If they were distributing the binaries without any indication that they were GPL'ed (i.e. no written offers), then yes, it would have been a violation. But it's not a violation any longer. They seem to be under compliance.
It might be DS emulation for 3DS. I'm pretty sure that DS games run under software emulation on that platform, given that you can do things like hit the "home" button to return to the 3DS's menu.
Nope. I think its hardware emulation. The DS games run on one of the processors. I think its the processor that runs the system OS, which is why you can't just back out of a DS game into the main menu, you have to quit the game. Also the reason why you don't get street passes when you play DS games.
IIRC, it can't run the System OS at the same time because the system switches in to 'DS Mode'. The DS actually had two processors inside, and AFAIK the 3DS under-clocks both processors to match what the DS had and runs the games that way (And thus, while it's in 'DS Mode' the only way back to 3DS mode is via the Home button).
Its also interesting to note that this is how Nintendo has handled backwards compatability for every gameboy generator. In the DS the GBA's arm was used for sound processing. And the GBA has a GBC's z80. The GBC itself was just a GB z80 with a higher clock and special memory space for color palettes.
> Its also interesting to note that this is how Nintendo has handled backwards compatability for every gameboy generator.
Same pattern as how they handled Game Cube compatibility on the Wii, I believe. I wouldn't be surprised if Wii mode on the Wii U were similar, but I'm not familiar with that.
True, in the case of both the Wii and WiiU they are mostly higher clocked Gamecubes. This is why Dolphin started as a Gamecube emulator and added Wii support. About a year ago I talked with one of the Dolphin developers and he anticipate extending to the WiiU once we have the CPU headroom.
I don't know who you talked to, but Dolphin will never have support for Wii U. Wii U emulation requires a completely different emulator type compared to Wii emulation.
Likewise the Sega Master System used a Z80 as its CPU; later, Sega used it for the Genesis / Mega Drive's sound management processor (plus a Yamaha synthesizer). If you plugged in the Power Base Converter, the Z80 would become the CPU and let you play Master System games.
More interestingly, I read something not to long ago that the GBA games released for the 'Ambassador' program on the 3DS are also run right on the hardware (For better or worse). I feel like that means the GBA's processor is also inside of the 3DS, probably because for 'DS Mode' to work it'd have to have a compatible sound processor in there somewhere.
