Home > Archive > Scheme > October 2004 > add your Scheme implementation to Debian GNU/Linux
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
add your Scheme implementation to Debian GNU/Linux
|
|
| Neil W. Van Dyke 2004-10-05, 8:58 pm |
|
I'd like to encourage people to add their Scheme implementations to
Debian GNU/Linux.
Debian is one of the most popular Linux distributions (and my personal
favorite). For a Debian user, having a Scheme implementation in Debian
*greatly* lowers the barrier to trying out the implementation.
For example, a Debian user can install DrScheme over the Internet simply
by executing the command "apt-get install drscheme". Also, the Debian
user will be notified in the future of new versions of the "drscheme"
package, and be given the option of upgrading.
And if you want to release an application program that uses a particular
Scheme interpreter or runtime library, you can specify that dependency
in the the application's Debian package, so that the dependencies are
automatically installed when the application is installed.
There are already a number of Scheme-related packages in Debian:
bigloo - A practical Scheme compiler
bigloo-devtools - Tools to help developping Bigloo programs
bigloo-doc - Documentation for the Bigloo scheme compiler
bigloo-examples - Examples for the Bigloo scheme compiler
bigloo-runtime-2.6b - Run-time libraries for Bigloo-generated programs
bigloo-runtime-2.6c - Run-time libraries for Bigloo-generated programs
bigloo-ude - Bigloo Unified Development Environment for Emacs
chicken - Simple Scheme-to-C compiler
drscheme - Scheme Programming Environment
elk - the Elk Scheme interpreter
escm - Embedded Scheme Processor
gauche - A Scheme implementation designed for script writing.
guile-1.6 - The GNU extension language and Scheme interpreter
guile-1.6-dev - Development files for Guile 1.6
guile-1.6-doc - Reference and tutorial documentation for Guile 1.6
guile-1.6-libs - Main Guile libraries
guile-1.6-slib - Guile SLIB support
guile-common - Common files for all guile versions
guile-db - Berkeley DB module for Guile
guile-library - Library of useful Guile modules
guile-pg - Guile bindings for the PostgreSQL client library
guile-www - Guile WWW module
guile1.4 - The GNU extension language and Scheme interpreter
guile1.4-doc - Reference and tutorial documentation for guile 1.4
guile1.4-slib - SLIB support for guile1.4 and libguile9
idsa-guile - Guile module for IDS/A
libautounit-guile - Guile Unit Testing framework
libbigloo2.6d - Run-time libraries for Bigloo-generated programs
libbigloo2.6e - Run-time libraries for Bigloo-generated programs
libelk0 - implementation of Scheme (the Extension Language Kit)
libguile-dev - Development headers and static library for libguile
libguile-ltdl-1 - Guile's patched version of libtool's libltdl
libguile9 - libraries for Guile1.4 (guile, guilereadline, and qthreads)
libguilegtk-1.2-0 - GTK+ 1.2 bindings for the Guile scheme interpreter
libguilegtk-1.2-dev - GTK+ 1.2 bindings for the Guile scheme
interpreter - development files
libgwrapguile-dev - Development package for libgwrapguile1
libgwrapguile1 - g-wrap: Tool for exporting C libraries into Scheme
interpreters
libqthreads-12 - QuickThreads library for Guile
libswig1.3.21-guile - Runtime support libraries for swig generated wrappers
mit-scheme - The MIT/GNU Scheme development environment
mzscheme - Rice University PLT Scheme Interpreter
oaklisp - An object-oriented dialect of Scheme.
quack-el - Enhanced Emacs support for Scheme programming
r5rs-doc - Revised(5) Report on the Algorithmic Language Scheme
rscheme - Threaded, persistent, OO, scheme interpreter and compiler
scm - A Scheme language interpreter.
scsh - A `scheme' interpreter designed for writing system programs
scsh-doc - Documentation for scsh, "The Scheme Shell"
skribe-doc - Documentation for the skribe documentation production system
slib - Portable Scheme library
stalin - An extremely aggressive Scheme compiler
stklos - An efficient Scheme System providing a powerful Object System
swig - Generate scripting interfaces to C/C++ code
swig1.3 - Generate scripting interfaces to C/C++ code
texmacs - WYSIWYG emacs-ish mathematical text editor, using tex fonts
wiliki - Yet another Wiki clone written in Scheme
Info on how to add a package to Debian is at:
http://www.debian.org/devel/
It's a nontrivial process, but it works pretty well.
You don't have to be the author of a piece of software in order to
maintain it's Debian packaging -- in fact, most Debian packages are
maintained by non-authors.
Neil
| |
| David Rush 2004-10-06, 8:56 pm |
| "Neil W. Van Dyke" <neil@neilvandyke.org> wrote in message news:<phd5zw7tt7.fsf@neilvandyke.org>...
> I'd like to encourage people to add their Scheme implementations to
> Debian GNU/Linux.
ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!
> It's a nontrivial process, but it works pretty well.
Grrrrr.....And it looks like we're going to have to re-license all of
the SRFIs in order to allow people to include them with their
implementations. And all because we don't want people *changing the
standards* (which will be technically legal after the re-licensing,
even if it is morally reprehensible). Lest you think we're insane,
Debian doesn't even distribute the RFCs anymore because the RFC
licenses are insufficiently 'free'.
Do you have any idea *how* we're going to even find Olin Shivers, much
less get a response out of him? And given his track record with
automatic weapons I shudder to think what might happen if he does
respond. Perhaps we should just send out the Scheme Underground attack
helicopters to selected Debian priesthood addresses right now and have
done with.
Oh yeah, there is no Scheme Underground.
Deep breath.
Bleah. I gave in to the rant anyway.
Move along now. Nothing to see here folks. Move along...
david rush
<srfi-editor mode='standard-disclaimer'/>
| |
| Nic Ferrier 2004-10-06, 8:56 pm |
| kumoyuki@gmail.com (David Rush) writes:
> "Neil W. Van Dyke" <neil@neilvandyke.org> wrote in message news:<phd5zw7tt7.fsf@neilvandyke.org>...
>
> ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!
>
>
> Grrrrr.....And it looks like we're going to have to re-license all of
> the SRFIs in order to allow people to include them with their
> implementations. And all because we don't want people *changing the
> standards* (which will be technically legal after the re-licensing,
> even if it is morally reprehensible).
This is guff. Is TCP under threat because GNU/Linux includes an
implementation? Of course not. There is nothing to stop people
including SRFI implementations in a Debian GNU/Linux based distro.
Note that the SRFI licence is similar to the apache licence and is
perfectly acceptable under the SRFI guidelines.
What is not possible is to include the SRFI documents in Debian
because of their determination to use only free documentation (and
their definition of free in this sense is very strict). But this is
not a big deal because the SRFIs are avaiable on the web.
btw... IMHO the SRFIs have been poorly managed by the Scheme
community. As a Scheme implementor it would be nice to be able to use
the documentation in some way other than by pointing people at it. A
texinfo version would work for me... but since the SRFI editors have
chosen to be laisseiz faire about editing standards it's not possible
to convert the documents into documentation formats other than HTML
(and we all know the problems with that).
Nic
| |
| Maurizio Boriani 2004-10-07, 9:00 am |
| >>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
[...]
Nic> btw... IMHO the SRFIs have been poorly managed by the Scheme
Nic> community. As a Scheme implementor it would be nice to be
Nic> able to use the documentation in some way other than by
Nic> pointing people at it. A texinfo version would work for
Nic> me... but since the SRFI editors have chosen to be laisseiz
Nic> faire about editing standards it's not possible to convert
Nic> the documents into documentation formats other than HTML (and
Nic> we all know the problems with that).
could be nice to write a scheme util similar to http://www.dewn.com/rfc/ but
for srfi. In this way, the 'client' can be free (GPL or similar) and the
down-load and conversion is done by end-user hands.
thanks,
Maurizio
--
Maurizio Boriani
GPG key: 0xCC0FBF8F
fingerprint => E429 A37C 5259 763C 9DEE FC8B 5D61 C796 CC0F BF8F <= fingerprint
| |
| Nic Ferrier 2004-10-07, 9:00 am |
| Maurizio Boriani <baux@member.snospam.org> writes:
>
> [...]
>
> Nic> btw... IMHO the SRFIs have been poorly managed by the Scheme
> Nic> community. As a Scheme implementor it would be nice to be
> Nic> able to use the documentation in some way other than by
> Nic> pointing people at it. A texinfo version would work for
> Nic> me... but since the SRFI editors have chosen to be laisseiz
> Nic> faire about editing standards it's not possible to convert
> Nic> the documents into documentation formats other than HTML (and
> Nic> we all know the problems with that).
>
> could be nice to write a scheme util similar to http://www.dewn.com/rfc/ but
> for srfi. In this way, the 'client' can be free (GPL or similar) and the
> down-load and conversion is done by end-user hands.
Yes.
But what we need first is an SRFI for web access from Scheme. And
before we have that we need an SRFI for accessing sockets from
Scheme. And that should probably be expressed as a module.
So much to do...
Nic
| |
| David Rush 2004-10-07, 9:00 am |
| Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> kumoyuki@gmail.com (David Rush) writes:
>
> This is guff. Is TCP under threat because GNU/Linux includes an
> implementation? Of course not.
This is a straw-man. TCP has such a wider usage base that this
comparison is meaningless. There are, in fact, mistakes in some of the
most widely-used SRFIs that ought to be fixed (e.g. argument
orderings). I for one, don't trust the implementor community to hew to
the letter of the SRFI if they can just change the document they ship
with their system.
Not that I mind if an implementor does fix the API, I just don't want
any hint that the changed API is a SRFI implementation. I'd vastly
prefer that the changed API get fed back into the process to result in
a new SRFI.
> There is nothing to stop people
> including SRFI implementations in a Debian GNU/Linux based distro.
That is not what the Debian people have said to some Scheme
implementors (w/rt the reference implementations). So, sorry, you're
wrong. There is a specific class of implementations which are
excluded from a Debian release: the Reference Implementations.
> Note that the SRFI licence is similar to the apache licence and is
> perfectly acceptable under the SRFI guidelines.
Of *course* the SRFI license is acceptable under SRFI guidelines. It's
not acceptable under *Debian* guidelines. And the SRFI process uses
the same license for both the code and the ref impls which is
(intentionally) similiar to the HTTP RFC license, not the Apache
license. We have been negotiating this for *months* (with a tip of the
hat to David Van Horn who has done the painful legwork).
> What is not possible is to include the SRFI documents in Debian
> because of their determination to use only free documentation (and
> their definition of free in this sense is very strict).
And they consequently view IETF RFCs as insufficiently free to include
them in their distro. Their attitude amounts to *intentionally* missing
the point of standards documents for religious reasons.
> But this is not a big deal because the SRFIs are avaiable on the
> web.
If you are a Scheme implementor who is very conscientious about
distributing complete documentation, it *does* matter. Do you think
we'd engage in this painful exercise if their wasn't demand from the
implementor community?
> btw... IMHO the SRFIs have been poorly managed by the Scheme
> community. As a Scheme implementor it would be nice to be able to use
> the documentation in some way other than by pointing people at it.
Just to stay on topic with my Debian Rant, this situation is
*effectively* imposed by the Debian license restrictions. The only
authoritative copies of the SRFIs are going to be the ones maintained
on schemers.org, and the Scheme Community will not be able to change
that.
Yes, you'll be able to include some kind of document which purports to
describe the SRFI-specified interface with your implementation, but
your *users* should check to see that it doesn't differ from the
authoritative versionm on srfi.schemers.org before making any
assumptions about it. It's a mutability issue, documents purporting to
describe SRFIs are about to become mutable data, whereas they were
once constants.
Am I being alarmist? Perhaps, but I simply can'y understand the lunacy
which drives the Debian people's attitude to making *standards*
documents *mutable*. It seems absolutely idiotic to me that they
should disallow the distribution of the very documents (IETF RFCs)
which have made their project possible. And I refuse to regard their
behavior as rational. In this matter they can be most charitably
described as misguided children who have no understanding of the adult
world.
> texinfo version would work for me... but since the SRFI editors have
> chosen to be laisseiz faire about editing standards it's not possible
> to convert the documents into documentation formats other than HTML
> (and we all know the problems with that).
I have had problems with the HTML template ever since my first day on
the job, probably for many of the same reasons as you. I spent some
time working on an XML DTD, but ran afoul of the wide variety of
things which may be the topic of a SRFI. I am ready to present the
case for a different format to the editorial team (and maybe even
retro-fit it to existing SRFIs), but I'd need to see a farily detailed
description of it first.
david rush
--
Engineering is the art of making what you want from things you can get.
-- Jerry Avins (on comp.lang.scheme)
| |
| Nic Ferrier 2004-10-07, 4:00 pm |
| David Rush <kumoyuki@gmail.com> writes:
> Yes, you'll be able to include some kind of document which purports to
> describe the SRFI-specified interface with your implementation, but
> your *users* should check to see that it doesn't differ from the
> authoritative versionm on srfi.schemers.org before making any
> assumptions about it. It's a mutability issue, documents purporting to
> describe SRFIs are about to become mutable data, whereas they were
> once constants.
But surely this is a normal situation. Most webservers don't ship with
a copy of rfc2616. They do ship with a manual which describes the
operation of the server's http stack. Most webservers manage to
implement http without a problem.
I don't see why the situation with SRFIs is different.
Another analogy is Scheme itself. AFAIK most implementations don't
ship a copy of R5RS. But they still manage to implement it.
> Am I being alarmist? Perhaps, but I simply can'y understand the lunacy
> which drives the Debian people's attitude to making *standards*
> documents *mutable*.
I am not a Debian developer, but I'm a GNU developer. Freedom is
important to us. I can understand why the Debian developers are not
convinced that standards documents should not be different from all
other documentation.
I don't agree with the Debian developers on this occasion, but I do
understand where they are coming from. They simply value freedom above
all else.
> I have had problems with the HTML template ever since my first day on
> the job, probably for many of the same reasons as you. I spent some
> time working on an XML DTD, but ran afoul of the wide variety of
> things which may be the topic of a SRFI. I am ready to present the
> case for a different format to the editorial team (and maybe even
> retro-fit it to existing SRFIs), but I'd need to see a farily detailed
> description of it first.
Are you really saying that docbook could not express everything that
an SRFI needs to say? Or even Texinfo?
Nic Ferrier
| |
| Bruce Lewis 2004-10-07, 4:00 pm |
| kumoyuki@gmail.com (David Rush) writes:
> ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!
Don't fight it; embrace it. It's sometimes the best way to get your own
misconceptions straightened out.
> Lest you think we're insane, Debian doesn't even distribute the RFCs
> anymore because the RFC licenses are insufficiently 'free'.
This doesn't prove one way or the other as to whether or not you're
insane, but Debian does distribute non-free software and documentation,
but puts it in a separate section. If you want to be able to work under
the assumption that you can create derivative works from anything on
your disk, you exclude this section. If you're willing to be a bit more
careful, you don't exclude that section and can do this:
blewis@softdev:~$ apt-cache show doc-rfc-std
Package: doc-rfc-std
Priority: optional
Section: non-free/doc
Installed-Size: 5312
Maintainer: Kai Henningsen <kai@debian.org>
Architecture: all
Source: doc-rfc
Version: 20030621-1
Replaces: doc-rfc-fyi-bcp (<< 20030621-1), doc-rfc-experimental (<< 20030621-1), doc-rfc-std-proposed (<< 20030621-1), doc-rfc-misc (<< 20030621-1), doc-rfc-old-std (<< 20030621-1), doc-rfc-0001-0999 (<< 20030621-1), doc-rfc-1000-1999 (<< 20030621-1), doc
-rfc-2000-2999 (<< 20030621-1), doc-rfc-3000-3999 (<< 20030621-1), doc-rfc (<< 20030621-1)
Filename: pool/non-free/d/doc-rfc/doc-rfc-std_20030621-1_all.deb
Size: 4822652
MD5sum: ce6598f1c82f9610bbe9ea22ae631c84
Description: Standard RFCs
The following categories are included:
| |
| Nic Ferrier 2004-10-07, 8:57 pm |
| David Rush <kumoyuki@gmail.com> writes:
>
> Hah! What planet do you program Scheme on? Most implementations *do
> not* implement R5RS in various ways. And they ship a document
> detailing the differences.
Yes. And mostly they're just about usable /8->
I still don't see your argument. They generally don't provide R5RS but
they do (even if not completely) implement it.
> As it is to me. The Debian policy limits the freedom of communities to
> produce standards which may be relevant to software that ships on
> Debian. Do you get it yet?
I get that you are cross about this. But free software developers hear
arguments like yours from all sorts of people. The Debian developers
are just being consistent. To the nth degree and in a futile way, I
agree. But that is their perogative.
And I think it's an interesting question to get standards people to
start thinking about : what does it mean to have a standard in a free
software world.
As Bruce Lewis has pointed out, it's easy to include SRFIs in Debian
because you can put them in non-free. Non-free is not hidden from the
user on install, selection of non-free is prompted by the installer so
it's not a ghetto.
> By those standards by which I could consider a texinfo solution, HTML
> is also a perfectly adequate solution. I don't know enough about
> DocBook (other than to observe that everybody thinks it's the ultimate
> answer to documentation problems) to answer the issue. What *is* your
> problem with the HTML, then? Perhaps we don't have similiar concerns
> after all...
Ok. I'll mail you privately about this... but for the record my
problem is the lack of markup reduces the chance for reuse of the
original documentation. I would like to ship GNU Info documentation
with my scheme impl. I would like to import SRFI documentation into
the info but I can't because there is no editorial documentation
standard (because SRFIs use HTML which makes for a free for all of
markup).
Nic
| |
| MJ Ray 2004-10-07, 8:57 pm |
| I am a debian developer, but I'm only giving my view on this one. If
you've got other debian developers telling you other things, point me at
any public statements and I'll discuss with them. I'm pretty sure David
Rush *is* ranting groundlessly, though.
Talk about "priesthood" is insane among a group where almost all
proceedings are public. Call us wrong if you want, but the priesthoods
are certain other "black box" operations. For example, where's the
srfi-editors list archive? (For that matter, where's schemers.org
tonight?)
kumoyuki@gmail.com (David Rush) wrote:
> Grrrrr.....And it looks like we're going to have to re-license all of
> the SRFIs in order to allow people to include them with their
> implementations. And all because we don't want people *changing the
> standards* [...]
If you don't want people editing it and passing off as the approved
version, you should try digital signatures or something like
that. Otherwise, the black hats will ignore copyright law and change
them anyway, while these silly rules hurt friends who respect the
SRFI project's wishes, whether those friends are trying to create a
free software operating system or an improved SRFI outside the SRFI
process. Why hurt friends?
For the SRFI code, I'm pretty convinced by Michael Sperber's
reasoning about why it is free (January on schematics-development at
schematics.sf.net). No-one has got off their backside to re-present
this to debian-legal, myself included. It doesn't seem that pressing,
as none of debian-legal seem convinced the other way enough to file bug
reports against scheme implementations AFAIK. I'll defer this work until
it has to be done.
> Lest you think we're insane,
> Debian doesn't even distribute the RFCs anymore because the RFC
> licenses are insufficiently 'free'.
This claim seems incorrect to me. Debian distributes them on its archive
network, but they can't be included in the operating system distribution.
I'll write a bit more in another reply on this topic.
--
MJR/slef My Opinion Only: maybe not of any group I know.
| |
| MJ Ray 2004-10-07, 8:57 pm |
| Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
> What is not possible is to include the SRFI documents in Debian
> because of their determination to use only free documentation (and
> their definition of free in this sense is very strict). [...]
Sorry, I'm sure you're wrong.
Debian has a long-standing commitment to use only *free software* (and
their meaning of free software is intended to be equivalent to the FSF
meaning (but there's been some recent difference in edge cases, usually
where FSF has said "<something> is free" and debian has not agreed yet)).
The two most common reasons are debian developers simply not being able
to agree, and FSF looking at a copyright licence while debian considers
a real live software package, ultimately.
Currently, as far as I know, the FSF does not claim that their "free
documentation" is free software. They actually have that position for
different reasons to debian, but the outcome is the same, so does it
*really* matter?
As I mentioned in a previous article, I think it seems fairer to honest
schemers to use methods other than copyright law to "quality assure"
genuine SRFI documents.
--
MJR/slef My Opinion Only: maybe not of any group I know
| |
| MJ Ray 2004-10-07, 8:57 pm |
| David Rush <kumoyuki@gmail.com> wrote:
> That is not what the Debian people have said to some Scheme
> implementors (w/rt the reference implementations). So, sorry, you're
> wrong. [...]
Please give references.
> And they consequently view IETF RFCs as insufficiently free to include
> them in their distro. Their attitude amounts to *intentionally* missing
> the point of standards documents for religious reasons.
Your attitude amounts to *intentionally* missing the point of free
software for religious reasons. Why should free software bow before
the altar of unresponsive standards bodies?
However, I would never start calling you "misguided children" or other
daft insults. I think you should either get your fingers under control
or exclude yourself from this whole issue for Schemers' sake.
--
MJR/slef My Opinion Only: maybe not of any group I know
| |
| MJ Ray 2004-10-07, 8:57 pm |
| David Rush <kumoyuki@gmail.com> wrote:
> [...] The Debian policy limits the freedom of communities to
> produce standards which may be relevant to software that ships on
> Debian. Do you get it yet?
You are trying to limit the freedom of communities to produce Debian
distributions which may be relevant to furthering support of your
standards. Do *you* get it yet?
End of the day, we're not going to send the Debian hit squad into
SRFI Editorial meetings to replace you with pliable ringers. You
can produce your standards, but Debian's clear wishes predate SRFIs.
| |
| Neil W. Van Dyke 2004-10-07, 8:57 pm |
|
Interesting discussion, but...
Whatever the unresolved license issues on SRFIs, I don't want people to
be discouraged from adding their favorite Scheme implementations to
Debian right away.
There are a few major Scheme implementations not yet in Debian, and
those implementations are being marginalized for the rather large base
of Debian users.
(Also, not that many people care, but I no longer have time to support
libraries such as HtmlPrag on implementations that are not in Debian.)
| |
| David Rush 2004-10-08, 9:10 am |
| Bruce Lewis <brlspam@yahoo.com> writes:
> kumoyuki@gmail.com (David Rush) writes:
>
>
> Don't fight it; embrace it. It's sometimes the best way to get your own
> misconceptions straightened out.
>
>
> This doesn't prove one way or the other as to whether or not you're
> insane, but Debian does distribute non-free software and documentation,
> but puts it in a separate section.
I am aware of this. Scheme implementors don't want to be left in this
ghetto because they are supporting SRFIs. This is the reality in the
community that we support.
And it is still insane that Debian ghetto-ize the RFC collection (and
by extension any standards documents) in this way. It is simply
missing the point of having standards documents in the first place.
david rush
--
Pedestrians are notoriously expensive to repair.
-- P.J. O'Rourke
_An Argument in Favor of Automobiles Instead of Pedestrians_
| |
| Neil W. Van Dyke 2004-10-08, 9:10 am |
|
I've not yet seen an actual instance of someone trying to add a Scheme
implementation to Debian but being unable to because of SRFI copyrights.
If I see a concrete example, I can work from that with people.
| |
| David Rush 2004-10-08, 3:58 pm |
| "Neil W. Van Dyke" <neil@neilvandyke.org> writes:
> There are a few major Scheme implementations not yet in Debian, and
> those implementations are being marginalized for the rather large base
> of Debian users.
And complaints from those implementors are perhaps the cause of
our issue investigation - hence my annotance about the whole problem.
> (Also, not that many people care, but I no longer have time to support
> libraries such as HtmlPrag on implementations that are not in Debian.)
And *this* is why I am so annoyed. In just the same way that so many
people who believe in free software are annoyed by the GPL. Debian is
a tar-baby that reduces everybody's freedom to the only kind of freedom
that Debian allows.
david rush
--
Einstein said that genius abhors consensus because when consensus is
reached, thinking stops. Stop nodding your head.
-- the Silicon Valley Tarot
| |
| David Rush 2004-10-08, 3:58 pm |
| MJ Ray <mjr@dsl.pipex.com> writes:
> David Rush <kumoyuki@gmail.com> wrote:
> End of the day, we're not going to send the Debian hit squad into
> SRFI Editorial meetings to replace you with pliable ringers. You
> can produce your standards, but Debian's clear wishes predate SRFIs.
But they don't predate IETF RFCs, which is the canonical case of
Debian's insanity. SRFIs just happen to be in the same boat.
david rush
--
.... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS.
-- Erik Naggum
| |
| David Rush 2004-10-08, 3:58 pm |
| MJ Ray <mjr@dsl.pipex.com> writes:
> where's the srfi-editors list archive?
I'd be more than happy to send it to you. It's about 90% spam these
days. Just ask Taylor Campbell.
> kumoyuki@gmail.com (David Rush) wrote:
>
> If you don't want people editing it and passing off as the approved
> version, you should try digital signatures or something like
Do *you* check them on packages you download? How often?
> that. Otherwise, the black hats will ignore copyright law and change
> them anyway
The reason why we are changing the license is because the risk is
actually trivial. The point is that we used a widely recognized and
widely redistributed license (the HTTP RFC license text), and Debian
won't recognize it.
> while these silly rules hurt friends who respect the
> SRFI project's wishes,
I am lost in a maze of twisty pronoun referents here...who's rules?
Debian's?
> whether those friends are trying to create a
> free software operating system or an improved SRFI outside the SRFI
> process.
The definition of a SRFI is a document that has gone through the SRFI
process.
> Why hurt friends?
I don't care about anyone who publishes a changed API from the SRFI
documents. What I care about is that they not represent their API as
having passed through the SRFI process. Admittedly, the number of
'black-hats' interested in this kind of fraud is almost certainly
zero, and we *are* going to change the license.
But who is hurting whom's friends. I am a great believer in free
software. I also believe that standards *promote* free software. Just
think about what the web would be today if HTTP was *not* freely
available. Or Usenet for Bog's sake! Debian is hurting the rest of the
free software community.
> For the SRFI code, I'm pretty convinced by Michael Sperber's
> reasoning about why it is free (January on schematics-development at
> schematics.sf.net). No-one has got off their backside to re-present
> this to debian-legal, myself included.
David Van Horn has been engaged in discussions with debian-legal and
with the OSI people. Well, I'm pretty sure about debian-legal but it
has been months since that happened. I know that most recently he has
been in discussion with the OSI.
> as none of debian-legal seem convinced the other way enough to file bug
> reports against scheme implementations AFAIK.
This started through reports given back to the SRFI-editors from some
major implementations. I don't know what transpired between them and
debian-legal.
>
> This claim seems incorrect to me. Debian distributes them on its archive
> network, but they can't be included in the operating system distribution.
> I'll write a bit more in another reply on this topic.
My claim was at best only partly correct, as has been pointed out by
others. However, there are implementations which ship fairly complete
documentation who get caught by the SRFI license.
david rush
--
Mathematicians stay away from actual numbers as much as possible. We
like to talk about numbers without actually exposing ourselves to
them - that's what computers are for.
-- Randy Waterhouse in _Cryptonomicon_
| |
| MJ Ray 2004-10-08, 3:58 pm |
| David Rush <kumoyuki@gmail.com> wrote:
> But they don't predate IETF RFCs, which is the canonical case of
> Debian's insanity. SRFIs just happen to be in the same boat.
They don't predate lots of things, but we are discussing SRFIs.
Your trouble seems to be caused by some change in SRFI editors' aims
rather than any change in Debian's aims.
I reject your silly claim that Debian is acting insane. Debian has said
it will produce a 100% free software OS. IETF RFCs are not free software.
Are you ignoring the two requests to provide references about SRFI
implementations being kept out of Debian, or have they not reached your
newsserver yet?
| |
| MJ Ray 2004-10-08, 3:58 pm |
| David Rush <kumoyuki@gmail.com> wrote:
> And *this* is why I am so annoyed. In just the same way that so many
> people who believe in free software are annoyed by the GPL. Debian is
> a tar-baby that reduces everybody's freedom to the only kind of freedom
> that Debian allows.
Why do you want to reduce Neil Van Dyke's freedom to choose what he
maintains and what he doesn't? I think it's brilliant that he helps
with any implementations besides his favourite. That's miles better
than many other library authors.
Really, you are starting to sound like the "Help! I'm being repressed!"
sequence. Please support your claims instead of just ranting, else no-one
can help you. Is that what you want? I think it's interesting that you
said "annoyed by" rather than "disagree with". Do you suffer from tall
poppy syndrome?
| |
| Neil W. Van Dyke 2004-10-08, 3:58 pm |
| > Why do you want to reduce Neil Van Dyke's freedom to choose what he
> maintains and what he doesn't?
It's more a practical matter for me than it is ideology or
freedom-flexing whim... Two disk drive failures deleted my manually-
installed trees of Scheme implementations. Trying to keep Scheme
implementations updated manually on my key computers had been a
energy-sapping mess, anyway. So I thought now is a great time to let
Debian do that job -- a job that Debian does rather well.
And I also wanted everyone to know that Scheme implementations are
missing a significant chunk of potential user base if they're not in
Debian.
| |
| MJ Ray 2004-10-08, 3:58 pm |
| David Rush <kumoyuki@gmail.com> wrote:
> MJ Ray <mjr@dsl.pipex.com> writes:
> I'd be more than happy to send it to you. [...]
Please consider publishing it.
> Do *you* check them on packages you download? How often?
Yes. Whenever possible.
> [...] The point is that we used a widely recognized and
> widely redistributed license (the HTTP RFC license text), and Debian
> won't recognize it.
I'm not sure what you mean by "recognize". I suspect you mean that Debian
won't distribute works under that licence. If so (and I've not checked
the HTTP case), then that is Debian's choice. If the licence clearly
doesn't grant users the freedom to use, adapt, redistribute and release
modifications, it should be obvious why.
> I am lost in a maze of twisty pronoun referents here...who's rules?
SRFI Editors'. Maybe "silly" isn't the best adjective. They seem silly
to me, but it depends what your aims are.
> The definition of a SRFI is a document that has gone through the SRFI
> process.
The definition of an improved SRFI is a document that has gone through
the SRFI process and subsequently been improved. Nothing forgives the
improver if they don't make clear that they changed it after review.
> I don't care about anyone who publishes a changed API from the SRFI
> documents. What I care about is that they not represent their API as
> having passed through the SRFI process. [...]
Other free software licences cover that, by things like requiring
clear marking of changes. Why not do that?
> But who is hurting whom's friends. I am a great believer in free
> software. I also believe that standards *promote* free software. Just
> think about what the web would be today if HTTP was *not* freely
> available. Or Usenet for Bog's sake! Debian is hurting the rest of the
> free software community. [...]
I agree with your stated beliefs, but I think your conclusion does not
necessarily follow from them. Maybe you have some other beliefs which
are influencing your view?
> David Van Horn has been engaged in discussions with debian-legal and
> with the OSI people. Well, I'm pretty sure about debian-legal but it
> has been months since that happened. I know that most recently he has
> been in discussion with the OSI.
Unless he uses a pseudonym, David Van Horn was not involved in the
December 2003/January 2004 discussions on debian-legal which led to me
asking schematics about it. Can you find references, please?
The failed Open Source Initiative has little relevance to debian, IMO.
> [...] However, there are implementations which ship fairly complete
> documentation who get caught by the SRFI license.
It is a shame that the SRFI licence is catching out free software
implementations of Scheme. I hope that you will publicise the draft
new licence.
--
MJR/slef My Opinion Only: maybe not of groups I know
| |
| Ray Dillinger 2004-10-08, 3:58 pm |
| Neil W. Van Dyke wrote:
>
>
> It's more a practical matter for me than it is ideology or
> freedom-flexing whim... Two disk drive failures deleted my manually-
> installed trees of Scheme implementations. Trying to keep Scheme
> implementations updated manually on my key computers had been a
> energy-sapping mess, anyway. So I thought now is a great time to let
> Debian do that job -- a job that Debian does rather well.
>
> And I also wanted everyone to know that Scheme implementations are
> missing a significant chunk of potential user base if they're not in
> Debian.
Discussion seems to be proceeding under the assumption that
everyone knows the answer to the questions I want to ask.
1) What does Debian regard as "free" software?
2) What does Debian regard as "free" documentation?
3) Does Debian regard standards as documentation?
(if so why? the purposes of standards and documentation
are entirely different).
4) What does a scheme implementor need to do in order to
put a scheme system in Debian?
I have looked at the copyright for SRFI's and they seem to
be the absolute minimum that a standard can be. IE, you can
create more stuff, you can comment on it, you can create
derivatve works, but don't change the standard itself.
That seems to be the minimum if we want to preserve people
from implementing something that the standard is not, thinking
that it is what the standard is. When their system is not
interoperable with systems that adhere to the standard, their
effort is revealed as a tragic waste of work.
That is what a standard has to do. Standards are completely
different from documentation; you don't change a standard to
conform to the behavior of the software, nor do you "improve"
a standard in incompatible ways without going through the
standards body and their process. The same considerations
motivated the copyright for the RFC's.
What problem does Debian have with this?
Bear
| |
| MJ Ray 2004-10-08, 8:56 pm |
| Ray Dillinger <bear@sonic.net> wrote:
> 1) What does Debian regard as "free" software?
See http://www.debian.org/social_contract - the intention of the contract
was to promise to only include free software in the FSF meaning. This is
vital if we are to describe a general copyright position to users, instead
of them having to check all licences for nasties like anti-commercial
terms, like some other distributions.
> 2) What does Debian regard as "free" documentation?
The Debian project gives documentation no special treatment.
Some have suggested it should, but none have yet offered a useful
and consistent way to distinguish documentation from other software,
despite requests. I'm not surprised: I described RMS's lower freedom
standard for GNU documentation as arbitrary and illogical many months ago.
> 3) Does Debian regard standards as documentation?
> (if so why? the purposes of standards and documentation
> are entirely different).
I'm fairly sure there is no policy regarding standards as documentation.
> 4) What does a scheme implementor need to do in order to
> put a scheme system in Debian?
Persuade someone (possibly themselves) to package it, a debian developer
(usually known as a sponsor if they're not the packager) to upload it
and the developer should convince the ftpmasters to accept it (often
easy, sometimes not). Neither the developer not ftpmasters should
accept something for inclusion in Debian which is not free software.
Otherwise it's regarded as a serious bug.
> [...] you don't change a standard to
> conform to the behavior of the software, nor do you "improve"
> a standard in incompatible ways without going through the
> standards body and their process.
Standards bodies get no special power for their works to be regarded
as free software if their works do not allow users the freedom to adapt
the software to their needs.
> The same considerations
> motivated the copyright for the RFC's.
Is that documented? If so, it seems a fairly basic block for free software
copies of the RFCs.
> What problem does Debian have with this?
None. Just don't expect debian to include things which are not free
software. If it meets minimum standards, it can go on the FTP archives,
but this is all debian's choice, not yours. Some people seem to forget
that.
--
MJR/slef My Opinion Only: maybe not of groups I know
| |
| Bruce Stephens 2004-10-08, 8:56 pm |
| Ray Dillinger <bear@sonic.net> writes:
[...]
> Discussion seems to be proceeding under the assumption that
> everyone knows the answer to the questions I want to ask.
>
> 1) What does Debian regard as "free" software?
> 2) What does Debian regard as "free" documentation?
> 3) Does Debian regard standards as documentation?
> (if so why? the purposes of standards and documentation
> are entirely different).
> 4) What does a scheme implementor need to do in order to
> put a scheme system in Debian?
<http://www.debian.org/social_contract#guidelines>
There's no distinction made between software and documentation, I
think: everything in Debian should follow the DFSG.
That means that nothing covered by the GNU FDL is in Debian (except by
accident). The problem seems to be the Invariant sections, quite
apart from whether it conflicts in some abstract sense, it seems to
potentially forbid useful derived versions (you might want to use part
of the text of some documentation in a reference card, but you'd be
required to keep the twenty pages of invariant sections).
> I have looked at the copyright for SRFI's and they seem to
> be the absolute minimum that a standard can be. IE, you can
> create more stuff, you can comment on it, you can create
> derivatve works, but don't change the standard itself.
Yes, it looks OK to me, too. I'm no expert on Debian, however.
Discussion appears to be in this thread:
<http://lists.debian.org/debian-lega...2/msg00326.html>.
Having read it, I'd summarise it as saying that the intent is probably
fine (the FAQ clarifications say the right things), but the copyright
itself isn't worded clearly enough.
[...]
| |
| Ray Dillinger 2004-10-09, 3:56 am |
| MJ Ray wrote:
> Ray Dillinger <bear@sonic.net> wrote:
>
>
> Standards bodies get no special power for their works to be regarded
> as free software if their works do not allow users the freedom to adapt
> the software to their needs.
Not even the ability to say, "this is the version that was
approved by the standards body; this other version is the
one that the implementation actually uses." ?? Hell, I'd
expect that much courtesy even for someone having written
ordinary program code; the changed version can be distributed
separately, or as a patch, but nobody should be able to
attribute the changed version to the original author without
his permission, nor to attribute a changed standard to a
standards body without their permission.
[color=darkred]
> Is that documented? If so, it seems a fairly basic block for free software
> copies of the RFCs.
If Debian insists that people should be able to modify
standards at will, without inserting notice of the
modification and a way to get the current version of
the real standard, I'd say it's a fairly basic block
against the utility of Debian.
Bear
| |
| Michael Erdmann 2004-10-09, 8:56 am |
| David Rush wrote:
> "Neil W. Van Dyke" <neil@neilvandyke.org> wrote in message news:<phd5zw7tt7.fsf@neilvandyke.org>...
>
...................
[color=darkred]
> Grrrrr.....And it looks like we're going to have to re-license all of
> the SRFIs in order to allow people to include them with their
> implementations. And all because we don't want people *changing the
> standards* (which will be technically legal after the re-licensing,
> even if it is morally reprehensible). Lest you think we're insane,
> Debian doesn't even distribute the RFCs anymore because the RFC
> licenses are insufficiently 'free'.
>
Don't worry, since there are a hand full of other languages available
with linux which can do the same as scheme and if it is not there
nobody will realize.
If debian is willing to include the implementations or at least some
what license complient rudimentry implementations, this will give the
scheme community a long need blood infusion.
Personally i am feeling this is a good idea and if there are licensing
problems you should overcome these problems.But this is just an
out siders view.
Michael
> Do you have any idea *how* we're going to even find Olin Shivers, much
> less get a response out of him? And given his track record with
> automatic weapons I shudder to think what might happen if he does
> respond. Perhaps we should just send out the Scheme Underground attack
> helicopters to selected Debian priesthood addresses right now and have
> done with.
>
> Oh yeah, there is no Scheme Underground.
>
> Deep breath.
>
> Bleah. I gave in to the rant anyway.
>
> Move along now. Nothing to see here folks. Move along...
>
> david rush
> <srfi-editor mode='standard-disclaimer'/>
| |
| Bruce Stephens 2004-10-09, 8:56 am |
| Ray Dillinger <bear@sonic.net> writes:
[...]
> If Debian insists that people should be able to modify standards at
> will, without inserting notice of the modification and a way to get
> the current version of the real standard, I'd say it's a fairly
> basic block against the utility of Debian.
Debian doesn't require that, of course. The GNU GPL is an acceptable
license for documentation (and anything else) in Debian, and one of
the conditions of distributing modified versions of a GPLed thing is:
2. You may modify your copy or copies of the Program or any
portion of it, thus forming a work based on the Program, and
copy and distribute such modifications or work under the terms
of Section 1 above, provided that you also meet all of these
conditions:
* a) You must cause the modified files to carry prominent
notices stating that you changed the files and the date of
any change.
| |
| MJ Ray 2004-10-09, 4:23 pm |
| Ray Dillinger <bear@sonic.net> wrote:
> Not even the ability to say, "this is the version that was
> approved by the standards body; this other version is the
> one that the implementation actually uses." ?? [...]
No, that is fine. A requirement to state changes is in the GPL, for
example. So, most of your post is arguing against a strawman. Sorry.
The SRFI copyright looks at first glance to go far beyond that. I think
the clarifications deal with most concerns, but it would be far better
to make the licence clearer and not leave lawyerbombs scattered around.
--
MJR/slef My Opinion Only and not of groups I know.
| |
| David Van Horn 2004-10-10, 3:56 am |
| MJ Ray <mjr@dsl.pipex.com> wrote in message news:<4166cb7a$0$917$cc9e4d1f@news-text.dial.pipex.com>...
> David Rush <kumoyuki@gmail.com> wrote:
>
> Unless he uses a pseudonym, David Van Horn was not involved in the
> December 2003/January 2004 discussions on debian-legal which led to me
> asking schematics about it. Can you find references, please?
That is correct; I have not participated in any discussion on
debian-legal. There was no reason to, as it clear from the thread
already referenced that it is disputed whether the SRFI license is
DFSG-free.
http://lists.debian.org/debian-lega...2/msg00326.html
> The failed Open Source Initiative has little relevance to debian, IMO.
The OSI has adopted the DFSG nearly verbatim, which is why we
approached them for an alternative opinion as to whether the SRFI
license conformed to the terms of the DFSG. I spoke privately with
the OSI board and publicly on the OSI discussion list. The public
discussion can be found here:
http://crynwr.com/cgi-bin/ezmlm-cgi...bfgoko#b
The conclusion has been that, at the very least, it is disputed
whether the SRFI license restricts use in a specific field of
endeavor. The source of contention is the phrase in the SRFI license
that "derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind."
Some interpret this as saying that derivative works which do not
comment on, explain, or assist in its implementation are not allowed.
We are considering changing the SRFI license to a widely agreed upon
free license, such as the MIT (X11) license. This would allow
implementations, among other things, to use the reference
implementations freely and to derive documentation from the SRFI
documents without worrying about their overall DFSG-free status. We
hope that by using such a license we can put these issues behind us
and get back to work. Although the GPL is attractive since it
requires prominent change notices, we feel that a copyleft license is
not suitable for the purposes of SRFIs.
However, the SRFI editors are still considering this issue. There
will certainly be a call for comments posted here and on srfi-discuss
before any change is made.
David
| |
| MJ Ray 2004-10-10, 3:57 pm |
| david@vanhorn.com (David Van Horn) wrote:
> That is correct; I have not participated in any discussion on
> debian-legal. There was no reason to, as it clear from the thread
> already referenced that it is disputed whether the SRFI license is
> DFSG-free. [...]
That thread is not particularly long. The timing means that many
contributors were away (I was). The thread makes it clear the licence
is confusing, but little else. There are some open questions. If SRFI
editors are interested, they should participate or encourage others,
rather than letting discussion die and then drawing conclusions.
> The OSI has adopted the DFSG nearly verbatim, which is why we
> approached them for an alternative opinion as to whether the SRFI
> license conformed to the terms of the DFSG. [...]
Unfortunately, current "OSI" members seem to consider them as a closed
definition. The DFSG are guidelines. This is a substantial difference,
as you can see in (for example) positions on patents. Current "OSI"
opinion is largely irrelevant.
> We are considering changing the SRFI license to a widely agreed upon
> free license, such as the MIT (X11) license. [...]
This would be good, as it is simpler and better understood.
> However, the SRFI editors are still considering this issue. There
> will certainly be a call for comments posted here and on srfi-discuss
> before any change is made.
I hope it is forwarded to debian-legal.
| |
| David Van Horn 2004-10-10, 3:57 pm |
| MJ Ray wrote:
> david@vanhorn.com (David Van Horn) wrote:
>
> That thread is not particularly long. The timing means that many
> contributors were away (I was). The thread makes it clear the licence
> is confusing, but little else. There are some open questions. If SRFI
> editors are interested, they should participate or encourage others,
> rather than letting discussion die and then drawing conclusions.
I drew no conclusion from this thread other than what you have just stated:
the thread makes it clear the license is confusing, hence we are considering
changing the license to make it less confusing.
But we also drew a conclusion from the choice by the Debian maintainers to
change the status of the RFC package to non-free. Since the SRFI copyright
statement is exactly that of the IETF RFCs, it is reasonable to assume that
any SRFI package, or any Scheme implementation that used SRFIs, would be
considered non-free by Debian. There may be Scheme implementations that do
use SRFIs and yet are considered free by Debian, but this is a bug -- one I'm
not about to report.
>
> Unfortunately, current "OSI" members seem to consider them as a closed
> definition. The DFSG are guidelines. This is a substantial difference,
> as you can see in (for example) positions on patents. Current "OSI"
> opinion is largely irrelevant.
Irrelevant to what? We are not simply concerned with appeasing the Debian
community. We are trying to iron out any possible license complications and
confusion so that Scheme implementors don't have to worry about it.
David
| |
| Ray Dillinger 2004-10-10, 8:56 pm |
| David Van Horn wrote:
> But we also drew a conclusion from the choice by the Debian maintainers
> to change the status of the RFC package to non-free. Since the SRFI
> copyright statement is exactly that of the IETF RFCs, it is reasonable
> to assume that any SRFI package, or any Scheme implementation that used
> SRFIs, would be considered non-free by Debian. There may be Scheme
> implementations that do use SRFIs and yet are considered free by Debian,
> but this is a bug -- one I'm not about to report.
I don't think I agree with your conclusion. A scheme implementation
could include the code needed to comply with SRFI's, without packaging
the text of the SRFI at all.
In that case we have simply code, either original and untouched by
the SRFI copyright, or a "derivative work" as allowed by the SRFI
license for purposes of implementing the SRFI, and nothing inhibits
people from changing it, although if they do so the scheme will
fall out of conformance with the SRFIs.
Bear
| |
| MJ Ray 2004-10-10, 8:56 pm |
| David Van Horn <dvanhorn@cs.uvm.edu> wrote:
> [...] There may be Scheme implementations that do
> use SRFIs and yet are considered free by Debian, but this is a bug -- one I'm
> not about to report.
If we believe SRFI Editors' clarifications, this is not the case. Of
course, we expect that any copyright holders who have the unfriendly
alternate view will make themselves known, as happened with PINE.
> Irrelevant to what?
Irrelevant to whether the SRFI licence meets the DFSG. That context still
remains above.
> We are not simply concerned with appeasing the Debian community.
I am disappointed that you use such unfriendly language.
| |
| Shriram Krishnamurthi 2004-10-11, 3:57 am |
| MJ Ray <mjr@dsl.pipex.com> writes:
>
> I am disappointed that you use such unfriendly language.
What unfriendly language? David did not say "We are not concerned
with appeasing the Debian community", which (while possibly true)
could be construed as provocative. He also didn't say, "We are simply
not concerned...", which would be even more aggressive.
What he instead pointed out, rightly, is that the SRFI process needs
to serve many masters, most of all the Scheme community, and in the
grand scheme of things the needs and demands of Debian take a pretty
low priority.
Shriram
| |
| MJ Ray 2004-10-11, 8:56 am |
| Shriram Krishnamurthi <sk@cs.brown.edu> wrote:
> MJ Ray <mjr@dsl.pipex.com> writes:
> What unfriendly language? [...]
Appeasement is a pejorative term, often used to liken the subject with the
Hitler government. Talk about appeasment is usually part of an argument
against discussion with the subject. There were bizarre claims that
asking "OSI" is somehow relevant to debian and that there's no need for
SRFI editors to talk to debian earlier in this thread.
Ultimately, few use "appease" to describe actions they support, so I
usually consider it unfriendly towards the subject.
| |
| David Van Horn 2004-10-11, 4:00 pm |
| Ray Dillinger wrote:
> David Van Horn wrote:
>
>
> I don't think I agree with your conclusion. A scheme implementation
> could include the code needed to comply with SRFI's, without packaging
> the text of the SRFI at all.
>
> In that case we have simply code, either original and untouched by
> the SRFI copyright, or a "derivative work" as allowed by the SRFI
> license for purposes of implementing the SRFI, and nothing inhibits
> people from changing it, although if they do so the scheme will
> fall out of conformance with the SRFIs.
The SRFI license applies to both the textual specification and the reference
implementation, except in the few cases where the reference implementation
is released under separate terms, such as 26, 33, 37, 43, and 56. So there
is no part of the SRFI document (including the reference implementation)
that is "untouched" by the copyright statement.
Also, my conclusion above is this: Debian considers work released under a
certain license as non-free, therefore other work released under the same
license would also be considered non-free. To disagree would be taking the
position that Debian will consider some work free and other work non-free
when released under the same license. It is a reasonable position to take
(for example, by taking intent into account), but it is not what you've said.
One conclusion I have certainly NOT made is that the SRFI license prohibits
the free use of SRFI documents, but rather that this has been disputed and
that there exists some confusion on the issue. This much has been demonstrated.
David
| |
| David Van Horn 2004-10-11, 4:00 pm |
| MJ Ray wrote:
> David Van Horn <dvanhorn@cs.uvm.edu> wrote:
>
>
> If we believe SRFI Editors' clarifications, this is not the case. Of
> course, we expect that any copyright holders who have the unfriendly
> alternate view will make themselves known, as happened with PINE.
Are you saying the Debian community takes the intent behind a license into
account when considering if it is free?
>
> Irrelevant to whether the SRFI licence meets the DFSG. That context still
> remains above.
I am not saying I went to the OSI for their analysis because it is relevant to
Debian. I was trying to get another opinion on the SRFI license from another
community. Like I said, we are concerned with more than just the Debian
community, we are trying to take into account a variety of issues so that we
best serve the Scheme community.
>
> I am disappointed that you use such unfriendly language.
This should be read as "We are concerned appeasing the Debian community. We
are also concerned with other communities, and other issues." If you take
issue with the word appease, feel free to read it as "We are concerned with
meeting the DFSG as interpreted by the Debian community."
As far as I can tell we both agree that a more widely agreed upon free license
that will reduce the confusion over the SRFI license is a good thing.
David
| |
| David Van Horn 2004-10-11, 4:00 pm |
| MJ Ray wrote:
> Shriram Krishnamurthi <sk@cs.brown.edu> wrote:
> Appeasement is a pejorative term, often used to liken the subject with the
> Hitler government.
That is ridiculous. To root of the word is peace. WordNet gives the
definition as "cause to be more favorably inclined; gain the good will of." I
welcome your comments on issues relevant to SRFI licensing issues, but putting
words in my mouth to the effect of "the Debian community is a bunch of
fascists" is totally counterproductive, not to mention a completely incorrect
reading of the intended meaning.
> Talk about appeasment is usually part of an argument
> against discussion with the subject. There were bizarre claims that
> asking "OSI" is somehow relevant to debian and that there's no need for
> SRFI editors to talk to debian earlier in this thread.
I never claimed OSI was relevant to Debian, only that they have adopted the
same guidelines and that I was interested in their opinion. I said that I was
not inclined to discuss the SRFI license further with the Debian community
because it has been demonstrated that some confusion exists over the SRFI/RFC
license, and that work licensed under the SRFI/RFC license has been considered
non-free. This has been enough for us to reconsider the license. Are you
saying that there exist no confusion? Are you saying Debian considers the RFC
package free? If not, you're disagreeing with something I'm not saying.
David
| |
| MJ Ray 2004-10-11, 4:01 pm |
| David Van Horn <dvanhorn@cs.uvm.edu> wrote:
> Are you saying the Debian community takes the intent behind a license into
> account when considering if it is free?
No. We can't measure intent. The debian-legal contributors do usually
take the public statements of the licensor into consideration. It also
takes the public statements of the licence authors into account, unless
we know there was little cooperation between licence author and licensor,
or the licensor makes a dissenting statement (like cdrtools).
> I am not saying I went to the OSI for their analysis because it is relevant to
> Debian. [...]
Sorry, then I misunderstood "we approached them for an alternative opinion
as to whether the SRFI license conformed to the terms of the DFSG."
> As far as I can tell we both agree that a more widely agreed upon free license
> that will reduce the confusion over the SRFI license is a good thing.
Yes. I hope the SRFI editors will be more transparant about its selection.
--
MJR/slef My Opinion Only and possibly not of any group
| |
| MJ Ray 2004-10-11, 4:01 pm |
| David Van Horn <dvanhorn@cs.uvm.edu> wrote:
> MJ Ray wrote:
> That is ridiculous. To root of the word is peace. [...]
Whether you want to ridicule me or not, "appeasement" is often associated
here with using short-term peace to achieve some other strategic goal,
such as the Chamberlain government using the peace of the Munich Agreement
to re-arm Britain in the face of Nazi agression and US isolationism. I
know that particular example was a long time ago, but it is probably near
the front of my mind after being at the nearby Madingley American War
Cemetary this w end. The same meaning is still current and frequently
used about political machinations.
If it wasn't your intention, prove it with your deeds. You probably should
be aware in future that "appeasement" is a very loaded term. I note
that wikipedia has a rather different interpretation to your dictionary.
> I never claimed OSI was relevant to Debian, only that they have adopted the
> same guidelines [...]
Sorry, even that seems incorrect. The first OSD was an edited DFSG, but
the main difference is attempting to use guidelines, tests, principles,
as a closed definition.
| |
| Ray Dillinger 2004-10-11, 8:57 pm |
| David Van Horn wrote:
> Ray Dillinger wrote:
>
>
>
> The SRFI license applies to both the textual specification and the
> reference
> implementation, except in the few cases where the reference implementation
> is released under separate terms, such as 26, 33, 37, 43, and 56. So there
> is no part of the SRFI document (including the reference implementation)
> that is "untouched" by the copyright statement.
Um, sorry, I must've been unclear. to be untouched by the SRFI
licence, it would need to be *ORIGINAL* code: not the reference
implementation from the SRFI itself.
If you use the reference implementation directly, then yes, you're
using code that's under the SRFI license; but in many cases the
reference implementation is more practical as a specification of
behavior than as a working implementation, and most schemes have
their own implementations of, eg, SRFI-9, which have nothing to
do with the reference implementation of SRFI-9.
This points out one way for a scheme to comply with various SRFI's
without using anything that's restricted under a SRFI license.
It does, however, defeat part of the purpose of the SRFI reference
implementations in some cases if you're not allowed to actually
use them.
Bear
>
> Also, my conclusion above is this: Debian considers work released under a
> certain license as non-free, therefore other work released under the same
> license would also be considered non-free. To disagree would be taking the
> position that Debian will consider some work free and other work non-free
> when released under the same license. It is a reasonable position to take
> (for example, by taking intent into account), but it is not what you've
> said.
>
> One conclusion I have certainly NOT made is that the SRFI license prohibits
> the free use of SRFI documents, but rather that this has been disputed and
> that there exists some confusion on the issue. This much has been
> demonstrated.
>
> David
| |
| Siegfried Gonzi 2004-10-12, 3:57 am |
| MJ Ray wrote:
> David Van Horn <dvanhorn@cs.uvm.edu> wrote:
>
> Whether you want to ridicule me or not, "appeasement" is often associated
> here with using short-term peace to achieve some other strategic goal,
> such as the Chamberlain government using the peace of the Munich Agreement
> to re-arm Britain in the face of Nazi agression and US isolationism. I
> know that particular example was a long time ago, but it is probably near
> the front of my mind after being at the nearby Madingley American War
> Cemetary this wend. The same meaning is still current and frequently
> used about political machinations.
Sorry, but where do you get such a strange explanation of appeasement. If I use
"leo" a well known translator in the net and type into "appeasement" I get
"Beschwichtigung" or "Abwiegelung" or "policy of appeasement" stands for
"Beschwichtigungspolitik.
I have never heard that one of the aforementioned German expressions or meanings
are by any means loaded in any sense. Where do people get their Nazi link to one
of them?
Fensterbrett
| |
| MJ Ray 2004-10-12, 8:57 am |
| Siegfried Gonzi <siegfried.gonzi@stud.uni-graz.at> wrote:
> Sorry, but where do you get such a strange explanation of appeasement.
History, mainly. I think you trimmed my reference to wikipedia. Specifically,
http://en.wikipedia.org/wiki/Appeasement
> If I use "leo" a well known translator in the net [...]
I've seen leo be very wrong in the past and its maintainers do not answer
emails. It may be that those German words are not similarly linked, as
translation is often not a perfect 1-1 relationship.
| |
| Siegfried Gonzi 2004-10-12, 8:57 am |
| MJ Ray wrote:
> Siegfried Gonzi <siegfried.gonzi@stud.uni-graz.at> wrote:
>
> History, mainly. I think you trimmed my reference to wikipedia. Specifically,
> http://en.wikipedia.org/wiki/Appeasement
>
>
> I've seen leo be very wrong in the past and its maintainers do not answer
> emails. It may be that those German words are not similarly linked, as
> translation is often not a perfect 1-1 relationship.
Hi:
I didn't follow the whole thread.
However, I often see that a lot of people connect many things to Nazi jargon.
My motivation for posting was the sole reason to show that in case "leo" its
translation has any rightful meaning to native English speakers and the German
translation was right, there is absolutely no link to Nazi-terms whatsoever.
I use "Beschwichtigung" or "Beschwichtigungspolitik" all the time and read it
every day in newspapers and I have never heard that anyone is going to link it
to the Nazis.
But one must say that it often depends on the context, e.g. "Ehre, Treue,
Tapferkeit" is often refered as Nazi-speaking. The words itself are harmless but
they had a meaning when seen in Nazi context.
Fensterbrett
| |
| David Van Horn 2004-10-12, 3:58 pm |
| Ray Dillinger wrote:
> Um, sorry, I must've been unclear. to be untouched by the SRFI
> licence, it would need to be *ORIGINAL* code: not the reference
> implementation from the SRFI itself.
Right, I had misunderstood.
David
|
|
|
|
|