Policy regarding license statements

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Policy regarding license statements

#31 Post by Dilvish »

adrian_broher wrote:...what makes you think that the DCO isn't good enough for this project, when it seems to be good enough for the Linux Kernel
I've already stated the legal weakness that the DCO itself has-- this indefinite reference to "the file" for critical license terms, and I explained how I expected it got that way. Did you give a counterargument to that which I have overlooked? Even that Linux Kernel submitting patches document you referred to (I think your link is missing the final letter) doesn't do nearly so much as it could to clarify that point or clearly specify a license grant from the contributor. Surely you don't consider the Linux Kernel code itself to be pure perfection, never possible to improve, so why would you expect their legal practices to be perfect and unimprovable?
Dilvish wrote:Also please note neither README.md for those projects refers to their COPYING file
Is this even required legally? Open source projects that follow the GPL project layout (Having a README, COPYING, CHANGELOG, src, share, ...) you can expect that the COPYING file contains the license terms because of customary practice.
Legally required as in definitely a judge would rule against you without that? No, but any murkiness about the terms people are going to be held accountable for is bad, and a potential source for an adverse ruling. Given that the README.md automatically features prominently in the display by GitHub, the focal point for people to submit contributions to a github-hosted project, it is an ideal place to call attention to anything critical like inbound license terms for contributions to a GitHub project. Our README.md refers contributors to a secondary document for details, which is fine. Whatever site or process is used to gather submissions should make the terms clear, or you're just pointlessly creating an opening for trouble.
Vezzra wrote:So, basically, we would incorporate a properly worded DCO into CONTRIBUTE.md, ideally with an explicit line stating something like "Each commit needs to be signed off, by which the contributor agrees to the projects license terms and releases their contributions according to these terms". Then, all that needs to be done is that each committer actually does that (signing off their commits). Have a CI build stage checking for a correct sign-off, so we can't accidentally merge a PR missing it.
I agree with the first part of that, putting some language along the lines of the DCO into our CONTRIBUTE.md. I disagree about us needing to institute the git signoff process. As the the documentation for git signoff itself notes, "The meaning of a signoff depends on the project..." i.e., you have to have a clear statement of what you intend the signoff to mean, or it is meaningless. It is that clear statement about the submission process and inbound licenensing requirements which provides the core (almost the entirety) of the project's legal position, regardless of the signoff.

For a project like the Linux Kernel which actually defends itself in litigation, the very tiny little bit of extra proof/notice that the signoff statement provides (about the contributor having notice the actu of submitting and/or providing signoff may be intended to signify agreement to some set of terms) may very well be worth the hassle-cost. Their actual justification for the signoff requirement in that document linked above focuses almost entirely just on some sort of project organizational tracking value. Please also keep in mind that since for projects like the Linux Kernel their contributions are much more likely needing to come from highly skilled programmers compared to the broad range of skill levels that helpful FO contributors can have, the barrier for them is likely much lower than it would be for many of our contributors. So it's worth more to them and costs them less.

Even under the terms of the standard DCO there is nothing that inherently requires the use of --signoff, any such requirement comes purely from the other project docments. As noted in that Software Conservancy article it is just fine to make it clear in the project documents that the act of submitting a contribution constitutes acceptance of the various specified terms regarding such (akin to click-wrap agreement to licensing or terms-of-use). (And that is a longstanding part of contract law, acceptance of a contract can done via taking some specified action, not only via signing something.)

So, like Geoff, I see no reason for us to require git --signoff (but I do think we need to augment our project documents to make these submission terms more clear).
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
labgnome
Juggernaut
Posts: 833
Joined: Mon Mar 02, 2015 5:57 pm

Re: Policy regarding license statements

#32 Post by labgnome »

adrian_broher wrote: Sorry, but you really underestimate how easy contributions nowadays are.
Dude.

I was thinking of going at all your various points. But honestly I really just have to say that a lot of what you say is kind of inappropriate. I specifically said that Git is difficult for me to use, and that I'm not alone in that. I find the app's interface to be obtuse and counter-intuitive on almost every level. I have attempted to give myself an understand of the platform already. So far after all this time I understand a total to two things about Git:
  1. It looks like what they drew in that episode of The Flash when they tried to explain time remnants.
  2. I understand noting about Git.


Now I am well aware that I am not a programmer but I have enjoyed being involved in Free Orion. That is in fact after hitting a brick wall I dropped my efforts to re-work the tech tree, because I knew that I was not going to be able to do it myself and would have to be sending everything through someone else, and unable to test things out for myself, and that's a lot more work than anything else I've contributed. So far one of the better things about Free Orion is the responsiveness of the people creating the game. I would love to be more directly involved, but that seems to be beyond my abilities.

I specifically said that having to go through Git for everything would be an obstacle. Now if you are offer to help in some capacity that is appreciated, but otherwise you should listen to people's concerns over things. Shutting someone down as soon as they tell you something is a problem is not a good way to collaborate.
All of my contributions should be considered released under creative commons attribution share-alike license, CC-BY-SA 3.0 for use in, by and with the Free Orion project.

User avatar
adrian_broher
Programmer
Posts: 1155
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Policy regarding license statements

#33 Post by adrian_broher »

labgnome wrote:Dude.

I was thinking of going at all your various points. But honestly I really just have to say that a lot of what you say is kind of inappropriate. [...] Shutting someone down as soon as they tell you something is a problem is not a good way to collaborate.
I wasn't my intention to belittle you. I'm sorry when this impression was given. I rather wanted to point out that the tools and platforms used before switching to Git and GitHub were way more counter-intuitive and contributor hostile and that you should really try to contribute directly because it is really easier nowadays, even for somebody who is not a long time software developer/engineer.
labgnome wrote:Now if you are offer to help in some capacity that is appreciated, but otherwise you should listen to people's concerns over things.
When you're saying that you don't understand Git this can mean a lot of things. Do you don't grasp the concept of Git or our project workflow? Are the tools you found so far too hard to use? Are the tutorials knee deep in the command line?

For the general concept of a VCS/Git I would consider those two videos easy understandable:

This explains the general need for a VCS: https://www.youtube.com/watch?v=8oRjP8yj2Wo
This explains how distributed collaboration works and what problems may occur during collaboration and how Git can help handling those issues: https://www.youtube.com/watch?v=uhtzxPU7Bz0

For the tool I would suggest that you use GitHub for Desktop Git Client, which is, from the looks of it, a really simplified client for the GitHub hosting service, where we store out Git repository on. The text editor you use to edit the files is up to your personal preference unless you also want a recommendation here too.

To setup a GitHub account, obtain GitHub for Desktop and get a general feel for how to use it you should watch this tutorial series:

How to create an GitHub account: https://www.youtube.com/watch?v=XBzUqQbHHhw
How to obtain GitHub for Desktop and its basic usage: https://www.youtube.com/watch?v=ci3W1T88mzw

For interaction with the upstream project and providing pull requests I still need to review some video because none of those I reviewed so far was convincing novice documentation.

If there are questions feel free to ask.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 5417
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Policy regarding license statements

#34 Post by Vezzra »

Geoff the Medio wrote:
Vezzra wrote:Seems pretty straightforward and simple to me. Although I wonder if the sign-off really has any legal relevance, at least it allows for the simple check, so why not?
Because it's needless noise in the commit logs and wasted time for everyone involved in making a pull request.
Considering the sign-off just requires a simple flag on the command line, or nothing more that checking a check box when using a GUI git client, which adds nothing more than a "signed-off by XYZ" line to the commit, I wouldn't exactly call that "needless noise" and "wasted time".

Of course, if there isn't any benefit/use at all, it's pointless to do it, even if it is as simple as that.

User avatar
Vezzra
Release Manager, Design
Posts: 5417
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Policy regarding license statements

#35 Post by Vezzra »

Dilvish wrote:Surely you don't consider the Linux Kernel code itself to be pure perfection, never possible to improve, so why would you expect their legal practices to be perfect and unimprovable?
To be fair, that's not what he claimed. He merely pointed out that the Linux project has seen much more legal action than we, and it's therefore safe to assume that whatever they have come up with regarding CLAs/DCOs/whatever license policies is, while most likely not perfect, still sound and proven.

Anyway, I don't think this is about doing things better than them, but having to adjust what they come up with to our needs, which are probably quite different.
I disagree about us needing to institute the git signoff process. As the the documentation for git signoff itself notes, "The meaning of a signoff depends on the project..." i.e., you have to have a clear statement of what you intend the signoff to mean, or it is meaningless.
Yeah, sure, but nothing prevents us from doing so (add a clear statement at a proper place what the sign-off is supposed to mean when contributing to FO).
For a project like the Linux Kernel which actually defends itself in litigation, the very tiny little bit of extra proof/notice that the signoff statement provides (about the contributor having notice the actu of submitting and/or providing signoff may be intended to signify agreement to some set of terms) may very well be worth the hassle-cost. [...] Please also keep in mind that since for projects like the Linux Kernel their contributions are much more likely needing to come from highly skilled programmers compared to the broad range of skill levels that helpful FO contributors can have, the barrier for them is likely much lower than it would be for many of our contributors. So it's worth more to them and costs them less.
I certainly don't want to introduce something convoluted and complicated which has just a very minor benefit. But we're talking about signing off commits here - that's a very easy and trivial thing to do. Something anyone who is capable of posting on a forum, or putting together even the simplest contribution, should have no trouble to do...?

Unless it's really completely pointless. Then sure, why bother?
Their actual justification for the signoff requirement in that document linked above focuses almost entirely just on some sort of project organizational tracking value.
Which is similar to the main practical use I see with requiring a sign-off. It confirms the contributor has read our license statemets/DCO/whatever and agreed to it. And we can check for that sign off, and prevent merging a PR that lacks it, or at least give some warning.
So, like Geoff, I see no reason for us to require git --signoff (but I do think we need to augment our project documents to make these submission terms more clear).
Don't get me wrong, I don't think that we absolutely need this sign-off thing. I just thought it to be a nice idea. If Geoff and you don't want to do this, and are sure that augmenting README.md and CONTRIBUTING.md properly is sufficient, I'm perfectly fine with that.

What I still do think is necessary is requiring contributions to be done by PR, and not just by forum posts, which would require extra license statements on the forum (in case fo contributors who want to provide their contributions only there). Because I have my doubts when it comes to the "legal sufficiency" (can you say it that way, or what would be the proper term?) of all those license statements scattered and buried deep in ancient, long forgotten threads.

o01eg
Programmer
Posts: 940
Joined: Sat Dec 10, 2011 5:46 am

Re: Policy regarding license statements

#36 Post by o01eg »

Vezzra wrote:Considering the sign-off just requires a simple flag on the command line, or nothing more that checking a check box when using a GUI git client, which adds nothing more than a "signed-off by XYZ" line to the commit, I wouldn't exactly call that "needless noise" and "wasted time".
Doesn't it also require to create PGP key and publish it on github?
Gentoo Linux x64, gcc-9.3, boost-1.72.0
Ubuntu Server 18.04 x64, gcc-7.4, boost-1.65.1
Welcome to the slow multiplayer game at freeorion-lt.dedyn.io.Version 0.4.10.1.
Donations are welcome: BTC:14XLekD9ifwqLtZX4iteepvbLQNYVG87zK

User avatar
Vezzra
Release Manager, Design
Posts: 5417
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Policy regarding license statements

#37 Post by Vezzra »

o01eg wrote:Doesn't it also require to create PGP key and publish it on github?
No, signing a commit (which requires a PGP key) and signing off a commit (which just requires specifying the sign-off option) are two different things.

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: Policy regarding license statements

#38 Post by LGM-Doyle »

I am not a lawyer, but I suggest if we are changing the legal requirements for contributing to the project that we pay a lawyer.

Legal English is as different from common English and technically precise as programming languages are.

That being said, I agree with Geoff, agreement with the GPL is implicit by anyone pulling the code and making changes. Making a pull request does not change the fact that the contributor has already agreed that their changes are governed by the GPL. Adding an additional barrier to contribution, that a lawyer has not said is required, is more likely to cause future legal issues or uncertainty than not.

Post Reply