FreeOrion

Forums for the FreeOrion project
It is currently Thu May 24, 2018 6:27 am

All times are UTC




Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Fri Mar 16, 2018 12:05 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
In the comment section of PR#2049 a discussion sprung up about our handling of license statements. Being about something which must be considered project policy, that discussion should take place here on the forum, so I opened this thread to continue it here.

The exchange so far:

Dilvish wrote:
@geoffthemedio looking through the README and CONTIRBUTING.md I see references to FO source being licensed under GPLv2, but I am not seeing anything explicitly akin to our old requirement for new contributors to explicitly state that their contributions are so licensed. Are we just leaving it implicit now?

adrian_broher wrote:
Dilvish wrote:
Are we just leaving it implicit now?

No, the contributor must state that he releases his contributions under the terms of the project. The placement where and how to state this is AFAIK dubious. I'm sure there were explicit forum posts for that but I can't find them. @Vezzra ping

Also this is maybe a good point to introduce a formal Developer Certificate of Origin (DCO)?

Geoff the Medio wrote:
@adrianbroher could you clarify what that means?

adrian_broher wrote:
@geoffthemedio
The DCO? It's a statement that needs to be posted by a contributor before accepting the contribution to a project. The Linux Foundation formalized this:

https://developercertificate.org/

Probably the best idea would be to insert this into a commit message so this can't be tampered by deleting a forum or issue comment.


Top
 Profile  
 
PostPosted: Fri Mar 16, 2018 12:39 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
Dilvish wrote:
@geoffthemedio looking through the README and CONTIRBUTING.md I see references to FO source being licensed under GPLv2, but I am not seeing anything explicitly akin to our old requirement for new contributors to explicitly state that their contributions are so licensed. Are we just leaving it implicit now?
When LGM-Doyle joined the project and began contributing, Geoff and I had a brief discussion about his license statement (see here):
Geoff the Medio wrote:
I figured it was OK to assume that FreeOrion repository code pull requests on github were GPL 2.0 licensed. I insisted on such a statement on the forums as it was not directly clear there under what license the code provided was expected to be released...
Vezzra wrote:
Oh, ok, didn't know that... are you sure? I mean, I thought that we'd at least had to have some statements like "If you make pull requests for our repo you agree to release your contribution under the licenses in use by the project" in the README.md or a similar prominent location.

Can we safely assume implicit agreement to our licenses without such a statement anywhere? Not that I really have any idea what I'm talking about, all that law stuff is beyond me...
Geoff the Medio wrote:
Not sure, no. But in this case, the request also modifies existing code, which was GPL licensed, and republishes it in a new repository on GitHub,

https://github.com/LGM-Doyle/freeorion/

The only way he could do this is by releasing it under compatible license(s). Also, that page has the same license statement from the Readme.md file, which indicates the code is GPL 2.0.
Vezzra wrote:
Ah yes, you're right of course, didn't think of that. Working with a clone of our repo means copying the license statements, so I guess we can safely assume such contributions to be released under the same licenses.
Geoffs reasoning here makes sense to me: if someone clones our repo on github, creates a branch there and uses that for a PR to our repo, they can't really do that without making the required license statements implicitly. I'm no laywer of course, so I can be dead wrong about this.

That said, I have to admit I like Marcels suggestion of using DCOs. When it comes to the legal stuff, relying on what makes sense to me as a someone who has no clue at all about said legal stuff probably isn't the best course of action. The law and common sense, well, tend to be very different things... ;)


Top
 Profile  
 
PostPosted: Fri Mar 16, 2018 12:50 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
adrian_broher wrote:
The placement where and how to state this is AFAIK dubious. I'm sure there were explicit forum posts for that but I can't find them. @Vezzra [i]ping[/i
I have to admit I can't tell you much more than you already know. When I joined the project, the practice has already been what it is now: once you start contributing, someone of the core devs asks for a proper license statement on the forum. There has been a small adjustment later (AFAICT), where the recommendation came up to put the license statement into your sig.

But I don't know about any forum threads/posts or wiki pages with a formal description/definition how license statements are to be handled. Maybe Geoff knows more about something like that?
Quote:
Also this is maybe a good point to introduce a formal Developer Certificate of Origin (DCO)?
As I said in my post above, I think that's a good idea. If we can agree on this and decide to make it project policy, we should also try to get such DCOs from as many of our past contributers as possible.


Top
 Profile  
 
PostPosted: Fri Mar 16, 2018 1:12 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
adrian_broher wrote:
The DCO? It's a statement that needs to be posted by a contributor before accepting the contribution to a project. The Linux Foundation formalized this:

https://developercertificate.org/
Interesting. I guess we'd have to create our own DCO, but if we do, it would probably make sense to make sure it's actually legally sound and watertight (as that example seems to be). However, I wonder who we could task with drafting such a document?
Quote:
Probably the best idea would be to insert this into a commit message so this can't be tampered by deleting a forum or issue comment.
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?


Top
 Profile  
 
PostPosted: Fri Mar 16, 2018 4:06 pm 
Offline
Space Kraken

Joined: Sat Dec 10, 2011 5:46 am
Posts: 107
Did you try to use https://www.clahub.com/ ?

_________________
Gentoo Linux amd64, gcc-6.4.0, boost-1.65.0
Ubuntu Server 18.04.0 x64, gcc-7.3, boost-1.65.1
Welcome to multiplayer public server at freeorion-test.dedyn.io. Version 2018-05-22.2e3c6f4
Donates are welcome: BTC: 14XLekD9ifwqLtZX4iteepvbLQNYVG87zK


Top
 Profile  
 
PostPosted: Fri Mar 16, 2018 4:37 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4606
Vezzra wrote:
but if we do, it would probably make sense to make sure it's actually legally sound and watertight (as that example seems to be).
Although it may look a bit imposing, it seems far from watertight to me. There appear to me to be two main points to the DCO, authorship of the submission and the license granted for it. The barn door of paragraph (b) regarding authorship they probably intentionally accepted as essentially unavoidable for an open source project, but something that looks just plain sloppy to me is these repeated dangling references to "the file"
Quote:
submit it under the open source license indicated in the file
And just which "the file" might that be? The Open Source Wallpaper License File I keep in my back pocket, which says you can display my unmodified contribution on computer screens and print and hang it as wallpaper, but if you modify it or translate it to object code you owe me royalties? I can imagine that at some stage of drafting they had a reference to a specific license file in the project, but at least under Anglo-American jurisprudence ambiguities are resolved against the drafter, so that leaves some shaky ground if relying on this DCO by itself. 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.

Looking into these matters a bit more, it appears to me that this "the license" ambiguity probably arose (still a bit carelessly I think) from them trying to generalize the statement for broader use by the open source community-- although not apparent in the version found at that dedicated URL, the DCO itself is apparently licensed for general use under the Creative Commons Attribution-ShareAlike 2.5 License.

Quote:
However, I wonder who we could task with drafting such a document?
I have a suitable background for the task, if we decide to take that path. If anyone else does also, please speak up.

I think a very helpful discussion of the practical and legal issues has been written up by the Software Freedom Conservancy. I would encourage all project leaders, and anyone else interested, to read through that before we proceed much farther with this discussion. My initial take after a first-pass read is that it is well-reasoned. I will also continue thinking about the matter and reading up a bit more as well.

o01eg wrote:
Did you try to use https://www.clahub.com/ ?
Thanks for that link, that certainly looks like a relatively straightforward path to handling CLA's. Note that their own docs do also mention some international legal privacy complications; even though the site looks very friendly it is not a no-brainer to use them.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Sat Mar 17, 2018 3:09 am 
Offline
Space Floater

Joined: Sat Jul 01, 2017 4:54 am
Posts: 32
Dilvish wrote:
I think a very helpful discussion of the practical and legal issues has been written up by the Software Freedom Conservancy. I would encourage all project leaders, and anyone else interested, to read through that before we proceed much farther with this discussion. My initial take after a first-pass read is that it is well-reasoned.

do-not-need-cla of Software Freedom Conservancy wrote:
However, most Conservancy projects use the same time-honored and successful mechanism used throughout the 35 year history of the Free Software community. Simply, they publish clearly in their developer documentation and/or other key places (such as mailing list subscription notices) that submissions using the normal means to contribute to the project — such as patches to the mailing list or pull and merge requests — indicate the contributors' assent for inclusion of that software in the canonical version under the project's license.

Personally I think this minimal simpler approach would be best. Place notice on this forum header or footer, top faq entry, project guide lines, top level github readme. Just cover: What would a reasonable person believe would happen when they submit code?


Top
 Profile  
 
PostPosted: Sat Mar 17, 2018 8:10 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12188
Location: Munich
Vezzra wrote:
When I joined the project, the practice has already been what it is now: once you start contributing, someone of the core devs asks for a proper license statement on the forum. There has been a small adjustment later (AFAICT), where the recommendation came up to put the license statement into your sig.
I'm not aware of that recommendation, and consider it unnecessary and awkward, in that it just fills the forum with pointless repeated text after every post the user makes.

Historically, all patch and art contributions by non-committers were submitted on the forums. To make it clear that the submitter was aware of and agreed to the applicable licenses, We would ask for a statement that they released their contributions under the GPL 2.0 or later or the CC-BY-SA 3.0.

On github, there is a clear license statement on the main repository page, and as mentioned elsewhere, almost any code contribution requires modifying the existing code and releasing the changes. Thus, I think that any such changes can be assumed to be released under a license at least as permissive as the license of the code that was modified. That doesn't really apply for art or other creative contributions, though, and I still prefer to ask new contributors for such a statement on their first pull request or perhaps on the forums, to be sure they are aware and agree to the relevant license.

(I do make an exception for very small changes, like typos or a one-or-two like code change that, in my opinion, are too small to be copyrightable, in which case I could accept without a clear statement of licensing.)

Quote:
But I don't know about any forum threads/posts or wiki pages with a formal description/definition how license statements are to be handled. Maybe Geoff knows more about something like that?
There isn't one that I'm aware of, unless the previous few paragraphs counts.

Quote:
Quote:
Also this is maybe a good point to introduce a formal Developer Certificate of Origin (DCO)?
As I said in my post above, I think that's a good idea. If we can agree on this and decide to make it project policy, we should also try to get such DCOs from as many of our past contributers as possible.
I think this overly formalizes something that doesn't need to be so bureaucratic.


Top
 Profile  
 
PostPosted: Sat Mar 17, 2018 4:44 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4606
After ready up on this a bit more now, I'd say agree at least mostly with what Geoff just said, but I would propose we improve the licensing somewhat. The biggest exception, or perhaps it's simply an uncertainty about what you meant, is about artwork-- it seems to me that submissions through GitHub should not need to be treated differently based on whether they are artwork or not (our licensing statements simply need to be broad enough to cover both artwork and code), and either type of submission via the forums needs a licensing statement.

I would say that our README.md should be modified to essentially incorporate the DCO, or equivalent terms (and although we all eschew redundancy, that section should probably be repeated in CONTRIBUTING.md).

Regarding the increasingly popular practice of requiring commit statements include a signoff, which is supposed to represent acknowledgement of and agreement to the DCO, I strongly agree with those commentators who say that such is so barely better than nothing that it is not worth bothering with. Requiring people to actually include the DCO URL in their commit statement would actually be pretty strong, but this whole "'signoff' is code for 'agree to the DCO'" is a bit ridculous-- to have any chance to making that stick you have to establish knowledge or at least notice which themselves would allow for *pretty much* just as strong of an argument as without the signoff.

Our current project documents are all focused on the outbound licensing terms. While we could argue that implies the inbound license for all submissions can be assumed to be commensurate, that would be a pointlessly weak position for us to leave ourselves in. We should at least augment README.md with a reference to the DCO (or have a DCO subsection), prefaced by a clarification that for our project the license file referenced by the DCO is the file named COPYING, pull requests or other submissions are not allowed without agreement to the DCO, and that the act of making such a submission is deemed agreement to the DCO and to licensing the submission under the license file. (The DCO at least sort of contains this last license grant bit in its last sentence, but that sentence also appears somewhat specific to redistribution rather than the full set of copyright rights, and so I think we should have this extra explicit license statement.)

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.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 1:23 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
o01eg wrote:
Did you try to use https://www.clahub.com/ ?
No, never heard about that. Certainly looks intriguing, especially the feature where you can see immediately with each PR if the contributor has already signed a CLA. Very helpful when it comes to not forget about asking new contributors for their license statements.

However, when it comes to legal stuff I'm reluctant to use a solution where you need to rely on an external service, especially one that depends on volunteers to keep it going. That service might go down, or we might at some point in the (distant) future decide to migrate to another VCS/VCS hoster (like we migrated from SVN/sourceforge to git/github), or whatever.

If we decide to work with DCOs/CLAs in the future, IMO it needs to be a simple system that works without any dependencies (other that the repo itself of course), so plain text with proper license statements/DCOs/CLAs/whatever stored in the repo (as text files, in commit messages, whatever) is the way to go.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 2:56 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
Dilvish wrote:
Although it may look a bit imposing, it seems far from watertight to me.
As I said, I'm not a lawyer. I probably know as much about all the legal stuff as my mother does about programming... ;) Not the point anyway. What I wanted to say is, if we are going to do such a thing (CLAs/DCOs/whatever), we should do it properly (whatever "properly" turns out to be in the end), otherwise it's just a big waste of time.
Quote:
The barn door of paragraph (b) regarding authorship they probably intentionally accepted as essentially unavoidable for an open source project, but something that looks just plain sloppy to me is these repeated dangling references to "the file"
Well, like you surmised, I guess that DCO might have to be used within a proper context or maybe it's just a template where you need to replace "the file" with something more specific.

If we want to go down that road, we need to come up with something suitable for FO anyway. And according to the article you linked, apparently we don't need to come up with some complicated, water-tight legal statements covering pages, so something simple and straightforward would probably be sufficient.
Quote:
Quote:
However, I wonder who we could task with drafting such a document?
I have a suitable background for the task, if we decide to take that path.
Excellent. :D Should we actually need it, consider yourself appointed. :mrgreen:
Quote:
I think a very helpful discussion of the practical and legal issues has been written up by the Software Freedom Conservancy. I would encourage all project leaders, and anyone else interested, to read through that before we proceed much farther with this discussion. My initial take after a first-pass read is that it is well-reasoned.
Interesting read, sounds pretty reasonable to me too (which probably doesn't mean much in my case, because, you know, no lawyer, see above ;)).

The main point of the article seems to be about not to go overboard with the CLA though, but to keep things as simple as possible, to avoid bogging down an open source project with needless legal stuff. Although I still think it might be reasonable at least to ask for a statement where the contributor confirms that their contribution meets the requirements of the licenses in use by the project, and didn't knowingly infringe any copyrights/patents/whatever - if that really isn't necessary, then just leave that out.

It was only after reading that DCO apparently used by Linux that I got the idea of including such statements. The reason why I like Marcels suggestion is that I've been thinking about something similar myself already. The problem (if you can call it a problem) is, currently the license statements of our contributors are kind of scattered. Before we migrated to git and github, every new contributor had been asked for their license statement (unless the contribution had been so minor that this had been deemed unnecessary), usually directly in the thread where they posted their first contribution(s). Which means, all those license statements are scattered over countless thread, covering more than a decade by now.

With the migration to git/github the situation actually got worse (IMO). Because now, if someone starts contributing by providing PRs, we can (apparently safely) assume that by doing so they implicitely release their contribution under the applicable project licenses. Their "license statement" is given by providing the PR, so to speak. Unless they provide their contribution on the forum, then we still need to ask for a license statement.

Now add to that the possibility that someone who has already been contributing code for a while (which is GPL2 and later licensed), suddenly makes an art contribution on the forum (which is CC BY-SA 3.0 licensed). In this case we'd have to ask for their license statement for their art contributions at that point, which could easily be overseen because that person has been around for al while already.

I often wondered what we would do (or have to do) if ever the case actually came up where we'd need to defend the project against some kind of allegations (whatever that might be), and had do provide a proper license statement of a certain contributor. We'd had to determine when the person in question started contributing, so we'd know where and what kind of license statement we'd have to start looking for.

What if there has been a major forum crash in the meantime, and a big part (or all) of the forum posts up to the time of the crash have been lost (I mean, it has happened before, in the founding days of FO)?

Which is why I thought collecting those statements as plain text files, "signed" in a way be the contributor so it's reasonably clear it has actually be issued by that contributor, might be a good idea. A text file containing nothing more than a license statement as it has been given on the forums before might be sufficient, provided via PR by the contributor (so it's clear the commit containing the license statement has been authored by them), could meet these requirements.

Or provide a formal license statement convering all cases in a text file, add it to the repo, and have every commit message contain a line with a link to that file at the end (something like: "Contribution released to the project according to the license statement in this file <link to license statement file>").

Or whatever idea might be the most feasible.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 4:37 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
Geoff the Medio wrote:
I'm not aware of that recommendation, and consider it unnecessary and awkward, in that it just fills the forum with pointless repeated text after every post the user makes.
Well, we never had an "official" discussion or "official" decisions on that, it's just something a couple of people started to do, and later recommended it to others. Did you never notice that practice? Quite a number of people did/do it, just look at the sigs of Dilvish and Mat for example.
Quote:
I think this overly formalizes something that doesn't need to be so bureaucratic.
I'm not going to disagree, I mean, it definitely feels needlessly bureaucratic. However, you're arguing common sense here, and as I said before, legal stuff and common sense can be very different things. The question is, what will be sufficient if we're ever confronted with a case where the legitimacy/authenticity of a contribution gets challenged?

See the thoughts I explained in my post above. The fact that we require proper license statements (implicit or explicit) before we accept a contribution clearly shows that it's apparently important to do so (otherwise, why bother?). However, if the way we do that now turns out to actually be insufficient if confronted with the need to produce the license statement of a particular contributor, that can withstand actual legal scrunity, then what's the point of going to any trouble at all getting those license statements?

As I noted repeatedly, I'm actually quite useless when it comes to legal stuff, so my concerns probably shouldn't been taken too seriously. It's just when Marcel came up with that suggestion of DCOs, I thought I'll add my two cent. Collecting and storing all those license statements in a central place instead of having them scattered on a forum (and having explicit and implicit ones) just makes sense to me...


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 5:40 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4486
Location: Sol III
Dilvish wrote:
I would propose we improve the licensing somewhat. The biggest exception, or perhaps it's simply an uncertainty about what you meant, is about artwork-- it seems to me that submissions through GitHub should not need to be treated differently based on whether they are artwork or not (our licensing statements simply need to be broad enough to cover both artwork and code), and either type of submission via the forums needs a licensing statement.
Personally I'd prefer if we could also somehow get rid of that distinction of contribution via the forums vs contributions via PR on github.

One way would be to require all contributions to be made via PR. Would that be a problem?
Quote:
Our current project documents are all focused on the outbound licensing terms. While we could argue that implies the inbound license for all submissions can be assumed to be commensurate, that would be a pointlessly weak position for us to leave ourselves in. We should at least augment README.md with a reference to the DCO (or have a DCO subsection), prefaced by a clarification that for our project the license file referenced by the DCO is the file named COPYING, pull requests or other submissions are not allowed without agreement to the DCO, and that the act of making such a submission is deemed agreement to the DCO and to licensing the submission under the license file.
If that's actually sufficient "in the face of the law" (so to speak ;)), that sounds like a reasonable solution.
Quote:
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.
Dunno, I guess historical reasons. The COPYING file has been the license file for as long as I can remember (and that predates my active involvment in the project). I also wonder why it resides in the "default" folder instead of the root directory (where it should be IMO). IIRC having LICENSE in the root directory is the expected default, isn't it? So if we are going to rename that file, lets do things thoroughly and move it there.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 6:17 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12188
Location: Munich
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.
Quote:
Also, is there some particular reason our COPYING file is not instead named LICENSE?
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
Quote:
I also wonder why it resides in the "default" folder instead of the root directory
I think the idea was that the license for a particular content set might be different from the default content set. I don't have strong objections to moving it to the root directory, though.


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 9:53 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4606
Geoff the Medio wrote:
That's the standard name for such files, or such was my impression....It's also suggested here: https://www.gnu.org/licenses/gpl-howto.en.html

I suppose that GNU statement is the reason for a lot of that. Please note that the gnu page you linked is all focused on outbound licensing, I did not see any explicit discussion of community projects or inbound licensing. Looking into what some of those Software Freedom Conservancy projects do, I see some with License.txt, some with Copying. I agree that either can work, but particularly in the case where we want it as a reference for licensing of inbound contributions, it still seems to me it would be better named License, License.txt or something similar (but that is a relatively minor issue).


Quote:
eg. Wesnoth has one... FreeCiv has one: https://github.com/freeciv/freeciv/blob/master/COPYING
Also please note neither README.md for those projects refers to their COPYING file, the one for Wesnoth instead refers to a forum page https://wiki.wesnoth.org/Wesnoth:Copyrights which discusses their relatively complicated mishmash of both inbound and outbound licensing terms, including inviting people to place any license restrictions they choose on their contributions which Wesnoth will then decide if they can be subsumed by the GPL. The README.md for FreeCiv makes no mention of either inbound or outbound licensing, and the site where it directs people to make contributions has no such statement readily apparent to me. Those may be big well known projects but so far I see more reason to not use them as exemplars in this area than to do so.

Quote:
Thus, I think that any such changes can be assumed to be released under a license at least as permissive as the license of the code that was modified.
No-- as the GPL itself explicitly discusses (more clearly in v3 than in v2, but it's really in both), if you don't (or are, say, prevented by third party patents from) license out your published derivations under the GPL, then you lose your inbound license-- but the GPL does not itself contain an automatically executing grantback/grantforward clause for derivations. That's the whole reason that the DCO came to be, but the mere existence of the DCO is still not sufficient-- the project needs statements/policies in place that sufficiently reference the DCO (or statements serving a similar purpose).

Anyways, it sounds like you and I are in agreement on the big-picture aspect that a low-hassle approach is reasonable for us, no CLA required. I am confident I can propose some augmented language for our README and CONTRIBUTING docs that you would not object to.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group