12
The GPL does not forbid you from using GPL'ed software. It requires something far more specific: if you modify the GPL'ed software and publish your modifications, then you can only publish under the terms of the GPL.
The question here is whether some use of Git would count as modification, and whether it counts as publishing. Different GPL versions ...
9
Whilst IANAL/IANYL, and no developer, it seems to me that the question boils down to "is it a licence violation to offer a repository from which someone could, with some effort, extract a non-licence-compliant subset of the code"?
I would argue that it isn't. With enough care, it's possible to extract a non-compliant version of code from most repositories. ...
9
As far as I can tell, the GPL does not require you to indicate what specific changes you make to a GPL-licensed work. The GPLv3 says
The work must carry prominent notices stating that you modified it, and giving a relevant date.
And the GPLv2 says:
You must cause the modified files to carry prominent notices stating that you changed the files and the ...
8
One useful way of handling long-term contributions from a fork could be:
Never touch master. On your fork, master reflects the status on the main project.
First, configure an upstream remote on your machine to the original project. You can do so by running git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (You need to do this ...
6
You aren't using git branches correctly.
Essentially, you should create a branch each time you want to submit a PR, make all the changes on that branch (could be more than one patch) and push it from there.
Once the PR is accepted, you should rebase your master branch from the upstream master, and when you have another idea you want to contribute, make sure ...
6
The signed-off line does not indicate the author but who authorized the commit to enter the project's repository. It has primarily nothing to do with who committed or pushed the commit.
Commonly it's used to indicate who did the review (that doesn't mean being the author, just the person who allows the commit to enter the repo or endorse the pull request.) ...
5
Git branches don't work very well for maintaining different “editions” of the same project, because there's no good way to share changes across branches without merging them completely. So simply for technical reasons, I'd urge you not to use differently-licensed branches. Such branches are also not very discoverable to users.
Instead, keep all the code in ...
5
I don't think it does, no. As the GPL FAQ makes clear:
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible... pipes, sockets and command-line arguments are ...
4
A common place is indeed in the readme, a separate contributors file which accompanies the project. Optionally and preferentially also shown this list in the application somewhere in the about dialogue or whereever you inform the user about credits and contributors.
If found in the more general credits section, more specifically contributors or authors ...
4
This might be technically be a case of copyright infringement, however:
you acted in good faith
you already corrected the license violation
you never pushed a HEAD that was in violation
Personally, I would have squashed or rebased the commits before pushing, but that is a minor point.
It could be argued that your fixed Git repository does contain the ...
3
In a nutshell, the Apache license allows you to modify the source code as long as you document your changes. You could view squashing the commits as such a change, and document it by stating something like "This project is forked from XYZ, with commit history .. squashed".
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 ...
2
The man pages of Git are under the same license as Git, e.g. GPL 2.0 (and v2.0 only: this is the same as the Linux kernel license)
2
The best way to know how you're expected to contribute to the project would be either check project documentation or reach one of the project maintainers.
Many open-source projects have would have some kind of a guideline for new contributors. For the project you're interested in this information is here: https://invent.kde.org/kde/kdeconnect-android/#...
2
The git repository as all information, so also the correct one.
IANAL, and more practical: I would make sure that all tags and publish branches will have the correct license. I would amend the source archives (tar.gz and similar) so that they have correct license (but probably I will keep the original file in a new place, with a README which tell about the ...
2
I would use a separate branch that mirrors exactly the head branch of the SVN repository, besides a master branch that contains the latest release of your fork and any other branches (feature, release, etc.) that are indicated by your preferred branching strategy.
When there is an update from the upstream project, you initially put that in the "upstream" ...
answered Nov 18 '18 at 9:36
Bart van Ingen Schenau
17.9k1 gold badge28 silver badges50 bronze badges
2
Each commit in git history is a legally distinct entity, and is licensed according to the LICENSE file that existed at that point in history. As an author, you have the right to change the license of your project at any time.
So, if commit X switches the project's license from no-license to MIT, then any user has the right to use the project from point X ...
2
Here are the steps you need to do to get a clean, nice pull request. I generally suggest this workflow to people with less previous exposure to git. You could make a rebase on auth repo master, but this might lead to non-trivial merging, depending on the delta. Therefore:
Do not delete your fork. That was bad advice in the comments.
Fetch the latest master ...
1
With respect to the other answers, I disagree with them.
You have developed some code, which you have released under a non-copyleft free licence; let's pick BSD 3-clause (BSD3). The choice doesn't affect the answer all that much, but it's easier than dealing with a list of possible licences.
At some point in the development of your project, you have ...
Only top voted, non community-wiki answers of a minimum length are eligible
