63

This is a tricky question. Open source licenses are generally irrevocable. Once you publish something under a license, you can relicense future versions but cannot retroactively change the license. Yet here, you have never directly published the project under the old license. My take on this is that the MIT license on the old commits is in effect for those ...


11

What you're describing is called a Version Control System or revision control system. It essentially stores one canonical copy in a central place, which can be downloaded, edited, and committed back there. If someone else changes it in the time you do, you must review those changes and incorporate them into your code before recommitting. Some major version ...


10

In corporate software development, all developers are, typically, using the same IDE running on the same version of the same operating system This is a misconception. Example: I run Eclipse Luna with openjdk-1.7 on Ubuntu 15.04, my colleague runs Eclipse Kepler with oracle jdk 1.7 (previously 1.6) on Windows. Still we got our builds working. The goal is to ...


9

This is a really broad subject so I'll answer at a very high level and not touch specifics unless they are relevant for OSS. "Works for me" This is really the crux of the problem; you have build environments that are different in a way that affects software behaviour. The industry at large has been tackling this for decades, and a number of best practices ...


8

if the LICENSE file is added in a single commit, then git rebase -i is an easy way to remove it. git rebase -i <root commit> will give you a list of all commits after the first one in an editor. find the commit that adds the LICENSE file and delete it from the list. pick 86a75a8 some commit pick 2dc535d some commit pick 264b12f add LICENSE <-- ...


6

As an example of an active & long-running open-source project, I will use Debian. First of all, you don't get commit access to the repositories all that easily. From the guide on how to contribute: Contributing. [...] You don't need to be an official Debian Developer to carry out just about all of these tasks. Existing Debian Developers acting as ...


6

I would suggest the following: Fork the project on github. Having a fork on github is needed for much of its infrastructure around pull requests. Having a fork on github makes everyones life easier. Optionally: Fork again to vso git. This way you can keep your in house development in house, and have all the issue tracking, CI, and other vso infrastructure ...


5

The GNU Project licenses are specific about what counts as source for a work: redistribution requires that one must also make available to every recipient the “complete corresponding source” for that very same work. This ensures the recipient has effective freedom to modify and redistribute the same work themselves. So, for a work licensed with that ...


5

Yes and no. If you have previously released versions of your software to the public, you generally can't revoke any license you have already released it under (doing so would cause massive issues for anyone who has already made use of the software). However, as the copyright owner, you retain the exclusive right to re-license (including dual licensing) any ...


5

I would suggest simply using GitHub. Its UI and paradigm is aimed specifically at what you want to achieve. Presumably you are already fetching the original project directly from GitHub, so you have all the internal infrastructure established to continue to do so. Simply forking it on GitHub maintains the link to the upstream original. Having both your fork ...


4

Files not covered by any license notice are considered "all rights reserved". I don't see how this can reasonably be exploited in any meaningful way. If you like, you can with many source repositories rewrite the history even after it happened and for example merge multiple commits.


4

"Committers" is a common (and unsurprising) name. Some projects make the distinction between "Maintainers" (who are responsible for participating in decisions about the project's direction and ultimately reaching consensus about them) and "Committers" (who actually merge, or commit patches), while some projects use them interchangeably.


4

What most people do is to make an archive of the release available for download. Access to newer source is nice, but the terms of the licenses are best met by providing the actual source. As we say at Apache, 'Apache Releases are Source Release, the binaries are just for convenience.' So, the important thing, from a licensing standpoint, is the source.


3

What is "good" is subjective. You could just make a rule that anyone who hasn't made contact with the dev team for a year gets removed, and they can be added back later if they ask. But another solution would be to restrict direct commits entirely. Github (and the other hosting services probably have something similar) lets you block all direct ...


3

You don't say anything about what type of revision control system (RCS) you use. However, the type of problem you describe is exactly the type of problem Git, being a distributed RCS, was created to fix. If everybody works on the master branch, or if everybody tries to consolidate every commit made by another team to their branch instantly, GIT will not ...


3

Version control systems are one way of allowing multiple people to work on the same files, but they don't support real-time collaborative editing of a single common version. There are FLOSS editors which support shared editing of documents in a manner similar to Google Drive; I've found that Gobby works quite well for this. It's used extensively during ...


3

The answer is: version control system Usual choices are: git SVN Bazaar Mercurial


3

Git repositories and submodules are just ways of organising and tracking changes to files. I doubt that any FLOSS license would have anything relevant to say whatsoever about including differently-licensed submodules in a Git repo. What does matter is when projects of different licenses are compiled together. Normally GPL and ARR are not compatible. But ...


2

A license grants others the right to copy and use your code under certain terms. Without a license, others have no right to use your code. This question expands on this. Unless you specifically relinquish your rights or allow others the right to use it, you are the only one that can use it. You are the only one that can exploit that situation, if you haven'...


1

When you say that it points to the creator's git repo, I assume you mean their central repository on GitHub. By default, links on GitHub point to the latest version of the code, but it is possible to get a link to a specific version of the code. Navigate to the "Commits" page. Find the commit that corresponds to the release you're using. Navigate to it ...


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