20
You own any code that you write.
When you contribute to projects you aren't handing over your copyright (ownership), you're giving them a license to your work. It's usually inferred to be the same license as what's in the project.
If you contribute to project B, you own the code, and gave Project B a license to that code.
Nothing prevents you from putting ...
17
The term "pull request" comes from git, where the git pull command is used to merge a different repository into your local one. So if someone else has a copy of your git repository, and makes changes to it that they would like you to incorporate, they can ask you to pull the changes from their repository; they're requesting a pull, hence the term "pull ...
15
That's a tricky question for the maintainers / core devs to answer and there cannot be "the one correct answer" as it depends highly on how that particular community works and how the people talk to each other.
Factors to consider are the type of contribution (bug fix, feature extension, new feature), quality of the contributions, the need and urgency to ...
13
The common understanding is to consider that contributions are made under the same license as the project these are contributed to (unless stated otherwise).
On GitHub, this is made explicit in the terms of service:
Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and ...
12
This depends in part on what the CLA requires, but it may be possible.
Do you have the ability to reuse the submission at all?
In general, it's understood that contributions to an open source project are offered under the same license as the project at large. In particular, the text of Apache License 2.0 makes this explicit:
Submission of ...
12
The primary way to contribute is by pull requests, just like you said. If your pull requests aren't accepted and you do not get any comments the project might as well be abandoned.
In this case I would open an issue/ticket and ask if you can participate as an maintainer. If you do not get a reply, create your own fork. Write a comment in your issue and say ...
11
If you have distributed version control systems, every developer has a copy of the full repository. If you change something to the software, you commit your changes to your local repository. If different repositories should have these changes, you can push the changes (moving changes to another repository you have the right to write to) or pull the changes (...
11
Some GPL projects require explicit copyright assignment, not merely licensing, of contributions. Copyright assignment is a bigger deal that licensing, and perhaps can't be arranged by an Apache style 'if you contribute it you are X'ing it' clause, where Apache fills in 'license' for X and a hypothetical alternative fills in 'assign'.
According to the Why ...
8
Update, based on new Terms of Service:
If a GitHub repository specifies a license, that's the default license for contributions.
Here's Section D.6 from GitHub's current Terms of Service:
6. Contributions Under Repository License
Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same ...
8
A pull request is related to version control systems. You may have several sets of users:
Administrators/Owners
Contributors
Testers
You want each of these people to be able to do different things:
Administrators/Owners
These people can be trusted. They might have full access to the repository in question, including full rights to commit what they want ...
6
Pull requests should be easy to review and integrate. Big pull requests can be easy if done properly, and small pull requests can be extremely tricky.
If your change is going to be big, or if it has a huge impact (e.g. breaks backwards compatibility), you should discuss what you are going to do with the maintainers first.
It may turn out that some of them ...
5
There doesn't seem to be a copyright violation here. The code was pretty clearly released under the LGPL, and open source licenses are (almost certainly) irrevocable; it doesn't matter that the patch was never accepted, the code was still released under the LGPL, so as long as the appropriate copyright notices are being maintained (and it seems like they are)...
5
Some projects such as Linux ask for the DCO to be signed in order to do due diligence, and ultimately to protect downstream users. The DCO does not forbid projects from establishing individual processes, such as requiring that it's clearly the committer who has signed off on the commit and to have a clear means of contact later.
This has nothing to do with ...
5
I found a service https://cla-assistant.io, recommended by https://cla.github.com.
Makes a hook to ensure every contributor signs the CLA.
Looks good so far. Will try and see how it goes.
5
If all the code is yours, then you can do anything that you would like with it. You can change the license, or even remove the license altogether. You don't have to keep a version licensed under the LGPL. If all the code is yours, you can do anything with it. Including dual-licensing similar to Qt.
But if some of that code is not yours, then you've got a ...
5
In case of doubt, you should state clearly that you only accept contributions under GPLv3 (or whatever license you select), and that the constributor must make sure they are allowed to contribute under the given terms. If it is redundant, it does no harm; if required, you need it to avoid getting into hot water. For a detailed example see e.g. the Linux ...
4
Since others have written code for the project, I believe they also have a small claim in the copyright of the project as a whole. Without a consensus of all copyright holders, I don't believe you are allowed to change the license of the project to GPLv2 because it is not compatible with GPLv3. However, if the other developers signed a contributor license ...
4
Although @jgauffin is giving you good general guidelines, I would add that it is important not to jump to conclusions too quickly.
In your question, you say that you haven't received any response for a few weeks but that there were commits to the projet in the last few months. To me it looks more like a project that is still maintained but not very actively....
4
The only correct answer here is "it depends".
You need to know your audience - in this case the people who will be accepting the pull requests.
Often, when you first start contributing to a project, the best approach is to choose a small (usually low priority) bug. Being low priority, it's probably not being worked on yet. Being a small fix, it is an ...
4
is it acceptable to change the implementation language via pull request?
Everything is "acceptable" for you to propose... but not everything may be accepted. If you were to submit a PR to one of my project that support Python2 and 3 and that your PR makes it support Python 3 only, I will very unlikely merge your PR unless I am ready to abandon Python 2 ...
3
To resolve this problem you can fork the version that includes a feature that you need and resolve the check problem. After that you can submit the PR with your changes.
An example:
There exist a project called A by some developer add the feature to fly over the world inside the fork of project is called A1. This fork A1 does need to define some additional ...
3
As @planetmaker pointed out, every one has their opinions. But weighing in my $.02, it's usually first raised first merged. So, whoever raised it later has to work on merging it in. The reason for doing this is simply because the the owner is just a middleman to make sure of code quality. So simulating the behaviour of git, usually the one who pushes after ...
3
When receiving contributions to a project, the default assumption is that the contribution is under the same licence as the project itself.
The main exceptions are when the contribution explicitly mentions a different licence or if it is of such a trivial/mechanical nature that the contribution doesn't qualify for copyright protection. The last reason will ...
answered Jun 7 '17 at 18:42
Bart van Ingen Schenau
21.3k3 gold badges30 silver badges55 bronze badges
3
Large bazaar-style open source projects usually don't just have one but many maintainers who review pull requests. Those often specialize in specific sub-modules of the application, so they have a better view of what is and isn't an appropriate contribution for that particular module.
2
There are a variety of ways to validate pull requests:
Some projects expect there to be an accepted issue before a PR is submitted. So, you can check the PR easily to see if it connects to an existing issue and then see if that issue is one that the team has said can move forward.
Hopefully on any large project there are a slew of tests integrated into ...
2
It depends on what changes you're making. I judge my submission of pull requests by criticality: for critical issues, it doesn't really matter how much you change, if you're fixing the issue; for tiny issues like code style, you just shouldn't change it because the author wrote it how the author wants it.
You could even assign a numeric scale to it, with 0 ...
2
If you submit a pull request that's too big, they will just reject it and tell you to split it up. If you submit one that's too small, they will just reject it and tell you to keep the branch around until it's done. Pull requests are public. You can get a good feel for the preferences of particular projects by viewing previous pull requests.
In my ...
1
Say you have a project under a permissive license (like MIT). Then I can go clone it, and build a copyleft licensed package on it (say GPL). If I ask you to pull, you are getting my modifications under copyleft (GPL, in this case), and have to respect that.
You should make absolutely clear under which conditions you accept code pulls (or any other ...
Only top voted, non community-wiki answers of a minimum length are eligible