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
Vezzra
Release Manager, Design
Posts: 5002
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Policy regarding license statements

#16 Post by Vezzra » Thu Mar 22, 2018 1:39 pm

Geoff the Medio wrote:
Vezzra wrote:One way would be to require all contributions to be made via PR. Would that be a problem?
It makes the barrier for entry for art contributions higher than necessary.
Would that really be that much of an issue? Considering we already require artists to provide PRs for our assets repo which have to include proper license statements.
That's the standard name for such files, or such was my impression. eg. Wesnoth has one: https://github.com/wesnoth/wesnoth/blob/master/COPYING and FreeCiv has one: https://github.com/freeciv/freeciv/blob/master/COPYING It's also suggested here: https://www.gnu.org/licenses/gpl-howto.en.html
Oh, ok. So there are different recommendations apparently.

Still, for the changes Dilvish proposes naming the file LICENSE might make more sense (IMO). COPYING makes sense for what Dilvish refers as "outbound" licensing I guess, but for a file that covers "outbound" and "inbound" LICENSE sounds more fitting?

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

Re: Policy regarding license statements

#17 Post by Vezzra » Thu Mar 22, 2018 1:43 pm

Dilvish wrote:I am confident I can propose some augmented language for our README and CONTRIBUTING docs that you would not object to.
Well, the license stuff would go into LICENSE, right? As far as I'm concerned, put it on your todo list. :D

User avatar
labgnome
Vacuum Dragon
Posts: 579
Joined: Mon Mar 02, 2015 5:57 pm

Re: Policy regarding license statements

#18 Post by labgnome » Fri Mar 23, 2018 11:40 pm

Vezzra wrote:Would that really be that much of an issue? Considering we already require artists to provide PRs for our assets repo which have to include proper license statements.
I mean I still don't understand github, and I have met a number of other people in a similar boat, who have basically had to leave projects that migrated to github. The reason that none of the stuff I've brought to the forums has made it to github is because I can't. It's why I (and I'm sorry for it) dropped the big tech-tree revision I wanted to take on. I could still do the work, but I'd have no way to contribute it so it just feels pointless.
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: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Policy regarding license statements

#19 Post by adrian_broher » Sat Mar 24, 2018 2:06 pm

labgnome wrote:I mean I still don't understand github, and I have met a number of other people in a similar boat, who have basically had to leave projects that migrated to github. The reason that none of the stuff I've brought to the forums has made it to github is because I can't. It's why I (and I'm sorry for it) dropped the big tech-tree revision I wanted to take on. I could still do the work, but I'd have no way to contribute it so it just feels pointless.
Sorry, but you really underestimate how easy contributions nowadays are. Comparing the previous used platforms and tools (Sourceforge, Subversion and CVS) with today ones (GitHub and git) it is dead easy to contribute by just looking at the adoption of the tools provided by contributors and core developers alike (Can't remember that pull requests were even a thing on Sourceforge and issue were hardly used at all, let alone having a CI).

I can assure you that you don't need to know how git is operated on the cli to contribute because all the basic functionality used in our workflow is accessible via the GitHub user interface, which is not that different to a regular bulletin board (which you obviously can operate on).

Also consider that every contribution that was done so far by you needed to be proxied through a core developer (according to the Git log Mat did this), which burns away the time of said developer by doing mundane tasks that he could work on more useful tasks. Non-professional open source projects are usually only limited by the skill of the contributors and the time they can invest. When you chip that time off it also somewhat hurts the project.

When you still face issue feel free to ask in the appropriate thread/forum as someone will certainly know the answer or know a proper resource to learn from.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12456
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Policy regarding license statements

#20 Post by Geoff the Medio » Sat Mar 24, 2018 2:33 pm

adrian_broher wrote:I can assure you that you don't need to know how git is operated on the cli to contribute because all the basic functionality used in our workflow is accessible via the GitHub user interface, which is not that different to a regular bulletin board (which you obviously can operate on).
[...]
When you still face issue feel free to ask in the appropriate thread/forum as someone will certainly know the answer or know a proper resource to learn from.
Is there a "tutorial for using github for non-programmers" or similar thread? I vaguely recall seeing one, but can't find it.

I ask because I can't figure out how to upload an image file and make a pull request on the github interface as easily as your post suggests. If, on a project I don't have push rights for, I click the "Create new file" or "Upload file" buttons, it takes me to a text entry box or an error message, respectively. If I figure out how to make a branch of a repository, then I can pick a file to upload, but if I give it a .png file, it gives an error message. It's also not at all clear how to put a file in a particular location.

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

Re: Policy regarding license statements

#21 Post by adrian_broher » Sat Mar 24, 2018 3:10 pm

Vezzra wrote:How exactly do you think this should work? Do you mean that each and every commit message should include a DCO? If not, that only leaves including the DCO in one of the commits someone contributes to the repo, which would scatter the DCOs across the thousands of commits in our repo. While still a vast improvement to our current policy (IMO), both options don't sound very appealing.

My suggestion would be to create a folder "license statements" (or something like that), and have every contributer commit a text file containing their DCO to that folder (ideally these commits would be signed, but I'm aware that only a minority actually GPG signs their commits). Is that similar to what you had in mind?

Or something else entirely?
I further researched this and the Linux Kernel developers handle it the following way. Inside the submitting-patches.rs guideline the DCO text is noted verbatim (this file is roughly the equivalent to our CONTRIBUTE.md). When contributing patches via $SOME_MECHANISM the contributor needs to sign of all of their commits by appending their author signature to the end of the commit message like

Code: Select all

Do a foo

This commits introduced the new do_a_foo function.

Signed-off-by: John Doe <jdoe@example.net>
Which can also be done by calling git commit with the -s parameter.

This explicit action indicates that the contributor at least understood the CONTRIBUTE.md and DCO and agreed to the terms of both.

On our side a CI build stage could check for us if the author of the commit matches the Signed-off-by statement in the commit message and block a pull request for merge. Which is the point of the clahub, which o0leg linked.
Dilvish wrote:I expect this DCO is probably referred to elsewhere in their license or submission documents, and that reference point would actually be the core legal basis for their position. Requiring people to reference the DCO at least creates a record that the person is specifically on notice that there is probably a license file someplace, "the file", which someone might hold them accountable to at some point, plus it contains these statements about the source of the specific contribution, which is a critical underpinning to the project's overall licensing position.
That would be the submitting-patches.rs mentioned above.
Dilvish wrote:I have a suitable background for the task, if we decide to take that path. If anyone else does also, please speak up.
I don't want to diminish your competences in any way, but 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 (that are somewhat battle proven in terms of fighting of legal issue with various third parties)? Skimming the article you posted suggest to me that either the DCO or relying on implicit agreement by pointing out at many place as possible that everything is licensed under the terms of X. I consider the explicit Agreement with DCO and sign-off more suitable IMO.
Dilvish wrote:Also, is there some particular reason our COPYING file is not instead named LICENSE? Particularly given that we want it to have significance as an inbound license as well as outbound, and to more clearly fit with the DCO, I think it would be better named LICENSE.
It's commonplace to place GPL derived licenses under this file name since... the existence of the the GPL I guess?
Vezzra wrote:I also wonder why it resides in the "default" folder instead of the root directory (where it should be IMO
Because code. The About.cpp accesses that file as resource and would break the development build when moving it to the root dir. But that should be fixable in the deployment scripts.
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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: Policy regarding license statements

#22 Post by adrian_broher » Sat Mar 24, 2018 3:16 pm

Geoff the Medio wrote:Is there a "tutorial for using github for non-programmers" or similar thread? I vaguely recall seeing one, but can't find it.
Pinned right at the top of the Programming forum but it's more a Q&A style not a tutorial per-se: http://www.freeorion.org/forum/viewtopic.php?f=9&t=9366
Geoff the Medio wrote:I ask because I can't figure out how to upload an image file and make a pull request on the github interface as easily as your post suggests. If, on a project I don't have push rights for, I click the "Create new file" or "Upload file" buttons, it takes me to a text entry box or an error message, respectively. If I figure out how to make a branch of a repository, then I can pick a file to upload, but if I give it a .png file, it gives an error message. It's also not at all clear how to put a file in a particular location.
You've got me there. I didn't realize that we also have binary assets to handle. Sorry, I need to investigate that first before I can answer that.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: Policy regarding license statements

#23 Post by adrian_broher » Sat Mar 24, 2018 3:39 pm

Geoff the Medio wrote:I ask because I can't figure out how to upload an image file and make a pull request on the github interface as easily as your post suggests. If, on a project I don't have push rights for, I click the "Create new file" or "Upload file" buttons, it takes me to a text entry box or an error message, respectively. If I figure out how to make a branch of a repository, then I can pick a file to upload, but if I give it a .png file, it gives an error message. It's also not at all clear how to put a file in a particular location.
See https://github.com/freeorion/freeorion/pull/2062 . You create a fork of the freeorion/freeorion repository under your github user, create a branch and navigate the repository tree. Then you upload or create files at your heart contents, create commits and finally create a PR against the freeorion/freeorion repository.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12456
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Policy regarding license statements

#24 Post by Geoff the Medio » Sat Mar 24, 2018 4:50 pm

adrian_broher wrote:Pinned right at the top of the Programming forum but it's more a Q&A style not a tutorial per-se: http://www.freeorion.org/forum/viewtopic.php?f=9&t=9366
I found that immediately, but I specifically wanted a tutorial, preferably with pictures / screenshots, as it's not reasonable to expect everyone to read through a big thread to see if their use case is handled, then post and have to wait. I also vaguely recalled there being some more tutorial-like post at some point...
adrian_broher wrote:See https://github.com/freeorion/freeorion/pull/2062 . You create a fork of the freeorion/freeorion repository under your github user, create a branch and navigate the repository tree. Then you upload or create files at your heart contents, create commits and finally create a PR against the freeorion/freeorion repository.
I know you know how to do it or could easily figure it out, but many people don't or can't. Even to just make a fork, there's no obvious button to do that, and the Create new file button that does do it is rather confusing, particularly in the case one wants to upload an image. And that assumes someone knows they need to make a fork or what a fork even is, which will not be the case in general for art contributors.

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

Re: Policy regarding license statements

#25 Post by adrian_broher » Sat Mar 24, 2018 5:01 pm

Geoff the Medio wrote:I found that immediately, but I specifically wanted a tutorial, preferably with pictures / screenshots
Then I don't know of any thread. But regarding a tutorial this seems promising: https://tvanantwerp.gitbooks.io/github- ... s/content/ .
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12456
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Policy regarding license statements

#26 Post by Geoff the Medio » Sat Mar 24, 2018 5:07 pm

adrian_broher wrote:But regarding a tutorial this seems promising: https://tvanantwerp.gitbooks.io/github- ... s/content/ .
Not really what I had in mind. Something much less wordy, immediately illustrated, specific and focused on the goal of making an image pull request with the web interface, and not so slow-to-load would be much more useful.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Policy regarding license statements

#27 Post by Dilvish » Sat Mar 24, 2018 9:42 pm

Geoff the Medio wrote:Something much less wordy, immediately illustrated, specific and focused on the goal of making an image pull request with the web interface,
Right, I can see for that particular purpose it would be good to keep looking for a better tutorial. But as a general tutorial for perhaps non-coder new scripting contributors this might still be a pretty helpful reference.
and not so slow-to-load would be much more useful.
Perhaps their server or your ISP just had a hiccup when you visited, I tried it just now and the pages & images seemed to load up just fine.
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
Vezzra
Release Manager, Design
Posts: 5002
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Policy regarding license statements

#28 Post by Vezzra » Sun Mar 25, 2018 2:12 pm

adrian_broher wrote:Comparing the previous used platforms and tools (Sourceforge, Subversion and CVS) with today ones (GitHub and git) it is dead easy to contribute by just looking at the adoption of the tools provided by contributors and core developers alike (Can't remember that pull requests were even a thing on Sourceforge and issue were hardly used at all, let alone having a CI).
No, there has been no such thing as PRs on Sourceforge using SVN. We had an issue tracker, but that hasn't been used very much. Practically everything happened on the forum - issues, feature requests, contributions, patches etc. Which had to be handled by devs with commit access, which is why moving to git/github was a really big step forward. That certainly reduced the workload for devs with commit access a lot.

However, it's also exactly the reason why for some contributors things got a bit more challenging. Before, they could just upload their patch/contribution to the forum, and one of the devs with commit access would handle the rest from there. Dead easy for the contributor, but a lot of work for the core devs. The switch to git/github shifted that workload toward the contributors, who now are able to handle a lot more of the stuff needed to provide their contributions. An enormous improvement for the project as a whole, as the workload now can be distributed much more efficiently. However, for contributors who maybe can upload stuff to a forum, but feel themselves out of their depths when confronted with github, things apparently became much more difficult.
I can assure you that you don't need to know how git is operated on the cli to contribute because all the basic functionality used in our workflow is accessible via the GitHub user interface, which is not that different to a regular bulletin board (which you obviously can operate on).
Well, maybe you don't need to learn to use git on the command line, but you'll probably won't be able to avoid using git in one way or the other completely. E.g. you need to keep master in your clone current with master in upstream, and I haven't found an obvious way to do that just using the github web interface, without using a git client and a local clone.

If we want enable those contributors, who have difficulties using git/github, to provide their contributions, we definitely need some kind of easy, not too extensive tutorial explaining the most basic concepts and workflows.

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

Re: Policy regarding license statements

#29 Post by Vezzra » Sun Mar 25, 2018 4:38 pm

adrian_broher wrote:I further researched this and the Linux Kernel developers handle it the following way. Inside the submitting-patches.rs guideline the DCO text is noted verbatim (this file is roughly the equivalent to our CONTRIBUTE.md). When contributing patches via $SOME_MECHANISM the contributor needs to sign of all of their commits by appending their author signature to the end of the commit message like

Code: Select all

Do a foo

This commits introduced the new do_a_foo function.

Signed-off-by: John Doe <jdoe@example.net>
Which can also be done by calling git commit with the -s parameter.

This explicit action indicates that the contributor at least understood the CONTRIBUTE.md and DCO and agreed to the terms of both.

On our side a CI build stage could check for us if the author of the commit matches the Signed-off-by statement in the commit message and block a pull request for merge. Which is the point of the clahub, which o0leg linked.
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.

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?
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 (that are somewhat battle proven in terms of fighting of legal issue with various third parties)?
As far as I understand, it's not so much a question of doing it better, but to adjust the DCO to our specific needs/licensing. AFAIK the Linux kernel is simply GPL licensed, FO OTOH has two licenses applied to different parts of the project. C++ code is GPL, artwork, text etc. is CC BY-SA 3.0, and content scripts are both. I'd expect that this needs to be reflected in a DCO somehow...?
Vezzra wrote:I also wonder why it resides in the "default" folder instead of the root directory (where it should be IMO
Because code. The About.cpp accesses that file as resource and would break the development build when moving it to the root dir. But that should be fixable in the deployment scripts.
Ah yes. Good point. However, I still think a file containing the license statements for the entire project should reside in the project root, so I propose to make the necessary changes to the code and move that file.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12456
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Policy regarding license statements

#30 Post by Geoff the Medio » Sun Mar 25, 2018 5:22 pm

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. If there is to be anything more formalized, which I still don't think is needed, it can be done once per committer, and certainly not for "all of their commits".

Post Reply