Re: Draft new DFSG - r1.4
Ian Jackson <ian@chiark.greenend.org.uk> writes:
> There are substantial changes here to the periphery, but the core
> remains largely unchanged.
Looks one of the important problem is the patch clause issue that I will discuss.
>
> B. Why are `modifications as patch only' licenses not allowed ?
>
IMHO it _is_ possible to have an intermediate clause, where the
copyright owner can enforce separating the original work from the
modifications without some of the inconvenients you mentioned.
> (DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
> licence to require that modifications be distributed only as original
> sources plus patches. The DFSG2 do not allow this. Here is why.)
>
> The following examples are things you should be legally able to do
> with free software, even if you're not the original author:
>
> * Run an anon-CVS service for your working tree.
I agree this should be allowed, but CVS allows to clearly separate the
original source from the patch. We just need a rationale that any
patch restriction clause should still allow the source to be
distribute under any control-revision system, when these conditions
are respected:
- the original source is put under the control-revision system
- there is some documentation for how to retrieve the original source,
or to generate a set of modifications between any version and the
original source, from the control-revision system.
> * Use a shared CVS server for your internal development.
Agree that it should be allowed, eventually with the same restrictions
than above.
>
> * Fork the software and competely reorganise the sources even though
> the original author hates you for it.
This is sensitive point, it is nice to be able to reorganise
source. But as long as we are allowed to extend, maintain and reuse
freely the software without restrictions, I think it is free enough to
be included in Debian. The DFSG does not say what we think is the
"Right Licensing" for software licensing or what we recommend, it says
what IS ACCEPTABLE FOR SOFTWARE TO BE PUT INTO THE DEBIAN
DISTRIBUTION. I like the current DFSG that says the patch clause is
bad, but we accept it.
The CVS issue is one of maintainance, there are other requirements:
possibillity of evolution, distribution without restrictions
commercial,... (all the contents ofthe previous DFSG). They should be
enforced. There is one more level of freedom that you want to require
(I simplify, but I think this is the spirit):
- being able to take any portion of source code from any part of the
debian source code distribution, and having the right to copy-paste it
for reuse in any other software, providing it is GPL.
That would greatly simplify the life developper by not having to read
and understand licences, (I think that by counting the time that all
developers in the world have spend trying to follow the QT licensing
issue, we would obtain enough manpower to rewrite QT from scratch).
But we are not defining an UFSG: Universal Free Software Guidelines, to
evangelize free software. We are defining what is free enough to be in
the Debian distrib.
The question is, do you think Qt and the TeX system are "free enough"
to go in Debian Operating system.
>
> * Take over maintenance after the original author has died, been
> bought, lost access to the 'net or whatever, and completely reorganise
> the source tree.
Reasonable reorganisations of source code are still doable with a
modifications-are-provided-separately clause. Altough I do not know
any supercvs, super-patch or super-diff tools that allow to take into
account renaming and moving of files, or moving of parts of code, they
may exist, and the job to go from original to modified and back could
be done anyway by a few scripts that will represent the modifications.
If the modifications you want to do are too big to be done this way,
it is probably not maintainance of a software anymore, but reuse in
another project (which is a different level of freedom).
>
> * Copy parts of the software into another program (unfortunately we
> don't have complete ability to do this anyway, at the moment).
I already discussed it above, tough we can disapprove officially, I
think software with these kind of restrictions can still go in Debian
without harming its original aim.
>
> * Repackage the original source package into a different distribution
> format (eg, better archive utility, better compression program,
> whatever).
That falls into maintainance, so I agree this should be explicitely
allowed, as long as the contents of the archive are the same.
> None of these things can be done if the licence takes full advantage
> of the DFSG1 patch clause.
>
> 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. 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.
>
> Also, any such exception would have to be written very carefully so
> that (eg) CVS servers are still allowed.
>
> All in all, it is better not to have the exception at all.
I disagree here, tough we may want to modify or add a rational for
the patch clause; it is easier to progressively convince people to not
use that, rather than for Debian to present stricter rules than what it
requires for its aim, it aim being:
> (c) The DFSG are written not just to ensure that the Debian Project
> can do with the software the things that we, our users, and our
> distributors, want or need to do. They are also intended to ensure
> that any third party free software developer can, given a piece of
> software from Debian, do all the things that they might reasonably
> expect to do with it in order to use and further develop free
> software.
>
This definition contains the word reasonable which is highly
subjective. I find it reasonable to be forced to provide a way to go
from and back between my version and the original version of a piece
of software if the original author asked to. That provides the freedom
for third-parties to choose which of the modifications they want to
take.
Loic
Reply to: