Github Pull Requests


#1

Hi, just wondering if the statement in the Github Wiki is still true. 

I saw a few recent pull requests, so sent one as its *much* more convenient to do so than sending a patch file. It also enables discussion of proposed code changes etc. 

I understand that the public repo is only a downstream mirror of the repo you guys work on. I'd like to understand the reasoning for this setup, as I've not seen it done like this on other open source projects. 

I think it would be nice if user contributions could be merged in, even if it was to a test branch for testing and modification before being merged into the master repo. This way peoples contributions would also be recorded on their Github profile, which gives us developers a nice warm fuzzy feeling :)

 


Forum module for issues/tickets? (Suggestion)
#2

Actually yes, having pull requests is turning out to be quite a handy way for us to see people's suggestions, so we may relax the prohibitions a bit.

I think it would be nice if user contributions could be merged in, even if it was to a test branch for testing and modification before being merged into the master repo. This way peoples contributions would also be recorded on their Github profile, which gives us developers a nice warm fuzzy feeling :)

Nice warm fuzzy feeling for them, but copyright + legal problems for us! We'd need to publish a contributor's agreement for people to sign before we could allow that. But yes, it's something we may do at some point.


#3

Would it be enough to add some kind of standard permission/disclaimer text to the description of the pull request when one creates it?


#4

Github doesn't seem to give any control over things like that - it won't even let you disable pull requests.


#5

Uhm, I have just submitted a pull request and it definetely let me enter some text for description.

What I meant was that, if I had some standard text to enter there in order to grant you permission to accept the pull request without caliming copyrights later, I would definitely have added that to speed up things.

 


#6

Sorry, totally misread your post! Yes, that's a good idea - we'll need to pass it by our legal people, but were already thinking about a solution for this.


#7

Surely if someone submits a modification to any JUCE file, so long as they don't alter the license at the top that license will remain in effect.

If someone is submitting a new file, they would need to paste the license at the top.

Can anyone articulate any potential problem?

π


#8

The problem would be if someone submited a pull request, and we accepted it, so there's a public record that they wrote that bit of code, and then they decided to claim it we were infringing their copyright by selling it as part of JUCE.

Regardless of whether they'd actually win in court, it's obviously not something we want to risk happening.


#9

there's a public record that they wrote that bit of code

Well, the same is true for bits of code or patches shared here in the forum, especially for those (very few, I admit) aimed to fix very specific bugs where testing has been difficult for the JUCE team, and for which it has been decided to incorporate the supplied user patch "as is" (reasonably doing so because it didn't harm users not seeing the specific bug in question).

Or also for some trivial parts, like the one liners used to detect the plug-in host based on its executable path/name: some of them are user-provided entirely.

So, all in all, yes, it's true that an accepted pull request provides an explicit public record of integration, but also true that there are other public records where it is manifest that that integration has taken place if one compares the provided code in the forum and the committed code in the repository.

If this is a real issue for you, then you should also publish a list of forum rules/agreement where it is stated that all the code that is posted in this forum can be used by JUCE without copyright infringment (I'd also say it is Public Domain)


#10

Yeah, we're going to firm-up the legal side of this kind of thing soon. Don't want to get too heavy about it though, it'd be silly if we asked people to sign a disclaimer for just reporting a typo or one-line fix.


#11

I just can't see any counterplay.

"Hey they are using my work. I want something!"

"Well duh you did volunteer it to an open source project with a clearly defined license."

I can't see that they would have any ground. I think they would have to explicitly copyright anything they wish to establish ownership of.

It might be worth posting a question up on http://law.stackexchange.com/ just to see if anyone can see a potential dodge.

But it looks very low risk to me... Worst case scenario you get a letter from a lawyer, you would have to revert the relevant commit and rewrite the contentious code.

And in this community it would be such unlikely behaviour. It is a blatant dick move, biting the hand that feeds.

Just be careful you don't start getting tangled in red tape! It would be a pity if that got in the way of tapping into a potentially valuable resource (community dev).

I suppose you could create a "contributors agreement" that you get contributors to acknowledge by "tick the box" to automatically defer ownership of future commits to ROLI.  You could mail it to them the first time they commit something, or it could even be in their profile page in the forum. "By checking this box I hereby agree that any contribution of mine may be used freely by ROLI unless I explicitly state otherwise.  So long as the user account has the same backing email as their GitHub, it should be good enough.

Final idea: maybe a sticky giving guidelines for contributing: (1) tick the agreement and mail it to Jules. (2) make sure you don't have your own copyright anywhere. (3) if adding files, be sure to copy the JUCE license over.

π


#12

Yes, that is my point: since it already is done in practice and hasn't raised issues so far, I think it is safe to say that a modest legal protection is enough. Also, I second entirely what pi said in its reply to the previous message in this topic.