Re: Proposed plan (and license) for the webpage relicensing

2006-04-21 Thread Bdale Garbee
On Thu, 2006-04-20 at 15:48 -0700, Don Armstrong wrote:

 Should we decide to change the license, we should either use the MIT
 license if we don't want it to be copyleft, or the GPL if we do. A
 custom license is not something that we want to write, and especially
 not without serious thought and consideration between people who have
 a great deal of experience in writing licenses.
  
 Contributing to license proliferation by a license which is not
 compatible with the GPL and some other free software licenses is not
 something that we want to do.

Thank you for saying that before I could get around to it, Don.  I
strongly agree.

Bdale


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



Re: [debian-ntp] Bug#328200: Problems with ntp

2005-09-14 Thread Bdale Garbee
On Wed, 2005-09-14 at 00:03 -0700, Steve Langasek wrote:

 The maintainers should have a chance to clear up this question first.

I'll have a look at it today.

Bdale


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



Re: [debian-ntp] Bug#328200: Problems with ntp

2005-09-14 Thread Bdale Garbee
On Wed, 2005-09-14 at 00:03 -0700, Steve Langasek wrote:

 The maintainers should have a chance to clear up this question first.

Ok, I've just been through the ntp source tree looking at all the
copyright and license assertions.  Executive summary is that there are
indeed some problems, but it's not bad, and I believe it can be fixed
with an upload that elides certain bits from the upstream sources and
makes one small change in the source code.

Here's what I found...

The contents of the ElectricFence subdirectory are GPL, redundant with
the Debian packages, and comletely unused.  Since we have to elide the
upstream source anyway, we could clip this tree, or we could leave it
and add a suitable content to debian/copyright.

The file util/ansi2knr.c is also GPL.  I'm pretty sure it's unused, but
an easy reference in debian/copyright would cover it.

The contents of the adjtimed subdirectory and a few files scattered
around the rest of the tree are copyright by Tai Jin, with a unique
license that is clearly DFSG-ok.  I suggest we add suitable content to
debian/copyright taken from adjtimed/adjtimed.c.

The arlib subdirectory contents are non-free, but only relevant if
configure is called with the --with-arlib option that we don't use.  I
suggest this be elided from the upstream source for the Debian source
package.

The file html/build/hints/solaris-dosynctodr.html appears to have been
taken from a sun.com web page complete with links to a license assertion
on Sun web content that I don't even want to read.  We should remove
this file from our source package.

The files in html/pic include a couple of small images of products that
I presume came from manufacturer web sites, which are used to illustrate
the documentation.  No explicit assertions of copyright or license.  I
believe this is fair use, but if not they could be replaced with an icon
or something and nothing important would be lost.

The file include/global.h has an RSA copyright assertion with all
rights reserved and no other grant.  However, the files that include it
clearly came from the rsaref2.0 package, which has a BSD-like license
with advertising clause.  I believe this header file also was part of
that package and therefore covered by the same RSA license terms.
Therefore, I suggest the copyright and license terms from libntp/md5c.c
should be added to debian/copyright to cover all inclusions from
rsaref2.0.

There are several files that are BSD with advertising clause, including
libntp/memmove.c, libntp/mktime.c, libntp/random.c, libntp/strerror.c,
libntp/strstr.c, ntpd/refclock_jupiter.c, and ntpd/refclock_mx4200.c.
These should be referenced in debian/copyright.

There are several files that are BSD-like with advertising clause
(several different copyright holders), including libntp/md5c.c
(mentioned above), libntp/ntp_rfc2553.c, ntpd/refclock_jjy.c,
ntpd/refclock/palisade.c, ntpd/refclock_ripencc.c,
ntpd/refclock_ulink.c, scripts/ntpsweep.in, and all of the sntp subdir
(which I believe is unused).  These should also be referenced in
debian/copyright.

The file libntp/ranny.c is non-free, with a unique copyright and license
assertion:

  /*
   * Random number generator is:
   *
   *  Copyright 1988 by Rayan S. Zachariassen, all rights reserved.
   *  This will be free software, but only when it is finished.
   *
   * Used in ntp by permission of the author.  If copyright is
   * annoying to you, read no further.  Instead, look up the reference,
   * write me an equivalent to this and send it back to me.
   */

  /*
   * Random number generator; see Knuth Vol 2. 2nd ed. p.27 
   * (section 3.2.2)
   */

There is exactly one use of the ranp2() function defined in this file,
which appears in ntpd/ntp_peer.c.  I don't have Knuth nearby, but
staring at the source, this looks like a pseudo-randum generator that as
called is returning an unsigned long containing a random number in the
bottom 16 bits.  Since all it is being used for is to initialize an
association ID, I don't see why we couldn't replace the call to
init_random() in ntp/ntpd.c with a call to srand(time()), and then
replace ranp2(16) in ntpd/ntp_peer.c with rand()  0x?  That would
allow us to elide libntp/ranny.c and the references to it in
libntp/Makefile* from our source package, which is probably easier than
finding the author and asking him to relicense this bit.

That's it.  The rest looks fine to me.

Bdale


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



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

2003-08-21 Thread Bdale Garbee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] (Branden Robinson) writes:


 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.

   [   ]  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.

   [ X ]  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.

   [ X ]  I am a Debian Developer as described in the Debian
  Constitution as of the date on this survey.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/

iD8DBQE/RTB4ZKfAp/LPAagRAn+DAJwPUA4uY42sE9Qqq0kaOM9XoIhWgACfX8EB
Uk3hEv12UQyuGwKOv7EXSBQ=
=vbJu
-END PGP SIGNATURE-



subscribe

2002-03-18 Thread Bdale Garbee


DNSsafe license

1999-03-17 Thread Bdale Garbee
I maintain the BIND package for Debian.  The new 8.2 version of BIND has been
released, and one of the significant new features is the DNS security system.
This functionality depends on DNSsafe, which is code licensed by RSA Data 
Security to the Internet Software Consortium for use with BIND, clearly with
the intent that it be broadly deployed and used.

I've looked at the license, and I think it's ok.  However, I'm not an expert
on licenses like this, and I would appreciate review of the terms by the
debian-legal community, to confirm or deny complicance of this license with
the DFSG before I upload BIND 8.2 packages to main.

Bdale


DNSSAFE LICENSE TERMS

This BIND software includes the DNSsafe software from RSA Data
Security, Inc., which is copyrighted software that can only be
distributed under the terms of this license agreement.

The DNSsafe software cannot be used or distributed separately from the
BIND software.  You only have the right to use it or distribute it as
a bundled, integrated product.

The DNSsafe software can ONLY be used to provide authentication for
resource records in the Domain Name System, as specified in RFC 2065
and successors.  You cannot modify the BIND software to use the
DNSsafe software for other purposes, or to make its cryptographic
functions available to end-users for other uses.

If you modify the DNSsafe software itself, you cannot modify its
documented API, and you must grant RSA Data Security the right to use,
modify, and distribute your modifications, including the right to use
any patents or other intellectual property that your modifications
depend upon.

You must not remove, alter, or destroy any of RSA's copyright notices
or license information.  When distributing the software to the Federal
Government, it must be licensed to them as commercial computer
software protected under 48 CFR 12.212 of the FAR, or 48 CFR
227.7202.1 of the DFARS.

You must not violate United States export control laws by distributing
the DNSsafe software or information about it, when such distribution
is prohibited by law.

THE DNSSAFE SOFTWARE IS PROVIDED AS IS WITHOUT ANY WARRANTY
WHATSOEVER.  RSA HAS NO OBLIGATION TO SUPPORT, CORRECT, UPDATE OR
MAINTAIN THE RSA SOFTWARE.  RSA DISCLAIMS ALL WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO ANY MATTER WHATSOEVER, INCLUDING ALL
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY RIGHTS.

If you desire to use DNSsafe in ways that these terms do not permit,
please contact RSA Data Security, Inc., 100 Marine Parkway, Redwood
City, California 94065, USA, to discuss alternate licensing
arrangements.


Re: DNSsafe license

1999-03-17 Thread Bdale Garbee
In article [EMAIL PROTECTED] you wrote:
 I'm afraid this is definitely non-free.  It forbids distribution of
 modified versions on several counts:

Be patient with me.  I don't see the problem, at least not yet.  I wouldn't
have brought the license to debian-legal if I thought it were beyond question,
but some discussion will be required to convince me of your assertions.

 The DNSsafe software cannot be used or distributed separately from the
 BIND software.  You only have the right to use it or distribute it as
 a bundled, integrated product.

Which section of the DFSG does this violate?  It prevents me from packaging
things such that the DNSsafe library is a separate entity from BIND, clearly.
It means that someone else can't borrow the DNSsafe library from BIND without
negotiating a different license with RSA.  However, I fail to see how this 
restricts distribution of modified versions of BIND in any way.

 The DNSsafe software can ONLY be used to provide authentication for
 resource records in the Domain Name System, as specified in RFC 2065
 and successors.  You cannot modify the BIND software to use the
 DNSsafe software for other purposes, or to make its cryptographic
 functions available to end-users for other uses.

This is unfriendly to the free software community at large, to the extent that
someone might want to use the DNSsafe code for some non-DNS purpose which this
license would not cover, forcing them to negotiate a different license with
RSA.  But again, I don't see how this violates the DFSG... or how it in any
way prevents distribution of BIND.

 If you modify the DNSsafe software itself, you cannot modify its
 documented API, [...]

This one is the most problematic point for me.  I'd like the API to be as free
as the software, but I can't see how this violates the DFSG.  We have lots of
cases where free software implements one or the other side of a proprietary 
API, after all.

Bdale