[COMMIT] sign & encrypt changes

[COMMIT] sign & encrypt changes

[Josh Huber]

NOTE: This patch has been committed.

Please take a look at this, and test it out.

As I've mentioned before, there are two ways to sign & encrypt a
message:

1. perform the two operations separately: sign, then encrypt.
2. perform the two operations as one: sign & encrypt at the same time.

#2 is generally desireable.  I've made the changes for pgpmime to
support this style of signencrypt.  Whether or not Gnus tries to do
this is controlled by the mml-signencrypt-style alist -- as you can
see the only method using it is pgpmime.

For other methods, signencrypt == style #1 still.  I haven't changed
the code for pgp or smime yet, as I don't use those methods and I'd
like to make sure things are still sane at this point.

I've also fixed some documentation, and changed the default for
gnus-message-replysignencrypted. (t just makes more sense).

So, now when you C-c C-m c p, you'll get a secure tag which has
signencrypt as the mode, and you should get a single encrypted (and
also signed) part instead of an encrypted part which contains a signed
part.  Less overhead is good.

I'd also like to know if smime can perform this operation -- I seem to
remember someone mentioning that it didn't work for them.  Are you
supposed to be able to sign & encrypt in one invocation of
openssl (this is the utility used for smime, correct?)?

lisp/ChangeLog addition:

2002-05-01  Josh Huber  <huber@alum.wpi.edu>

	* gnus-msg.el (gnus-message-replysignencrypted): enabled by
	default.
	* mml-sec.el:
	* mml-sec.el (mml-signencrypt-style): New.
	* mml-sec.el (mml-pgpmime-encrypt-buffer): Accept optional
	argument `sign'.
	* mml-sec.el (mml-secure-message-encrypt-pgp): Changed default to
	signencrypt.
	* mml-sec.el (mml-secure-message-encrypt-pgpmime): Ditto.
	* mml.el (mml-generate-mime-1): Changed logic so a part which is
	both signed & encryped is processed in one operation. (rather than
	two separate ops: sign, then encrypt)
	* mml2015.el (mml2015-gpg-extract-signature-details): Give some
	indication if a message is signed by an expired key.
	* mml2015.el (mml2015-gpg-encrypt): Accept optional argument which
	enables combined sign & encrypt operation. (this was always on
	before).
	* mml2015.el (mml2015-encrypt): Accept optional argument `sign'.


texi/ChangeLog addition:

2002-05-01  Josh Huber  <huber@alum.wpi.edu>

	* gnus.texi (Signing and encrypting): Fix doc.  Also, add a
	paragraph about replysign/replyencrypt/replysignencryped use.


gnus source patch:
Diff command:   cvs -q diff -u
Files affected: texi/gnus.texi lisp/mml2015.el lisp/mml.el lisp/mml-sec.el lisp/gnus-msg.el

Index: lisp/gnus-msg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-msg.el,v
retrieving revision 6.87
diff -u -r6.87 gnus-msg.el
--- lisp/gnus-msg.el	2002/04/27 23:07:35	6.87
+++ lisp/gnus-msg.el	2002/05/01 22:06:22
@@ -234,7 +234,7 @@
   :type 'boolean)
 
 (defcustom gnus-message-replysignencrypted
-  nil
+  t
   "Setting this causes automatically encryped messages to also be signed."
   :group 'gnus-message
   :type 'boolean)
Index: lisp/mml-sec.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml-sec.el,v
retrieving revision 1.13
diff -u -r1.13 mml-sec.el
--- lisp/mml-sec.el	2002/04/14 04:10:15	1.13
+++ lisp/mml-sec.el	2002/05/01 22:06:22
@@ -46,6 +46,13 @@
 (defvar mml-default-encrypt-method (caar mml-encrypt-alist)
   "Default encryption method.")
 
+(defvar mml-signencrypt-style
+  '(("smime"   separate)
+    ("pgp"     separate)
+    ("pgpmime" combined))
+  "Alist specifying whether or not a single sign & encrypt
+operation should be perfomed when requesting signencrypt.")
+
 ;;; Security functions
 
 (defun mml-smime-sign-buffer (cont)
@@ -68,8 +75,8 @@
   (or (mml2015-sign cont)
       (error "Signing failed... inspect message logs for errors")))
 
-(defun mml-pgpmime-encrypt-buffer (cont)
-  (or (mml2015-encrypt cont)
+(defun mml-pgpmime-encrypt-buffer (cont &optional sign)
+  (or (mml2015-encrypt cont sign)
       (error "Encryption failed... inspect message logs for errors")))
 
 (defun mml-secure-part (method &optional sign)
@@ -174,21 +181,17 @@
   (interactive "P")
   (mml-secure-message "smime" (if dontsign 'encrypt 'signencrypt)))
 
-;;; NOTE: this should be switched to use signencrypt
-;;; once it does something sensible
 (defun mml-secure-message-encrypt-pgp (&optional dontsign)
   "Add MML tag to encrypt and sign the entire message.
 If called with a prefix argument, only encrypt (do NOT sign)."
   (interactive "P")
-  (mml-secure-message "pgp" (if dontsign 'encrypt 'encrypt)))
+  (mml-secure-message "pgp" (if dontsign 'encrypt 'signencrypt)))
 
-;;; NOTE: this should be switched to use signencrypt
-;;; once it does something sensible
 (defun mml-secure-message-encrypt-pgpmime (&optional dontsign)
   "Add MML tag to encrypt and sign the entire message.
 If called with a prefix argument, only encrypt (do NOT sign)."
   (interactive "P")
-  (mml-secure-message "pgpmime" (if dontsign 'encrypt 'encrypt)))
+  (mml-secure-message "pgpmime" (if dontsign 'encrypt 'signencrypt)))
 
 (provide 'mml-sec)
 
Index: lisp/mml.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml.el,v
retrieving revision 6.53
diff -u -r6.53 mml.el
--- lisp/mml.el	2002/04/14 04:10:15	6.53
+++ lisp/mml.el	2002/05/01 22:06:22
@@ -530,22 +530,30 @@
 	      (insert "\n--" mml-boundary "--\n")))))
        (t
 	(error "Invalid element: %S" cont)))
-      (let ((item (assoc (cdr (assq 'sign cont)) mml-sign-alist))
+      ;; handle sign & encrypt tags in a semi-smart way.
+      (let ((sign-item (assoc (cdr (assq 'sign cont)) mml-sign-alist))
+	    (encrypt-item (assoc (cdr (assq 'encrypt cont))
+				 mml-encrypt-alist))
 	    sender recipients)
-	(when item
+	(when (or sign-item encrypt-item)
 	  (if (setq sender (cdr (assq 'sender cont)))
 	      (message-options-set 'message-sender sender))
 	  (if (setq recipients (cdr (assq 'recipients cont)))
 	      (message-options-set 'message-recipients recipients))
-	  (funcall (nth 1 item) cont)))
-      (let ((item (assoc (cdr (assq 'encrypt cont)) mml-encrypt-alist))
-	    sender recipients)
-	(when item
-	  (if (setq sender (cdr (assq 'sender cont)))
-	      (message-options-set 'message-sender sender))
-	  (if (setq recipients (cdr (assq 'recipients cont)))
-	      (message-options-set 'message-recipients recipients))
-	  (funcall (nth 1 item) cont))))))
+	  (let ((style (second (assoc (first sign-item)
+				      mml-signencrypt-style))))
+	    ;; check if: we're both signing & encrypting, both methods
+	    ;; are the same (why would they be different?!), and that
+	    ;; the signencrypt style allows for combined operation.
+	    (if (and sign-item encrypt-item (equal (first sign-item)
+						   (first encrypt-item))
+		     (equal style 'combined))
+		(funcall (nth 1 encrypt-item) cont t)
+	      ;; otherwise, revert to the old behavior.
+	      (when sign-item
+		(funcall (nth 1 sign-item) cont))
+	      (when encrypt-item
+		(funcall (nth 1 encrypt-item) cont)))))))))
 
 (defun mml-compute-boundary (cont)
   "Return a unique boundary that does not exist in CONT."
Index: lisp/mml2015.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml2015.el,v
retrieving revision 6.43
diff -u -r6.43 mml2015.el
--- lisp/mml2015.el	2002/02/20 00:15:32	6.43
+++ lisp/mml2015.el	2002/05/01 22:06:22
@@ -414,10 +414,13 @@
 (defun mml2015-gpg-extract-signature-details ()
   (goto-char (point-min))
   (if (boundp 'gpg-unabbrev-trust-alist)
-      (let* ((signer (and (re-search-forward
-			   "^\\[GNUPG:\\] GOODSIG [0-9A-Za-z]* \\(.*\\)$"
+      (let* ((expired (re-search-forward
+		       "^\\[GNUPG:\\] SIGEXPIRED$"
+		       nil t))
+	     (signer (and (re-search-forward
+			   "^\\[GNUPG:\\] GOODSIG \\([0-9A-Za-z]*\\) \\(.*\\)$"
 			   nil t)
-			  (match-string 1)))
+			  (cons (match-string 1) (match-string 2))))
 	     (fprint (and (re-search-forward
 			   "^\\[GNUPG:\\] VALIDSIG \\([0-9a-zA-Z]*\\) "
 			   nil t)
@@ -429,12 +432,16 @@
 	     (trust-good-enough-p
 	      (cdr (assoc (cdr (assoc trust gpg-unabbrev-trust-alist))
 			  mml2015-trust-boundaries-alist))))
-	(if (and signer trust fprint)
-	    (concat signer
-		    (unless trust-good-enough-p
-		      (concat "\nUntrusted, Fingerprint: "
-			      (mml2015-gpg-pretty-print-fpr fprint))))
-	  "From unknown user"))
+	(cond ((and signer fprint)
+	       (concat (cdr signer)
+		       (unless trust-good-enough-p
+			 (concat "\nUntrusted, Fingerprint: "
+				 (mml2015-gpg-pretty-print-fpr fprint)))
+		       (when expired
+			 (format "\nWARNING: Signature from expired key (%s)"
+			  (car signer)))))
+	      (t
+	       "From unknown user")))
     (if (re-search-forward "^gpg: Good signature from \"\\(.*\\)\"$" nil t)
 	(match-string 1)
       "From unknown user")))
@@ -559,28 +566,39 @@
       (insert (format "--%s--\n" boundary))
       (goto-char (point-max)))))
 
-(defun mml2015-gpg-encrypt (cont)
+(defun mml2015-gpg-encrypt (cont &optional sign-also)
   (let ((boundary
 	 (funcall mml-boundary-function (incf mml-multipart-number)))
 	(text (current-buffer))
 	cipher)
     (mm-with-unibyte-current-buffer-mule4
       (with-temp-buffer
-	(unless (gpg-sign-encrypt
-		 text (setq cipher (current-buffer))
-		 mml2015-result-buffer
-		 (split-string
-		  (or
-		   (message-options-get 'message-recipients)
-		   (message-options-set 'message-recipients
-					(read-string "Recipients: ")))
-		  "[ \f\t\n\r\v,]+")
-		 nil
-		 (message-options-get 'message-sender)
-		 t t) ; armor & textmode
-	  (unless (> (point-max) (point-min))
-	    (pop-to-buffer mml2015-result-buffer)
-	    (error "Encrypt error")))
+	(flet ((gpg-encrypt-func 
+		 (sign plaintext ciphertext result recipients &optional
+		       passphrase sign-with-key armor textmode)
+		 (if sign-also
+		     (gpg-sign-encrypt
+		      plaintext ciphertext result recipients passphrase
+		      sign-with-key armor textmode)
+		   (gpg-encrypt
+		    plaintext ciphertext result recipients passphrase
+		    armor textmode))))
+	  (unless (gpg-encrypt-func
+		    sign-also ; passed in when using signencrypt
+		    text (setq cipher (current-buffer))
+		    mml2015-result-buffer
+		    (split-string
+		     (or
+		      (message-options-get 'message-recipients)
+		      (message-options-set 'message-recipients
+					   (read-string "Recipients: ")))
+		     "[ \f\t\n\r\v,]+")
+		    nil
+		    (message-options-get 'message-sender)
+		    t t) ; armor & textmode
+	    (unless (> (point-max) (point-min))
+	      (pop-to-buffer mml2015-result-buffer)
+	      (error "Encrypt error"))))
 	(goto-char (point-min))
 	(while (re-search-forward "\r+$" nil t)
 	  (replace-match "" t t))
@@ -641,11 +659,11 @@
   mml2015-use)
 
 ;;;###autoload
-(defun mml2015-encrypt (cont)
+(defun mml2015-encrypt (cont &optional sign)
   (mml2015-clean-buffer)
   (let ((func (nth 2 (assq mml2015-use mml2015-function-alist))))
     (if func
-	(funcall func cont)
+	(funcall func cont sign)
       (error "Cannot find encrypt function"))))
 
 ;;;###autoload
Index: texi/gnus.texi
===================================================================
RCS file: /usr/local/cvsroot/gnus/texi/gnus.texi,v
retrieving revision 6.276
diff -u -r6.276 gnus.texi
--- texi/gnus.texi	2002/05/01 00:18:31	6.276
+++ texi/gnus.texi	2002/05/01 22:06:28
@@ -11226,6 +11226,14 @@
 @sc{Mailcrypt}, you need to install at least one of them.  The
 @sc{s/mime} support in Gnus requires the external program OpenSSL.
 
+Often, you would like to sign replies to people who send you signed
+messages.  Even more often, you might want to encrypt messages which
+are in reply to encrypted messages.  Gnus offers
+@code{gnus-message-replysign} to enable the former, and
+@code{gnus-message-replyencrypt} for the latter.  In addition, setting
+@code{gnus-message-replysignencrypted} (on by default) will sign
+automatically encrypted messages.
+
 Instructing MML to perform security operations on a @sc{mime} part is
 done using the @kbd{C-c C-m s} key map for signing and the @kbd{C-c
 C-m c} key map for encryption, as follows.
@@ -11234,39 +11242,39 @@
 
 @item C-c C-m s s
 @kindex C-c C-m s s
-@findex mml-secure-sign-smime
+@findex mml-secure-message-sign-smime
 
-Digitally sign current @sc{mime} part using @sc{s/mime}.
+Digitally sign current message using @sc{s/mime}.
 
 @item C-c C-m s o
 @kindex C-c C-m s o
-@findex mml-secure-sign-pgp
+@findex mml-secure-message-sign-pgp
 
-Digitally sign current @sc{mime} part using PGP.
+Digitally sign current message using PGP.
 
 @item C-c C-m s p
 @kindex C-c C-m s p
-@findex mml-secure-sign-pgp
+@findex mml-secure-message-sign-pgp
 
-Digitally sign current @sc{mime} part using @sc{pgp/mime}.
+Digitally sign current message using @sc{pgp/mime}.
 
 @item C-c C-m c s
 @kindex C-c C-m c s
-@findex mml-secure-encrypt-smime
+@findex mml-secure-message-encrypt-smime
 
-Digitally encrypt current @sc{mime} part using @sc{s/mime}.
+Digitally encrypt current message using @sc{s/mime}.
 
 @item C-c C-m c o
 @kindex C-c C-m c o
-@findex mml-secure-encrypt-pgp
+@findex mml-secure-message-encrypt-pgp
 
-Digitally encrypt current @sc{mime} part using PGP.
+Digitally encrypt current message using PGP.
 
 @item C-c C-m c p
 @kindex C-c C-m c p
-@findex mml-secure-encrypt-pgpmime
+@findex mml-secure-message-encrypt-pgpmime
 
-Digitally encrypt current @sc{mime} part using @sc{pgp/mime}.
+Digitally encrypt current message using @sc{pgp/mime}.
 
 @item C-c C-m C-n
 @kindex C-c C-m C-n

-- 
Josh Huber

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Josh Huber <huber@alum.wpi.edu> writes:

> As I've mentioned before, there are two ways to sign & encrypt a
> message:
>
> 1. perform the two operations separately: sign, then encrypt.
> 2. perform the two operations as one: sign & encrypt at the same time.
>
> #2 is generally desireable.

It breaks PGP 2 support with some GnuPG versions.  I'm not sure if
GnuPG 1.0.7 corrects this.

Re: [COMMIT] sign & encrypt changes

[Josh Huber]

Florian Weimer <fw@deneb.enyo.de> writes:

> It breaks PGP 2 support with some GnuPG versions.  I'm not sure if
> GnuPG 1.0.7 corrects this.

Okay, since I don't have pgp2, nor do I know anyone still using it,
could you test it for me?  Perhaps it should be easier to configure if
it's going to cause problems for some people.

Why does it break pgp2 support, btw?  (even with the --pgp2 option?)

Thanks,

-- 
Josh Huber

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Josh Huber <huber@alum.wpi.edu> writes:

>> It breaks PGP 2 support with some GnuPG versions.  I'm not sure if
>> GnuPG 1.0.7 corrects this.
>
> Okay, since I don't have pgp2, nor do I know anyone still using it,
> could you test it for me?

I can't test it reliably, either.  But I'm going to ask on the GnuPG
mailing list.

> Why does it break pgp2 support, btw?

GnuPG 1.0.6 cannot create PGP 2 compatible sign+encrypt messages in
one go.  IIRC, Werner misread the OpenPGP specification and didn't
implement a required feature (he thought that it was optional or
something like that).

> (even with the --pgp2 option?)

--pgp2 is 1.0.7 stuff.

Re: [COMMIT] sign & encrypt changes

[Josh Huber]

Florian Weimer <fw@deneb.enyo.de> writes:

> GnuPG 1.0.6 cannot create PGP 2 compatible sign+encrypt messages in
> one go.  IIRC, Werner misread the OpenPGP specification and didn't
> implement a required feature (he thought that it was optional or
> something like that).

Okay, I see.

> --pgp2 is 1.0.7 stuff.

Alright.  I'm on the gnupg-users list as well...I guess I just
remember reading about that option recently. :)

Thanks for checking this out,

-- 
Josh Huber

Re: [COMMIT] sign & encrypt changes

[Dmitry Bely]

Florian Weimer <fw@deneb.enyo.de> writes:

> --pgp2 is 1.0.7 stuff.

BTW, Florian, are you going to include any support for gpg 1.0.7
--search-keys option into your gpg.el? E.g. the possibility to import
unknown keys "on the fly" would be very useful...

Hope to hear from you soon,
Dmitry

Re: [COMMIT] sign & encrypt changes

[Josh Huber]

Dmitry Bely <dbely@mail.ru> writes:

> BTW, Florian, are you going to include any support for gpg 1.0.7
> --search-keys option into your gpg.el? E.g. the possibility to
> import unknown keys "on the fly" would be very useful...

For the purpose of importing unknown keys on the fly, how is this
different than specifying a keyserver in the gnupg options file?

ttyl,

-- 
Josh Huber

Re: [COMMIT] sign & encrypt changes

[Dmitry Bely]

Josh Huber <huber@alum.wpi.edu> writes:

>> BTW, Florian, are you going to include any support for gpg 1.0.7
>> --search-keys option into your gpg.el? E.g. the possibility to
>> import unknown keys "on the fly" would be very useful...
>
> For the purpose of importing unknown keys on the fly, how is this
> different than specifying a keyserver in the gnupg options file?

... and auto-key-retrieve. Yes, indeed. But anyway explicit search support
would be useful.

Hope to hear from you soon,
Dmitry

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

>> For the purpose of importing unknown keys on the fly, how is this
>> different than specifying a keyserver in the gnupg options file?
>
> ... and auto-key-retrieve.

Auto-key-retrieve can be abused to hide "bugs" in messages.

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> --pgp2 is 1.0.7 stuff.
>
> BTW, Florian, are you going to include any support for gpg 1.0.7
> --search-keys option into your gpg.el?

Most likely no.  gpg.el is dead, I won't invest any more work into it.
I can't get the copyright from the university, and they won't assign
it to the FSF.  Anybody is most welcome to rewrite it from scratch.
(I'll do that myself one day, I guess.)

Work in gpg.el usually means changes to Gnus, and while I've signed
papers for Gnus, I haven't for gpg.el (or Emacs or GnuPG), and for my
own safety, I have to keep these two things separate.

> E.g. the possibility to import unknown keys "on the fly" would be
> very useful...

Indeed.

Re: [COMMIT] sign & encrypt changes

[Dmitry Bely]

Florian Weimer <fw@deneb.enyo.de> writes:

>> BTW, Florian, are you going to include any support for gpg 1.0.7
>> --search-keys option into your gpg.el?
>
> Most likely no.  gpg.el is dead, I won't invest any more work into it.
> I can't get the copyright from the university, and they won't assign
> it to the FSF.  Anybody is most welcome to rewrite it from scratch.
> (I'll do that myself one day, I guess.)

Ahh... I did not noticed that it has University Of Stuttgart copyright. But
why this is so bad? Anyway it's GPL'ed so I see no problem here. They are
going to sell it under different license? Good luck! :-)

> Work in gpg.el usually means changes to Gnus, and while I've signed
> papers for Gnus, I haven't for gpg.el (or Emacs or GnuPG), and for my
> own safety, I have to keep these two things separate.

It's a pity, if not to say more. Mailcrypt is dead, gpg.el (which I think
is superior to Mailcrypt) is dead also. Who is going to live? :-)

>> E.g. the possibility to import unknown keys "on the fly" would be
>> very useful...
>
> Indeed.

Hope to hear from you soon,
Dmitry

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>>> BTW, Florian, are you going to include any support for gpg 1.0.7
>>> --search-keys option into your gpg.el?
>>
>> Most likely no.  gpg.el is dead, I won't invest any more work into it.
>> I can't get the copyright from the university, and they won't assign
>> it to the FSF.  Anybody is most welcome to rewrite it from scratch.
>> (I'll do that myself one day, I guess.)
>
> Ahh... I did not noticed that it has University Of Stuttgart copyright. But
> why this is so bad? Anyway it's GPL'ed so I see no problem here. They are
> going to sell it under different license? Good luck! :-)

I wrote gpg.el in order to have something which could be integrated
into GnuPG or GNU Emacs some day.  Back then, I was told that the
university wouldn't oppose assigning the copyright...

Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

>> Ahh... I did not noticed that it has University Of Stuttgart copyright. But
>> why this is so bad? Anyway it's GPL'ed so I see no problem here. They are
>> going to sell it under different license? Good luck! :-)
>
> I wrote gpg.el in order to have something which could be integrated
> into GnuPG or GNU Emacs some day.  Back then, I was told that the
> university wouldn't oppose assigning the copyright...

Probably this is a bit of offtipic, but could you explain me why
transfering the copyright to FSF is necessary? Why some GPL'ed sources,
those copyright is holded by somebody else, cannot be supplied with Gnus?
(Or "integrated", if you like this word). Why they cannot be maintained?
What you are afraid of?

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

>>> Ahh... I did not noticed that it has University Of Stuttgart copyright. But
>>> why this is so bad? Anyway it's GPL'ed so I see no problem here. They are
>>> going to sell it under different license? Good luck! :-)
>>
>> I wrote gpg.el in order to have something which could be integrated
>> into GnuPG or GNU Emacs some day.  Back then, I was told that the
>> university wouldn't oppose assigning the copyright...
>
> Probably this is a bit of offtipic, but could you explain me why
> transfering the copyright to FSF is necessary? Why some GPL'ed sources,
> those copyright is holded by somebody else, cannot be supplied with Gnus?

That's official FSF policy we cannot change.

> What you are afraid of?

The copyright owner might claim that it never released the source
under the GPL, and try to extract royalties or damages from the FSF.
A valid assignment contract makes this extremely unlikely, but without
such a contract, you are in the mercy of the copyright owner to some
extent.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Jorgen Schaefer]

Florian Weimer <fw@deneb.enyo.de> writes:

> The copyright owner might claim that it never released the source
> under the GPL, and try to extract royalties or damages from the FSF.
> A valid assignment contract makes this extremely unlikely, but without
> such a contract, you are in the mercy of the copyright owner to some
> extent.

Also, only the copyright holder may sue someone over a copyright
infringment. So the FSF can only defend a program if it is indeed
the copyright holder.

Quoting the document of the FSF on this issue:

| Project GNU has to be careful to obey intellectual property laws,
| even though these laws are wrong and people generally should share
| useful information without hesitation, because we are in the
| public eye.
| 
| This means that if you want to contribute software, you have to do
| something to give us legal permission to use it. There are four
| ways this can be done:
| 
| * Assign the copyright to the Free Software Foundation. This is
|   what we prefer because it allows us to use the copyright law to
|   prevent others from hoarding modified versions of the program.
| 
| * Keep the copyright yourself and give us a suitable nonexclusive
|   license. It will then be up to you to prevent any unauthorized
|   hoarding of modified versions; we will be unable to act. (This
|   alternative is impractical for us if the use for your work is to
|   be merged into a preexisting GNU program.)
| 
| * Keep the copyright and release the program yourself under the
|   GNU GPL. (This alternative too is impractical for contributions
|   to a preexisting GNU program.)
| 
| * Put the code in the public domain. Then there is nothing to stop
|   hoarding of modified versions, but we can still use the program
|   in GNU.
| 
| Most of these alternatives require a signed piece of paper to make
| it happen.

HTH,
        -- Jorgen

-- 
((email . "forcer@forcix.cx")          (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg .    "1024D/028AF63C"))

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Jorgen Schaefer <forcer@forcix.cx> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> The copyright owner might claim that it never released the source
>> under the GPL, and try to extract royalties or damages from the FSF.
>> A valid assignment contract makes this extremely unlikely, but without
>> such a contract, you are in the mercy of the copyright owner to some
>> extent.

Why not to ask University for the signed paper confirming that gpg.el is
really released under GPL license? (although I can hardly believe they can
deny that)

> Also, only the copyright holder may sue someone over a copyright
> infringment. So the FSF can only defend a program if it is indeed
> the copyright holder.

1. Is there at least *one* case where FSF has defended its software in
the court? 
2. After modificating gpg.el in any way *you* will be the copyright holder
also. Transfer this copyright to FSF and release the updated gpg.el with

Copyright (C) 2000 RUS-CERT, University Of Stuttgart
Copyright (C) 2002 Free Software Foundation, Inc.

If your new code will be stolen, you can ask FSF to defend your rights in
the court. What is the problem?

> Quoting the document of the FSF on this issue:
>
> | Project GNU has to be careful to obey intellectual property laws,
> | even though these laws are wrong and people generally should share
> | useful information without hesitation, because we are in the
> | public eye.
> | 
> | This means that if you want to contribute software, you have to do
> | something to give us legal permission to use it. There are four
> | ways this can be done:
> | 
> | * Assign the copyright to the Free Software Foundation. This is
> |   what we prefer because it allows us to use the copyright law to
> |   prevent others from hoarding modified versions of the program.
> | 
> | * Keep the copyright yourself and give us a suitable nonexclusive
> |   license. It will then be up to you to prevent any unauthorized
> |   hoarding of modified versions; we will be unable to act. (This
> |   alternative is impractical for us if the use for your work is to
> |   be merged into a preexisting GNU program.)

It's our case. Release new updated gpg.el as a separate Emacs package (or
leave it in ./contrib), and everybody will be happy.

Just to dot the i's: Do you realize how many copyright holders are involved
e.g. into the Linux kernel? And nobody cares. Many developers participate
in its delopment. XEmacs, which I use and prefer to GNU Emacs, has

Copyright (C) 1985-1999 Free Software Foundation, Inc.
Copyright (C) 1990-1994 Lucid, Inc.
Copyright (C) 1993-1997 Sun Microsystems, Inc. All Rights Reserved.
Copyright (C) 1994-1996 Board of Trustees, University of Illinois
Copyright (C) 1995-1996 Ben Wing

Nobody cares also. So Gnus community position on copyright issues looks
like a bit paranoid to me ...

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Kai Großjohann]

Dmitry Bely <dbely@mail.ru> writes:

> Nobody cares also. So Gnus community position on copyright issues looks
> like a bit paranoid to me ...

It is not the position of the Gnus community.  Gnus is part of Emacs,
and that's where the requirement comes from.  It is not enough to
convince the Gnus maintainer(s), you need to convince the Emacs
maintainer(s), as well.  And that means RMS, and he has thought about
this for a _long_ time and surely he's got a very firm position on this.

kai
-- 
Silence is foo!

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Groъjohann) writes:

>> Nobody cares also. So Gnus community position on copyright issues looks
>> like a bit paranoid to me ...
>
> It is not the position of the Gnus community.  Gnus is part of Emacs,

Is not it a separate package that can work under GNU Emacs? GNU Emacs is
*not* required for Gnus: it can also very successfully work under XEmacs,
which obviously does not conform to RMS' general line.

> and that's where the requirement comes from.  It is not enough to
> convince the Gnus maintainer(s), you need to convince the Emacs
> maintainer(s), as well.  And that means RMS, and he has thought about
> this for a _long_ time and surely he's got a very firm position on this.

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Paul Jarc]

Dmitry Bely <dbely@mail.ru> wrote:
> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Groъjohann) writes:
>> It is not the position of the Gnus community.  Gnus is part of Emacs,
>
> Is not it a separate package that can work under GNU Emacs? GNU Emacs is
> *not* required for Gnus: it can also very successfully work under XEmacs,
> which obviously does not conform to RMS' general line.

Gnus is distributed as its own package, but also GNU Emacs includes
Gnus in its distribution tarball.  For that to happen, Gnus's
copyright must be completely held by the FSF.  If we loosen the
restrictions for Gnus, then we can't have it included in Emacs
anymore.

That might not be such a bad thing, though.  People sometimes have
trouble with load-path conflicts when trying to use a newer Gnus than
the one that came with their Emacs.  Or they sometimes have trouble
because they're using the old version that came with their Emacs
instead of the latest version.


paul

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> That might not be such a bad thing, though.

On the whole, I think it is good to have Gnus included in Emacs.

kai
-- 
Silence is foo!

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> That might not be such a bad thing, though.

Most Gnus users are using the version bundled with Emacs (according to
the last User-Agent statistics I saw).  Not the XEmacs version, or the
unbundled version.  If Gnus development split, I'd contribute to the
bundled version of Gnus.

And I believe being paranoid over legal issues is a smart thing.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
>
>> That might not be such a bad thing, though.
>
> Most Gnus users are using the version bundled with Emacs (according to
> the last User-Agent statistics I saw).  Not the XEmacs version, or the
> unbundled version.  If Gnus development split, I'd contribute to the
> bundled version of Gnus.

Gnus has already been split into non-FSF owned Gnus branches -- I
believe several of the T-Gnus, Chao-Gnus, Nana-Gnus, Et-Gnus,
Shoe-Gnus, Semi-Gnus etc branches includes, or included at some point
in time, non-FSF owned code that implements additional features.
FWIW, I'd contribute to the bundled version as well.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> That might not be such a bad thing, though.
>
> Most Gnus users are using the version bundled with Emacs (according to
> the last User-Agent statistics I saw).  Not the XEmacs version, or the
> unbundled version.

Anyway, this "monolitic tarball" approach looks archaic nowadays. Most
users needs *binary* [X]Emacs distribution and sophisticated package system
(like XEmacs has) that lets the end user to update his/her system without
downloading and recompiling everything.

>  If Gnus development split, I'd contribute to the
> bundled version of Gnus.

Nobody wants the development split, but FSF policy makes everything for
that. Ask yourself: why all these Gnus clones exists?

> And I believe being paranoid over legal issues is a smart thing.

Only when somebody proves in court that GNU license really works, they will
become "legal".

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Matthieu Moy]

Dmitry Bely <dbely@mail.ru> writes:

> Anyway, this "monolitic tarball" approach looks archaic nowadays. Most
> users needs *binary* [X]Emacs distribution and sophisticated package system
> (like XEmacs has) that lets the end user to update his/her system without
> downloading and recompiling everything.

But very few people will  like to have 3 packages (Emacs/Gnus/BBDB) to
download,  compile, configure,  ... before  being able  to  simply use
mail.  I liked to  be able  to type  M-x gnus  from a  newly installed
Emacs. 

Then, if distributions (like Debian  and Mandrake) like to split Emacs
and Gnus in several packages,  then, why not, because the distribution
itself provides integration.

-- 
Matthieu

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

>> Anyway, this "monolitic tarball" approach looks archaic nowadays. Most
>> users needs *binary* [X]Emacs distribution and sophisticated package system
>> (like XEmacs has) that lets the end user to update his/her system without
>> downloading and recompiling everything.
>
> But very few people will  like to have 3 packages (Emacs/Gnus/BBDB) to
> download,  compile, configure,  ... before  being able  to  simply use
> mail.  I liked to  be able  to type  M-x gnus  from a  newly installed
> Emacs.

With XEmacs you should just select Tools->Packages->List and install,
specify what you need, and it will do all the rest.

> Then, if distributions (like Debian  and Mandrake) like to split Emacs
> and Gnus in several packages,  then, why not, because the distribution
> itself provides integration.

Possible. Anyway, there is no real need to have Gnus included into Emacs
tarball and to follow FSF copyright policy.

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Matthieu Moy]

Dmitry Bely <dbely@mail.ru> writes:

> With XEmacs you should just select Tools->Packages->List and install,
> specify what you need, and it will do all the rest.

You need at  least to have an internet connection  and download it. It
is very enoying  to have to download  each time you want to  use a new
function. 

-- 
Matthieu

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Dmitry Bely <dbely@mail.ru> writes:

> Anyway, this "monolitic tarball" approach looks archaic nowadays. 

It was archaic case 10 years ago, when Emacs was large compared to
normal hard disks.  Today, Emacs is a tiny application by modern
standards, and unbundling make a lot less sense than it used to.  

> Most users needs *binary* [X]Emacs distribution and sophisticated
> package system (like XEmacs has) that lets the end user to update
> his/her system without downloading and recompiling everything.

These days, I tend to update Emacs on my local machine automatically
together with everything else by running dselect.  I _do_ remember the
time when I downloaded and compiled everything myself, but I disagree
that doing that is what most users need these days.

>>  If Gnus development split, I'd contribute to the
>> bundled version of Gnus.
>
> Nobody wants the development split, but FSF policy makes everything for
> that. Ask yourself: why all these Gnus clones exists?

Because most Japanese developers have problems with English?  The
documentation and mailing lists for the forks (not clones) seem to be
predominatingly in Japanese.  Apparently, they also have problems
cooperating with each others, since there are so many of them.

>> And I believe being paranoid over legal issues is a smart thing.
>
> Only when somebody proves in court that GNU license really works, they will
> become "legal".

When the GPL has proven itself in court, one of several reasons to
insist on a single copyright owner will be removed.  You need a single
copyright owner (or at least strong disclaimers from the other owners)
to change the license.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Sean Neakums]

commence  Per Abrahamsen quotation:

>> Only when somebody proves in court that GNU license really works,
>> they will become "legal".
>
> When the GPL has proven itself in court, one of several reasons to
> insist on a single copyright owner will be removed.  You need a single
> copyright owner (or at least strong disclaimers from the other owners)
> to change the license.

However, I believe the primary reason that the FSF requires copyright
to be assigned to it is that it has received legal advice that any
actions it might take against copyright violations would be much
weakened if it did not hold copyright on all the code in question.  It
has little to do with the GPL itself, apart from the fact that the GPL
is a copyright license.  This is touched on here:

http://www.fsf.org/licenses/gpl-violation.html

> Note that the GPL, and other copyleft licenses, are copyright
> licenses. This means that only the copyright holders are empowered
> to act against violations. The FSF acts on all GPL violations
> reported on FSF copyrighted code, and we offer assistance to any
> other copyright holder who wishes to do the same.
>
> But, we cannot act on our own if we do not hold copyright. Thus, be
> sure to find out who the copyright holders of the software are
> before reporting a violation.

-- 
 /////////////////  |                  | The spark of a pin
<sneakums@zork.net> |  (require 'gnu)  | dropping, falling feather-like.
 \\\\\\\\\\\\\\\\\  |                  | There is too much noise.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Mon, 06 May 2002 13:31:16 +0100, Sean Neakums <sneakums@zork.net> said:

Sean> However, I believe the primary reason that the FSF requires copyright
Sean> to be assigned to it is that it has received legal advice that any
Sean> actions it might take against copyright violations would be much
Sean> weakened if it did not hold copyright on all the code in question.

I'd be willing to bet they have a large number of illegally assigned
copyrights (say where a person says he's working on his own outside of
work but who was actually doing so during work time, on work computers
and it's probably quite provable that he was).

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[William M. Perry]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> On Mon, 06 May 2002 13:31:16 +0100, Sean Neakums <sneakums@zork.net> said:
>
> Sean> However, I believe the primary reason that the FSF requires copyright
> Sean> to be assigned to it is that it has received legal advice that any
> Sean> actions it might take against copyright violations would be much
> Sean> weakened if it did not hold copyright on all the code in question.
>
> I'd be willing to bet they have a large number of illegally assigned
> copyrights (say where a person says he's working on his own outside of
> work but who was actually doing so during work time, on work computers
> and it's probably quite provable that he was).

This is why the FSF also requires a disclaimer from your employer in most
cases.  My employer signs a 5-year blanket disclaimer at a time for me.

-bp
-- 
Ceterum censeo vi esse delendam

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Mon, 06 May 2002 10:31:25 -0500, wmperry@gnu.org (William M. Perry) said:

William> This is why the FSF also requires a disclaimer from your
William> employer in most cases.

It's the "most" that worries me.  I know their in the policy of doing
so, but I doubt they check out the claims from the people (ie, figure
out who they're employed by and send the employer something).

William> My employer signs a 5-year blanket disclaimer at a time for
William> me.

That's very cool of them.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Wes Hardaker <wes@hardakers.net> writes:

> I'd be willing to bet they have a large number of illegally assigned
> copyrights

All the assignments the have received from me are illegal in the
strict sense of the word: as a German, I cannot assign copyright, only
ea usufruct of a copyright (commonly called exploitation rights).  (Of
course, I have informed the FSF about this problem, and the contract
is probably valid before a US court, which is the most important thing
for them.)

But if someone illegally assigns copyright in the majority of the
cases (e.g. if there is a third party having rights to the code),
that's not the problem of the FSF, but of the poor developer.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Florian Weimer <fw@deneb.enyo.de> writes:

> All the assignments the have received from me are illegal in the
> strict sense of the word: as a German, I cannot assign copyright, only
> ea usufruct of a copyright (commonly called exploitation rights). 

Is that still the case?  Danish copyright law was changed a few years
ago to allow transfer of "all rights", making it much more similar to
US law.  I assumed this was some kind of EU standardization.

In any case, I doubt my assignment on "future work" would be valid in
a Danish court, it is too generic.  So I might be able to stop
distribution of Emacs temporarily in Denmark.  I guess the free
software community would survive ;-)

> But if someone illegally assigns copyright in the majority of the
> cases (e.g. if there is a third party having rights to the code),
> that's not the problem of the FSF, but of the poor developer.

It could become the FSF problem if the rightful owner tried to stop
distribution.  But it might protect them from having to pay damages,
they are clearly in good faith.

As I said before, it is all a question of multiple lines of defence. 

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> Most users needs *binary* [X]Emacs distribution and sophisticated
>> package system (like XEmacs has) that lets the end user to update
>> his/her system without downloading and recompiling everything.
>
> These days, I tend to update Emacs on my local machine automatically
> together with everything else by running dselect.  I _do_ remember the
> time when I downloaded and compiled everything myself, but I disagree
> that doing that is what most users need these days.

All XEmacs packages are already precompiled. You may include them in the
distribution, my update them off the XEmacs website, or may create
the neccessary .deb packages, that will be handled by apt/dselect. In any
case I fail to understand why having Gnus included into Emacs tarball (and
following FSF copyright policy) is so important.

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Simon Josefsson]

On Mon, 6 May 2002, Dmitry Bely wrote:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> >> Most users needs *binary* [X]Emacs distribution and sophisticated
> >> package system (like XEmacs has) that lets the end user to update
> >> his/her system without downloading and recompiling everything.
> >
> > These days, I tend to update Emacs on my local machine automatically
> > together with everything else by running dselect.  I _do_ remember the
> > time when I downloaded and compiled everything myself, but I disagree
> > that doing that is what most users need these days.
> 
> All XEmacs packages are already precompiled. You may include them in the
> distribution, my update them off the XEmacs website, or may create
> the neccessary .deb packages, that will be handled by apt/dselect. In any
> case I fail to understand why having Gnus included into Emacs tarball (and
> following FSF copyright policy) is so important.

Because it is included?  If our goal isn't to be included in Emacs, we can
chose this and go our own path (like all previous Gnus forks has done).  
But then someone else will maintain the Gnus copy that IS included in
Emacs, and I suspect most developers will follow that route instead.

If you want Emacs to use a package model so that Gnus is not shipped with
Emacs, this is the wrong mailing list for that discussion and emacs-devel
is probably more appropriate.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Simon Josefsson <jas@extundo.com> writes:

>> All XEmacs packages are already precompiled. You may include them in the
>> distribution, my update them off the XEmacs website, or may create
>> the necessary .deb packages, that will be handled by apt/dselect. In any
>> case I fail to understand why having Gnus included into Emacs tarball (and
>> following FSF copyright policy) is so important.
>
> Because it is included?

So there is no real reason.

> If our goal isn't to be included in Emacs, we can
> chose this and go our own path (like all previous Gnus forks has done).  
> But then someone else will maintain the Gnus copy that IS included in
> Emacs, and I suspect most developers will follow that route instead.
>
> If you want Emacs to use a package model so that Gnus is not shipped with
> Emacs, this is the wrong mailing list for that discussion and emacs-devel
> is probably more appropriate.

This topic was started from Florian Weimer's statement that he cannot any
longer develop gpg.el because gpg.el does not follow FSF copyright policy
which is necessary because Gnus is included into GNU Emacs tarball. I think
I have explained why in fact there is no real reason for Gnus to continue
following FSF policy and abandoning any copyrighted code. So I think now
the topic is really over.

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Simon Josefsson]

On Mon, 6 May 2002, Dmitry Bely wrote:

> >> All XEmacs packages are already precompiled. You may include them in the
> >> distribution, my update them off the XEmacs website, or may create
> >> the necessary .deb packages, that will be handled by apt/dselect. In any
> >> case I fail to understand why having Gnus included into Emacs tarball (and
> >> following FSF copyright policy) is so important.
> >
> > Because it is included?
> 
> So there is no real reason.

Having it included is reason enough for me.

I would agree that it would be _better_ if Emacs supported a package
system so that Gnus could be released more frequently, but last time I saw
the discussion about package systems on emacs-devel I got the impression
that RMS didn't like it.

> This topic was started from Florian Weimer's statement that he cannot any
> longer develop gpg.el because gpg.el does not follow FSF copyright policy
> which is necessary because Gnus is included into GNU Emacs tarball.

Yes, so gpg.el should be removed and replaced with a FSF-owned PGP/GPG
interface IMHO.  There is one called PGG and I'm looking at merging it
into Gnus.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> Yes, so gpg.el should be removed and replaced with a FSF-owned PGP/GPG
> interface IMHO.  There is one called PGG and I'm looking at merging it
> into Gnus.

I agree.  The sooner we can get rid of gpg.el, the better.

However, I can't find any information on an Elisp version of PGG.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> I would agree that it would be _better_ if Emacs supported a package
> system so that Gnus could be released more frequently, but last time I saw
> the discussion about package systems on emacs-devel I got the impression
> that RMS didn't like it.

Well, the maintainer of the XEmacs package system recommended that RMS
did _not_ adopt it for Emacs in its current form.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Simon Josefsson]

On Tue, 7 May 2002, Per Abrahamsen wrote:

> Simon Josefsson <jas@extundo.com> writes:
> 
> > I would agree that it would be _better_ if Emacs supported a package
> > system so that Gnus could be released more frequently, but last time I saw
> > the discussion about package systems on emacs-devel I got the impression
> > that RMS didn't like it.
> 
> Well, the maintainer of the XEmacs package system recommended that RMS
> did _not_ adopt it for Emacs in its current form.

An earlier discussion left me with the impression that the whole concept 
of packages was too complicated and that something simpler should be done.  
No description of what that could be was given, and the discussion died.

(A search functionality for the emacs-devel list would be quite useful... 
I gave up looking for the message after going through a few months worth 
of data.)

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Simon Josefsson <jas@extundo.com> writes:

>> >> All XEmacs packages are already precompiled. You may include them in the
>> >> distribution, my update them off the XEmacs website, or may create
>> >> the necessary .deb packages, that will be handled by apt/dselect. In any
>> >> case I fail to understand why having Gnus included into Emacs tarball (and
>> >> following FSF copyright policy) is so important.
>> >
>> > Because it is included?
>> 
>> So there is no real reason.
>
> Having it included is reason enough for me.

Have you really compiled your Emacs from sources? Most people just use the
binary package that is included into their OS distribution. And it's up to
package maintainer whether to include Gnus, say, into emacs-bla-bla.deb, or
create two separate packages emacs-bla-bla.deb and gnus-bla-bla.deb. GNU
Emacs tarball contents has nothing to do with that.

> I would agree that it would be _better_ if Emacs supported a package
> system so that Gnus could be released more frequently,

It generally does not matter if GNU Emacs has package system or not. Even
if it has not, OS packages are enough. Obviously FSF copyright policy does
not affect them.

> but last time I saw the discussion about package systems on emacs-devel I
> got the impression that RMS didn't like it.

One more reason to choose XEmacs :-)

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Tue, 07 May 2002 21:16:37 +0400, Dmitry Bely <dbely@mail.ru> said:

Dmitry> Have you really compiled your Emacs from sources?

I do.  I like to compile in specific options to XEmacs (like disabling
the toolbar support, as it's just a waste of space (but I do have
gutters enabled since I have a time tracking system that puts the
status in the gutter (I've spent 3m 6s writing this so far)).  Also, I
tend to use the later and frequently beta branches of XEmacs...

Dmitry> Most people just use the binary package that is included into
Dmitry> their OS distribution.

Most people do, I'm sure.  But you're asking a list that probably
isn't composed of "most".
-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Dmitry Bely]

Wes Hardaker <wes@hardakers.net> writes:

> I do.  I like to compile in specific options to XEmacs (like disabling
> the toolbar support, as it's just a waste of space (but I do have
> gutters enabled since I have a time tracking system that puts the
> status in the gutter (I've spent 3m 6s writing this so far)).  Also, I
> tend to use the later and frequently beta branches of XEmacs...
>
> Dmitry> Most people just use the binary package that is included into
> Dmitry> their OS distribution.
>
> Most people do, I'm sure.  But you're asking a list that probably
> isn't composed of "most".

People in this list do not use the older Gnus included in Emacs
source distribution. They download the separate package from
ftp.gnus.org (or even checkout CVS) and install it themselves. (BTW, not
only Gnus. There are valuable elisp packages that are distributed only
separately). The average user just installs its OS' binary package. For
whom including Gnus into the source Emacs tarball is so important?

Hope to hear from you soon,
Dmitry

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Dmitry Bely <dbely@mail.ru> writes:

> People in this list do not use the older Gnus included in Emacs source
> distribution. They download the separate package from ftp.gnus.org (or
> even checkout CVS) and install it themselves. (BTW, not only Gnus. There
> are valuable elisp packages that are distributed only separately). The
> average user just installs its OS' binary package. For whom including
> Gnus into the source Emacs tarball is so important?

Me.  My users all use the Gnus that comes with XEmacs or Emacs, and that's
quite a few people here at Stanford.  And if it were separated out from
Emacs, that would either involve a bunch of additional work for me to
separately install it and then keep it in sync with the Emacs version or a
decision to just only make Gnus available to XEmacs users.

I personally run some CVS version of Gnus dating from the last time that I
felt like doing a cvs update, but that's not an acceptable version for the
average user.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Dmitry Bely <dbely@mail.ru> writes:

> The average user just installs its OS' binary package.

Are there any OS'es where installing the "emacs" package gets you
another version of Gnus than what is bundled?

> For whom including Gnus into the source Emacs tarball is so
> important?

Me.  I use CVS Gnus, but everyone else at KVL use the version bundled
with Emacs.  I want my improvements to eventually benefit them.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Dmitry Bely <dbely@mail.ru> writes:

> Have you really compiled your Emacs from sources?

Of course.  How else am I going to get Emacs for Solaris?  sunfreeware
isn't stuff I'd really trust unless I was desperate or didn't have any
sort of compiler, and I don't want to use Sun's odd version (besides, I
might not have purchased Forte).

> Most people just use the binary package that is included into their OS
> distribution.

If they're running Linux.  Or maybe one of the *BSDs.  Or a binary Windows
download (although that's not the OS distribution).  There are a whole
bunch of other operating systems out there; all the world is not Linux.  :)

> It generally does not matter if GNU Emacs has package system or
> not. Even if it has not, OS packages are enough.

s/OS/Linux/; maintaining Emacs add-ons with separate SysV packages isn't
something I'd particularly recommend to anyone.  And see note above about
ubiquity of Linux.  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Dmitry Bely <dbely@mail.ru> writes:

> I think I have explained why in fact there is no real reason for Gnus to
> continue following FSF policy and abandoning any copyrighted code. So I
> think now the topic is really over.

Except that people don't agree with you.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> It was archaic case 10 years ago, when Emacs was large compared to
> normal hard disks.  Today, Emacs is a tiny application by modern
> standards, and unbundling make a lot less sense than it used to.

And package management systems make life hard for people like me, who are
trying to maintain a central software installation in an unusual file
system like AFS.  They mostly assume that you can just blithely install
stuff into the compiled-in paths, which of course isn't true in AFS which
requires one to install into a different location and then release.

I really like XEmacs (much better than Emacs) from an installation
perspective, but that's not because of the packaging system.  That's
because the sumo tarballs have considerably more stuff bundled than the
Emacs, which reduces the amount of stuff I have to hunt down separately
and install myself.  I often don't even bother because building is too
much of a pain, which means that XEmacs users have more Lisp packages
available than Emacs users.

It would be really cool if someone would put together a Sumo equivalent
for Emacs containing the stuff that has unclear licensing that the FSF
can't ship with Emacs itself.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Amos Gouaux]

>>>>> On Mon, 06 May 2002 11:55:04 -0700,
>>>>> Russ Allbery <rra@stanford.edu> (ra) writes:

ra> And package management systems make life hard for people like me, who are
ra> trying to maintain a central software installation in an unusual file
ra> system like AFS.  They mostly assume that you can just blithely install
ra> stuff into the compiled-in paths, which of course isn't true in AFS which
ra> requires one to install into a different location and then release.

We don't use AFS, but structure things somewhat similarly with a
twisted mixture of tools.  For the most part it makes deploying
software on a large scale more convenient, especially backing out a
boo-boo.  However, I concur that package systems can at times make
this a horrible hell to cope with.

(Seems ironic.  Long ago I wished that all software would use
autoconf so that I could easily set the "prefix" Makefile var during
"make install".  Gradually, this became more and more common as
time went by.  But HO!  Now there are all these package environments 
that require even more fiddling.  Funny how things improve to be
more flexible.  Alas, I digress way too much.)

ra> I really like XEmacs (much better than Emacs) from an installation
ra> perspective, but that's not because of the packaging system.  That's
ra> because the sumo tarballs have considerably more stuff bundled than the
ra> Emacs, which reduces the amount of stuff I have to hunt down separately
ra> and install myself.  I often don't even bother because building is too
ra> much of a pain, which means that XEmacs users have more Lisp packages
ra> available than Emacs users.

To be honest, this was one of the reasons why I've been primarily
using XEmacs for the last couple of years after virtually growing up
on Emacs.  Very convenient indeed.  And because of the package
structure, it was pretty easy to script the removal of things that
we didn't necessarily want to deploy.

ra> It would be really cool if someone would put together a Sumo equivalent
ra> for Emacs containing the stuff that has unclear licensing that the FSF
ra> can't ship with Emacs itself.

Not only that, but Emacs itself (yeah, topic for another list I'm sure)....

-- 
Amos

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Mon, 06 May 2002 11:55:04 -0700, Russ Allbery <rra@stanford.edu> said:

Russ> And package management systems make life hard for people like
Russ> me, who are trying to maintain a central software installation
Russ> in an unusual file system like AFS.  They mostly assume that you
Russ> can just blithely install stuff into the compiled-in paths,
Russ> which of course isn't true in AFS which requires one to install
Russ> into a different location and then release.

One way to accomplish things under AFS is to have one machine which
always points their afs links to the rw space and thus you can pretty
much do builds on that machine.  Thus doing package installs on an
XEmacs running on that machine wouldn't cause problems for you.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Wes Hardaker <wes@hardakers.net> writes:

> One way to accomplish things under AFS is to have one machine which
> always points their afs links to the rw space and thus you can pretty
> much do builds on that machine.  Thus doing package installs on an
> XEmacs running on that machine wouldn't cause problems for you.

Yeah, that does work for the most part.  It does have the drawback,
though, that an ill-behaved package manager can write all sorts of stuff
into the wrong places and won't be stopped by the normal read-only
volumes, which means that I often have to clean up after things that
decided they could mess around in a /usr/local/bin equivalent rather than
just writing into the package directory (which is usually redirected to
its own volume via a symlink).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Mon, 06 May 2002 13:25:11 -0700, Russ Allbery <rra@stanford.edu> said:

Russ> Yeah, that does work for the most part.  It does have the
Russ> drawback, though, that an ill-behaved package manager can write
Russ> all sorts of stuff into the wrong places and won't be stopped by
Russ> the normal read-only volumes, which means that I often have to
Russ> clean up after things that decided they could mess around in a
Russ> /usr/local/bin equivalent rather than just writing into the
Russ> package directory (which is usually redirected to its own volume
Russ> via a symlink).

I didn't say it solved *all* your problems ;-)

AFS is a pain sometimes, but always worth it (IMHO) in large scale
deployments.  A side effect of even being able to do a 'vos release'
is having a more difficult installation process for certain packages.
I actually have heard DCE handles this better but I haven't played withit.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Russ Allbery]

Wes Hardaker <wes@hardakers.net> writes:

> AFS is a pain sometimes, but always worth it (IMHO) in large scale
> deployments.  A side effect of even being able to do a 'vos release' is
> having a more difficult installation process for certain packages.  I
> actually have heard DCE handles this better but I haven't played withit.

I adore AFS.  We manage a site-wide installation of over 500 packages with
just one and a half FTEs; there's no way that I could do that without AFS.

We tried to use DFS back when it was first being pushed by Transarc and
had it fail horribly on us.  Incredibly complex, unstable, slow, and
difficult to work with.  We abandoned any attempt to switch and never
looked back.  AFS has its quirks, but it's still head and shoulders above
anything else that's available in terms of enterprise file systems.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Russ Allbery <rra@stanford.edu> writes:

> I adore AFS.  We manage a site-wide installation of over 500 packages with
> just one and a half FTEs; there's no way that I could do that without AFS.

AFS always impresses me when I see it in action (mostly when something
strange happens to my home directory at the math department).

> We tried to use DFS back when it was first being pushed by Transarc and
> had it fail horribly on us.

Our computing center ins considering migrating back to AFS for a
distributed file system because DFS support is simply not there on
most machines.  (I'm still surprised are concerned with UNIX
distributed file systems, officially, it's a Microsoft shop.)

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Mon, 06 May 2002 14:20:49 -0700, Russ Allbery <rra@stanford.edu> said:

Russ> I adore AFS.  We manage a site-wide installation of over 500
Russ> packages with just one and a half FTEs; there's no way that I
Russ> could do that without AFS.

Yep.  I've lived it for numerous years until my current position and I
couldn't imagine running an infrastructure without it.  It does,
however, have it's quirks.  But the benefits outweigh the quirks.

Oh, and to keep us on topic with the mailing list: gnus rocks too.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Kai Großjohann]

Russ Allbery <rra@stanford.edu> writes:

> I really like XEmacs (much better than Emacs) from an installation
> perspective, but that's not because of the packaging system.  That's
> because the sumo tarballs have considerably more stuff bundled than the
> Emacs, which reduces the amount of stuff I have to hunt down separately
> and install myself.  I often don't even bother because building is too
> much of a pain, which means that XEmacs users have more Lisp packages
> available than Emacs users.

Recently, I've started to think that building is a pain, too, so for
example JDE I just untarred into the site-lisp directory, done.  That
was not so much of a pain :-)

kai
-- 
Silence is foo!

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

> Only when somebody proves in court that GNU license really works, they will
> become "legal".

Why don't you help to create a precedent by infringing the GPL?

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Dmitry Bely <dbely@mail.ru> writes:

> Why not to ask University for the signed paper confirming that gpg.el is
> really released under GPL license? (although I can hardly believe they can
> deny that)

Won't happen.  gpg.el is neither research, nor can you earn money by
licensing it under the GPL.

> 1. Is there at least *one* case where FSF has defended its software in
> the court? 

GPL violations are copyright violations if the GPL is not effective.
Nobody dared to challenge this in court yet.

> 2. After modificating gpg.el in any way *you* will be the copyright holder
> also. Transfer this copyright to FSF and release the updated gpg.el with
>
> Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> Copyright (C) 2002 Free Software Foundation, Inc.
>
> If your new code will be stolen, you can ask FSF to defend your rights in
> the court. What is the problem?

I won't do that because it will get me into extremely murky terrain
(at least as long as I'm working at RUS-CERT).

> Nobody cares also. So Gnus community position on copyright issues looks
> like a bit paranoid to me ...

It's the FSF policy.  If we changed it, the FSF would stop releasing
Gnus along with GNU Emacs, something we certainly wish to avoid.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Fri, 03 May 2002 21:18:23 +0200, Florian Weimer <fw@deneb.enyo.de> said:

Florian> It's the FSF policy.  If we changed it, the FSF would stop
Florian> releasing Gnus along with GNU Emacs, something we certainly
Florian> wish to avoid.

The real problem is that the FSF's forced assignment essentially slows
development progress because it excludes developers who can't do
assignments but who could otherwise still effectively release GPLed
software.  I'm not saying that the FSF is doing a bad thing, but it
does cause problems like this one where they've effectively limited
who can work on a project based not on copyrights but on assignment
issues.  And sub-projects like Gnus are affected if they wish to be
deployed with the parent project.  I'm surprised RMS hasn't tried to
force Debian to go to only GPL assigned code (which greatly greatly
cripple the usability of the distribution).

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Florian Weimer]

Wes Hardaker <wes@hardakers.net> writes:

> The real problem is that the FSF's forced assignment essentially slows
> development progress because it excludes developers who can't do
> assignments but who could otherwise still effectively release GPLed
> software.  I'm not saying that the FSF is doing a bad thing, but it
> does cause problems like this one where they've effectively limited
> who can work on a project based not on copyrights but on assignment
> issues.

Yes, of course, and I've become a victim of this process myself.
However, freedom is more important than advancement of technology...

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Wes Hardaker <wes@hardakers.net> writes:

> The real problem is that the FSF's forced assignment essentially slows
> development progress because it excludes developers who can't do
> assignments but who could otherwise still effectively release GPLed
> software. 

I think _most_ people (not FW) who complain actually _can_ do
assignments, it is merely an inconvenience.  Especially since the FSF
contracts are negotiable (contracts tend to be).

> I'm surprised RMS hasn't tried to force Debian to go to only GPL
> assigned code (which greatly greatly cripple the usability of the
> distribution).

FSF themselves distribute lots of code with no papers.  And they don't
have papers for core part of GNU, such as X11.

Why then have papers on any parts?  Think of it as multiple lines of
defence.  I believe lawyers always think that way.

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Wes Hardaker]

>>>>> On Sat, 04 May 2002 16:27:24 +0200, Per Abrahamsen <abraham@dina.kvl.dk> said:

Per> I think _most_ people (not FW) who complain actually _can_ do
Per> assignments, it is merely an inconvenience.  Especially since the FSF
Per> contracts are negotiable (contracts tend to be).

I don't see it as they can't personally, but rather the company they
work for might be more than willing to say "sure, go ahead and submit
your code to the OSS project under the GPL".  The instant you ask them
to sign something, however, they have to consult their legal team and
then invariably it'll end up getting passed to someone who's heard bad
things about the GPL and the 7 line patch will no longer be exportable
from that source.  Or, university employees have to go through a slew
of paperwork to release stuff.  9/10 times I'd be the direct boss
would just say to "do it" and not to go through the business and
contracts office to do the right thing for a 7 line patch.

I think the FSF's goals are admirable and their cause is a good one,
however they're harming productivity.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Copyright/license issues (was: [COMMIT] sign & encrypt changes)

[Per Abrahamsen]

Wes Hardaker <wes@hardakers.net> writes:

> I don't see it as they can't personally, but rather the company they
> work for might be more than willing to say "sure, go ahead and submit
> your code to the OSS project under the GPL". 

The simplest paper is the disclaimer, which just states that they will
make no legal claims on the software in question.  I believe it is 10
lines long, and it doesn't mention the GPL or any other license.

The one time I had to get such a signature, my departement head used
about 30 seconds to decide that "no, he could not image AT&T having an
economic interest in Danish keyboard remapping for Emacs".  While
other bosses may be more conservative, I doubt anything in that
disclaimer can scare a lawyer.

The long contracts are generally for author of the code, and are
mostly about additional rights and guarentees provided by the FSF.

Re: Copyright/license issues

[Werner Koch]

On Fri, 03 May 2002 17:57:24 +0400, Dmitry Bely said:

> Why not to ask University for the signed paper confirming that gpg.el is
> really released under GPL license? (although I can hardly believe they can
> deny that)

It is really a tough job to convince this university.  We have tried
for a long time to get assignments for Florian's GnuPG enhancements
and it all ended up that someone else had to write them froms cratch.

> 1. Is there at least *one* case where FSF has defended its software in
> the court? 

We are even better - even very big companies did not try to violate
the GPL after friendly negotations with the FSF.  They fixed the
license problems instead which sometimes mean to release the software
under the GPL.

One of the goals of the FSF Europe is to enforce the GPL in Europe.
Due to the different legal system it would be even harder to do this
without ghaving the exclusive rights to the software.  Anyone who
infringe a GPLed software not protected by good legal methods
(i.e. copyright assignments or our European counterparts) is very
likely to get away within.  The Linux klernel being the premium
example of a software where the license is very hard to enforce.

> 2. After modificating gpg.el in any way *you* will be the copyright holder
> also. Transfer this copyright to FSF and release the updated gpg.el with

No.  Usually you assign all future modifications too.

> Nobody cares also. So Gnus community position on copyright issues looks
> like a bit paranoid to me ...

All big projects require this:  XFree, Samba, apache etc.

  Werner

Re: [COMMIT] sign & encrypt changes

[Florian Weimer]

Josh Huber <huber@alum.wpi.edu> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> It breaks PGP 2 support with some GnuPG versions.  I'm not sure if
>> GnuPG 1.0.7 corrects this.

It doesn't.

> Why does it break pgp2 support, btw?  (even with the --pgp2 option?)

--pgp2 means that GnuPG detects and bails out with an error message.
See: http://lists.gnupg.org/pipermail/gnupg-users/2002-May/thread.html#12911
and following articles.

Re: [COMMIT] sign & encrypt changes

[Josh Huber]

Florian Weimer <fw@deneb.enyo.de> writes:

> --pgp2 means that GnuPG detects and bails out with an error message.
> See: http://lists.gnupg.org/pipermail/gnupg-users/2002-May/thread.html#12911
> and following articles.

I see, so should we make the default work with pgp2?  How many people
are still using this?

Thanks for checking on this,

-- 
Josh Huber

Re: [COMMIT] sign & encrypt changes

[Werner Koch]

On Fri, 03 May 2002 21:21:44 +0200, Florian Weimer said:

>>> It breaks PGP 2 support with some GnuPG versions.  I'm not sure if
>>> GnuPG 1.0.7 corrects this.

> It doesn't.

Correct.  The reason is that this can't be done in a PGP2 compatible
way without the use of temporary files.

Anyway, the 2 step approach is the better one becuase you can strip
the encryption layer and keep the signature with all its
meta-information intact.  rfc3156 allows the combined method only for
conveninece - the standard is to use MIME objects for it.

  Werner

Re: [COMMIT] sign & encrypt changes

[Josh Huber]

Werner Koch <wk@gnupg.org> writes:

> Anyway, the 2 step approach is the better one becuase you can strip
> the encryption layer and keep the signature with all its
> meta-information intact.  rfc3156 allows the combined method only
> for conveninece - the standard is to use MIME objects for it.

Good timing -- I just commited a change to switch the default back for
pgpmime, and added a function for people who want to switch this
setting in their local configuration.

There is another good thing which happened due to these changes:

Before, the encrypt call was *always* calling gpg-sign-encrypt, so if
you signed & encrypted a message you would get a signed part enclosed
inside a signed & encrypted part.

Now at least the outside part is encrypted only. ;)

Of course, I've only made the changes for pgpmime so far.  Vanilla PGP
and S/MIME haven't been done yet, but at least pgpmime is doing the
right thing now.

ttyl,

-- 
Josh Huber