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 [EMAIL PROTECTED] 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
