Update License Verbiage.

[stevemeacham]

133

Updated the LICENSE file's copyright line to include each year there have been changes. Also added the KSLib team as the copyright holder.

Updated almost all of the README file's licensing information, and tried to keep the same "break it down for you" tone while remaining accurate and precise, as such things ought to be.

1. Delineated what information applies to contributors vs users.
2. Mentioned the inconvenient truth that most, if not all, of KSLib inherits the GPLv3 from kOS, whether we would like it to or not. Kept the focus on "additional protections," which is true, keeping in mind that the MIT License was made to protect programmers while the GPL was made to protect users.
3. Focused the "Why MIT" (and not the GNU GPL) section on the GPL's verboseness and complexity, and dropped the arguably disparaging treatment of new Kerboscript programmers.
4. Corrected and standardized some terminology about licenses and their names.

I hope this helps. Questions or discussion welcome!

[nuggreat]

I do not think KSLib is bound by the license kOS uses because kOS is closer to a compiler than a library when it's relationship to kerboscript is accounted for. This opinion is mostly based on what I was reading in the GNU FAQ about using something under that license.

[stevemeacham]

I'd be ok with removing the reference to inheriting the GPLv3 if you insist. Before you decide, consider my reasoning below. I speak not as a lawyer, but from regrettably spending the last eight years of my career as a government IT compliance officer. If you think I'm bad about legalese, you should talk with me about accessible user interfaces, which was my area of speciality.

KSLib wouldn't inherit the GPL because it uses the kOS language, interpreter, or compiler. It's because it also uses and relies upon the kOS structures and API. Consider lib_navball and lib_navigation. Those are the main ones that would bring kOS' GPL into play, as they derive functionality largely and directly from the Vessel structure, which is essential to them interacting with KSP. I grant that they are only two of many libraries, but they are part of the larger work of KSLib, which therefore could result in the GPL applying to the rest of KSLib. If you consider the List and Vector structures to be API rather than language, and I think it could be argued that they are, inheriting the GPL becomes even more likely because we use them even more.

That's where I was coming from. In the end, such things are decided by judges, not by code warriors. I could be completely wrong, but I might not be, either. Again, I'll drop that statement if you'd like. Say the word.

[nuggreat]

Good point I hadn't considered that though as the vast majority of the structures in kOS are wrappers of the KSP API, unity structures, or mono/c# structures to the enable there use in the kOS language so I don't know how that would change things. The only things I can think of that are entirely made by kOS are the steering manager, the SKID stuff, part tags, the kOS processor part, the built in PID, and the terminal.

It can also be argued that structures like vessel are part of the definition of what makes kerboscript the language what it is. Of everything in kOS the addons are more like APIs/libraries as they are external to the core mod and can in theory be removed or added with no issues.

[stevemeacham]

It was a tangential point in any case. I'm starting to think it will cause more confusion than it's worth, even if it's correct. Again, I can update the pull request to remove it, or you can remove it with my blessing.

We could replace the entire "Why MIT?" section with something like this, too:

"The primary reason for selecting the MIT License rather than adopting the kOS' GPLv3 is that the GPL's verbosity is incongruent with kOS' purposefully limited drive capacity and the general triviality of Kerboscript programs."

[nuggreat]

I will handle removing the point when I pull in the PR.