Re: OSD && DFSG convergence
Steve Langasek <firstname.lastname@example.org> writes:
> On Sun, Jan 26, 2003 at 12:55:05PM -0500, Russell Nelson wrote:
> > Hi. I'm the vice-president of the Open Source Initiative, and I'm
> > writing to you today in that stead.
> > We want to explore convergence between the Open Source Definition, and
> > the Debian Free Software Guidelines. OSI is interested in mending
> > differences in our community, so that we can stand together.
I applaud this, but I don't think a literal merging of the OSD and
DFSG (from which the OSD derived) is feasible, nor does it really (in
itself) create solidarity with us or other free software projects. In
fact, attempting to merge the two documents seems more likely to cause
bitterness, flamewars, and bad feeling.
Why? Well, to start with, lets look at the structural issues.
The first issue is semantics, always a big stumbling block. I'm sure
there are a lot of people in the project who would object to the term
"open source", for reasons that are far too hashed over to return to
Next, the logistical maintenance and overview process may well be
Finally, as Steve pointed out, I'm sure the OSI would wish to maintain
their own autonomy in determining if particular licenses are "open
source", just as we in Debian need our own autonomy in doing so. I'm
not sure if replacing this "departmentalized" assessment of freeness
with some sort of centralized assessment is even desirable. Speaking
for myself, of course, if the autonomy of the projects I work on are
slowly usurped by remote bureaucratic, unaccountable organizations, I
feel the fun of it all might start to seep away, and I might be
inclined to wander off and do other things.
I might suggest, however, you approach the LSB or other larger free
software standards organizations regarding a community-wide definition
of "free software", "open source", or whatever you want to call it.
If your only interest really is in mending fences between the OSI and
other free-software projects such as Debian, I'm sure there are more
productive means of doing so. I can talk more about this offline with
you if you like -- although I'd have to first survey what fences are
> > Is there anything in the OSD which would prevent the Debian project
> > from adopting it whole cloth? Is there anything the Debian project
> > would like to see changed in the OSD before it could adopt the
> > OSD?
Well, yes -- the DFSG is explicitly a *Debian* free software
guideline, and we find it is functional that it is so. This is the
structural issue of autonomy and specificity I mentioned above.
For instance, if you look at how point (2), "Source Code", is
different between the DFSG and the OSD, you can see how we have a bit
of specificity which we would need but in terms of a general open
source definition would be inappropriate.
The only other divergance of real note I found was "10. The License
must be technology-neutral". I'm not sure how people on Debian-legal
would react to this. It seems somewhat reasonable on the surface but
one generally needs to get down to cases in order to assess a
> > Regardless of the merits of this proposal, I see two problems with the
> > current DFSG. One is that software must comply with the DFSG to be a
> > part of Debian, and yet the DFSG does not admit the possibility of
> > public-domain unlicensed software.
Why do you claim this? I don't see the basis in the DFSG for claiming
we don't allow public domain software. As for unlicensed software, my
understanding was that under the Bern copyright treaties in most of
the world, unlicensed means "all rights reserved", i.e., not free at
> Then again, neither does the OSD,
> > because we're only applying it to licenses. Another problem is that
> > the DFSG does not prohibit a license from requiring a specific form of
> > affirmative assent known as click-wrap. Our recently-passed change to
> > the OSD fixes that problem.
Oh, I see, this is provision 10.
> I'm inclined to believe that your second example is also a minor
> issue, because if the software is DFSG-compliant in all other
> respects, it should be possible to legally remove the click-wrap
> requirement from the code -- just as you can charge someone a fee
> for giving them GPL software, but you cannot prevent them from
> giving it away for free once they have it.
Hmm. Yes, I would think the Deiban maintainer would be able to strip
the click-wrap, or if not, the software wouldn't really be DFSG-free
anyhow, would it?
I'm not even convinced that provision 10 in the OSD really
specifically and satisfactorily eliminates the case of
"click-wrapping". I mean, isn't it sufficient covered in the "no
discrimination against persons or groups", e.g., persons who don't use
or can't use the UI technology employed by the click-wrap?
Even if that's stretching it too far, isn't point (10) worded rather
oddly? It says:
10. The License must be technology-neutral
No provision of the license may be predicated on any individual
technology or style of interface.
I would think it would be better to say that the license must not
require that the user have to specifically acknowledge the license in
order to go into effect. However, again, IANAL -- if you could
provide a case of some free software that imposes click-wrapping
(e.g., would obstensibly pass DFSG but not clause 10 in the OSD) that
might help clarify the discussion.
> Can you provide a reference to the changes to the OSD text for our
I would find some sort of "diff" (either literally or just an
overview) useful as well.
...Adam Di Carlo..<email@example.com>...<URL:http://www.onshored.com/>