[copyleft-next] Network access to Corresponding Source

Kuno Woudt kuno at frob.nl
Sat Feb 9 09:37:50 UTC 2013


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.


More information about the copyleft-next mailing list