Patches (was Re: Draft new DFSG - r1.4)
Ian Jackson wrote:
> B. Why are `modifications as patch only' licenses not allowed ?
As others have mentioned, I think this is an EXTREMELY bad time to
forbid patch-only licenses. And, no disrespect for anyone intended,
but I have a lot more respect and trust for the opinions of RMS than I
do for *anyone* in the Debian organization, including myself! If RMS is
willing to declare the QPL a free license, that's good enough for me.
> The following examples are things you should be legally able to do
> with free software, even if you're not the original author:
There is nothing I'm aware of that you cannot do with a patch-only
license; you just can't necessarily do it in a convenient manner.
> * Run an anon-CVS service for your working tree.
Sure you can! You just have to keep the patches as separate files under
CVS control. Awkward, and it somewhat limits the usefulness of CVS, but
it doesn't actually limit what you can do with the code.
> * Use a shared CVS server for your internal development.
Again, yes you can. Same reasoning.
> * Fork the software and competely reorganise the sources even though
> the original author hates you for it.
Again, while it's not convenient, you can certainly do whatever you like
with your working copy, as long as you *distribute* it in the form of
patches against the original code.
> * Take over maintenance after the original author has died, been
> bought, lost access to the 'net or whatever, and completely reorganise
> the source tree.
Again, this would be inconvenient and difficult, but quite possible.
Same reasoning as the last point.
> * Copy parts of the software into another program (unfortunately we
> don't have complete ability to do this anyway, at the moment).
This would be extremely difficult, but still possible. You could make a
patch that deletes everything but one line from the original, and adds
the new code from your new project around that, if you really wanted.
> * Repackage the original source package into a different distribution
> format (eg, better archive utility, better compression program,
> whatever).
I don't see how this relates to patch-only licensing at all. Patch-only
doesn't say anything about how the original source tree is packaged. It
just says that it must be delivered in an unmodified form, and patches
must be separate and clearly marked. If I pack up the original source
tree with cpio rather than tar, the source tree itself is not modified.
I think that the freedom to deliver the source as a cpio archive, or
even a zipinfo or lharc file, is an important one, and it might be worth
looking at some way to guarantee that freedom. But that's an entirely
separate issue from the issue of patch-only licenses.
> It might be possible to write a wording for an exception, to allow a
> requirement that distribution of modified versions be accompanied by
> distribution of the original source code. Such an exception wouldn't
> initially greatly impede the activities I mention above, but would
> make distribution of the source on CD (for example) excessively bulky
> after a while.
This brings up a whole 'nuther question: are we going to reject
packages that are large and bulky and not very useful to most people,
just because they're large and bulky and not very useful to most people?
There's already going to be a limiting factor here, in that if something
is really difficult to package for Debian, probably nobody will *want*
to package it for Debian, and it won't be an issue. But if someone is
willing to volunteer the time and effort to do so, do we really want to
reject it, and if so, where, exactly, do we draw the line?
> Imagine if for every program you'd taken some code
> from you had to supply a complete source archive of that program; with
> increasing code reuse the amount of source being distributed would
> quickly become unreasonable.
Isn't the decision over whether it's unreasonable something a developer
should be free to decide for herself?
As I said, the large-and-bulky issue is something we should discuss
separately. Maybe we want to have a policy that such things are
required to have a priority of 'extra'. Maybe even we want to make all
patch-only licensed code have a priority of 'extra'. That sounds like a
reasonable approach to me. But the idea of rejecting free code just
because it's difficult to use strikes me as a bad one.
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or cwaters@systems.DHL.COM | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: