Hello,
On 02/09/2013 01:54 AM, Joshua Gay wrote:
On 02/08/2013 06:05 PM, Kuno Woudt wrote:
Hello,
On 02/08/2013 10:49 PM, Joshua Gay wrote:
## Stuff I'm not sure about
- Requiring the user to use a version control systems (e.g., providing
access only over a "git clone" statement).
I think this should be allowed. The source code is in general aimed at developers (what are you going to do with the source code if you're not a developer?),
You might ask someone who knows how to program to make changes to the program for you.
But if you're not a programmer, how do you know if the zip file you downloaded does indeed contain the complete and corresponding source code you need? Most free software projects do not include third party libraries in their tar balls or source code repositories, you should ensure that you download matching versions of all dependencies if you want to be able to build the software years from now [1].
There are no guarantees that you can do a successful build of the source code you downloaded unless you do a build. If you cannot do this yourself, you should hire a programmer to do so. Having to "git clone" is the least of your concerns in this scenario.
Consider this example. Let's say I work in a medical clinic and I buy a device that has a lot of software on it. In the future it might become buggy or I might want to get the software upgraded (recompile with a new version of the kernel and other parts, etc). I might want to download a save a copy of the complete and corresponding source because it may go away in a few years and the manufacture might not be required to continue providing it online.
If I was hired by you to fix a bug in that software, I will first have to try to understand the software. For that, a full commit history will be very valuable in helping me understand why certain parts of the code have been implemented the way they are. Nowadays a lot of information which would in the past be in comment blocks has been moved to commit messages.
Or, to use the phrase from the GPL: A tar ball of the source code is nowadays no longer the "the preferred form of the work for making modifications to it". The preferred form is a clone of the DVCS repository with full history. Especially when trying to fix a bug, it is often useful to go back in history to find the commit which introduced the bug, this will give a developer a better understanding of the bug and will help him fix it in a way which doesn't break things elsewhere.
Also, one thing that concerns me is that people won't provide a copy of the Corresponding Source. They might point people to check out the trunk of the source, which could be a newer version that does not correspond with the current binary that is running. So even if we can assume that a link to a git repo is OK, I hope that very clear and simple instructions for getting the *Corresponding Source* would be provided and not just the latest source.
Obviously they have a copy of the Corresponding Source if they have the full history :). Release tags solve this problem, and in my experience most projects that do releases do use them. I can see the desire to mandate use of release tags which correspond with binaries, but I'm not convinced this is enough of a practical problem that the copyright license should mandate it for derivatives.
-- kuno / warp.