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 ...


6

Not only do GitHub's terms of service codify that the submission would be covered under the Apache 2 license, so too does the Apache 2 license itself: "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally ...


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 ...


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.


3

Particularly referencing GitHub's Terms of Service, it is highly likely that the PR can be considered to be licensed under the Apache 2.0 license and therefore your company could happily use it in your proprietary project (assuming you give appropriate attribution etc). However, "highly likely" is not "certain" (and "highly likely&...


3

Pull from the fork, not form PR itself. PR must be coming from another github repo which would be a fork of the main one. That fork must also have LICENSE file along with commits you are interested in, making it clear that code in PRs is licensed under the same license.


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 ...


Only top voted, non community-wiki answers of a minimum length are eligible