Gorgeous. I'd love to see a side-scroller or roguelike type game in this visual style.
> MRMO-Halftone "Deluxe" version can be used in both non-commercial and commercial projects of any kind, excluding those relating to or containing non-fungible tokens ("NFT") or blockchain-related projects.
Although the discussion around Blender add-ons and the GPL is interesting, this isn't an add-on and doesn't apply. It's a .blend scene, thus isn't bound by the GPL since it's an output from Blender. This is ultimately the equivalent of any other exported artwork, like a 3D model.
Below is the relevant part from that page:
> What you create with Blender is your sole property. All your artwork – images or movie files – including the .blend files and other data files Blender can write, is free for you to use as you like.
It is not settled that add-ons have to be GPL. The add-ons are python programs that do not contain or link against Blender code. Instead, they are called by Blender itself (and can call Blender python APIs). It's not much different from a Linux userspace program, for example.
There are reasonable arguments either way. For example, is an add-on for an electronics device that directly interfaces with the motherboard considered a derivative work? How about an accessory for some kind of tool? Like a plug in, they are useless without the original device, but does that make them derivative works that need permission to be distributed? We'd argue not for copyright of the designs of physical goods, so why would it be different for software?
There are clearly arguments either way and this isn't a settled matter.
It's likely the case that the author doesn't understand that they can't encumber their users under the terms of the license granted to them.
> Sharing or selling Blender add-ons (Python scripts)
> Blender’s Python API is an integral part of the software, used to define the user interface or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL compatible license. You are free to sell such scripts, but the sales then is restricted to the download service itself. Your customers will receive the script under the same license (GPL), with the same free conditions as everyone has for Blender.
Merely using an API doesn't infect GPL software (for example, syscalls on an OS). The actual legal argument from the FSF on this point is more convoluted, and hinges on the plug-in being a derivative work in the legal sense. Whether this is true or not isn't settled.
It seems to me that the legal community leans in the direction that using an API doesn't make a work derivative in and of itself, and that transforming the actual work and redistributing the transformation (or the work itself) is required. It is however clearly a gray area.
Yes, I agree. However using an API that may-or-may-not be bound by the GPL is different (de facto) from using an API that the licensor claims is covered by the GPL. It's quite a bit more risky IMO.
> using an API doesn't make a work derivative in and of itself
Note that while it might be a gray area, there is some (recent) precedent [1]. Although a SCOTUS ruling isn't quite as binding as it used to be... :(
IIRC that case isn't that the using an API makes it a derivative work, but that the API itself is copyrighted and that making an implementation of that API is a copyright violation (except for fair use, etc...).
EDIT: gpm is correct, they didn't arrive to such a conclusion.
They didn't decide either way on that question. To quote wikipedia "This conclusion rendered the need to evaluate the copyright of the API unnecessary".
Yeah...if that is the case, wouldn't nvidia graphic driver's kernel-shim-to-closed-source-binary not be legit, since the shim defines an API in the kernel and then the closed source blob uses that GPL'd API?
Nvidia are already moving to a world where the Linux kernel driver is GPLed and in Linux mainline and only the firmware and userspace parts would be proprietary. So that potential GPL violation is in the process of being resolved. Eventually the signed proprietary firmware and the upstream Linux kernel driver would be shared between the proprietary nvidia driver and the open source nouveau driver. Of course they shoved parts of the Linux kernel driver into the proprietary firmware as part of the process, so....
The bulk of a modern video driver on linux (and most operating systems) is not in the kernel. The kernel module just facilitates communication between the user space drivers in mesa and the hardware.
Precisely. Though perhaps NVidia would argue they're giving themselves a license exemption?
If you understand drivers as plugins (which makes sense, really, drivers are kernel plugins), and if you understand plugins as derivative, it would be even worse. It would mean every driver on Windows's copyright is Microsoft's by default. And that the original NVidia closed source is already GPL.
Not just NVIDIA, ZFS too. From the GPL perspective, any non GPL compatible license is considered the same way.
That said, that part of the GPL on library linking was never attempted to be enforced in court.
For additional entertainment: redistributing a linked GPL program to a non-GPL compatible non-OS bundled (those have an exception) library is supposed to be forbidden too, but is very often done. For example, for the Visual C++ runtimes.
It’s supposed to not be okay according to the FSF, which does quite some overreach in their FAQs. A reminder that the FAQs themselves are _not_ part of the license.
There is a way that Oracle could solve the ZFS situation; release a CDDLv2 that is compatible with the GPL, then the CDDLv1 auto-upgrade clause would mean that all CDDLv1 software that hasn't opted out of the upgrade clause would now be GPL compatible. Some parts of OpenZFS would need to be relicensed or reimplemented, but that job would be much smaller than reimplementing ZFS for GPL compatibility. More discussion here:
Drivers aren't plugins. They link to and incorporate GPL code. You can't grant special terms in that scenario. The best they can do is dual license their headers. The hazy area is where no linking happens and it's just a pure API without code sharing.
Do DKMS drivers have to include headers as redistributed? I was under the impression they didn't have to, but I have very little expertise with DKMS and could definitely be wrong.
> I'd love to see a side-scroller or roguelike type game in this visual style.
The license says "you may not distribute the shader even if you modify it", so I don't know if you could. Obviously you'd convert the shader to HLSL and simplify it for realtime, but the vague language doesn't make it clear to me if a reimplementation of the shader counts as your own thing, or as a derivative for the purposes of "you may not distribute". Though I highly suspect the author would give you a go-ahead if you just email him directly.
A bigger concern I have for animated content is that dithering usually looks horrible in motion. It might be perfect for a Myst-style game, though - something with very minimal movement.
In the context of game assets, usually distribute in this sense means provide for download for other game devs to use, rather than include it in a published game. Generally speaking, asset artists are happy for you to modify their assets for use in your game (and often, it's necessary for game engine compatability or efficiency)
Yup. If the author doesn't show examples with motion, it is pretty safe to say that it won't look well for animations. This most often does not come for free.
It's unenforceable (the author even admits this) but a tonne of game asset artists have had their work stolen and resold as NFTs, and so a lot of them have started including this clause just to make it clear because when the NFT scammers disappear with the cash, the buyers often end up contacting the original artist (and more often than not, start making demands and threats)
The license explicitly forbids using this for NFTs. Cut and pasted from the very end:
Licensing:
"Basic" version license: MRMO-Halftone "Basic" version can be used in non-commercial projects of any kind, excluding those relating to or containing non-fungible tokens ("NFT") or blockchain-related projects. You can modify it to suit your needs. You may not redistribute, or resell it, even if modified. Credit is not necessary, but very much appreciated.
"Deluxe" version license: MRMO-Halftone "Deluxe" version can be used in both non-commercial and commercial projects of any kind, excluding those relating to or containing non-fungible tokens ("NFT") or blockchain-related projects. You can modify them to suit your needs. You may not redistribute, or resell them, even if modified. Credit is not necessary, but very much appreciated.
Reminds me of when I started gaming there was a cRPG series called the 'gold box' - pools of radiance, curse of the azure bonds, secret of the silver swords, etc.
The first of these was in CGA (I guess corresponding to CMYK?) which was I think '4-bit'. Then 'Curse' was EGA and Silver Blades was VGA.
Ok on looking these up, its way more complicated than that. Still, those colours are a nostalgia trip...
> MRMO-Halftone "Deluxe" version can be used in both non-commercial and commercial projects of any kind, excluding those relating to or containing non-fungible tokens ("NFT") or blockchain-related projects.
Warms my heart <3