RandyTheDev

Hey @Beetlecat, it should absolutely work with your G513 :) If you have any issues let me know.

Hey @fwdixon , unfortunately this mod does not support the G110 yet! I'll look into adding support for that keyboard in the next week or so!

@fwdixonUnfortunately my patch for this issue has not been merged by @battlemoose yet My fix above should work though! https://forum.kerbalspaceprogram.com/index.php?/topic/169895-141-ksp-logitech-rgb-control-v110-2018-03-18/&do=findComment&comment=3336813

I’m trying to avoid getting into the intricacies of which bits of the GPL are legally enforceable in a court of law or not, that opens up a whole other bag of worms! I’d much rather focus on respecting the GPL’s original intent As for the difference between KSP and Linux, when you write a Linux app, your code isn’t really that reliant on Linux. It would be relatively simple to get it working with a different OS like Windows or FreeBSD. Linux isn’t even required to compile the software for Linux! KSP mods on the other hand, are entirely dependent on Kerbal Space Program being present.

The moment you resort to insults is the moment you concede the point. It’s basically saying you don’t have anything more constructive to add to the conversation but you still disagree because you’re either too stubborn to either back down publicly (understandable imho) or worse, you believe that you are infallible.

Looks like my hope was misplaced! The irony that a law professor is throwing petty insults is not lost on me. Here's an article on how to argue: http://bigthink.com/paul-ratner/how-to-disagree-well-7-of-the-best-and-worst-ways-to-argue You might find it helpful for your job. In the future, try to keep any of your arguments near the pointy end of the pyramid!

Your translation of the GPL isn't worth the paper it was written on. You can't just snip the text that was irrelevant to your extremely narrowly-scoped example and then claim I've somehow not read/misinterpreted the GPL. You're being deliberately obtuse and misleading. The bit you snipped is only irrelevant because you chose the one type of mod that has no object code or executable component whatsoever. That's not the case for the vast majority of KSP mods. They do need to worry about the bits you snipped out. Your interpretation of what source code/object code is, is so laughably wrong it's difficult to correct you without appearing to condescend. As the license states, source-code is a file type that is the preferred form of the work for making modifications to it. For a DLL, this would be something like C# source files (.cs), for a texture, it would actually be something like a Photoshop PSD, or the native format of whatever editor was used to create it. It has nothing to do with the format you published it as, and everything to do with how easy it would be for someone to continue the work you released. Object code is defined as literally any form of the work that is not source code. Since we are talking about software, this is typically a compiled version of the source code, and results in a DLL, LIB or EXE file. While it's technically possible to edit these by hand, for all intents and purposes, it's not remotely practical. So in the context of KSP mods, this means that if you publish a DLL, you have only published the object form of your work, not the source form. I'd actually argue that .dds files do not qualify as source code, since they are generally only an output format. To Simplify to a gross level but without losing nearly as much of the original intent than you removed: Source form: The type of files you edit while developing a mod/any piece of software. Object form: The type of files you exported once you were done and were ready to release, which were generated from a source form at some point (not necessarily by you). No. Conveying Verbatim copies specifically only applies to redistributing the work in its source form. The moment you convey work in its object form you must also convey the corresponding source. Everything you said in this sentence is wrong. As long as they only convey the work in source form, there is no requirement to provide the corresponding source. This can be any source, not just the formats you distributed your mod in. For example, they can add C# source code to add extra capabilities to your part. If they compile that into a DLL, they are now responsible to convey the corresponding source which includes the actual C# source code, as well as all of your source form files. There is no requirement to translate the files back into .cfg, .dds, or .mu, in-fact, they are more than allowed to translate your original work into different source-form files, and they will still count as source form files! The only requirement is that you provide a means to convey your source form files to a user. To correct one of your earlier examples, it is perfectly fine to change a .cfg file into a .txt file and vice-versa, as they are both perfectly acceptable formats for specifying a part config. Including the original mod with your product does nothing to assist with GPL compliance, all that matters is that all corresponding source is available to any licensee who requests it. This is simply untrue, at no point does the GPL restrict a licensee's ability to make money by using/redistributing the work. I have no idea where you pulled this nonsense from, but I imagine it's a very similar place to the rest of it. Like I said, there is no requirement to distribute the original mod, only one to convey the corresponding source. If you modify the source form of the original mod, you only need to distribute the modified version of the source form. Not the modified version in addition to the original. I hope you actually try to understand my counter-arguments, rather than your usual schtick of throwing uninspired insults.

It's literally a direct quote from the GPL. https://www.gnu.org/licenses/gpl-3.0.en.html Section 1, Paragraph 4.

What I am trying to say is that it is impossible for a user to respect the GPL if they intend to distribute a binary form of your mod or a derivative. Almost, but not quite. The GPL requires redistributors to convey all of the corresponding source of the binary, not just the source code for the binary alone. The corresponding source of any GPL-licensed work is defined as the following: My understanding is that this means a redistributor would need the capability to convey the source code for: Assembly-Csharp.dll to compile, and/or modify the mod Kerbal Space Program to run the object code This requirement to convey more than just the mod's source code is what makes me believe that KSP mods are effectively incompatible with being licensed under the GPL.

While this is true, by incorrectly licensing your mod under the GPL you falsely imply that the user has permission to distribute binary versions of the mod (or modified versions) under the terms of the GPL. This is not possible, as there is no way for them to acquire the "corresponding source" that they are required to convey to anyone they distribute their version of the mod to. They may also be under the false impression that they can freely incorporate the code of other GPL-licensed software products into their version of the mod, and distribute a binary version of the combined work. They could then be sued by the other developer for incorporating their GPL-licensed software in a GPL-incompatible software product.

Pull request submitted! https://github.com/battlemoose/ksp-logirgb/pull/2 Has some various minor bugfixes.

That's actually a pretty accurate summary of what's going on! It's not Kopernicus' fault per se, they're using a system library that is causing the issues. That's actually what I'm planning on doing! It turns out this behaviour is a known missing feature in C#'s build system. I'll move the tests to a separate C# project which should resolve the issue.

So this is incredibly weird, but it's actually the unit testing framework I introduced that is causing this. It's not included in the release since it's only needed for development, but for some reason it's still packaged as a dependency, and Koperincus expects it to be there and freaks out when it can't find it. Anyway, download NUnit.3.9.0.nupkg from this URL https://github.com/nunit/nunit/releases/3.9 Once downloaded rename it to NUnit.3.9.0.zip, and copy lib/net35/nunit.framework.dll into your GameData/KSPLogiRGB folder. Kopernicus should work from then on. By the way, Kopernicus has a version checker so won't work with 1.4.1. To get rid of the version warning message for KSPLogiRGB in 1.3.1, edit the KSPLogitechRGBControl.version file to look like this: { "NAME": "KSP Logitech RGB Control", "DOWNLOAD": "https://github.com/battlemoose/ksp-logirgb/releases", "VERSION": { "MAJOR": 1, "MINOR": 1, "PATCH": 0, "BUILD": 0 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 4, "PATCH": 1 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 3, "PATCH": 1 } } I'll look more into stopping NUnit from being packaged with the mod... How odd. Pinging: @Dark Necrotic, @battlemoose

I’ll investigate SOON™️. But seriously I will follow this up later today. Is there any particular configuration you’re using with Kopernicus?

The modified version of KSP is also considered to be a combined work (according to the FSF), which would also need its source code to be conveyed. This actually isn't something I don't necessarily believe in, and it is legally untested. However, I think that it is better to err on the side of caution. It's also irrelevant to the main argument (my bad I guess ), as you correctly stated, the Corresponding Source is required for any distributed binary, not just executable ones.