Re: Summary : ocaml, QPL and the DFSG.

2004-07-21 Thread Stephen Ryan
On Wed, 2004-07-21 at 13:53, Matthew Garrett wrote:
 Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
 
 Because privacy is an inherent right of Debian's users.  Further,
 communication with others, and sharing useful information and tools
 with them, should not have any impact on my privacy from you.
 
 Why is privacy an inherent right? Why does personal privacy outweigh the
 importance of modifications to free software being available to all?

Because you'd really think it sucks if we were to post video of you
taking a shit on the main Debian web site, and because we haven't seen
you volunteering your login information, SSN, bank account #s, etc. to
everyone else, either.  And even if you are some kind of pervert who
likes that kind of publicity, you're outnumbered by about 6 billion to
one.  

I have yet to see anyone arguing against privacy but then agreeing to
furnish their banking details to the world.  Some form of privacy is
therefore desirable, and I fail to see how it is desirable that it NOT
be the default.

-- 
Stephen Ryan
Digital Rights Management is bad for all of us:
http://www.bricklin.com/robfuture.htm



Re: DRAFT: debian-legal summary of the QPL

2004-07-20 Thread Stephen Ryan
On Tue, 2004-07-20 at 18:59, Matthew Palmer wrote:

 One thing that still bothers me about this, and I haven't seen a good
 rebuttal of it yet, is why we're so keen to use the law to void out a clause
 in the licence because it's unenforcable.  I've mentioned it before and had
 it danced around, but I still don't see why we shouldn't be honouring the
 author's wishes as expressed in his chosen licence.

Neither do I.  Relying on the unenforcability of a license or a clause
in a license is foolishness in the extreme; all it takes is a little
lobbying from Hollywood for some seemingly unrelated thing, and
presto-chango, it's suddenly retroactively an enforcable clause under
the new and improved Super-DMCA, and because somebody had this
discussion and therefore noticed the clause, that makes it wilful
infringement.

Now, it may be that the author's wishes may or may not be practical, but
nobody is actually required to carry any particular author's works.  For
myself, I consider forced-distribution clauses of any sort to be of such
a nature that I am unwilling to submit myself to them.  I can give my
friend a CD or DVD full of binaries and corresponding source and
discharge my obligations entirely under the GPL and anything else I
consider to be Free.  YMMV.  That CD can even be customized for them,
and I've still discharged my obligations.  Under the QPL (or GPL 3(b),
which I think is equally impractical for such small scale distribution),
I've just incurred an obligation for some indeterminate time in the
future, when I may or may not be able to discharge that obligation
without significant cost.  That risk is too great for me to consider
participating, and hence, I personally will not touch anything licensed
under the QPL.

What is acceptable for Debian to distribute is another matter entirely,
but I do think that the pass a CD along to a friend model ought to be
considered as part of the discussion.  



Re: DRAFT: debian-legal summary of the QPL

2004-07-19 Thread Stephen Ryan
On Mon, 2004-07-19 at 12:00, Brian Thomas Sniffen wrote:
 [EMAIL PROTECTED] writes:
 
  I wouldn't consider a license free if it said, for example, if you 
  modify
 this program you must add your name to this wiki page as soon as 
 possible.
 It wouldn't fail the desert island test (as soon as possible might 
 easily
 mean never) but it would fail the dissident test.
 
  But the QPL also fails the dissident test, and has a much less onerous
  requirement than the Add your name to a wiki license.
 
 It's a much more onerous requirement: it has the same effect, that you
 must contact the original author, who then gets to do what he wants
 
  Hey, no, you are wrong on this. The original author has to contact you 
  first,
  with the request. And i don't buy the idea of a generic call for patches,
  since nobody can prove that you indeed received that request (think about a 
  TV
  less dissident, or a guy on a desert island :). And anyway, first upstream
  need to learn of the patch, which he wouldn't do if the dissident didn't
  broadly distribute its changes.
 
 He doesn't need to learn of the patch first in the case of the generic
 call.  Additionally, the idea is not to help users get away with as
 much as possible.  It is desirable that users be able to do the right
 thing, abide by the wishes of authors completely, and still have
 freedom with respect to the software.
 
 So we can't just suggest that users pretend they never heard the
 generic call for patches, or the invocation of a termination clause.

Hear, hear!  I've heard this crap about it being okay to violate the
written terms of the license because of some exceptional circumstance
here or there or because a lawsuit against the violation would fail on a
legal technicality or nobody will ever find out.  I don't care if you
think they're little white lies or nobody will ever find out --
descending to that type of argument surrenders the moral high ground in
a spectacular fashion, and provides a mile-wide painted target for the
opponents of Freedom.  DON'T GO THERE!
-- 
Stephen Ryan
Digital Rights Management is bad for all of us:
http://www.bricklin.com/robfuture.htm



Re: DRAFT: debian-legal summary of the QPL

2004-07-15 Thread Stephen Ryan
On Thu, 2004-07-15 at 15:23, Matthew Garrett wrote:
 Nathanael Nerode [EMAIL PROTECTED] wrote:
 Matthew Garrett wrote:
  You could look at it that way. On the other hand, if I release my
  GPLed code under 3(b) then anyone who receives it can pass on the offer
  I gave them (under 3(c)). I am then obliged to pass on my modifications
  directly to people who I never provided binaries to. Is distribution
  under 3(b) and 3(c) non-free?
 
 If those were the only options, it was the loose consensus that that would
 not be free.
 
 Really? Wow. That's insane.

Whoa!  Just exactly how is that insane?  

Under 3(b), You promise to be a non-profit global distributor (and
philanthropist archiver!) for a minimum of three years.  You may only
use 3(c) for small scale, unmodified distribution, as there is no offer
to pass on for a modified version -- the source code must be for the
version of the binary that you distribute.

Under 3(b), if you ever distribute something, you must hang on to the
source code for it for a minimum of three years.  I understand that this
isn't a problem for Debian, seeing as how there's only a stable release
every 3 years anyway, but it sure is a problem for a small-scale
distributor or lone programmer.  Under 3(b), you promise to distribute
copies of that source code at the cost of distribution for those three
years -- your cost of securely storing that source code is irrelevant,
and you must eat that cost.  Under 3(b), you must undertake to obtain
export licenses, if necessary; just because the person requesting the
code obtained their binary from a third party who has the appropriate
export license doesn't mean that you necessarily do, and there is
nothing in the GPL exempting you from having to obtain it.  This may be
a hassle[0].  Under 3(b), your specific life circumstances are
irrelevant; the fact that your life may have turned upside-down in the
past three years (I know mine has!) has no bearing on the fact that you
still have a legally-binding offer out to the entire world, valid for at
least those three years.  I'm probably missing a whole bunch of
inconveniences incurred by distributing under 3(b), too.

3(b) is a PITA.  3(c) is only an option for noncommercial distribution,
and even then, only if no changes have been made. I'm sorry, but anyone
who would submit to all the inconvenience of 3(b) just for the privilege
of offering a patch to the community is the one who is insane.  Freedom
that only the insane may take advantage of is not freedom, IMO.

3(a) is salvation, because it allows me to give the source at the same
time as the binary and to have no further obligations to anyone -- and
this is precisely where Free Software has thrived; if every programmer
was also required to be a non-profit distributor, I don't think there
would be any code to be having pointless arguments like this about.

[0] Understatement of the minute, at least.

-- 
Stephen Ryan
Digital Rights Management is bad for all of us:
http://www.bricklin.com/robfuture.htm



Re: If DFSG apply to non-software, is GPL*L* incompatible with DFSG?

2004-02-28 Thread Stephen Ryan
On Sat, 2004-02-28 at 09:58, Joe Llywelyn Griffith Blakesley wrote:
 Last year, when the controversy over whether the DFSG applies to 
 documentation (in particular GNU-FDL-ed documentation), I meant to mention to 
 someone (but promptly forgot) that the license under which the text of the 
 FSF's licenses (GPL, LGPL, FDL) are licensed is much stricter than even the 
 FDL so cearly violates the DFSG (if they apply to it).
 
 The GPL c are allowed to be copied only in full without any modifications.
 
 If the DFSG do apply to non-software -- has a descision been made on this? -- 
 this would I think effectively stop Debian from distributing any GPLed work 
 on a CD which conforms to the DFSG.

Uh-huh.  This too has been discussed to death, though perhaps not with
an appropriate summary.

Basically, the law requires that the copyright notice remain intact, and
in a prescribed form.  Furthermore, the law states that anyone other
than the copyright holder who makes a copy of a copyrighted work (other
than the poorly defined fair use rights and the backup exemption),
is guilty of copyright infringement and subject to statutory damages of
up to $150,000 per copy.  Your only defense against this is the license
granted by the copyright holder; if you alter it, it is no longer the
license granted by the copyright holder, and might even be used as
evidence of wilful intent to infringe (=maximum damages).  Because of
this, it is foolish in the extreme not to include the *exact* license
text supplied by the original author with *every* copy.

It is therefore clear that attempting to apply complete DFSG-freedom to
a license is extreme folly; why would you ever want to open yourself up
like that?

It is clear to me that Debian has been proceeding with something roughly
like the following:

The legal documents (copyright notice, license) must be retained
verbatim in order for all of us to avoid being sued into oblivion. 
Proper attribution (i.e., not misrepresenting anything about the
original author) is the only honest thing to do.  Everything else should
be modifiable to suit, or else it isn't truly Free.  

I think it is up to those who would propose that the license texts be
DFSG-free as well to provide a proposed benefit that would be worth
exposing the project to $150,000 in liability per copy made of each
affected package.  

-- 
Stephen Ryan [EMAIL PROTECTED]
Digital Rights Management is bad for all of us:
http://www.bricklin.com/robfuture.htm



Re: If DFSG apply to non-software, is GPL*L* incompatible with DFSG?

2004-02-28 Thread Stephen Ryan
On Sat, 2004-02-28 at 16:35, Don Armstrong wrote (quoting the GPL FAQ):

I think the key line is this:

 (You can use the legal terms to make another license but it won't be
 the GNU GPL.)

The legal terms are not copyrightable; this is the FSF admitting that,
in a very oblique way.  I believe the line is that the protections of
the law are too important to be owned by any one entity, and must be
available to all.

So, legal terms are not copyrightable, and you can use them to make
another license if you like.  The specific terms as applied by any given
author to any given work are not subject to further modification, with
substantial penalties for violation.

Everything in Debian is copyrighted by someone else (i.e., not the
Debian project as a whole) and distributed by Debian.  The someone
else (even if otherwise affiliated with Debian) is free per above to
use any legal terms they like.  Legally, Debian must reproduce the
given legal terms verbatim; so must everyone who redistributes
anything they receive from Debian.   The official project stance *must*
be that immutable licenses are acceptable, because *every* license in
Debian is de-facto immutable.  

In short, licenses in Debian are already as free as they possibly can
be.

This should be put into a FAQ and buried for good.



Re: Starting to talk

2003-09-26 Thread Stephen Ryan
On Fri, 2003-09-26 at 04:25, Thomas Bushnell, BSG wrote:
 Stephen Ryan [EMAIL PROTECTED] writes:
 
  No, you're not the only one with that impression.  Personally, I'm ready
  to killfille [EMAIL PROTECTED] as a bunch of trolls.  The only reason I
  haven't is that I think there are some people worth listening to who are
  part of gnu, but you'd never know it from listening to this bunch.
 
 Please don't.  Heck, I'm still [EMAIL PROTECTED]  
 
 RMS does not speak for GNU developers in general; he has conducted no
 poll about these issues among GNU developers and has no ability to
 speak for them.

My apologies; I'm well aware of both your contributions and your stance
on the subject -- it's just that you haven't been using that address to
post to this list.  I haven't actually implemented any such block,
because it's easier and safer for me to just delete posts from known
trolls than it would be to engage in a fingers-in-the-ears exercise for
a whole domain (say, in case you did post from that address).  I am
*hugely* disappointed by the current state of affairs, though, because I
learned to value freedom from RMS' writings, and now I find that he only
cares about freedom for technical behavior, and all other aspects of
the system can take care of themselves.  
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: A possible GFDL compromise

2003-08-27 Thread Stephen Ryan
On Wed, 2003-08-27 at 07:13, Fedor Zuev wrote:
   Removing of secondary section from manual can't be count nor
 as improvement, nor as adaptation of manual.

It is, by definition[0], off-topic.  Therefore, as any good editor[1]
will tell you, it would be an improvement to remove it.


[0] Read the GFDL; every Secondary Section is defined as being
off-topic.

[1] The human kind, who is responsible for making sure that the
resulting work is coherent and complete.  It is painfully obvious that
the so-called Free Software community could *desperately* use the
services of many competent editors of this sort.  The emacs manual, in
particular, is filled with off-topic material, begins with a bunch of
legalese that a) belongs at the end, and b) describes in great detail
how that emacs as a whole is licensed under a self-incompatible license
(GPL+GFDL, since it claims right there that the documentation is part of
the editor[2]), contains advertisements (for other systems, no less),
and contains a couple of embarrassingly juvenile comments about some of
the operating systems it runs on.  All in all, an embarrassment to Free
Software -- and that's all just in the first page of the index!

I'm not an editor by trade, nor am I willing to work on something where
I perceive the license to be the height of hypocrisy *and* the license
is written in such a way as to ensure that I cannot succeed in my task. 
I do, however, recognize that the GFDL is a very real limitation on the
improvements that can be made to this manual. 

[2] The electronic kind.
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: SURVEY: Is the GNU FDL a DFSG-free license?

2003-08-21 Thread Stephen Ryan
 === CUT HERE ===
 
 Part 1. DFSG-freeness of the GNU Free Documentation License 1.2
 
   Please mark with an X the item that most closely approximates your
   opinion.  Mark only one.
 
   [ X ]  The GNU Free Documentation License, version 1.2, as published
  by the Free Software Foundation, is not a license compatible
  with the Debian Free Software Guidelines.  Works under this
  license would require significant additional permission
  statements from the copyright holder(s) for a work under this
  license to be considered Free Software and thus eligible for
  inclusion in the Debian OS.
 
   [   ]  The GNU Free Documentation License, version 1.2, as published
  by the Free Software Foundation, is a license compatible
  with the Debian Free Software Guidelines.  In general, works
  under this license would require no additional permission
  statements from the copyright holder(s) for a work under this
  license to be considered Free Software and thus eligible for
  inclusion in the Debian OS.
 
   [   ]  The GNU Free Documentation License, version 1.2, as published
  by the Free Software Foundation, can be a license compatible
  with the Debian Free Software Guidelines, but only if certain
  restrictions stated in the license are not exercised by the
  copyright holder with respect to a given work.  Works under
  this license will have to be scrutinized on a case-by-case
  basis for us to determine whether the work can be be considered
  Free Software and thus eligible for inclusion in the Debian OS.
 
   [   ]  None of the above statements approximates my opinion.
 
 Part 2. Status of Respondent
 
   Please mark with an X the following item only if it is true.
 
   [   ]  I am a Debian Developer as described in the Debian
  Constitution as of the date on this survey.
 
 === CUT HERE ===



Re: A possible approach in solving the FDL problem

2003-08-13 Thread Stephen Ryan
On Wed, 2003-08-13 at 15:37, Sergey V. Spiridonov wrote:
 Jeremy Hankins wrote:
 
  You recommend that we assign values to all the pros  cons of a
  particular license, and call free any license in which the positives
  outweigh the negatives.  Am I understanding you correctly?
 
 Yes, exactly.
 
  The problem with this* is that what you're really describing is the
  utility of the license, which is something completely different from
  the freedom of it.  Take the simple case of a license that pays me to
  accept it -- it may be non-free in many ways, but a lot of people
  would probably think the positives (free money) outweigh the negatives
  (no right to modify or redistribute, for example).
 
 
 Unfortunately we do not live in the ideal world.
 
 Freedom has a value because it is convenient and useful to be free. 
 Nothing else. There is no need to have a freedom which can't be used, 
 and sometimes we can agree to give away a bit of our freedom, which we 
 can't (or do not want) utilize in exchange for other values.
 
 A good example is GPL, which takes away the freedom to use GPL sources 
 in closed sources. We don't want to utilize such a freedom and we 
 exchange this freedom for helping GPL to spread. Note, there still can 
 be special rare cases, where such a freedom is really needed.
 
 Another example can be FDL. It takes away the freedom to modify parts 
 that deals exclusively with the relationship of the publishers or 
 authors political statements. Usually, there is no need to modify 
 someones political statement, and we exchange this freedom for helping 
 FDL documentation to spread. Note, there still can be special rare 
 cases, where such a freedom is really needed.

You speak as though freedom is a commodity to be bought and sold on the
futures market, and as though market share was more valuable than
freedom.  Freedom which you personally do not have a use for is
freedom that can be traded away in exchange for market share or more
software or something.  

You have taken the one sacred cow in the entire place here, and have
suggested that it is merely a convenience, and that we should have a
barbecue next Friday afternoon.  Free enough -- them's fightin'
words.  

You have also suggested that market share or wider distribution is a
thing of sufficient value on its own that it is worth sacrificing some
freedom to get it.  That is clearly nonsense; anyone to whom market
share is more valuable than freedom should be standing in Redmond, WA
with a job application.  I heard they're still hiring up there.  Or
working for RedHat.  Or Sun.  Or somebody else like that.  

What you have missed is that freedom is easily traded away, but only
gotten with blood, sweat, and tears.  Those who have paid for their
freedom in sweat are far less likely to give it away as freely as you
wish to.

*I* think you have the wrong number. 
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: APSL 2.0

2003-08-07 Thread Stephen Ryan
On Thu, 2003-08-07 at 06:51, MJ Ray wrote:
 Adam Warner [EMAIL PROTECTED] wrote:
  Here's a mere consequence: If Debian is persuaded that the APSL 2.0 is
  DFSG-free then a subsequent revision of the GPL with the addition of a
  viral electronic service clause would also be DFSG-free.
 
 It is expected that GPL-3 will contain something similar to the Affero GPL
 requirement for remote services to offer users the code.  Do you object
 to that?  If so, why?  If you are offering interaction with the code
 via some sort of remote procedure call, you are not using it privately
 for your own ends and some of the users may want to adapt the software,
 which is a freedom normally offered by free software.

I have a web site on a server that I control.  Every piece of software
on that server is there to assist in rendering or managing the web site
in some way or another.  I'm aware that Apache and the Linux kernel are
not under an Affero-type license, but suppose with me for a moment that
the whole installation was under such a license.  I'm now liable to
distribute the source code for an entire operating system to every
person who manages to obtain a web page from me.  I'm also liable to
distribute the source code for an entire operating system to every
sco'er in the world who manages to send me a spam, because they're
using my email service.  If such a bit is added to the GPL with no
other changes, I either have to deliver the source code with every web
page (or spam), or I have to promise to keep it up there for a minimum
of three years.  All of a sudden, licensing SCO or Windows looks cheap
by comparison - at least they only demand the large payment once.

Thankfully, this is all hypothetical at this point, and the kernel and
Apache are both licensed under a different license (GPLv2 only, and
Apache has its own license), but I'm bothered by the fact that this is
being put forth as free.  As Adam points out, this is a networked
world; if I can only afford to exercise my freedom by not being
networked (being a hermit), that freedom is *worthless*.



Re: APSL 2.0

2003-08-07 Thread Stephen Ryan
On Thu, 2003-08-07 at 10:22, MJ Ray wrote:
 Stephen Ryan [EMAIL PROTECTED] wrote:
  the whole installation was under such a license.  I'm now liable to
  distribute the source code for an entire operating system to every
  person who manages to obtain a web page from me.
 
 How does this differ from your current obligation to either provide
 the source or equivalent offer to that which you obtained the source?
 Or is your server a 0-user affair?  So why wouldn't the offer clause
 work for you?

Has Debian made such an offer?  I can only pass along such an offer if I
received one in the first place.  To my knowledge, Debian has made no
such offer on any code.  It also does not apply if I make any commercial
use of my server (which I do, to the tune of a couple hundred dollars
per year).  

The difference is that I don't currently run a debian mirror on it, and
I don't have to, either.  The difference is that I currently have to get
into the distribution business only if I want to be in the distribution
business, whereas such licenses obligate every person who has a computer
running such code to be in the distribution business (I'm phrasing this
carefully so as to avoid any difficulty over the definition of a user
here).

Of what use is Free software if nobody is willing to run it?



Re: Open Software License

2003-06-02 Thread Stephen Ryan
On Mon, 2003-06-02 at 19:34, Mark Rafn wrote:
 On Mon, 2 Jun 2003, Joey Hess wrote:
 
  The Open Software License
  v. 1.0
 
  3) Grant of Source Code License. The term Source Code means the
  preferred form of the Original Work for making modifications to it and
  all available documentation describing how to access and modify the
  Original Work. Licensor hereby agrees to provide a machine-readable
  copy of the Source Code of the Original Work along with each copy of
  the Original Work that Licensor distributes.
 ...
 
 This is phrased very oddly.  I think the intent is for this to apply to 
 derived works, where you becomes licensor and the downstream recipient 
 becomes you.  I don't think it's non-free, just hard to follow.
 
  5) External Deployment. The term External Deployment means the use
  or distribution of the Original Work or Derivative Works in any way
  such that the Original Work or Derivative Works may be accessed or
  used by anyone other than You, whether the Original Work or Derivative
  Works are distributed to those persons, made available as an
  application intended for use over a computer network, or used to
  provide services or otherwise deliver content to anyone other than
  You. As an express condition for the grants of license hereunder, You
  agree that any External Deployment by You shall be deemed a
  distribution and shall be licensed to all under the terms of this
  License, as prescribed in section 1(c) herein.
 
 Whee!  I haven't changed my mind since the Affero discussion.  I
 personally think it's a non-free use restriction to declare that deliver
 content to anyone other than You is equivalent to distribution of the 
 software.

I agree strongly; in a networked world all software potentially falls
under such clauses, and then, the only persons able to use software
under such licenses are those who are willing to undertake the
obligations of publication.  Forced publication requirements have always
been a problem before, when they applied to a far smaller set of people,
and I don't see why it should be any better that every user is forced to
publish the software.  In theory, it's a great way to increase the
availability of the software, but in practice, it limits the usage to
those with the resources and the ability to publish it.  If I run such
software on a network-accessible port over a dial-up connection, am I in
violation of the license for disconnecting when *I'm* done, as opposed
to when whoever's downloading the source code off my is done?  If I run
the software on a network-connected cellphone or PDA where I pay per
byte, do I have to offer the source for download through the
phone/PDA?   If I run an email auto-responder service from behind a NAT
firewall, do I have to email the sources, too?

Personally, I doubt that any software so useful that it warrants letting
this particular camel's nose into the tent; I can see the rest of the
camel from here, and it's going to ruin the tent.
-- 
Stephen Ryan [EMAIL PROTECTED]



Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

2003-05-23 Thread Stephen Ryan
On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote:
 Anthony DeRobertis [EMAIL PROTECTED] writes:
 
  On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote:
 
  I don't.  If it makes use of features specific to the GNU version, it
  should either use the normally part of your OS exception, or if
  distributed with GNU grep be itself available under the GNU GPL.
 
  So every script that Debian distributes that makes use of features only
  found in GPL tools must be under the GPL (since Debian can't use the
  normal part of OS exception).
 
  Let's take a concrete example: apache-ssl. In particular, it's postint.
  It uses adduser, which is under the GPL. It also uses update-rc.d,
  also under the GPL. So, as above, we have to say the postinst is
  available under the GPL. However, it also uses
  /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the
  GPL and the OpenSSL license are not compatible.
 
  Is the above legal? If so, why? 
 
 I'm not a lawyer -- but I think distribution of apache-ssl.postinst
 must be distributed under the terms of the GPL.  As such, it can't be
 distributed by others without an OpenSSL exception or a license which
 grants a superset of the freedoms of the GPL.

I'm surprised no one else has jumped on this yet.

No.  The script in question is a derivative of both OpenSSL and of
adduser, and the author of the script has no legal standing to relicense
either of those.  Thus, no script which uses both OpenSSL and adduser
may be distributed by anyone under any terms, because it would link
OpenSSL with adduser, and they are under incompatible terms.  Even
though the script itself may offer an exception for OpenSSL, adduser
doesn't have that exception, and thus, the work as a whole is
undistributable.  

Wait.  Isn't dpkg under the GPL?  Now everything on the entire system
has to be under the GPL, because you can't even get it installed without
the use of dpkg.


The other option, of course, is that the kernel exec() function *is* a
barrier, Debian *can* be used for real work and not just an exercise in
ivory-tower masturbation.  
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Comments on GFDL, may be useful for statement

2003-04-29 Thread Stephen Ryan
 at least be removed rather than continuing to
disseminate incorrect information.


Q. But doesn't this mean that the original author will no longer be
able to protect his/her views from being misrepresented?

A. No worse than the ability to *add* additional things that the
original author doesn't agree with causes the original author to be
misrepresented. Invariant sections cut both ways, remember; not only
are the original author's views cast in stone forever, so are the
views of any other person who cares to add them and make them
invariant. In any case, one may only assume that the document reflects
at most the views of the last author to modify the document.  

Q. But the GPL itself is marked Verbatim copying only and you
distribute that.  Aren't you hypocrites?

A. First of all, only the preamble of the GPL is so marked; the FSF has
stated that you may take the actual content of the GPL and modify it to
produce another license, although they strongly recommend against it, in
that the modified license *will* be confusing.  Additionally, in many
jurisdictions, legal texts such as software licenses may not be
copyrighted, so as to prevent private monopolies on the law.  Finally,
as regards the effect of the license, the license must be preserved
intact in order for it to have any legal standing.  


Footnotes
-

[0] This point is a little tricky; I think that it is clear that if a
GFDL document were included into the source code of a GPL application
in the form

   const char * help = GFDL doc with invariant sections;

then that would constitute a violation of at least the GPL.  Further,
when talking about code, the FSF considers dynamic linking of a
library to be equivalent to static linking; that is, whether the
library is loaded at run-time or included as part of the binary on
disk is irrelevant, and the two parts cannot be distributed that way
unless the licenses are compatible.  Given that precedent, I think
it's a stretch to say that an application could load the document as
help text dynamically from a file, at run-time, but could not include
it as part of the binary, statically linked in.  Additionally,
context-sensitive help requires that the code know enough about the
documentation to know which part to display; this is *not* the same as
simply loading a document as raw data, because the application must
know about the meaning of the document in order to load the
appropriate parts, and furthermore depends on its existence.

[1] Yes, that's an insult; Free software is behind the times when it
comes to pervasive, integrated online help.  Many command line
applications are nicely documented by the man pages, but programs with
GUI interfaces could benefit greatly from the context-sensitive help
facilities which are standard features of commercial proprietary
software.  It is *not* a beneficial thing to discourage the
development of this, either.  Being able to point the mouse at
something on the screen and ask What is this? is a tremendous help
to people unfamiliar with the program.

[2]
http://lists.debian.org/debian-legal/2002/debian-legal-200212/msg00058.html
The error may or may not have been fixed in later releases of that
document. That point is irrelevant -- the fact that we have to sit
around and wait for the original author to update something wrong is
something that we have to do with proprietary software, not with Free
software.  If I really wanted that, I'd run Windows.

[3] Dr. Hook and the Medicine Show did the song Cover of the Rolling
Stone, which includes the lines

Wanna see my picture on the cover
Wanna buy five copies for my mother
and
We keep getting richer but we can't get our picture
On the cover of the Rolling Stone
It seemed apropos to me as I was writing this out.  Okay, so I'm weird.


[4] Yes, I know that the GFDL limits Cover Texts to some small amount,
significantly less than the 24 line spew from mkreiserfs, but I bet he
could get the whole thing in by having each contributor add a few
words from that spew as a cover text. Besides that, I don't intend to
pick on him particularly - anybody else's ego trip would be just as
ugly.

[5]
http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00455.html


-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: query from Georg Greve of GNU about Debian's opinion of the FDL

2003-04-14 Thread Stephen Ryan
On Mon, 2003-04-14 at 11:00, Georg C. F. Greve wrote:
...
 In the special case that you seem to be referring to, which is as
 author of a specialized help GUI, you could of course jump to the
 relevant paragraphs/parts of the documentation directly.

Um, not without the same type of intimate knowledge required to link a
library into the application.  So why is it okay to display a help text
in a GUI but not to dynamically link a library?  Consider:

Dynamically loaded Library:
---
* Loaded from a separate file at run-time.
* Need entry points, names, and API.
* Contains information needed to make the software work; use may be
optional; output may be visible to the user.
* Need to know what the specific part of the library being called does
in order for it to be useful.

Context-Sensitive Help:
---
* Loaded from a separate file at run-time.
* Need entry points, section names, and formatting information.
* Contains information needed to make the software usable; use may be
optional; output definitely visible to the user.
* Need to know what the specific part of the documentation says in order
for it to be useful.


When you explain the differences, please cover why using the technical
means of hard-coding printf() statements in the source code would be
clearly unacceptable, whereas loading the text from a file at run-time
would be acceptable.  Then tell us why the same argument doesn't work
for dynamically loading libraries vs. copying the source code into the
source for the application.

 That would make the relevant information immediately accessible
 without requiring to hide or remove any part of the document. 
 
 Hiding or even removing parts of the documentation doesn't seem
 necessary for that and in general does not seem like a useful job for
 the author of a GUI.

Information overload is not a feature.  Thus Free software must be
condemned to carry whatever ill-conceived poorly-edited crap for
documentation that is given to it, all because the author of the
documentation must be treated as though s/he were bringing the Ten
Commandments from on high.  Why should I get a copy of the GNU Manifesto
when I request help on saving files?  All I wanted was to know how to
save a file; speaking for myself, I get hostile when I get such
blatantly off-topic crap instead of help, and I'm sympathetic to the
cause of Software Freedom.  I can't imagine how someone not already
sympathetic to Freedom in software would react.  

 The decision of what a user wants to read should be made by the user,
 not by the author of his or her software.

I agree.  So every time the user asks for help, let's make him scroll
through the entire text of the Bible first, so that the user can make
the decision to read it or not, and not be limited by the author of the
software.  Of course, we wouldn't want to be discriminatory, so let's
include the Torah and the Koran and .  

Before you say that the Invariant Sections are different, keep in mind
that the license explicitly states that the only sections eligible to be
covered as Invariant Sections are off topic to begin with.  I think it's
really stupid to be enshrining off-topic material as something which
must be preserved forever.  Would your attitude be the same if the GNU
Emacs manual was distributed with some religious texts attached as the
Invariant Sections?  The Republican Party platform?  The Unabomber's
Manifesto?  Mein Kampf?  Something from Al-Qaeda?  All of the above, all
at once?  Anyone may add an Invariant Section; no-one may remove them. 
Thus, in the limit, every document under such a license will collapse
under its own weight.  See the FSF statement on the old BSD license for
why this is bad.


I've heard the argument about needing incentives for authors to write
documentation for Free software.  I don't buy it.  For one thing, that
argument should apply just as well to writing the software in the first
place.  For another, I don't see that there is any benefit to be gained
from higher quality documentation that isn't completely lost by the
loss of freedom -- and if there is such a benefit, why doesn't it apply
to software as well?
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: Dissident versus ASP

2003-03-19 Thread Stephen Ryan
On Wed, 2003-03-19 at 14:52, Jeremy Hankins wrote:

 You may want to go back and reread the message in question, I have a
 feeling you saw the bit about folks with big pipes and didn't read on
 about folks with smaller pipes.
 
 I gave suggested several ways in which things could be made easier:
 
 * If no changes have been made to the source, a URL to upstream may be
   sufficient.
 
 * If changes have been made and upstream incorporates them, a URL may
   still be sufficient.
 
 * If upstream doesn't incorporate the patches, distribution of patches
   along with the URL of upstream may be enough.
 
 * If even distribution of patches is onerous, include a written offer
   option, ala the GPL.
 
 * Going yet farther, a license may include a time delay (of one month,
   for example) before source distribution is required.
 
 I don't see that combination of options an onerous, even for folks
 with small pipes.  Do you?  If you think so, tell me who's going to
 have trouble meeting *any* of these requirements.

(I'm assuming we're still talking about a hypothetical future version of
the GPL, since people who license under BSD/MIT/X type licenses aren't
too likely to care about closing an ASP loophole.)

The current GPL doesn't allow anything like these.  No URLs, no
patches-only, no pointers to someone else hosting the source.  You (the
party distributing the binaries) must also distribute the *full* source
from the same place as the binaries, or you must provide a written
offer, valid for at least three years to provide the full source at
cost.  Providing an ASP is often done commercially because bandwidth and
hardware aren't free in either sense of the word, so the pass along
option is forbidden to such people.  Even if I'm just doing it for some
friends and some of them pitch in some money to help cover the bandwidth
bill, that probably counts as commercial.  

This isn't a matter of a few K of patch files.  This is a matter of
tens to hundreds of MBs of *full source*.  The GPL FAQ explicitly states
that pointers to upstream URLs are not a valid way of meeting the
license demands, and gives (good) reasons as to why patches and pointers
to other's copies of the source are not appropriate.


-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: The ASP nightmare: a description

2003-03-13 Thread Stephen Ryan
On Thu, 2003-03-13 at 15:05, Joe Moore wrote:
 Jeremy Hankins said:
  Joe Moore [EMAIL PROTECTED] writes:
  Jeremy Hankins said:
 
  Take this to the logical extreme where everybody starts doing this
  and every Free program has several ASP versions, and you have the ASP
  nightmare.
 
  How is this different (from a licensing perspective) from a
  publicly-accessible shell server?  Assume for a minute that all the
  GPL'd binaries on the server are chmod a-r, so no user can make a copy
  of the binaries (just to avoid the distribution issue).  This is
  exactly the line of thinking that caused problems with the LPPL 1.2
  (where their definition of distribution included making software
  available on a shared system)
 
  I don't know.  Is it?  Should it be?  I'm uncertain.
 
 I personally don't see a difference between a public-utility type service
 that gives CPU resources to remote users by running ASP code and a
 public-utility type service that gives CPU resources to remote users by
 running shell code.  (at least from a licensing standpoint)
 
  I think that so long as the source for these programs are generally
  available there's no real problem.  The problem shows up when someone
  uses this technique (which could be a web server or a shell server) to
  make the programs available for use but intentionally restricts access
  to source  binaries.
 
 Well, the current (and probably future) version of the GPL requires a lot
 more than generally available.  It requires equivalent access (at least)

Good grief!  So then any machine I own or control which is going to be
accessed by anyone besides myself, who has the possibility of copying
any binaries from it (current GPL) or has the possibility of running any
binary on it (hypothetical future GPL), said binaries including, say,
the network stack which responds to a ping over the network, must have
the source code installed on it so that any other user accessing that
machine may copy it as well, so as to satisfy equivalent access.  But
my Zaurus doesn't have enough storage space to even keep the source code
on it, so connecting my Zaurus to the 'net where someone else might
connect to it, even contrary without my permission, is in violation of
the GPL.  

I looked up public performance on Google, just to see what I could see,
and found that public performance is interpreted rather liberally, at
least in the context of music, so that public performance is any
performance of the work in the presence of persons outside one's
immediate family and close acquaintances, including otherwise private
members-only clubs.  The music industry has long asserted control over
public performance, and a few years ago suffered a PR black eye the
size of Texas when they sued the Girl Scouts for singing songs around a
campfire.  This is also why, in family restaurants, the staff sings a
house song celebrating the patron's natal anniversary, rather than
Happy Birthday when such occasions arise - it's so they don't have to
pay royalties every time they sing it.  

This is just the result of the music industry engaging in a scope creep
w.r.t. public performance, and is partly due to the fact that public
performance is not very well defined in the law.  Personally, I think
that the chance is quite high that someone could fall afoul of the
public performance clause of the hypothetical GPL-3 just as easily as
falling afoul of the public performance clause attached to music.  Do we
*really* want to call it Free when doing the equivalent of playing the
radio too close to customers violates the license?


Brett Glass[0] is starting to make sense to me.  That is a truly
terrifying thought.



[0] Moderately well-known anti-GPL troll, often found on ZD-Net boards.
All other anti-GPL trolls are small and cute in comparison. 
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: The Show So Far

2003-03-12 Thread Stephen Ryan
On Wed, 2003-03-12 at 04:12, Anthony Towns wrote:

[Much good stuff snipped]

 I think it would be really nice to be able to justify tests like:
 
   (d) can you use it completely naively - without reading,
   understanding or thinking about the license - without running
   the risk of violating the license
 
   (e) can you modify it to make it useful, then use it similarly
   naively?
 
 on similar technical grounds; since those things do have real benefits
 to users.

I think at least (d) should be a reasonable test.  Consider trying to
argue the opposite in front of a judge.  Well, your honor, I know that
the software looks like it's designed to do x, y, and z, and the default
installation of the software does x, y, and z as soon as it's installed,
but the license clearly states that .  This seems far too similar
to By reading this message you agree to send me $500 to me.

(e) seems to me to be (d) under the assumption that software should be
Free(tm).

Not having these carries with it the implicit message that freedom is
only for those willing to do the equivalent of subscribing to
debian-legal, and not at all for the casual user, which just enforces
the erroneous thought that Well, I can't program, so having the source
isn't any good to me anyway.

-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: Barriers to an ASP loophole closure (was Re: OSD DFSG - different purposes - constructive suggestion!)

2003-03-11 Thread Stephen Ryan
On Tue, 2003-03-11 at 11:58, Steve Langasek wrote:

 I find this an acceptable compromise.  The GPL already implements
 something very close to this:  if you give someone a copy, they're able
 to pass it on to a third party who in some cases then has grounds for
 demanding source from the author.  Extending that to letting a PCH demand
 access to changes if someone tells him about them doesn't seem too much
 of a stretch.

Close; the case in question for the GPL only arises in the case where
someone actually makes a written offer valid for at least three years.
Have you *ever* seen such an offer?  I haven't.  Was the entity making
that offer still around three years later?  

Further, it would seem that anyone making such an offer would know about
it, since they do have to write it down, and that explicitly states that
the offer is valid to any third party.  In other words, I can only be
screwed over by that clause if I agree to it in writing.  Extending to
the case where that's a mandatory part of the license is a rather
different story.



I've been trying to write down my objections to re-classifying public
performance (a.k.a. ordinary use w.r.t. server type software) as
distribution, and I'm beginning to conclude that GPL'd software is
inappropriate for casual copying, even without the added burden imposed
by closing the ASP loophole.


3a) requires that I give the complete copy of the source along with the
binary; if public performance is classified as distribution, I'd be
forced to ship the complete source code for the Linux kernel, Apache,
PHP, and who knows what all else with every web page so as to be clearly
in compliance with this section.  Adding a link to the source on someone
else's site would be very hard to defend in court as falling under this
section; hosting the source code myself means I've just agreed to become
a kernel.org mirror.  As an aside, this might mean that binary-only
mirrors are in technical violation of the GPL, because the source code
must be distributed with the binaries, and distribution of the source
code by a different entity probably doesn't count (in the same place,
from the comments after section ).

3b) requires that I make a multi-year commitment to being reachable
*and* agreeable to working without profit during that time period.  I
have no control over how far my written offer will be propagated without
my knowledge, yet I must honor that written offer, as any weakening of
this clause will lead to even larger loopholes than the ASP loophole. 
If the at cost clause is interpreted strictly, then I'm unwilling to
make such an offer, since it means that I have to do charity work while
the bank comes in to foreclose on my house.  If it is interpreted
loosely, then someone from the music or movie industry comes in and says
that their costs are very high, and that you'll have to pay a million
dollars for the source code.  Per file.  Either way, I've never seen
such an offer, and there's no way that I'll ever agree to make such an
offer without having enough cash in hand to ensure that I can survive
those three years on at cost work.

3c) requires that some other sucker has agreed to 3b) *and* that that
offer has been either made to me or relayed to me.  Furthermore, even if
I do have such an offer, I may not take advantage of it if I happen to
be engaged in commercial activity related to the distribution.  Right
now, I don't think that's much of a problem, but if public performance
is classified as distribution, then I think that it would be far too
easy to be engaged in commercial distribution -- e.g., any business
web site would be engaged in commercial distribution of Apache under
that definition.



I haven't yet gotten everything together in my head yet, but I'm afraid
that closing the ASP loophole will result in the possibility of being in
violation of the GPL-v3 simply by making a machine with too much
software on it accessible from the net.

Furthermore, if such a change is sloppily written, too much software
might mean a bare-bones bootable system, as responding to pings is a
service, too, and is hard to distinguish from software-that-cures-cancer
as an ASP (technically, that is; both receive network packets and
respond to them with other network packets; I am sure that there are
other protocols that aren't quite as trivial as ping but still far less
than something we'd actually call an ASP that could be used as an
example as well).  


-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: [Discussioni] OSD DFSG convergence

2003-03-05 Thread Stephen Ryan
On Tue, 2003-03-04 at 22:36, Russell Nelson wrote:


 To anybody who think I'm being insincere, or duplicitious, or not
 listening to you, or impervious to facts, I offer a hearty fuck you,
 fuck off, and fuck yourself.  

Right.  Rubbery green skin, smells bad, bad hair, obnoxious attitude. 
Back under the bridge with you!

*plonk*


-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: PHP4 And GPL mixing, what is linking?

2003-02-07 Thread Stephen Ryan
On Fri, 2003-02-07 at 09:04, James Michael DuPont wrote:
 Dear all,

...

 What about SQL database, can I prevent non-free software from using the
 database of a GPled application?

I don't particularly know about the rest, but this one is just plain
pure evil.  Don't do it.  Don't think about it.  Don't even try it. 
Leave this one for the Dark Side.

There are a couple of minor practical problems in the way you phrased
that, but those could probably be overcome with some work.  The part
that can't be overcome is that you are considering a restriction on
usage, rather than on modification or redistribution, and the GPL only
considers modification and redistribution, not usage.  

One thing I'm not clear on is whether the database in question is
intended to be a static database supplied with the application and never
altered afterwards, or whether said database includes any user input.  

If the database is built from user input, you have no legal standing to
demand that the user may not do as they please with their data.  In the
GPL, there is an explicit statement that the output of the program is
not covered unless its contents constitute a work based on the Program,
and whether that is true depends on what the Program does.  Such a claim
must be made carefully, because otherwise the author of any program
capable of writing arbitrary bits to disk could claim copyright over
every work written since.  Even with the restriction that the output
file needs to contain some copyright-able work from the author,
Microsoft might be able to claim copyright over every Word document in
existence, which would be a poor precedent to support.  Do not feed the
Cthulhu.  I note also that gcc and bison, in particular, disclaim
copyright on the output.

Whether the database includes user data or not, restricting the fashion
in which data may be used fails other things.  For instance, may one use
a non-free program to back up the data from such a program?  What about
restoring the data?  Restructuring the database for optimal performance
/ space usage / etc.?   Displaying usage statistics or other summaries
of the database?  May it be stored on a non-free filesystem?  May the
disk format be checked by a non-free program?  May the data be
compressed by a non-free archiving program?  Written to CD by a non-free
program?  Transferred by a non-free ftp program?  May the network
packets containing that data be passed through a non-free network router
(the source for most appliance-type routers is very definitely
proprietary)?  May I write a Free application which simply dumps the
data to stdout and provide a hint to the user that the non-free
application might do something useful with the output?  What if someone
else provides the hint?  What about two layers of indirection? 
Three?  
 
Obviously, these questions extend to the absurd, and yet some of these
show up in actual practice - e.g., I have actually written a backup
script for an Oracle database at work which dumps all fields of all
tables to a SQL script which would recreate the database.  

While I was googling for details on some of the licenses, I noticed that
you have been asking questions like this for a year; I'm afraid that
there are no easy answers to these questions.  Obviously, it grates to
think that Free software could be subverted into being used by non-Free
software, but the act of restricting that would make the (formerly) Free
software into something which is less Free than the non-Free.

He who fights with monsters might take care lest he thereby become a
monster.  -- Nietzsche

-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: Bug#173601: ITP: jpgraph -- OO Graph Library for PHP

2002-12-19 Thread Stephen Ryan
On Thu, 2002-12-19 at 12:36, Steve Langasek wrote:
 Hi Luis,
 
 On Wed, Dec 18, 2002 at 02:46:21PM -0500, Luis Bustamante wrote:
 
JpGraph is an OO class library for PHP 4.1 (or higher). JpGraph
  makes it easy to draw both quick and dirty graphs with a minimum of
  code and complex professional graphs which requires a very fine grain
  control. JpGraph is equally well suited for both scientific and
  business type of graphs.
 
  [cc to [EMAIL PROTECTED]
 
I want to package this software because the latest version of
  acidlab (which hasn't been uploaded yet[1]) requires it instead of
  phplot like previous version for graphing alert data of an
  IDS/Firewall. Anyway I'm not sure if we can include it in Debian as it
  uses QPL 1.0 and the author says in his page:
 
   JpGraph is released under a dual license.  QPL 1.0 (Qt Free
Licensee) For non-commercial, open-source and educational use and
JpGraph Professional License[2] for commercial use.
 
Can we include it in non-free despite the restriction it holds for
  commercial use? (if so acidlab should be in contrib then)
 
  References:
  1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155212
  2. http://www.aditus.nu/jpgraph/jpgprolicense.pdf
 
 If the QPL permits redistribution (I haven't read that license in a
 while), it should be ok for non-free.
 
 If acidlab upstream uses JpGraph, then of course you have little choice;
 but you might be interested to point them towards Vagrant
 http://vagrant.sourceforge.net/, an imlib-based PHP graphing class
 available under the GPL that gives very impressive-looking results.
 
 Cheers,

Waitaminnit.  Maybe I'm missing something here, but isn't the QPL a Free
Software license?  I didn't do that much of a careful search, but I
googled for QPL DFSG and found a bunch of hits that make it look like
the QPL is considered Free.  If so, then why shouldn't jpgraph go into
main?  The commercial clause is no more obnoxious than a
GPL/talk-to-me dual license, as it applies only in the case of
closed-source use.

What am I missing?
-- 
Stephen RyanDebian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: linux gpl question

2002-04-25 Thread Stephen Ryan
On Thu, 2002-04-25 at 07:15, martin f krafft wrote:
 [please cc me on responses]
 
 hey wise people,
 
 i have a question that's stunning us over here. there's someone
 selling a complete firewall appliance atop a linux kernel. he
 advertises it as hardened and as super-secure because he patched the
 kernel here and there, and because he added userland stuff.
 
 now my question: the kernel's gpl, so everything using the kernel
 source must be gpl. that does force this guy to make the source of all
 his kernel tree patches available, unless he provides binary patches
 for the kernel, right? in this case, does he have to let people know
 exactly which patches are applied?

I think he needs to provide the exact patched source code.

Quoting from the GPL:

2...a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

and

3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange;
or,

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

Section 3. c) does not apply, since he is the upstream for this
particular modification.

Together, these two sections mean that the complete source code must be
provided, and that the modified sections must be marked as such.

Unless he can come up with binary-only patches from nothing, his product
is a derivative of the Linux kernel source, and therefore must be
shipped with *complete* source code.  

 or, can he simply make the kernel source available, but ship it in
 binary only form with his patches applied?

Binaries are fine, but the complete source used to generate those
binaries is the source that must be supplied, per 3a) or 3b).

IANAL, TINLA, etc.
--  
Stephen RyanDebian GNU/Linux
Technology Coordinator
Center for Educational Outcomes at Dartmouth College


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: * WARNING: Crypto software to be included into main Debian distribution

2002-03-04 Thread Stephen Ryan
On Mon, 2002-03-04 at 03:09, [EMAIL PROTECTED] wrote:
 
   I don't know what the right list to bring this issue up is, so I
 write to all three lists to get to the right people. 
   
   Here are my views on the crypto on main subject.
   
   I suppose there has been debate on this subject before on other
 debian lists, but as I'm not subscribed to more than 3 and have no
 idea on where/when it may have sprung...
 
   My view is that by including crypto on main, and dissapearing it
 from non-us, the silly regulations from the US goverment are imposed
 on the US emargoed countries in an anti ethical way for two reasons:

Actually, this has absolutely *nothing* to do with crypto.  The trade
embargo is (at least for some countries) total, meaning that *nothing*
may be exported to those countries or imported from those countries. 
Not gcc.  Not even hello.  NOTHING.  NADA.  ABSOLUTELY NOTHING.  So
the problem arises if you have (supposedly) Free Software on a public
Internet site and the United States involved in any way whatsoever.  

The US embargo may be anti ethical, but it applies regardless.

 1. Software in non-us was not developed inside the US

Not always.  e.g. Kerberos and PGP were both developed inside the US,
legally exported and are now available outside the US and can be
imported back in.  Kerberos is Free, PGP is not (replaced by GPG which
is Free).

 and should not be restricted to 'export'  into other countries.

It isn't.  It just may not be exported FROM the US (and maybe other
countries; people who live in other countries need to be aware of the
local laws in their countries, and abide by them just as much as people
who live in the US need to be aware of the laws in the US and abide by
them).

 2. As I understand, the Free Software definition does not apply
 any sort of exception to US embargoed countries.
 
   So, either the Free Sofware definition gets reviewed and appends
 a clause stating that free software is 'free except in US embargoed
 countries', or Debian should stop saying it is Free software. Period.

Nothing in the Free Software definition (or the GPL) requires anyone to
violate local law in the process.  The worst thing that happens (in the
case of irreconcilable contradiction) is that you may not distribute the
software at all.  Nothing - I repeat, absolutely nothing, in either the
Free Software definition or the DFSG or any of the licenses involved,
requires me to distribute the software to *anyone*.  It only states what
must happen *if* and when I do distribute the software.  If local law
requires that I not distribute the software to certain persons, then I
am in violation of that law should I do so and I should rightly expect
to have the local law enforcement officials coming to bust my ass if I
break that law.

A friendly reminder that you should not break the law, and a few steps
to make sure that I do not break the law, does not make the software not
Free.  Free Software does not mean scofflaw - if the developers of
Free Software really were scofflaws, then none of us would bother
writing Free Software at all - we'd just pirate proprietary software
instead [we in a very loose sense of the word, since my personal Free
Software contributions are still quite small].  But we don't, because
that would be a violation of copyright law.  

   Restricting redistribution to a given country is in my opinion a blatant 
 violation of the GPL which states that no further restrictions should be 
 imposed on the software covered by it.

Actually, no.  Read section 8 of the GPL, which explicitly *includes*
such a clause.

   There may be a third option which would be to move the main distribution 
 servers of Debian outside the US (they are all within the US right now, 
 aren't they?).

Nice idea in theory.  Some of the folks I work with have a map which
shows worldwide backbone bandwidth.  If you cut the US out, you cut out
something between 75% and 90% of world-wide Internet bandwidth;
furthermore, those servers are donated; you'd have to find equivalent,
also donated servers outside the US in order to do that.  Servers and
bandwidth ain't cheap, but if you do find some, I'm sure the Debian
project would be pleased to accept.  You'd also have to find developers
outside the US to replace all those inside the US, since (as others have
already observed) the act of uploading something to a site known to
export to an embargoed country could be interpreted as a knowing act of
export to that country, and therefore a chargeable offense under US
law.  Your proposal would just make it more likely that all US
developers would have to quit, since every upload would be an export.
-- 
Stephen Ryan
Technology Coordinator
Center for Educational Outcomes at Dartmouth College



Problems in GNU FDL 1.2 Draft

2002-02-12 Thread Stephen Ryan
 the
 copies in covers that carry, clearly and legibly, all these Cover
 Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
 the back cover.  Both covers must also clearly and legibly identify
 you as the publisher of these copies.  The front cover must present
 the full title with all words of the title equally prominent and
 visible.  You may add other material on the covers in addition.
 Copying with changes limited to the covers, as long as they preserve
 the title of the Document and satisfy these conditions, can be treated
 as verbatim copying in other respects.
 
 If the required texts for either cover are too voluminous to fit
 legibly, you should put the first ones listed (as many as fit
 reasonably) on the actual cover, and continue the rest onto adjacent
 pages.


Hmm this seems familiar.  Where have I seen a license before that
required large amounts of invariant text to be printed, even if it was
inconvenient and required more space, and a well written objection to
it?  Ah, yes, right here:

http://www.gnu.org/philosophy/bsd.html

I'm only going to suggest that one should consider pots and kettles
*very* carefully, in light of the above referenced commentary on the
*BSD license before finalizing the new GNU FDL.  Eliminating Invariant
Sections as a permitted part of the FDL will also eliminate this
potential problem.


-- 
Stephen RyanDebian GNU/Linux
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College



Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiab le text

2001-12-04 Thread Stephen Ryan
On  4 Dec, Walter Landry wrote:

 I've already voted for this.  I think that Invariant text is an
 abomination.  It is unfortunate that the GNU manuals may be booted
 into non-free, but that is what happens when you forcefully interject
 political commentary into technical documentation.

Right on!  Between this and Henning's comments on the content of the
invariant sections, I think it is important to notice that the GFDL, if
used properly, *insists* that the invariant sections be off-topic,
and therefore a distraction and a waste of disk space (paper in the
case where the documentation is printed) *at best*, so that the absolute
very best thing you can get out of an invariant section is a
distraction, an off-topic tangent, something that lowers the overall
quality of the work.  Even though I happen to agree with some of the
political commentary in the GNU technical documentation, it remains
political commentary and therefore off-topic in technical documentation.



Stephen Ryan
not a DD but I hope to be one someday when I grow up