On Sat, Feb 20, 1999 at 01:00:59PM -0500, Dale Scheetz wrote:
> On Sat, 20 Feb 1999, Anthony Towns wrote:
>
> > On Fri, Feb 19, 1999 at 06:57:05PM -0500, Dale Scheetz wrote:
> > > > The Debian Free Software Guidelines define what it means for software
> > > > to be free as far as the Debian project is concerned. Software that
> > > > follows these guidelines is termed "DFSG-free".
> > > So what do we call software that follows the original DFSG?
> >
> > If it meets these guidelines as well, we'd call it "DFSG-free". If it
> > doesn't, we call it "non-free".
> >
> > Consider the Postfix license. The one that's free except that it has the
> > "you agree to terminate this license and destroy all copies" and so on.
> I haven't read the license, but if it has the clause you quote it is
> non-free under the current DFSG. It isn't clear under your re-written
> document whether this would be free or non-free.
From the postfix .diff.gz copyright file:
+ In the event an intellectual property claim is made or appears likely
+ to be made with respect to the Software, you agree to permit IBM to
+ enable you to continue to use the Software, or to modify it, or replace
+ it with software that is at least functionally equivalent. If IBM
+ determines that none of these alternatives is reasonably available, you
+ agree, at IBM's request, upon notice to you, to discontinue further
+ distribution of the Software and to delete or destroy all copies of the
+ Software you possess. This is IBM's entire obligation to you regarding
+ any claim of infringement.
Note that this license was written to by DFSG-free, and quotes from its
home site include:
``...IBM is
making Secure Mailer available for commercial deployment on an
extremely liberal open source license.''
-- http://www.alphaworks.ibm.com/formula/securemailer
So it's obviously not clear to everyone that it's not free under the
current DFSG.
``_Termination of License_ The license must remain valid until the
licensee terminates it or violates the terms of the license.''
-- draft DFSG
Yes, perhaps that could be more clearly written, but at least it does
directly address the `free now and forever more'.
> > You're allowed to freely redistribute it. Source code's available, you
> > can make derived works, it doesn't have a patch clause, doesn't
> > discriminate, you can redistribute with the same license, it doesn't
> > contaminate other programs.
> > So it meets the DFSG.
> > So it's DFSG-free, right?
> > Why is it in non-free, then?
> It imposes distribution restrictions.
It doesn't though -- you /can/ distribute it at the moment quite freely.
There are no restrictions on your distributing it. The problem is that
there /might/ be restrictions at some point in the future.
Arguing that the possibility of a restriction is itself a restriction
seems to me to be the sort of obscure legal wrangling that ought to
be avoided.
> > The point of rewriting the DFSG is to make it more clear exactly what we
> > mean by free software -- that's the point of the DFSG in the first place.
> > If the DFSG doesn't quite match our ideas of free at the moment, then
> > we should change it, shouldn't we?
> Depends upon who "we" are doesn't it?
> The current definition is the one I use. I see no reason to change it.
> I certainly don't see changing it in the ways you have outlined with your
> document as any kind of improvement. Sorry.
The DFSG is used for a few reasons. It's used to read so you can introduce
yourself to the free software philosophy. It's used to determine if a
license is free, and it's used as a reference to write a free license.
Personally, I think the latter of these two are more important -- so I
think it's important that you don't have to sit and ponder whether a clause
possibly discriminates against someone, or if this weird clause does turn
out to be a restriction against distribution, or whatever else.
> > And if some of those programs that used to satisfy the DFSG don't
> > satisfy the new one, that's because we didn't consider them free in the
> > first place. So why call them anything but non-free?
> The DFSG represents a line drawn in the sand. You wish to make that line a
> mobile one, based on the current concensus obtainable by the loudest
> mouths. There are always those who would wish that the line were a little
> farther in one direction or the other, but that doesn't mean that the line
> should move.
The line is not moving from what Debian is doing. What Debian says, however,
is not what the DFSG currently states in a number of ways.
Please name one program in non-free that would move into contrib or main
under these guidelines, or one that would move the other way, if you wish
to assert this.
> > Running "make install" *is* a special action -- you kind of have to do
> > it, but if it has an "rm -rf /" as one of its commands you shouldn't be
> > required to.
> Sorry, but the point of this statement completely escapes me.
Even the special actions that you *have* to do (compiling the program,
installing it, sacrificing a chicken, whatever) shouldn't be "required"
by anything except the laws of physics.
> > > > 2.2. Source Code
> > > > ----------------
> > > > Source code must be freely available if it exists. Source code refers
> > > > to the form used to make changes to the software.
> > > Sorce code refers to the actual material that is covered by the copyright.
> >
> > Huh? /bin/ls is source code? Or it's not covered by copyright?
> >
> /bin/ls is not source code, and is not covered by the copyright.
> It is covered by the license.
Well, we could put this in, but then there'd be five thousand other people
complaining that it was complicated legalese and how much it sucked.
> > The only completely free license is saying "Do what you will with it",
> I submit that the above quote is not free. It allows me to take someone
> elses work and place it under a proprietary license, thus reducing the
> free access by the end user to said software.
``It allows me to do [something]''. That's freedom. It might not be *good*,
but it's freedom. The end user can still get the original if s/he so chooses.
> The intention of
> restrictions within a "free license" is to restrict activity which would
> weaken the freedoms we require.
Well, within the GPL anyway. Other free licenses restrict activities just
for the sake of it sometimes, it seems to me. :-/
> Because the restrictions it imposes are intended to keep the material
> free, we accept the restrictions. Because those restrictions are
> "unfriendly" to other licenses we consider Free, this continues to be a
> contentious issue. Deprecating a set of currently accepted restrictions is
> a bit more social engineering than is warranted.
I agree with this, btw. I like the GPL, I don't think it should be
deprecated, or discouraged, or whatever. Darren feels differently on
that clause, and has left the "deprecated" marker in for comment.
> > > > 2.5. Distribution
> > > > -----------------
> > > In fact, the source availability clause requires that you distribute the
> > > source (the true copyright material) whenever you distribute a derived
> > > binary from that source.
> > Which is another restriction the GPL places on you, but which also
> > restricts your freedoms.
> Only your freedom to oppress your users!
Sure. Just because it's not completely-utterly-BSDish-free doesn't mean it's
either bad, or non-free. That's all I'm trying to say.
> It is the "forced" availability of source that is one of the three
> underpinning structures supporting the freedoms we desire.
The BSD license doesn't force this, and the various BSD projects haven't lost
all their source code from the face of the earth yet.
I realise what you're saying, forced source code availability really does
help the user -- that's why it's allowed quite happily. But it also makes
life more painful in some cases (for binary only mirrors, for example),
which is why it /is/ a restriction.
(and I do know of some projects that *have* lost their source while
binaries were still being happily distributed far and wide)
>>>> 3.5. Availability of source code
>>>> --------------------------------
>>>> The license may require that distributors make a reasonable effort to
>>>> provide source code of versions of the software they distribute.
> The term "make a reasonable effort" is ambiguous.
Yes, it is. It's ambiguous because what's reasonable changes. It might not
be reasonable to require everyone who recieves a copy of a binary also
recieves a copy of the source right now -- with CDs being not all that
large anymore, and hard drives easily filling; but in a dozen years,
when we've all got multi-hundred gigabyte drives, maybe it won't be
so unreasonable.
> I sell Fred a Binary CD, and say "Do you want Source with that?",
``No, but I might have a sundae, thanks?'' :)
> and he
> says "I don't think so, maybe later." I say "It would be better if you got
> it now.", and Fred says "Naw, not right now."
>
> Have I made a "reasonable effort"? If he comes back to me three months
> later and says, "OK, I really need the source now, I have to fix
> something.", and I reply, "Sorry, I don't have any more of those." do you
> consider that I lived up to the Free Software "contract"? I don't.
Keeping source available for a year or so doesn't seem unreasonable to me,
no.
> > > > 3.6.4. Original source (deprecated)
> > > > -----------------------------------
> > > Requirement of pristine source distribution restricts none of the freedoms
> > > that we are promoting and provides assured access to the original work.
> > It makes it effectively impossible to use fragments of code in other
> > programs -- you have to distribute, say, the entire Xemacs source code
> > so you can use their five line "getCursorPosn()" function, or some such.
> Only if Xemacs were under those restrictions. Like the GPL vs LGPL, there
> are reasons for having certain restrictions in one place and not in
> others.
Would you be able to make up a more realistic example than Xemacs for me
then?
> The "pristine original source" provides the user with access to
> the original source under circumstances where the delivered binary is
> modified beyond the desires of that user. The ability to return to the
> original work and selectively add only the desired features is a freedom
> we should support.
And we do, in two ways. First, they're always allowed to get the
original source whenever they want. No one's stopping them, and Debian's
distribution specifically helps them. So what's the point of requiring it
anyway? Second, just because this is discouraged or deprecated, doesn't
mean they can't do it. It just means that you can't reuse (remodify?) the
software in some particularly useful ways (ie, cutting and pasting some
code to somewhere else it would be useful).
> > It also make it difficult to fork software -- if the original creator dies,
> > and he didn't leave a "if I die, this is BSD'ed" like troll tech has, then
> > you have to distribute the last version the creator wrote with every new
> > version that gets created.
> The whole point is to protect the access to the original author's work,
> even after he has died. I wish to be able to apply a license that can't be
> pried loose, even from my dead hands ;-) and your guidelines don't clearly
> give me ways to do that.
Again, just because it's discouraged, doesn't mean you can't do it, and it
doesn't make it non-free.
But I'm not quite sure why you'd really want this, anyway, so I might
just be missing your point.
> > > > 3.6.5. Patch clause (deprecated)
> > > > --------------------------------
> > > > Source level modifications may be required to be distributed as the
> > > > original source with a list of differences.
> But isn't CVS primarily a diff repository?
> Not that I want to get into technical details here. This was meant to
> point out the ambiguity of your statements.
Hmmm. It doesn't `distribute' them as original source + differences,
it stores them as that. But yeah, I see what you mean.
>>>> 5.1. Deprecated
>>>> ---------------
>>>> By deprecated, we mean this is allowed but discourage and disliked.
>>>> These items may be removed in future versions. Also, software without
>>>> deprecated clauses is recommended over software that has licenses with
>>>> such clauses.
>>> So there are levels of freeness described herein who's relative merits an
>>> value are deprecated as well? This is a guideline for discrimination that
>>> has no value to me, or to the freedoms that I cherish in free software.
>> Again, "discouraged" might be a better word, and you are, of course, free
>> to ignore it, and just differentiate on "free" vs "non-free".
> What do you mean by that? One group can call a program free that another
> group can call non-free, using the same guidelines? And this is an
> improvement? I don't get it.
You're welcome to ignore the "discouraged" tags.
Others are welcome to divide software into "non-free", "free but discouraged",
"free and not-discouraged". Both the latter are free, though, and match with
what you want to say is free.
> > But I think there is a difference between free software that makes use of
> > the advertising clause or the patch cluase and software that doesn't. Not
> > enough of one to make it non-free, but enough to discourage it some what.
> Such muddy thinking does not promote the clear understanding of the "line
> of demarcation" between free and non-free. You would have some things
> understood to be "near, or over the line" depending on the individual's
> preferences in reading the guidelines. This is totally unacceptable to me.
And yet you get it at the moment, with IBM reading the guidelines one
way and claiming Postfix is open source, and Debian reading them another.
The "discouraged" part doesn't touch the `line of demarcation', it
just marks the clauses that cause problems that aren't (generally)
commensurate with their benefits.
>>>> 5.2. Non-binding Requests
>>>> -------------------------
>>>> The license may make any number of non-binding requests. These should
>>>> be clearly separated from the binding section of the license.
>>> Licenses are legal descriptions of what you may, and may not, do with the
>>> licensed material. There are no such things as "non-binding requests" with
>>> requard to a license, you either regulate the behaviour or you don't.
>> Maybe there shouldn't be, but there is. Consider:
>> ``Vim is Charityware. You can use and copy it as much as you like,
>> but you are encouraged to make a donation to orphans in Uganda.'',
>> for example.
> Since it is not a legally binding portion of the license (it contributes
> nothing to the definition of the license) and does not impact any of the
> three freedoms that we hold dear, I believe that such statements have no
> bearing upon whether the license is free, or non-free. Can you give me an
> example of a "non-binding request" that would make a license non-free?
No, they specifically don't have bearing on whether the license is free or
non-free. That's why they're in the "notes" section.
> Then why mention them?
So that when we say "No your free software can't require its users to pet
a cat", we can give them an alternative way of encouraging people to be
nice to cats.
It's meant to make life easier for license writers, or packagers suggesting
changes that would make a non-free license free.
>>>> 5.3. Weaker Restrictions
>>>> ------------------------
>>>> The license have less restrictive versions of the restrictions listed
>>>> here.
>>> This isn't a grammatical sentance. What does this statement say?
>> ``The license may make use of less restrictive versions of the Restrictions
>> lists above''.
> So, what am I getting from this statement that didn't already exist. The
> fact that you make this one point clear, implies that there are other
> situations where the allowed terms are also required terms, but you don't
> clarify what those terms are.
? I'm not sure what you mean here.
> The DFSG is inteded to be a "key out" document. That is, you key the
> license against the specific items in the document. If it satisfies the
> terms of the key, the document is "in". If it fails on a key test, the
> document is "out".
>
> You seem to want a document that can declare a key item as excluded, and
> then later drag the document back "in" with a set of exceptions to the
> previous key. Cross document ambigueties will always be resolved in favor
> of the license,
The current DFSG says it's free as long as it doesn't do these bad things.
That means that if there are a few other bad things that we didn't think
of, then we're stuck, we have to say "they're only guidelines anyway",
or we have to go through some weird contortions to make the new bad
thing seem the same as an old bad thing.
The draft DFSG says it's free as long as it the only restrictions against
doing what we want are these (relatively) good things.
Basically, the default changes from going into main, to going into
non-free. And the only way anything is going to not go where we want it
is if it has some novel restriction that actually enhances its freedom,
as opposed to it having some novel restriction that makes it completely
non-free, yet not specifically disallowed by the current DFSG.
But I'll certainly grant that the "It must do this." "But" "It might
not do this" shouldn't be as separated as it is.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``Like the ski resort of girls looking for husbands and husbands looking
for girls, the situation is not as symmetrical as it might seem.''
Attachment:
pgp32pNd1sjm_.pgp
Description: PGP signature