Nabble - debian-vote

Richiesta autorizzazione

2009-12-10T03:12:14Z

Buongiorno,

sono Giorgia Ferrari, assistente Marketing di Forum Media Srl, società operante nel campo dell'editoria e della formazione professionale.

La presente per richiederLe l'autorizzazione, ai sensi della vigente normativa sulla Privacy, ad inviarLe, a titolo informativo, tramite e-mail qualche dettaglio sui nostri recenti prodotti editoriali specifici per il settore Tecnico-Amministrativo, Ambiente e Sicurezza, Risorse Umane, Management e Formazione Professionale.

A questo proposito vorremmo inviarLe, a titolo informativo, schede prodotto dettagliate in modo che Lei possa valutare un Suo possibile interesse. Nel caso in cui preferisca ricevere dette informazioni via fax, oppure ad altro indirizzo di posta elettronica, voglia cortesemente trasmetterci i riferimenti.

Teniamo a precisare che, nel rispetto rigoroso della normativa sulla privacy, valuteremo solo autorizzazioni con la modalità opt-in, ossia non invieremo nulla senza un Suo regolare ed espresso assenso.

RingraziandoLa per l'attenzione, Le porgo i miei più cordiali saluti.

Giorgia Ferrari
FORUM MEDIA
www.forum-media.it

Il vostro indirizzo e-mail è trattato in conformità all'Art. 13 del D.lgs 30 giugno 2003 n.196, garantendo la massima riservatezza ed al fine di fornire utili informazioni commerciali per la Sua/Vostra attività. Se non volete ricevere più messaggi inviati per conto dell'operatore si prega di inviare un messaggio all'indirizzo unsubscribe@....

Come join me on Government Lists - U.S. | Canada

2009-12-09T06:28:07Z

Network Email

Join me on Government Lists - U.S. | Canada

REACH YOUR KEY GOVERNMENT AUDIENCE EASILY!

government--
mailing--
lists.com has:

1 blog post

I welcome you to join me on this business network.

REACH YOUR KEY GOVERNMENT AUDIENCE EASILY!
http://www.government-mailing-lists.com

Click to Join

Members on Government Lists - U.S. | Canada:

government--
mailing--
lists.com

Richard Furlong

Ryan Sharpe

Jim Kellough

Nitin Chaudhry

About Government Lists - U.S. | Canada

government-mailing-lists.com is the key-contact database for reaching government markets. Government Lists – U.S. | Canada

10 photos

To control which emails you receive on Government Lists - U.S. | Canada, click here

[Future Icon Records] You've been added to our mailing list.

2009-11-28T19:59:05Z

Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS (Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) and we want to share with you His first Original Christmas song I made a radio edit of so happy here it is if you like it Radio Edit Of - So Happy https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060d Instrumental Radio Edit - So Happy https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410 

--------
Get your free download from Future Icon Records here: http://fburls.com/39-82ZLpDDj
--------

You have been added to the Future Icon Records fan list!

If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link:

http://www.FanBridge.com/signup/fansignup.php?userid=129853&email=debian-vote@...&confCode=bbK6arh6769h9YchPe9thh2bUt

--
This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists.

With FanBridge your information is always secure.

For more information about FanBridge please visit http://www.FanBridge.com/learn/
--

***Important: Please be sure to add the email address (futureiconrecords@...) to your safe senders list.***

Here's how:

Gmail
1. Click Contacts along the left side of any Gmail page.
2. Click Add Contact.
3. In the primary email address box, type futureiconrecords@....
4. Click Save.

AOL (version 9.0 or higher)
1. Click the Mail menu and select Address Book.
2. In the pop up box, click the Add button.
3. In the "Other E-Mail" field, type futureiconrecords@....
4. Make our From address the "Primary E-Mail" address by checking the associated check box.
5. Click the Save button.

AOL 8.0
1. Open this confirmation email.
2. Click Add Address.
3. Verify the sender's contact information (futureiconrecords@...).
4. Click Save.

Yahoo!
1. Click the "addresses" button
2. Select "Add Contact"
3. Save the futureiconrecords@... to your contacts list.

Hotmail
1. Click Options.
2. On the left side of the page, click Mail, and then click Junk E-Mail Protection.
3. Click Safe List.
4. Type futureiconrecords@..., and then click Add.

Outlook
1. Right-click on a message from futureiconrecords@....
2. Point to Junk E-mail, and click Add Sender to Safe Senders List.

----------------------------------------
Future Icon Records sent this email to debian-vote@...
Questions? Contact futureiconrecords@... or Future Icon Records, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States

Update Your Information - http://fburls.com/35-BlSsCSI9
Forward to a friend - http://fburls.com/88-5dwv8lkt
Unsubscribe - http://fburls.com/11-1Dk7uEIp
Privacy Policy - http://www.FanBridge.com/learn/privacy.php

This email message is powered by FanBridge:
http://www.FanBridge.com/b.php?id=129853
Powering Valuable Fan Relationships

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-28T11:00:38Z

On Thu, Nov 19, 2009 at 11:59:54AM +0100, Wouter Verhelst wrote:
> On Sun, Nov 15, 2009 at 02:37:51PM +0100, Bill Allombert wrote:
> > Hello,
> >
> > I would like to move the discussion to debian-vote where it belongs.
> > I'd like to apologize to have started this cross-post in the first place.
> > (please CC me).
>
> Actually, I'm thinking it's probably more on-topic on -legal in this
> stage. But whatever.

Well, I already sent a previous answer to debian-legal (by mistake, but still).

> > On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote:
> > The idea was that if you distribute it in source form, someone else might
> > start to run the software on the public internet and then the 'your modified
> > version must offer' clause take effect.
>
> Indeed.
>
> > So if you are a service provider, is the AGPL trivially bypassable by
> > 1) not accepting it and 2) having someone else doing the modification for you
> > but never actually providing any service themself?
>
> I'm not sure, but I'm also not sure how that is relevant to the
> discussion of whether the AGPL is or is not free?
>
> If this requirement cannot be bypassed, then the clause does apply and
> any argument on the freeness of the license that is based on such
> bypassing cannot be valid.

My point was that compliance with section 13. lay squarely on the shoulder
of the developer modifying the software since it is obvious that the AGPL
drafters did not intent to put any liability to the service provider, and
so my objections 2.2 and 2.3 stand. In particular, the developer has to offer
the source code for as long as a service provider is using it, even if the
developer is unaware of it.

> > So it is not "with every network conversation", but it is "all users".
>
> Indeed.
>
> I guess the wording could/should be modified. If the license were to say
> that the offer must not be removed, and must be put in an appropriate
> place that is available to all users interacting with it and should not
> be hidden from view, that would probably be better. Then again, that's
> quite a convoluted to say something like that.
>
> Having said that, I'm not convinced it makes the license non-free. If
> you use a license on a piece of software that it was not meant for in
> the first place, then of course it will cause problems. AIUI, the AGPL
> was written for web apps, not for general-purpose software, and in that
> context this phrasing causes no ill effects.

There is nothing fundamental in webapps which make webapps code improper for
use in non-webapps applications. The right to take code in a project and
reuse it for a totally different purpose is a fundamental free software right.

> If someone were to use the AGPL on a web server, that would be a
> problem. But I don't think that's the case, is it?

Someone might want to reuse code in an AGPL software inside a webserver,
but the AGPL prevent that. How a license that disallow use in web servers can
be more free than a license that disallow use in genetic research ? How can it
satisfy DFSG 6 ?

In any case, thanks a lot for your contribution to the debate.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Convite: Results of the Lenny release GR @ sex 27 de nov de 2009 (debian-vote@lists.debian.org)

2009-11-27T04:58:00Z

Claudio Filho <filhocf@...> writes:

> Você foi convidado para o seguinte evento.
>
> Título: Results of the Lenny release GR
> I've been reminded that as Acting Secretary I should officially announce the
> results of the recent vote. My apologies for the delay!

In case anyone is confused: This is *not* an exceedingly delayed
announcement. It is copy-and-pasted content from an existing message
From 2008.

--
\ “It seems intuitively obvious to me, which means that it might |
`\ be wrong.” —Chris Torek |
_o__) |
Ben Finney

attachment0 (203 bytes) Download Attachment

Convite: Results of the Lenny release GR @ sex 27 de nov de 2009 (debian-vote@lists.debian.org)

2009-11-27T04:02:55Z

mais detalhes »

Results of the Lenny release GR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1I've been reminded that as Acting Secretary I should officially announce the
results of the recent vote.  My apologies for the delay!
Details of the outcome and how various options were voted are available at 
	http://www.debian.org/vote/2008/vote_003
The winning option was number 5, "Assume blobs comply with GPL unless proven
otherwise", the full text of which is appended below.
Since the election concluded, several developers have asked for some statement
from the DPL and/or Secretary as to what this result really means.  Steve and
I have discussed it, and we think it's pretty clear.  This result means that
the Debian Lenny release can proceed as the release team has intended, with
the kernel packages currently in the archive.
Bdale

  Assume blobs comply with GPL unless proven otherwise
    1.  We affirm that our Priorities are our users and the free software 
	community (Social Contract #4);
    2.  We acknowledge that there is a lot of progress in the kernel firmware 
        issue; most of the issues that were outstanding at the time of the 
        last stable release have been sorted out.  However, new issues in the 
        kernel sources have cropped up fairly recently, and these new issues 
	have not yet been addressed;
    3.  We assure the community that there will be no regressions in the 
	progress made for freedom in the kernel distributed by Debian relative 
	to the Etch release in Lenny (to the best of our knowledge as of 1 
	November 2008);
    4.  We give priority to the timely release of Lenny over sorting every 
	bit out; for this reason, we will treat removal of sourceless firmware
	as a best-effort process, and deliver firmware as part of Debian Lenny
	as long as we are legally allowed to do so, and the firmware is 
	distributed upstream under a license that complies with the DFSG.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFJYp2nZKfAp/LPAagRAlJrAJ0Wdji75LonKCG9Vuj38Bdbb/lHpgCfR/Ij
5Ldf00T3SO8cXn2TMPOLZcg=
=Am85
-----END PGP SIGNATURE-----

-- 
To UNSUBSCRIBE, email to debian-devel-announce-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Quando

sex 27 de nov de 2009

Agenda

debian-vote@...

Quem

•	filhocf@...- criador
•	debian-devel-announce@...
•	debian-vote@...

Vai? Sim - Talvez - Não mais opções »

Convite do Google Agenda

Você está recebendo este e-mail de cortesia na conta debian-vote@... por ser um participante deste evento.

Para não receber mais notificações futuras sobre este evento, recuse-o. Você também pode se inscrever para ter uma conta do Google em https://www.google.com/calendar/ e controlar suas configurações de notificação de toda a sua agenda.

invite.ics (5K) Download Attachment

Metal Alüminyum Sistemleri

2009-11-24T18:33:23Z

ARAR Yapı Metal Alüminyum Sistemleri

ARAR Yapı Metal Alüminyum Sistemleri
Yapı Metal Alüminyum Sistemleri Olarak Kurulan Firmamız; Alüminyum Doğrama Sistemleri, Faliyetlerine Başlamıştır.
Alüminyum Kompozit Panel, Alüminyum Levha Kaplama,Üretim ve Profesyonel Ekibiyle En Yakın Çözüm Ortağınız.

HİZMETLERİMİZ


KÜPEŞTE	CAM BALKON	OTOMATİK KAPI VE PANJUR


PVC DOĞRAMA	CEHPE GİYDİRME	FOTOSELLİ OTOMATİK KAPI


	ALÜMİNYUM DOĞRAMA	SİNEKLİK

ARAR Yapı Metal Alüminyum Sistemleri
Gümüşpala mh. E5 Yan Yol Üzeri Avcılar / İSTANBUL
Tel : + 90 212 591 36 65
Fax : + 90 212 593 63 58

www.araryapimetal.com

Listeden Çıkmak için beni@... adresine "Çıkar" başlıklı Boş bir e-posta gönderiniz.

Üç ayda İngilizce konuşmak istiyor musunuz?

2009-11-21T15:58:02Z

Üç ayda İngilizce konuşmak istiyor musunuz

Üç ayda İngilizce konuşmak

istiyor musunuz?

Lütfen tıklayın

www.pratikingilizce.com

EN İYİ ÜRÜNLER BURADA

2009-11-19T14:58:29Z

Yeni Sayfa 1

KATAGORİLER

Dış beslenme

Kilo almak istiyorum

Beslenme Ürünleri

Cilt Bakım Setleri

Parfümler

Cilt Saç Bakım Ürünleri

Distribütör Ürünleri

Kilo vermek istiyorum

Dış beslenme
Herbalife Herbal Aloe Nemlendirici Şampuan	Herbalife Herbal Aloe Saç Kremi	Herbalife NouriFusion Vitaminli Tonik	Herbalife Radiant C Ferahlatıcı Yüz Spreyi
Kilo almak istiyorum
Herbalife Kilo Alma Programı 1 - Ekonomik Program	Herbalife Kilo Alma Programı 2 - Standart Program	Herbalife Kilo Alma Programı 3 - Geliştirilmiş Program (Shaker H	ShapeWorks Formül 3 Kişiye Özel Protein Takviyesi
Beslenme Ürünleri
Herbalife Formül 1 Tek Porsiyon İçeren 26Gr Shake Karışım Paketl	Herbal Aloe Konsantre İçecek	Herbalife Liftoff Efervesan İçecek	Herbalife Niteworks
Cilt Bakım Setleri
Cilt Bakım Seti 1	Cilt Bakım Seti 2	Cilt Bakım Seti 3	Cilt Bakım Seti 4
Parfümler
Heart - Bayan Parfüm	Man - Erkek Parfümü	Soul - Erkek Parfüm	Woman - Bayan Parfüm
Cilt Saç Bakım Ürünleri
Herbalife Body Buffing Scrub - Vücut İçin Temizleyici	Herbalife Body Contouring Créme - Vücut Şekillendirici Krem	Herbalife NouriFusion Gece Kremi	Herbalife Skin Activator Yenileyici Gece Kremi
Kilo vermek istiyorum
Herbalife Kilo Verme Programı 1	Herbalife Kilo Verme Programı 2	Herbalife Kilo Verme Programı 3 (Shaker Hediyeli)	Herbalife ShapeWorks Hızlı Başlangıç Programı
Distribütör Ürünleri

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-19T02:59:54Z

On Sun, Nov 15, 2009 at 02:37:51PM +0100, Bill Allombert wrote:
> Hello,
>
> I would like to move the discussion to debian-vote where it belongs.
> I'd like to apologize to have started this cross-post in the first place.
> (please CC me).

Actually, I'm thinking it's probably more on-topic on -legal in this
stage. But whatever.

> On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote:
> > > If you modify a GPL-licensed software and distribute the modified version in
> > > source form only, you do not have any long standing obligation. This is not
> > > the case here.
> >
> > That's not true. It says 'your modified version must offer', it does not
> > say 'you must offer'. In other words, if you don't run it on the public
> > Internet, there is no problem.
>
> The idea was that if you distribute it in source form, someone else might
> start to run the software on the public internet and then the 'your modified
> version must offer' clause take effect.

Indeed.

> > > So if you are as service provider, is the AGPL trivially bypassable by
> > > having someone doing the modification for you but never actually
> > > provide any service ?
> > After thinking about this a bit more, I'm actually not entirely sure
> > about my previous statement here anymore.
> >
> > Indeed, you would probably need to be providing the source of the
> > version you're running, even if you did not make any local modifications
> > yourself.
>
> I strongly doubt that the AGPL put any kind of limitation/liability on merely
> running the software, for various reasons:
>
> 1) Philosophy: the FSF stance is that
> * The freedom to run the program, for any purpose (freedom 0).
>
> 2) Copyright law: mere copyright law do not allow to limit use of the software
> once you legally have a copy, so you do not have to agree with the AGPL in
> order to merely use the software, and so the AGPL cannot impose any
> condition upon you.
>
> 3) the AGPL text: Section 9:
>
> 9. Acceptance Not Required for Having Copies.
>
> You are not required to accept this License in order to receive or
> run a copy of the Program. Ancillary propagation of a covered work
> occurring solely as a consequence of using peer-to-peer transmission
> to receive a copy likewise does not require acceptance. However,
> nothing other than this License grants you permission to propagate or
> modify any covered work. These actions infringe copyright if you do
> not accept this License. Therefore, by modifying or propagating a
> covered work, you indicate your acceptance of this License to do so.
>
> So if you are a service provider, is the AGPL trivially bypassable by
> 1) not accepting it and 2) having someone else doing the modification for you
> but never actually providing any service themself?

I'm not sure, but I'm also not sure how that is relevant to the
discussion of whether the AGPL is or is not free?

If the requirement that such modifications are made available in a
particular way can be bypassed, then it can be assumed to not apply and
thus cannot cause the license to be non-free.

If this requirement cannot be bypassed, then the clause does apply and
any argument on the freeness of the license that is based on such
bypassing cannot be valid.

> > > Assume this is web server. Are you suggesting it modify the page it serve to
> > > add the notice ?
> >
> > It says "in a prominent place", not "with every network conversation".
>
> It does not say either of that, it says 'your modified version must
> prominently offer all users interacting with it remotely through a
> computer network'.
>
> So it is not "with every network conversation", but it is "all users".

Indeed.

I guess the wording could/should be modified. If the license were to say
that the offer must not be removed, and must be put in an appropriate
place that is available to all users interacting with it and should not
be hidden from view, that would probably be better. Then again, that's
quite a convoluted to say something like that.

Having said that, I'm not convinced it makes the license non-free. If
you use a license on a piece of software that it was not meant for in
the first place, then of course it will cause problems. AIUI, the AGPL
was written for web apps, not for general-purpose software, and in that
context this phrasing causes no ill effects.

If someone were to use the AGPL on a web server, that would be a
problem. But I don't think that's the case, is it?

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

YENİ HOBİNİZİ KEŞFEDİN

2009-11-16T05:41:14Z

Yeni Sayfa 1

Ana Sayfa

Mağazamız

Yeni Ürünler

Markalarımız

Hakkımızda

Bize Ulaşın

KATAGORİLER
Havalı Silahlar	PaintBall Silahlar	Tabanca Tüfek Harbileri
Optikler	Fener ve Projektörler	Metal Temizleme ve Bakım Yağları
AirSoft & PaintBall	Av Bıçakları	Diana Yedek Parça
Elektronik	Çakılar	Yandan Paralakslı Dürbünler
Kampçılık	PCP Tüfekler	Önden Paralakslı Dürbünler
Bıçaklar	Pistonlu Tüfekler	Holosight
PCP Silahlar	CO2 Tabancalar	Dampa Ayaklar
Pistonlu Silahlar	Multipump Tabancalar	İki Parçalı Ayaklar
CO2 Silahlar	PCP ve Diğer Pompalar	PaintBall Tabancaları
Multipump Silahlar	PCP Dolum Aparatları	Sabit Av Bıçakları
Silah Aksesuarları	Markaya Özel Aksesuarlar	Set Bıçaklar
Saçmalar (Pelletler)	Silah Şarjörleri	Havalı silah Saçmaları (misket)
Silah Teknik Yedek Parça	Silah Dürbünleri	Silah Dürbün Ayakları
Temizlik ve Bakım Ürünleri	Havalı silah Peletleri (paraşüt)	Namlu ucu Moderatörler

MARKALAR

AirArms	Beretta	Diana	Haendler & Natermann	Röhm	Square	Tasco
Bauer	Bushnell	FX airguns	Smith & Wesson	Jansen	Tippmann	Walther
Benjamin	Crosman	Gamo	Megaline	Sprayway	Weihrauch	Zeiss

Katresu Av ve Spor Malzemeleri San. Tic. A.Ş.
Vişne1 Mah. Garantikoza çarşısı H1 Blok No:2 Zekeriyaköy - Sarıyer / İstanbul – Türkiye
Telefon : +90 212 202 99 30
Fax : +90 212 202 97 93

Ana Sayfa

Mağazamız

Yeni Ürünler

Markalarımız

Hakkımızda

Bize Ulaşın

Listeden Çıkmak için beni@... adresine "Çıkar" başlıklı Boş bir e-posta gönderiniz

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-15T05:37:51Z

Hello,

I would like to move the discussion to debian-vote where it belongs.
I'd like to apologize to have started this cross-post in the first place.
(please CC me).

On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote:
> > If you modify a GPL-licensed software and distribute the modified version in
> > source form only, you do not have any long standing obligation. This is not
> > the case here.
>
> That's not true. It says 'your modified version must offer', it does not
> say 'you must offer'. In other words, if you don't run it on the public
> Internet, there is no problem.

The idea was that if you distribute it in source form, someone else might start
to run the software on the public internet and then the 'your modified version
must offer' clause take effect.

...

> > So if you are as service provider, is the AGPL trivially bypassable by
> > having someone doing the modification for you but never actually
> > provide any service ?
> After thinking about this a bit more, I'm actually not entirely sure
> about my previous statement here anymore.
>
> Indeed, you would probably need to be providing the source of the
> version you're running, even if you did not make any local modifications
> yourself.

I strongly doubt that the AGPL put any kind of limitation/liability on merely
running the software, for various reasons:

1) Philosophy: the FSF stance is that
* The freedom to run the program, for any purpose (freedom 0).

2) Copyright law: mere copyright law do not allow to limit use of the software
once you legally have a copy, so you do not have to agree with the AGPL in
order to merely use the software, and so the AGPL cannot impose any
condition upon you.

3) the AGPL text: Section 9:

9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.

So if you are a service provider, is the AGPL trivially bypassable by
1) not accepting it and 2) having someone else doing the modification for you
but never actually providing any service themself?

> > Assume this is web server. Are you suggesting it modify the page it serve to
> > add the notice ?
>
> It says "in a prominent place", not "with every network conversation".

It does not say either of that, it says 'your modified version must prominently
offer all users interacting with it remotely through a computer network'.

So it is not "with every network conversation", but it is "all users".

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

signature.asc (204 bytes) Download Attachment

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-14T19:04:49Z

On Fri, Nov 13, 2009 at 02:24:38PM +0100, Bill Allombert wrote:

> On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote:
> > On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote:
> > > 2.1 This clause restricts how you can modify the software.
> > > Doing a simple modification to a AGPL-covered software might require you to
> > > write a substantial amount of extra code to comply with this clause.
> >
> > How is this any different from the requirement in the regular GPL to
> > provide source at no cost? Often this is done through website, too.
>
> If you modify a GPL-licensed software and distribute the modified version in
> source form only, you do not have any long standing obligation. This is not
> the case here.

That's not true. It says 'your modified version must offer', it does not
say 'you must offer'. In other words, if you don't run it on the public
Internet, there is no problem.

> > > 2.2 This clause forces the developer modifying the software to
> > > incur cost. A developer modifying the software and distributing
> > > the modified version need to incur the cost of providing access to
> > > the Corresponding Source from a network server as long as at least
> > > one person is using the software and this for all published
> > > modifications, even long after the developer stopped using and/or
> > > distributing the software.
> >
> > Actually, that's not true.
> >
> > This clause applies to service providers who provide a service based
> > upon a slightly modified piece of AGPL software. The requirement to
>
> The clause apply to whoever made the modification, not whoever provide the
> service. They might be different people, and the modifier should not be
> responsible for what the service provider do. Do you agree ?

No, I do not agree.

Similarly to how the regular GPL only triggers when you distribute
software, this clause only triggers when the software is run. Indeed,
the developer modifying the code should not be responsible for what the
service provider does, but it is perfectly possible for such a developer
to add a "fill in the blanks" type of hyperlink to the application,
which the service provider must then replace with a hyperlink to the
actual source that they're using (presumably on their own server).

The clause says "the software must provide a link to the source". It
does not say "the developer must make the source available".

> > distribute the modifications only applies to your service:
> >
> > "if you modify the program, your modified version must [...] offer [...]
> > an opportunity to receive the Corresponding Source of your version"
> >
> > It does not say that you must distribute the Corresponding Source for
> > all eternity.
>
> The license does not specify a limitation of time.

There is no time limitation, indeed, but it only applies for as long as
users can get at an instance of the software as you are running it. Once
you stop doing that, the requirement will automatically go away, too.

> > Compliance with this clause can be accomplished by simply
> > adding a hyperlink to a .tar.gz with your source on an appropriate
> > place.
>
> This require you for keeping the .tar.gz online for as long a people are
> providing services using your modified software, which can be a long time
> after you stopped distributing it and stopped to care about it.

Again, there is no such requirement for the developer. It is perfectly
possible for a developer to provide instructions in an INSTALL file or
something similar that explains that anyone installing the software must
put the source tarball online along with the installed program.

> > That does require you to have proper procedures in place to make
> > sure the .tar.gz is always up-to-date with regards to the 'released'
> > version of your service, but this is no different from doing the same
> > with releasing embedded hardware that uses GPL software, for instance.
>
> Not really: with the GPL, you can just ship a CD-ROM with the source code with
> each embedded devices. At this point your have no further obligation.
> (I bought several devices which provided such CD-ROM. This is far from
> hypothetical.)

In that case, the CD-ROM needs to contain the right version of the
source code (and not the version that was used until three hours before
release, when a final critical bug was found). That requires proper
procedures to be in place, in much the same way as the AGPL requires you
to have proper procedures to be in place.

[...]

> > > -- A user of the modified version can mis-install it, mis-configure it or
> > > run it in an untested environment where it does not comply with this
> > > clause.
> > >
> > > -- A user of the modified version can use it in a configuration that cause
> > > it to fail to comply with this clause (for example using a reverse proxy
> > > that remove link to the source code from the html output).
> >
> > No. If you do not modify the software _yourself_, you do not need to
> > publish such a link. Only if you have local modifications is this
> > necessary.
>
> So if you are as service provider, is the AGPL trivially bypassable by
> having someone doing the modification for you but never actually
> provide any service ?

After thinking about this a bit more, I'm actually not entirely sure
about my previous statement here anymore.

Indeed, you would probably need to be providing the source of the
version you're running, even if you did not make any local modifications
yourself.

Having said that, if you install the software in a way that causes it to
fail so that a user would not be able to download the software, then
that would probably be a bug in your instance of the installation. The
key word here is 'intent' -- if a service provider did this
intentionally and is unwilling to fix the problem when told about it,
they should be sued. If they do so unintentionally, and make a best
effort to fix the issue once it's pointed out, it should not be a
problem.

> > > 3. This clause is incompatible with Section 6. of the Debian Free Software
> > > Guideline.
> >
> > > 3.1 This clause does not allow you to modify the software to perform tasks
> > > where complying with it is not technically feasible, for example:
> > >
> > > -- The code is modified to run on an embedded system with tight size limit.
> > >
> > > -- The code is modified to interact with the user using a network connection
> > > with extremely low throughput.
> >
> > Nowhere does that clause say that you need to put the code on the same
> > device as the one you're running it on; size limits and network
> > throughput issues should therefore not be an issue.
>
> Yes, but you still have to display a proeminent offer. This can still be too
> much, if the display is just a pair of digits.

If the only interface is a display with a pair of digits (i.e., there's
no network interface), then the AGPL does not apply.

If the system is used over the network, then the network protocol or the
place where you sign up or something similar would need to contain the
relevant offer. The embedded display would then just be using the
protocol.

> > > -- The code is modified to interact with the user using a network protocol
> > > that does not allow to display a prominent offer.
> >
> > This is actually your best argument so far, but I don't think it's
> > completely true either.
> >
> > First, network protocols that "do not allow to display" anything are
> > abundant, since no network protocol "displays" anything -- clients that
> > use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.
>
> Agreed. What if the client cannot be expected to display such notice ?

If you are developing a network protocol, you really cannot be expected
to be able to control what the client can and cannot do -- even an HTTP
browser could hide parts of a webpage, without the server being able to
do anything about that.

I think that if you provide instructions to the source in whatever is
sent over the network, preferably in such a way that it would be
displayed by default (but in comment headers if that's not possible),
you'd be fine.

> > This clause requires that the user be informed about the fact that the
> > software is modified. In a piece of software that uses HTTP, this is
> > simple -- just add a link to the website, and you're done.
>
> Assume this is web server. Are you suggesting it modify the page it serve to
> add the notice ?

It says "in a prominent place", not "with every network conversation".
For instance, the link to the source could be part of the 403 error
pages.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-13T05:24:38Z

On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote:
> On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote:
> > 2.1 This clause restricts how you can modify the software.
> > Doing a simple modification to a AGPL-covered software might require you to
> > write a substantial amount of extra code to comply with this clause.
>
> How is this any different from the requirement in the regular GPL to
> provide source at no cost? Often this is done through website, too.

If you modify a GPL-licensed software and distribute the modified version in
source form only, you do not have any long standing obligation. This is not
the case here.

> > 2.2 This clause forces the developer modifying the software to incur cost.
> > A developer modifying the software and distributing the modified version
> > need to incur the cost of providing access to the Corresponding Source from
> > a network server as long as at least one person is using the software and
> > this for all published modifications, even long after the developer stopped
> > using and/or distributing the software.
>
> Actually, that's not true.
>
> This clause applies to service providers who provide a service based
> upon a slightly modified piece of AGPL software. The requirement to

The clause apply to whoever made the modification, not whoever provide the
service. They might be different people, and the modifier should not be
responsible for what the service provider do. Do you agree ?

> distribute the modifications only applies to your service:
>
> "if you modify the program, your modified version must [...] offer [...]
> an opportunity to receive the Corresponding Source of your version"
>
> It does not say that you must distribute the Corresponding Source for
> all eternity.

The license does not specify a limitation of time.

> Compliance with this clause can be accomplished by simply
> adding a hyperlink to a .tar.gz with your source on an appropriate
> place.

This require you for keeping the .tar.gz online for as long a people are
providing services using your modified software, which can be a long time
after you stopped distributing it and stopped to care about it.

> That does require you to have proper procedures in place to make
> sure the .tar.gz is always up-to-date with regards to the 'released'
> version of your service, but this is no different from doing the same
> with releasing embedded hardware that uses GPL software, for instance.

Not really: with the GPL, you can just ship a CD-ROM with the source code with
each embedded devices. At this point your have no further obligation.
(I bought several devices which provided such CD-ROM. This is far from
hypothetical.)

> > 2.2. While this clause does restrict mere use of the software, instead it
> > creates liabilities for people modifying the software, even if they
> > distributed their modified version in source form, with respect to the way
> > the software perform on user systems.
> >
> > -- Modifying the software can unwillingly introduce a bug that cause it
> > not to comply with this clause.
>
> That hardly matters; bugs can be fixed. If you bring someone to court
> because they introduced a bug in their software, I'm sure the judge will
> punish you for wasting the court's time.
>
> On the other hand, if such a bug were to exist and the developers would
> seem unwilling to fix the issue in a reasonable timeframe upon being
> notified of the problem, then that would mean they simply do not comply
> with the requirements of this license, and should be sued.

The developer might release a fixed version of the software (and thus
a new Corresponding Source) without being able to force the service provider
to switch to that new version, which has no legal obligation.

> > -- A user of the modified version can mis-install it, mis-configure it or
> > run it in an untested environment where it does not comply with this
> > clause.
> >
> > -- A user of the modified version can use it in a configuration that cause
> > it to fail to comply with this clause (for example using a reverse proxy
> > that remove link to the source code from the html output).
>
> No. If you do not modify the software _yourself_, you do not need to
> publish such a link. Only if you have local modifications is this
> necessary.

So if you are as service provider, is the AGPL trivially bypassable by having
someone doing the modification for you but never actually provide any service ?

> > 3. This clause is incompatible with Section 6. of the Debian Free Software
> > Guideline.
>
> > 3.1 This clause does not allow you to modify the software to perform tasks
> > where complying with it is not technically feasible, for example:
> >
> > -- The code is modified to run on an embedded system with tight size limit.
> >
> > -- The code is modified to interact with the user using a network connection
> > with extremely low throughput.
>
> Nowhere does that clause say that you need to put the code on the same
> device as the one you're running it on; size limits and network
> throughput issues should therefore not be an issue.

Yes, but you still have to display a proeminent offer. This can still be too
much, if the display is just a pair of digits.

> > -- The code is modified to interact with the user using a network protocol
> > that does not allow to display a prominent offer.
>
> This is actually your best argument so far, but I don't think it's
> completely true either.
>
> First, network protocols that "do not allow to display" anything are
> abundant, since no network protocol "displays" anything -- clients that
> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.

Agreed. What if the client cannot be expected to display such notice ?

> This clause requires that the user be informed about the fact that the
> software is modified. In a piece of software that uses HTTP, this is
> simple -- just add a link to the website, and you're done.

Assume this is web server. Are you suggesting it modify the page it serve to
add the notice ?

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.

signature.asc (204 bytes) Download Attachment

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-12T07:10:34Z

On Thu, Nov 12, 2009 at 1:24 PM, Toni Mueller <toni@...> wrote:

>
> Hi,
>
> On Wed, 11.11.2009 at 23:46:59 +0100, Martin Langhoff <martin.langhoff@...> wrote:
>> Yes, this is one of the awkward things I find in the AGPL. If it's not
>> a webapp, what then?
>
> please see this:
>
> http://www.fsf.org/licensing/licenses/gpl-faq.html#AGPLv3InteractingRemotely
>
> It could eg. also be network file system software (NFS, AFS, SMB,
> etc.).

Yes, I am aware of that. What I was trying to say is "how do we comply, then?"

>> That would be complying with the spirit of the license, but not the
>> actual clause AFAICS.
>
> Ok. I'd say that this should have been an oversight in the formulation
> of the license, but maybe consulting the original discussions when the
> license was in the making, could be enlightening.

Yes, it will help us understand the spirit better. But we are looking
at what the license actually says.

m
--
martin.langhoff@...
martin@... -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-12T04:24:21Z

Hi,

On Wed, 11.11.2009 at 23:46:59 +0100, Martin Langhoff <martin.langhoff@...> wrote:
> Yes, this is one of the awkward things I find in the AGPL. If it's not
> a webapp, what then?

please see this:

http://www.fsf.org/licensing/licenses/gpl-faq.html#AGPLv3InteractingRemotely

It could eg. also be network file system software (NFS, AFS, SMB,
etc.).

> > If the software uses some other protocol that doesn't allow you to do
> > some lay-out like HTTP does, then you simply need to make sure that
> > people using your software are informed out-of-band.
>
> That would be complying with the spirit of the license, but not the
> actual clause AFAICS.

Ok. I'd say that this should have been an oversight in the formulation
of the license, but maybe consulting the original discussions when the
license was in the making, could be enlightening.

Kind regards,
--Toni++

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-12T02:25:45Z

Frank Lin PIAT a écrit :

> Russell Coker wrote:
>> On Thu, 12 Nov 2009, Wouter Verhelst <wouter@...> wrote:
>>> First, network protocols that "do not allow to display" anything are
>>> abundant, since no network protocol "displays" anything -- clients that
>>> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.
>> If you connect to my SMTP server you will see a legal disclaimer (which I
>> claim to be as valid as any that you may see in a .sig).
> [..]
>> Now in terms of granting rights, if my mail server contained AGPL code
>> and this was displayed in the SMTP protocol then a user could connect
>> to it and discover whether I was using code for which they could demand
>> the source.
>
> I disagree with your interpretation.
> The AGPL states "prominently offer all users", displaying at protocol
> level doesn't comply with either "prominently" nor with "all users"
> (because only a few sysadmins will telnet to port 25.)
> Such offer should be on SMTP *and* on the website offering this service.

I fail to see how it would be more prominently offered. At least tcp/25
is related to the service itself, a website has nothing to do with it.
(I mean, there /might/ be a website offering the service, but in most
cases there is not).

Cheers,

--
Yves-Alexis

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-12T00:22:05Z

Russell Coker wrote:
> On Thu, 12 Nov 2009, Wouter Verhelst <wouter@...> wrote:
>> First, network protocols that "do not allow to display" anything are
>> abundant, since no network protocol "displays" anything -- clients that
>> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.
>
> If you connect to my SMTP server you will see a legal disclaimer (which I
> claim to be as valid as any that you may see in a .sig).
[..]
> Now in terms of granting rights, if my mail server contained AGPL code
> and this was displayed in the SMTP protocol then a user could connect
> to it and discover whether I was using code for which they could demand
> the source.

I disagree with your interpretation.
The AGPL states "prominently offer all users", displaying at protocol
level doesn't comply with either "prominently" nor with "all users"
(because only a few sysadmins will telnet to port 25.)
Such offer should be on SMTP *and* on the website offering this service.

(Would you consider it valid if the offer were included in HTTP headers?)

/me don't like AGPL, especially due to the way linked/combined code is
contaminated. I hate the way FSF made an exception for GPL-v3, and not for
"any compatible license". That's proprietary sh*t.

Regards,

Franklin

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-11T18:23:38Z

On Thu, 12 Nov 2009, Wouter Verhelst <wouter@...> wrote:
> First, network protocols that "do not allow to display" anything are
> abundant, since no network protocol "displays" anything -- clients that
> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.

If you connect to my SMTP server you will see a legal disclaimer (which I
claim to be as valid as any that you may see in a .sig). The fact that the
vast majority of SMTP clients don't check for such things should have the
exact same amount of legal relevance as the fact that most Microsoft
customers don't read their EULA.

Now in terms of granting rights, if my mail server contained AGPL code and
this was displayed in the SMTP protocol then a user could connect to it and
discover whether I was using code for which they could demand the source.

It would be entirely reasonable and plausible for someone to admire some
features that were in a running mail server, connect to port 25 with nc or
telnet, see a notification of AGPL code, and then demand a copy of the
source.

--
russell@...
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-11T14:46:59Z

On Wed, Nov 11, 2009 at 11:11 PM, Wouter Verhelst <wouter@...> wrote:
>> -- The code is modified to interact with the user using a network protocol
>> that does not allow to display a prominent offer.
>
> This is actually your best argument so far, but I don't think it's
> completely true either.

Yes, this is one of the awkward things I find in the AGPL. If it's not
a webapp, what then?

> If the software uses some other protocol that doesn't allow you to do
> some lay-out like HTTP does, then you simply need to make sure that
> people using your software are informed out-of-band.

That would be complying with the spirit of the license, but not the
actual clause AFAICS.

> "your modified version must prominently offer all users interacting with
> it [...]"
>
> I don't think that must necessarily be interpreted into saying that it
> must be done by the software itself,

Well, it sounds like it does mean exactly that.

m
--
martin.langhoff@...
martin@... -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-11T14:11:40Z

On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote:

> Dear developers,
>
> I respectfully submit this general resolution proposal to your consideration.
> (this GR proposal supersedes the proposal in <20090318235044.GA30722@yellowpig>)
>
> Asking for seconds,
> (please CC me)
> Bill. <ballombe@...>
>
> This General Resolution is made in accordance with Debian Constitution 4.1.5,
> however it overrides a decision of the FTP masters made in
> <87k5aovzzi.fsf@...> [1].
>
> [1] <http://lists.debian.org/debian-legal/2008/11/msg00097.html
>
> ========= Text of the GR ===================
> The Debian project resolves that softwares licensed under the GNU Affero
> General Public License are not free according to the Debian Free Software
> Guideline.
> ========= End of the text ==================
>
> RATIONALE (to be amended if necessary):
>
> 1. The GNU Affero General Public License (AGPL) is essentially the GNU General
> Public License with the following additional clause reproduced below.
> See http://www.fsf.org/licensing/licenses/agpl.html for the full text
> of the license.
> ""
> 13. Remote Network Interaction; Use with the GNU General Public License.
>
> Notwithstanding any other provision of this License, if you modify the
> Program, your modified version must prominently offer all users interacting
> with it remotely through a computer network (if your version supports such
> interaction) an opportunity to receive the Corresponding Source of your
> version
> by providing access to the Corresponding Source from a network server at no
> charge, through some standard or customary means of facilitating copying of
> software. This Corresponding Source shall include the Corresponding Source for
> any work covered by version 3 of the GNU General Public License that is
> incorporated pursuant to the following paragraph.
>
> Notwithstanding any other provision of this License, you have permission to
> link or combine any covered work with a work licensed under version 3 of the
> GNU General Public License into a single combined work, and to convey the
> resulting work. The terms of this License will continue to apply to the part
> which is the covered work, but the work with which it is combined will remain
> governed by version 3 of the GNU General Public License.
> ""
>
> 2. This clause is incompatible with Section 3. of the Debian Free Software
> Guideline:
>
> 2.1 This clause restricts how you can modify the software.
> Doing a simple modification to a AGPL-covered software might require you to
> write a substantial amount of extra code to comply with this clause.

How is this any different from the requirement in the regular GPL to
provide source at no cost? Often this is done through website, too.

> 2.2 This clause forces the developer modifying the software to incur cost.
> A developer modifying the software and distributing the modified version
> need to incur the cost of providing access to the Corresponding Source from
> a network server as long as at least one person is using the software and
> this for all published modifications, even long after the developer stopped
> using and/or distributing the software.

Actually, that's not true.

This clause applies to service providers who provide a service based
upon a slightly modified piece of AGPL software. The requirement to
distribute the modifications only applies to your service:

"if you modify the program, your modified version must [...] offer [...]
an opportunity to receive the Corresponding Source of your version"

It does not say that you must distribute the Corresponding Source for
all eternity. Compliance with this clause can be accomplished by simply
adding a hyperlink to a .tar.gz with your source on an appropriate
place. That does require you to have proper procedures in place to make
sure the .tar.gz is always up-to-date with regards to the 'released'
version of your service, but this is no different from doing the same
with releasing embedded hardware that uses GPL software, for instance.

> 2.2. While this clause does restrict mere use of the software, instead it
> creates liabilities for people modifying the software, even if they
> distributed their modified version in source form, with respect to the way
> the software perform on user systems.
>
> -- Modifying the software can unwillingly introduce a bug that cause it
> not to comply with this clause.

That hardly matters; bugs can be fixed. If you bring someone to court
because they introduced a bug in their software, I'm sure the judge will
punish you for wasting the court's time.

On the other hand, if such a bug were to exist and the developers would
seem unwilling to fix the issue in a reasonable timeframe upon being
notified of the problem, then that would mean they simply do not comply
with the requirements of this license, and should be sued.

> -- A user of the modified version can mis-install it, mis-configure it or
> run it in an untested environment where it does not comply with this
> clause.
>
> -- A user of the modified version can use it in a configuration that cause
> it to fail to comply with this clause (for example using a reverse proxy
> that remove link to the source code from the html output).

No. If you do not modify the software _yourself_, you do not need to
publish such a link. Only if you have local modifications is this
necessary.

> 3. This clause is incompatible with Section 6. of the Debian Free Software
> Guideline.
>
> 3.1 This clause does not allow you to modify the software to perform tasks
> where complying with it is not technically feasible, for example:
>
> -- The code is modified to run on an embedded system with tight size limit.
>
> -- The code is modified to interact with the user using a network connection
> with extremely low throughput.

Nowhere does that clause say that you need to put the code on the same
device as the one you're running it on; size limits and network
throughput issues should therefore not be an issue.

Additionally, if you're working with embedded software, the 'normal'
GPL's clauses about software redistribution will already apply,
regardless of whether or not the software is used over a network
connection; these are often complied with in ways that would be
sufficient for this clause, too.

> -- The code is modified to interact with the user using a network protocol
> that does not allow to display a prominent offer.

This is actually your best argument so far, but I don't think it's
completely true either.

First, network protocols that "do not allow to display" anything are
abundant, since no network protocol "displays" anything -- clients that
use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.

This clause requires that the user be informed about the fact that the
software is modified. In a piece of software that uses HTTP, this is
simple -- just add a link to the website, and you're done.

If the software uses some other protocol that doesn't allow you to do
some lay-out like HTTP does, then you simply need to make sure that
people using your software are informed out-of-band. For instance, if
the service you provide requires a username and password, then the
registration email could provide the required information.

If the only thing the software you've modified does is, say, produce an
XML stream that some custom client which you've written then interprets,
then all you need to do is make sure this custom client has the
necessary information in an appropriate place.

The clause says

"your modified version must prominently offer all users interacting with
it [...]"

I don't think that must necessarily be interpreted into saying that it
must be done by the software itself, rather than by anything that would
be used in cooperation with the network server.

In other words, I do not think that the AGPL is any more non-free than
the GPL is, at least not according to the DFSG. That's not to say that I
think the AGPL is a good idea or that I'll be releasing any
AGPL-licensed software any time soon, but that's of course a different
matter altogether.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html

signature.asc (205 bytes) Download Attachment

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-11T12:40:47Z

Bill Allombert wrote:

> 13. Remote Network Interaction; Use with the GNU General Public License.
>
> Notwithstanding any other provision of this License, if you modify the
> Program, your modified version must prominently offer all users interacting
> with it remotely through a computer network (if your version supports such
> interaction) an opportunity to receive the Corresponding Source of your
> version
> by providing access to the Corresponding Source from a network server at no
> charge, through some standard or customary means of facilitating copying of
> software. This Corresponding Source shall include the Corresponding Source for
> any work covered by version 3 of the GNU General Public License that is
> incorporated pursuant to the following paragraph.

This is obviously only relevant if the software is interacted with
remotely which is made cristal clear with the '(if your version supports
such interaction)'.

> 2. This clause is incompatible with Section 3. of the Debian Free Software
> Guideline:
>
> 2.1 This clause restricts how you can modify the software.
> Doing a simple modification to a AGPL-covered software might require you to
> write a substantial amount of extra code to comply with this clause.

Not at all unless the modified version is interacted with remotely which
should make providing the source trivial AFAICS?

> 2.2 This clause forces the developer modifying the software to incur cost.
> A developer modifying the software and distributing the modified version
> need to incur the cost of providing access to the Corresponding Source from
> a network server as long as at least one person is using the software and
> this for all published modifications, even long after the developer stopped
> using and/or distributing the software.

As long as the users are using it by interacting remotely with it...

> 2.2. While this clause does restrict mere use of the software, instead it
> creates liabilities for people modifying the software, even if they
> distributed their modified version in source form, with respect to the way
> the software perform on user systems.

If you distribute it in source form, there are no users interacting with
it remotely AFAICS?

> -- Modifying the software can unwillingly introduce a bug that cause it
> not to comply with this clause.

How so?

> -- A user of the modified version can mis-install it, mis-configure it or
> run it in an untested environment where it does not comply with this
> clause.

Yes, that's the same for many other software where you for instance need
to show a disclaimer.

> -- A user of the modified version can use it in a configuration that cause
> it to fail to comply with this clause (for example using a reverse proxy
> that remove link to the source code from the html output).

Same as above.

> 3. This clause is incompatible with Section 6. of the Debian Free Software
> Guideline.
>
> 3.1 This clause does not allow you to modify the software to perform tasks
> where complying with it is not technically feasible, for example:
>
> -- The code is modified to run on an embedded system with tight size limit.

And there will be users remotely interacting with it? While possible,
it's something to consider when using it on an embedded device. Though
the same is true for huge applications.

> -- The code is modified to interact with the user using a network connection
> with extremely low throughput.

Why would that cause any problem? It's not because one needs to provide
the source that it has to be downloaded AFAICS?

> -- The code is modified to interact with the user using a network protocol
> that does not allow to display a prominent offer.

Any example of this?

Cheers

Luk

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

GR proposal: the AGPL does not meet the DFSG (take 2)

2009-11-11T11:52:23Z

Dear developers,

I respectfully submit this general resolution proposal to your consideration.
(this GR proposal supersedes the proposal in <20090318235044.GA30722@yellowpig>)

Asking for seconds,
(please CC me)
Bill. <ballombe@...>

This General Resolution is made in accordance with Debian Constitution 4.1.5,
however it overrides a decision of the FTP masters made in
<87k5aovzzi.fsf@...> [1].

[1] <http://lists.debian.org/debian-legal/2008/11/msg00097.html

========= Text of the GR ===================
The Debian project resolves that softwares licensed under the GNU Affero
General Public License are not free according to the Debian Free Software
Guideline.
========= End of the text ==================

RATIONALE (to be amended if necessary):

1. The GNU Affero General Public License (AGPL) is essentially the GNU General
Public License with the following additional clause reproduced below.
See http://www.fsf.org/licensing/licenses/agpl.html for the full text
of the license.
""
13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users interacting
with it remotely through a computer network (if your version supports such
interaction) an opportunity to receive the Corresponding Source of your
version
by providing access to the Corresponding Source from a network server at no
charge, through some standard or customary means of facilitating copying of
software. This Corresponding Source shall include the Corresponding Source for
any work covered by version 3 of the GNU General Public License that is
incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to
link or combine any covered work with a work licensed under version 3 of the
GNU General Public License into a single combined work, and to convey the
resulting work. The terms of this License will continue to apply to the part
which is the covered work, but the work with which it is combined will remain
governed by version 3 of the GNU General Public License.
""

2. This clause is incompatible with Section 3. of the Debian Free Software
Guideline:

2.1 This clause restricts how you can modify the software.
Doing a simple modification to a AGPL-covered software might require you to
write a substantial amount of extra code to comply with this clause.

2.2 This clause forces the developer modifying the software to incur cost.
A developer modifying the software and distributing the modified version
need to incur the cost of providing access to the Corresponding Source from
a network server as long as at least one person is using the software and
this for all published modifications, even long after the developer stopped
using and/or distributing the software.

2.2. While this clause does restrict mere use of the software, instead it
creates liabilities for people modifying the software, even if they
distributed their modified version in source form, with respect to the way
the software perform on user systems.

-- Modifying the software can unwillingly introduce a bug that cause it
not to comply with this clause.

-- A user of the modified version can mis-install it, mis-configure it or
run it in an untested environment where it does not comply with this
clause.

-- A user of the modified version can use it in a configuration that cause
it to fail to comply with this clause (for example using a reverse proxy
that remove link to the source code from the html output).

3. This clause is incompatible with Section 6. of the Debian Free Software
Guideline.

3.1 This clause does not allow you to modify the software to perform tasks
where complying with it is not technically feasible, for example:

-- The code is modified to run on an embedded system with tight size limit.

-- The code is modified to interact with the user using a network connection
with extremely low throughput.

-- The code is modified to interact with the user using a network protocol
that does not allow to display a prominent offer.

signature.asc (204 bytes) Download Attachment

Doctor List in the USA

2009-09-22T03:36:45Z

Current Doctors in America

788,865 in total <> 17,105 emails

34 primary and secondary specialties

16 different sortable fields

Cost just slashed - $392

{}{}{} These come F.R.E.E. with every order {}{}{}

US Pharmaceutical Company Executives Database
Names and email addresses of 47,000 employees in high-ranking positions

American Hospital List
more than 23k hospital administrators in over 7k hospitals [worth over $300 alone)

US Dentist Database
More than half a million listings [worth $499 alone!]

Database of US Chiropractors
100k Chiropractors offices with full contact data including email, postal address, phone and fax

send email to: Charley@...

exp. mar Sept 26 2009

to get off please email exit@...

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Antalya'da Konaklama Yarım Pansiyon 50TL'den itibaren

2009-09-14T00:33:14Z

Yeni Sayfa 1

www.hotelroyalhill.com

* Dört Yıldızlık Hizmet*

ANTALYA Konyaaltı Sahilindeki Otelimizde sizleri de ağırlamaktan mutluluk duyarız.

Sngl HB 70TL ( Sabah Kahvaltısı, Akşam Yemeği Dahil )

Dbl HB 120TL ( Sabah Kahvaltısı, Akşam Yemeği Dahil )

Trpl HB 150TL ( Sabah Kahvaltısı, Akşam Yemeği Dahil )

* Otel Misafirlerine ücretsiz Hamam-Sauna-Fitness ve tüm odalarda ücretsiz wireless bulunmaktadır.

* Havaalanına ve Anfaş fuar Merkezine 15km - Antalya limanına, Otogara ve Şehir merkezine 3km uzaklıktadır.

Şirket toplantılarınız, Düğün ve Gala yemekleriniz için 80 ve 400 kişilik toplantı salonumuz Hizmetinizdedir.

Tel : 0 242 228 40 40 ( Pbx )
Fax: 0 242 228 45 46

info@...

www.hotelroyalhill.com

Convite - Música Sertaneja de Raiz

2009-08-24T11:04:10Z

Boa Tarde,

Convidamos você para visitar nossa página na internet.
www.joaotoledoepaulinho.com.br

Participe da Promoção Indicação Premiada.

Muito obrigado,

João Toledo & Paulinho

Não deseja mais receber nossas mensagens? Cancele o recebimento aqui.

Re: Bits from the release team and request for discussion

2009-08-15T11:44:50Z

Manoj Srivastava <srivasta@...> writes:

> On Tue, Aug 11 2009, Gunnar Wolf wrote:
>> I basically oppose such a GR, as it is is merely speculative (who
>> knows _now_ or at the GR voting time when we will be close to
>> achieving our release goals?), and because it is a ruling on a
>> technical subject (at least according to some metrics). But if the
>> vote were to be held at all, I would add:
>>
>> 6. The Debian project recognizes the responsible team to take any
>> decisions regarding the freeze date and reach to be the Release
>> Team, and accepts their best judgement in this regard.
>
> Perhaps you should look at this less confrontationally. The vote
> is a non-binding recommendation, it is an information gathering vote
> where people provide feedback to the release team; by voting for the
> option that best suits their development plans.

While I can't really disagree with this, I don't think a GR will
actually provide all the needed information.

In a GR, quite a few people will prefer one option over the other for
reasons that have nothing to do with the feasibility or quality of a
freeze at a given point [1].

I believe answers to a short questionnaire (what will be released when?
should it be in squeeze) would help a lot more, and thus I'm currently
working with the rest of the release team to send such mails.

At this point, I would like to once again apologize for the less than
optimal handling of communication between the release team and the rest
of the project in the past month. [2] The last weeks were shaped by
discussions that would have been unneeded if we had explained proposals
in a better way (and marked them more clearly as proposals) and avoided
some (now obvious) mistakes.

Marc

Footnotes:
[1] As example, people who know that they have a few thousand machines
running lenny will probably prefer a later date, so that they don't
need to do mass dist-upgrades after just 30 months.
[2] Please note that this statement is not a coordinated release team
statement, but an expression of my personal feelings.

attachment0 (202 bytes) Download Attachment

Re: Bits from the release team and request for discussion

2009-08-12T16:38:42Z

On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote:
>
>Any thoughts? We could have such a vote over and done in about two weeks,
>with the DPL's consent, and it'd seem a lot more inclusive and less
>cabal-tastic than how things seem to be working atm...

Personally, I think the last thing we need is a GR on this front right
now. There's still discussion going on and plenty of scope for
interested people to make their feelings known. We don't need the
overhead of a GR at all that I can see.

--
Steve McIntyre, Cambridge, UK. steve@...
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bits from the release team and request for discussion

2009-08-12T16:28:34Z

On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote:
> Any thoughts? We could have such a vote over and done in about two
> weeks, with the DPL's consent, and it'd seem a lot more inclusive and
> less cabal-tastic than how things seem to be working atm...

I think it is a bad idea, given that the release team seems to be
listening to the project and revising their freeze schedule ideas.

Michael

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bits from the release team and request for discussion

2009-08-12T15:58:01Z

On Wed, Aug 12 2009, Gunnar Wolf wrote:

> Manoj Srivastava dijo [Tue, Aug 11, 2009 at 03:08:52PM -0500]:
>> > I basically oppose such a GR, as it is is merely speculative (who
>> > knows _now_ or at the GR voting time when we will be close to
>> > achieving our release goals?), and because it is a ruling on a
>> > technical subject (at least according to some metrics). But if the
>> > vote were to be held at all, I would add:
>> >
>> > 6. The Debian project recognizes the responsible team to take any
>> > decisions regarding the freeze date and reach to be the Release
>> > Team, and accepts their best judgement in this regard.
>>
>> Perhaps you should look at this less confrontationally. The vote
>> is a non-binding recommendation, it is an information gathering vote
>> where people provide feedback to the release team; by voting for the
>> option that best suits their development plans.
>>
>> Based on the outcome, the release team can come to an *informed*
>> decision. By objecting to the vote, you might be making the tasks of
>> the release team harder, by denying them information from the project
>> at large.
>
> It is not confrontational, as it has been pointed out by others
> here. You might rephrase what I meant to say as:
>
> 6. This particular developer knows there is more to a release than
> his personal (or particular group's) points of view, and
> acknowledges any decision put forward by the release team, as
> long as they listen to the project real concerns, will be
> better informed and, thus, better than any random date that
> might be pushed forward

Why is this vote not being considered a part of the release
managers listening to the developers? Throw away the results of the
vote. The release managers can just look at the raw data, to see how
many people are saying that for their packages, the optimal release
date is foo. Then, factor in other variables, and look at large
packages differently, look at the major packages to sync with upstream
and other distributions, and decide.

This whole thing of we must not even take a straw poll to see
what developers might say, because giving the developers a voice will
somehow undercut the release team seems somewhat strange to me.

I would be against binding resolutions, but I am in favour of
non-binding straw polls.

manoj
--
Kill Ugly Processor Architectures Karl Lehenbauer
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bits from the release team and request for discussion

2009-08-12T14:59:12Z

Manoj Srivastava dijo [Tue, Aug 11, 2009 at 03:08:52PM -0500]:

> > I basically oppose such a GR, as it is is merely speculative (who
> > knows _now_ or at the GR voting time when we will be close to
> > achieving our release goals?), and because it is a ruling on a
> > technical subject (at least according to some metrics). But if the
> > vote were to be held at all, I would add:
> >
> > 6. The Debian project recognizes the responsible team to take any
> > decisions regarding the freeze date and reach to be the Release
> > Team, and accepts their best judgement in this regard.
>
> Perhaps you should look at this less confrontationally. The vote
> is a non-binding recommendation, it is an information gathering vote
> where people provide feedback to the release team; by voting for the
> option that best suits their development plans.
>
> Based on the outcome, the release team can come to an *informed*
> decision. By objecting to the vote, you might be making the tasks of
> the release team harder, by denying them information from the project
> at large.

It is not confrontational, as it has been pointed out by others
here. You might rephrase what I meant to say as:

6. This particular developer knows there is more to a release than
his personal (or particular group's) points of view, and
acknowledges any decision put forward by the release team, as
long as they listen to the project real concerns, will be
better informed and, thus, better than any random date that
might be pushed forward

--
Gunnar Wolf • gwolf@... • (+52-55)5623-0154 / 1451-2244

attachment0 (196 bytes) Download Attachment

Re: Bits from the release team and request for discussion

2009-08-12T12:56:08Z

On Tue, 11 Aug 2009, Matthew Johnson wrote:

> On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
> > Personally I don't think we should do a GR to recommend a freeze or release date.
> > We already used the DPL election to push a release, when it was *long* due, but
> > I don't think we should push a freeze.
>
> Zack has been patching devotee to allow more informal (and not at all
> binding) polls to be run with the same infrastructure. I think this
> could be a suitable candidate to run using that. It allows us to have a
> poll which can only be voted in by DDs and not easily stuffed, but
> without having to go through the pain of a formal resolution.

I would like to see such a poll as well.

Cheers,
--
Raphaël Hertzog

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bits from the release team and request for discussion

2009-08-12T08:08:08Z

On Wed, Aug 12, 2009 at 1:10 AM, Bernhard R. Link <brlink@...> wrote:

* Marc Singer <elf@...> [090812 03:12]:

> 2009/8/11 Josselin Mouette <joss@...>
>
> > [deletia]
> >
> > I do not trust a majority of people ? regardless of the people ? to make
> > an appropriate managerial decision. We have people in charge, who take a
> > lot of time to remain informed of the status of various subsystems in
> > Debian so that they can make informed decisions. If we replace them by a
> > majority?s vote, you can expect the decisions to be wrong.
> >
>
> It is also challenging to get a large group of people well enough informed
> to make a decision worthy of the effort.

While it is challenging to inform a large group of people, that is in my
eyes rather a reason to make it a vote: If you do not inform people well
enough so that they would vote for the best solution, they will not
recognize the best solution as that, so they will be unhappy with those
doing the decisions and be frustrated, leaving or working against the
solution.

So if you cannot get the people affected by the decision to back up the
decision (and if it is only in a way of "X I trust, X said Y") then not
doing a vote is the wrong way to go: Better risk a suboptimal decision
and people supporting that to having decided an optimal solution that
cannot work due to lack of support or even no longer having people doing
the better solutions in charge as noone likes their decisions.

The claim that "...noone [sic] likes their decisions" is hardly defensible.

Whether or not there is a GR, the point is that it is difficult to assess the benefit
of a recommendation made by the membership as it has everything to do with
the question asked and the depth of their knowledge of the issue. Perhaps
the fundamental issue is whether or not the membership is willing to trust the
decisions of the release managers.

Cheers

Re: Bits from the release team and request for discussion

2009-08-12T01:10:25Z

* Marc Singer <elf@...> [090812 03:12]:

> 2009/8/11 Josselin Mouette <joss@...>
>
> > [deletia]
> >
> > I do not trust a majority of people ? regardless of the people ? to make
> > an appropriate managerial decision. We have people in charge, who take a
> > lot of time to remain informed of the status of various subsystems in
> > Debian so that they can make informed decisions. If we replace them by a
> > majority?s vote, you can expect the decisions to be wrong.
> >
>
> It is also challenging to get a large group of people well enough informed
> to make a decision worthy of the effort.

While it is challenging to inform a large group of people, that is in my
eyes rather a reason to make it a vote: If you do not inform people well
enough so that they would vote for the best solution, they will not
recognize the best solution as that, so they will be unhappy with those
doing the decisions and be frustrated, leaving or working against the
solution.

So if you cannot get the people affected by the decision to back up the
decision (and if it is only in a way of "X I trust, X said Y") then not
doing a vote is the wrong way to go: Better risk a suboptimal decision
and people supporting that to having decided an optimal solution that
cannot work due to lack of support or even no longer having people doing
the better solutions in charge as noone likes their decisions.

Hochachtungsvoll,
Bernhard R. Link

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bits from the release team and request for discussion

2009-08-12T01:06:09Z

On Tue, Aug 11, 2009 at 07:56:33PM -0500, Manoj Srivastava wrote:
> The whole vote is to come up with a recommendation for the
> decision makers

And should the decision makers not follow that recommendation, the
flamewars will truely begin.

The format and phrasing of this is:
"The Debian project recommends [something]".
I would feel very uncomfortable going against the project directly
recommending I follow a particular course of action. This indicates to
me that this is more of an instruction, rather than a recommendation,
despite the wording.

Neil
--
<moray> hm, maybe wearing a black t-shirt while dusting my bedroom for the
first time in years wasn't such a good idea

--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...