Re: [RFC] Modification history as a source code
NB: another reordering of arguments, first come the comments that I
think point to the weakest point of my argument:
On Thu, Jun 19, 2003 at 05:46:20PM -0400, Anthony DeRobertis wrote:
DB>> Everyone already uses version control systems,
AD> No, not everyone. There are certainly a lot of little changes I
AD> don't bother importing to my CVS repository. I make the change,
AD> compile, and then often send a mail to submit@b.d.o. That's
AD> certainly published.
<...>
AD>>> I don't think a free license can require much more than "if you
AD>>> distribute this, give source under the same terms." It certainly
AD>>> can't require me to spend an indefinite amount of money keeping
AD>>> stuff around years after I'm dead.
DB>> The only difference between source as a source code and source as
DB>> a revision history is size,
AD> If you required me to distribute as original source + patches, I
AD> could maybe accept that. But my obligation should end there.
AD>
AD> If GPL 3(a) were not there (leaving only 3(b) and (3c)) then that
AD> would not be a free license, IMO.
The way I see it is that we should clarify and simplify the rules for
transfer of responsibility for preserving modifications from individual
contributor to CVS or BTS admin or upstream maintainer. Maybe it should
be untied from transfer of copyright, so that you can retain the
copyright, but rely on third party for storing your modifications for
you. The question is how to minimize the effort for small contributions.
------------------------------------------------------------------------
AD>>> I don't think its reasonable to expect me to keep track of every
AD>>> single change I've ever made;
DB>> Did you notice that I limit this to _published_ modifications?
AD> Sorry, I missed that. However, I've certainly sent various people
AD> random patches (is that published?);
IANAL, but I think it only qualifies for distribution, not for
publishing. Whoever chooses to claim copyright on the patch and publish
it, should take responsibility for keeping track of it.
AD> sent various things to mailing lists, the bts, etc. I sure haven't
AD> kept track of them. It'd be a major hassle to do so.
In these cases, mailing list and BTS archives should do the job for you.
DB>> I think adding the same condition as in GPL 3(b) would solve this
DB>> problem in the same way: 3 years is certainly less than "forever
DB>> minus 1 day".
AD> Well, then there isn't a way to gather the source code for the work
AD> after three years: Various authors no longer keep their changes;
AD> the links fall dead.
And how is it different from what we have now?
AD>>> (Just imagine that every time you patched XFree, you had to keep
AD>>> the entire XFree tree around. Ouch.)
DB>> There is difference between full copies of each version and
DB>> revision history (e.g. CVS repository).
AD> Well, a CVS repository for XFree would still be huge.
You don't have to keep your own copy of CVS repository, either. You can
rely on the XFree project's repository.
AD> I assume you mean I could chose to only keep patches around?
Yes, it is your call how you choose to store your modifications.
<...>
DB>> this would just make it required by a license. Technically, GPL
DB>> creates similar requirement of using the source instead of hacking
DB>> on binary.
AD> Where does the GPL prohibit binary patching?
Ok, 'require' was a bad word, I had to say 'encourage'. GPL doesn't
require it, but it encourages it in a way that it makes it much simpler
to comply with GPL if you hack on source. Requiring to keep track of
your modifications also doesn't require you to use version control
software, but encourages it.
DB>> Where did I say that? Does GPL require that source is available
DB>> "in the same network-accessible location"? It just has to be
DB>> available.
AD> If there is to be any hope whatsoever of assembling source from all
AD> those pointers, I think it has to be network accessible.
It would just make the task easier, but it is not required.
<...>
DB>> and money spent is finite and marginal in comparison with effort
DB>> and money spent on producing the modification in question.
AD> The storage space may be. The network bandwidth may be. The effort
AD> organizing it (and fulfilling requests) probably isn't, at least
AD> for small works.
This is something that we have to figure out, I still believe that there
are ways to address all the difficulties you've pointed out.
--
Dmitry Borodaenko
Reply to: