Re: Draft new DFSG
This message response to some detailed comments.
Avery Pennarun writes ("Re: Draft new DFSG"):
> On Mon, Nov 23, 1998 at 02:58:41PM +0000, Ian Jackson wrote:
> > [the DFSG v2]
>
> In general, I like the idea of improving DFSG. I liked the formatting of
> the original better, though -- it's shorter, and gets right to the point.
>
> > (c) Requirements for placing notices
> [...]
> > It must be possible to write such notices so that they are truthful,
> > not offensive, and not unreasonably long for the context in which they
> ^^^^^^^^^^^^^
>
> All right, it's a Debian version of the Communications Decency Act! As with
> the original CDA in the U.S., you will probably find that "offensive" is way
> too vague to enforce.
You don't understand. All that that sentence does is make a program
not DFSG-free if it says things like
You may only distribute a port of this program to a Microsoft
operating system if you place prominent notices stating that Bill
Gates is an evil bastard.
Whereas the purely factual
You may only distribute a port of this program to a Microsoft
operating system if you place prominent notices stating that the
original authors strongly disapprove of Bill Gates.
is OK.
Or do you think a program whose licence requires you to place
offensive notices should be DFSG-free ?
...
> Too vague. I think some laws prevent "ordinary" software from being used in
> life-critical situations in some countries. It needs to be specially
> designed and certified. Simply because of those laws, does it make my copy
> of the Linux kernel not DSFG-free?
Can you come up with a better wording ? How about making legal
restrictions OK if they apply to _any_ software used in that context
or for that purpose ?
Daniel Martin writes ("Re: Draft new DFSG"):
> Ian Jackson <ian@chiark.greenend.org.uk> writes:
>
> <SNIP>
> > 3. Exemptions
> >
> > (a) Requirement to distribute source code
> >
> > The licence may require source code for the work to be distributed
> > whenever the executable is distributed, provided that:
> <SNIP>
> > ii. The licence allows the distributor of executables to offer to
> > distribute the source code instead of actually distributing it. The
> > licence
> > (1) may require the offer to be in writing
> > (2) may specify some minimum length of validity of the offer (not
> > more than 3 years)
> > (3) may require the offer to be open to all third parties.
>
> I'd suggest rephrasing point (2) to:
> (2) may not require that any such offer remain valid for more
> than 3 years
> That still is a bit convoluted, but it seems slightly clearer - it
> took me a little while to realize that point (2) as written does in
> fact mean what it's intended to mean.
If you say just `may not require' then the fact that it may require a
minimum validity at all is not stated, but implied.
> <SNIP>
> > (h) Changed name or version number for modified version
> >
> > The licence may require modified versions to be distributed under a
> > different name or with a different version number, provided that this
> > doesn't interfere with using the modified version as a replacement for
> > the original.
>
> I'd like to see this changed to:
> The licence may require modified versions or (versions distributed
> under a different license per (b) above) to be distributed under a
> different name or with a different version number, provided that this
> doesn't interfere with using the modified version as a replacement for
> the original.
>
> This is so that a name change can be required if, for example, I take
> some bit of code under a NPL-ish license (that is, free but entity XYZ
> can use the code for non-free stuff) and release a GPLed version.
> (A license that allows stuff similar to this came up in an IRC
> conversation about how TT might adjust the Qt license so that it could
> be GPL-compatible).
How about `the licence may require certain versions' ? After all,
there's no harm in a restriction like
You may not call a port of this program to Windows `foobar'.
> > (i) Advertising restriction (deprecated)
>
> This makes me nervous - I'd prefer to not have the DFSG have a
> built-in time-out. As much as I approve of saying "advertising
> clauses are disapproved of", I don't know that I'd want to throw out
> BSD-ish stuff.
This needs to be discussed.
> <SNIP>
> > 4. Restrictions due to law
> >
> > (a) If in a particular jurisdiction the distribution, modification or
> > use of a work is restricted by law, then the work is not
> > DFSG-free in that jurisdiction.
> >
> > (b) It is still DFSG-free in other jurisdictions, provided that those
> > who control (directly or indirectly) the work and the conditions under
> > which it is distributed, do not have the power to lift the
> > restrictions other than by changing the nature of the work, and
> > express a desire that the legal restrictions be lifted.
>
> I object to the phrase "express a desire that the legal restrictions
> be lifted" - I'd like to consider xyz crypto package free even if the
> author heartily approves of the US crypto restrictions because, for
> example, they allow his country to have a booming software crypto
> industry.
How about changing `and' to `or' and adding a requirement that they
don't act inconsistently with the expressed desire ?
> > (c) In the case of restrictions due to patents, a work can in any case
> > not be DFSG-free if those who control the work and the conditions
> > under which it is distributed are software patent aggressors.
>
> I _strongly_ object to this. In fact, I can't think of any possible
> way to rephrase it that will satisfy me.
Why do you object to it ?
Do you disagree with the Leage for Programming Freedom ?!
Ian.
Reply to: