Nintendo Open Source Software Source Code Distribution Page | Hacker News Reader

Nintendo Open Source Software Source Code Distribution Page

nintendo.co.jp

164 pointspdknsk37 comments

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? :)

The package is here: http://www.nintendo.co.jp/support/oss/data/MarioKart8_OSS1.0...

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.)

Someone downvoted this, I assume they mean to say it's incorrect? Can they or someone else elaborate?

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).

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.

Thanks for the correction!

Ahah, maybe :)

However, the SBC codec library is LGPL, not GPL-only. Notice COPYING.LIB along the COPYING!

Just the main sbcdec and sbcenc are pure GPL, and they are not very long files, so it's likely they rewrote those parts.

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)?

No, GPL only requires you to provide source-code to users on request. No general publication requirement.

Yes, and those users are free to publish that code in any way they desire.

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.

http://www.gnu.org/copyleft/gpl.html - "And you must show them these terms so they know their rights"

Most games have all of this info in the credits, and if you get a manual anymore, in there.

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.

https://www.gnu.org/licenses/gpl-faq.html#WhatDoesWrittenOff...

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.

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.

Does this page leak news about Nintendo DS emulation for the Wii U Virtual Console? Or is this a mistake/old news?

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.

I believe that's also how the PS2 worked. I think it used the PS1 processor as the sound chip as well so they didn't need to emulate the processor.

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.

> 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.

Source: I'm a Dolphin developer.

Sorry then I must be wrong. All I remember it from was an IRC conversation on the PPSSPP channel.

IIRC Wii's CPU is a faster GameCube CPU, but the Wii U one is totally new, so the Wii U includes a Wii CPU.

That's cool, I didn't know that. Thanks!

It was rather quietly announced earlier this year, during a financial results briefing.

http://www.nintendo.co.jp/ir/en/library/events/140130/02.htm...

They released Brain Training DS in JP and EU about a month ago for the Wii U.

Hopefully there will be some classic nintendo backdoors in this code somewhere.

There is a working exploit for the Wii U web browser: https://bitbucket.org/Marionumber1/wiiu-userspace

Indeed, and for those keeping an eye on the scene... an exploit for newest firmware 5.1.0 was just released a day ago or so. http://www.eurasia.nu/modules.php?name=News&file=article&sid...

Keep an eye on the work MrBean has been doing to MarioKart8 - http://www.youtube.com/user/MrBean35000vr

http://www.youtube.com/watch?v=-S4ZhmanOeM

http://www.youtube.com/watch?v=UVbZXqxIV7I

Reply on news.ycombinator.com