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

[Bill Allombert]

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. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Wouter Verhelst]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

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. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

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).
> > 

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

[Bill Allombert]

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 

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

[Martin Langhoff]

On Thu, Nov 12, 2009 at 1:24 PM, Toni Mueller  wrote:
>
> Hi,
>
> On Wed, 11.11.2009 at 23:46:59 +0100, 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.langh...@gmail.com
 mar...@laptop.org -- 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Toni Mueller]

Hi,

On Wed, 11.11.2009 at 23:46:59 +0100, 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Yves-Alexis Perez]

Frank Lin PIAT a écrit :
> Russell Coker wrote:
>> On Thu, 12 Nov 2009, Wouter Verhelst  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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Frank Lin PIAT]

Russell Coker wrote:
> On Thu, 12 Nov 2009, Wouter Verhelst  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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russell Coker]

On Thu, 12 Nov 2009, Wouter Verhelst  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.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Martin Langhoff]

On Wed, Nov 11, 2009 at 11:11 PM, Wouter Verhelst  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.langh...@gmail.com
 mar...@laptop.org -- 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Wouter Verhelst]

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.ga30...@yellowpig>)
> 
> Asking for seconds,
> (please CC me)
> Bill. 
> 
> 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@delenn.ganneff.de> [1].
> 
> [1]  
> = 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.

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

[Luk Claes]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

Dear developers,

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

Asking for seconds,
(please CC me)
Bill. 

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@delenn.ganneff.de> [1].

[1] 

Re: GR proposal: the AGPL does not meet the DFSG

[Bill Allombert]

On Mon, Apr 06, 2009 at 09:27:06AM +0200, Lionel Elie Mamane wrote:
> On Mon, Apr 06, 2009 at 02:02:42AM +0200, Bill Allombert wrote:
> > On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote:
> >> On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:
> 
> >>> RATIONALE (to be amended if necessary):
> 
> >>> 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 can require 
> >>> you to
> >>> write a substantial amount of extra code to comply with this
> >>> clause.
> 
> >> No, it does not. Merely modifying the software does not trigger the
> >> clause. It is triggered only if you offer a service to third parties
> >> using your modified version, or distribute it to others that do. The
> >> latter part (distribute to others that do) is unfortunate; I expect it
> >> is not the intention of the AGPL writers.
> 
> > As written, suppose you modify it and distribute it (in source form)
> 
> Exactly: modify _and_ distribute. Modify alone is not a trigger (to
> fall back to math jargon, it is not a sufficient condition).
> 
> > and it reachs the original copyright holder, they can run it and
> > complains if it does not "prominently offer all users interacting
> > with it remotely through a computer network". So in practice the
> > clause is triggered as soon as your version supports such
> > interaction.
> 
> _If_ you distribute it (or run it so that others can interact with
> it). Similarly, clauses 5c, 5d, 6 of the GNU GPL gets triggered on
> distribution, not on modification alone.

You are correct. I misread what you wrote (specifically
"or distribute it to others that do").

> >> Distribution is the same trigger than what triggers the "copyleft"
> >> clauses of the ordinary GPL; so that trigger cannot in itself be a
> >> problem for DFSG freedom.
> 
> > The trigger seems to be "modification" rather than "distribution".
> 
> No, conjunction of the two (or conjunction of modification and letting
> others interact with it).

So to summary the trigger is:
1) Modification and distribution (even in source form).
or
2) Modification and "use it so that others can interact with
  it remotely through a computer network".

> There is a big uncertainty there what "interacting with the user"
> means; a library of mathematical functions clearly would not. A
> complete PHP-style application like mailman, imp, ... clearly
> would. But a PHP library that produces chunks of HTML to be displayed
> to the user by the caller? I don't know.

This one of several uncertainty with this license which make me really
uncomfortable. Free softwares licenses should not require you to be
a lawyer to understand them.

> > 1) your program must fit in 8kB or
> 
> Why is that not a problem for clause 5d of the GNU GPL v3 (clause 2d
> of version 2), which we do consider free? Imagine a GPLed program
> whose interactive user interfaces _do_ display "Appropriate Legal
> Notices". Damn, you want to squeeze within a small size, and the
> "Appropriate Legal Notices" make you go over the limit. How is that
> situation different from the AGPL one?

I am not necessarily a fan of that particular clause of the GPL because
it interfers with DFGS-3, but it reads:

d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.

which is much less obnoxious than the AGPL.  At least you can remove the
interactive user interfaces and then remove
the Appropriate Legal Notices.

> > 2) your program interact with users in a low-level way that preclude
> > from "proheminently offering" or
> 
> I'm not sure I understand what that means. Very low-level would
> be... e.g. blinking lights and switches, like very early hobbyist
> computers? Then the user is assumed to be understanding some protocol
> over these blinking lights. But that protocol may not be rich enough
> for an URL or similar (e.g. the protocol is just one 8-bit number in
> base two through eight non-blinking lights). Yes, OK, that's a
> clear-cut (if corner) case where it is a real problem.
> 
> > 3) your program can send notice of "offering source" but clients
> > programs for this protocol generally never display such notice, so it is not
> > "proheminent" or
> 
> > (e.g. a pop3 server can display a message when you telnet to it, but
> > almost nobody ever does that).
> 
> Is a POP3 server, when not being used through telnet / nc / ...,
> interacting with a user? It seems to me it is not; it is interacting
> with the user's mail retrieval agent (fetchmail, icedove, ...).

What would you say if a CGI script was "offering source" by means of
HTTP headers instead of in the HTML code ?
Maybe the POP3 server is required to create

Re: GR proposal: the AGPL does not meet the DFSG

[Kurt Roeckx]

On Mon, Apr 06, 2009 at 06:49:57AM +0300, Aigars Mahinovs wrote:
> 2009/3/19 Bill Allombert :
> > Dear developers,
> >
> > I respectfully submit this general resolution proposal to your 
> > consideration.
> >
> > Asking for seconds.
> >
> > - - - - - - -
> > General Resolution made in accordance with Debian Constitution 4.1.5:
> >
> > The Debian project resolves that softwares licensed under the GNU Affero
> > Public License are not free according to the Debian Free Software Guideline.
> > - - - - - - -
> >
> 
> I second the above proposal.

gpg: BAD signature from "Aigars Mahinovs "


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Lionel Elie Mamane]

On Mon, Apr 06, 2009 at 02:02:42AM +0200, Bill Allombert wrote:
> On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote:
>> On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:

>>> RATIONALE (to be amended if necessary):

>>> 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 can require you 
>>> to
>>> write a substantial amount of extra code to comply with this
>>> clause.

>> No, it does not. Merely modifying the software does not trigger the
>> clause. It is triggered only if you offer a service to third parties
>> using your modified version, or distribute it to others that do. The
>> latter part (distribute to others that do) is unfortunate; I expect it
>> is not the intention of the AGPL writers.

> As written, suppose you modify it and distribute it (in source form)

Exactly: modify _and_ distribute. Modify alone is not a trigger (to
fall back to math jargon, it is not a sufficient condition).

> and it reachs the original copyright holder, they can run it and
> complains if it does not "prominently offer all users interacting
> with it remotely through a computer network". So in practice the
> clause is triggered as soon as your version supports such
> interaction.

_If_ you distribute it (or run it so that others can interact with
it). Similarly, clauses 5c, 5d, 6 of the GNU GPL gets triggered on
distribution, not on modification alone.

>> Distribution is the same trigger than what triggers the "copyleft"
>> clauses of the ordinary GPL; so that trigger cannot in itself be a
>> problem for DFSG freedom.

> The trigger seems to be "modification" rather than "distribution".

No, conjunction of the two (or conjunction of modification and letting
others interact with it).

>> Even if the clause is triggered, the most additional "extra amount
>> of code" you have to write is provide a link to a download
>> location.

> This assumes the program is a CGI script or at least can display
> text content to the users interacting with it through a network.

Well, the clause applies only to versions that interact with users; so
we place ourselves in the case where the program is interacting with
the user in some way. So it is giving the user messages in some form,
be it text, hypertext, audio, pictures, ... _And_ the user is giving
messages to the program, in some form such as following links, mouse
clicks, keyboard key presses, ... So if it has to obey this clause, it
has the ability to convey some content to the user. If the only
content it can convey is audio, then read an URL aloud slowly enough
so that a normal person can follow.

Interaction is necessarily bidirectional in my understanding; the
program can communicate to the user and the user can communicate
(usually "give orders") to the program.

>> Adding exactly one string in a relatively prominent place. That's
>> not "a substantial amount", especially as typically an AGPL-covered
>> software will already have the download link or mechanism, you only
>> have to change the URL or something like that. I'd
>> be sympathetic to a statement along the lines of:

>>  Software licensed under the AGPL, that does not itself provide an
>>  "opportunity to receive the Corresponding Source" in the meaning
>>  of clause 13, or is structured such that changing this opportunity
>>  to the source of modified version is not easy, is non DFSG-free,
>>  if it is not free for other reasons (e.g. dual license BSD /
>>  AGPL).

> What if you are reusing only part of the software ?

If that part interacts with the user, the clause applies, but you
interact with the user, so you can. If that part does not interact
with the user, you are off the hook.

There is a big uncertainty there what "interacting with the user"
means; a library of mathematical functions clearly would not. A
complete PHP-style application like mailman, imp, ... clearly
would. But a PHP library that produces chunks of HTML to be displayed
to the user by the caller? I don't know.

> What if your version (but not the original) implement a limited
> protocol that does not allow to convey arbitrary messages to the
> users ?

You are designing the protocol anyway; add one message to your
protocol that says "full sources available at... / do ${ACTION} to get
the sources", ...

But what if you cannot chose the protocol, but want to be a drop-in
replacement for another program (e.g. some non-free program)? Yes,
that can be a real problem.

>>> 2.2 This clause forces the developer modifying the software 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
>>> the software.

>> Ah, I see. That's probably unfortunate

Re: GR proposal: the AGPL does not meet the DFSG

[Aigars Mahinovs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

2009/3/19 Bill Allombert :
> Dear developers,
>
> I respectfully submit this general resolution proposal to your consideration.
>
> Asking for seconds.
>
> - - - - - - -
> General Resolution made in accordance with Debian Constitution 4.1.5:
>
> The Debian project resolves that softwares licensed under the GNU Affero
> Public License are not free according to the Debian Free Software Guideline.
> - - - - - - -
>

I second the above proposal.

For me the whole reason of the DFSG is so that our user would be able
to take all the software in main, use it, change it and distribute it
with minimal legal hassle. Due to reasons other people voiced in the
thread, I do not think GNU AGPL fulfill the implicit 'no legal
surprises' criteria.

- --
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)

iEYEARECAAYFAknZe9AACgkQMzCiFWcgm94RGQCePG2uVJv1aZpYtCFEIBLsZYMy
8kEAmgNQLXJy3zR9IzUSG7KSEqB12+LY
=mERC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Bill Allombert]

On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote:
> On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:
> 
> > RATIONALE (to be amended if necessary):

First of all, thanks a lot for your helpful contribution to this discussion.

> > 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 can require you 
> > to
> > write a substantial amount of extra code to comply with this
> > clause.
> 
> No, it does not. Merely modifying the software does not trigger the
> clause. It is triggered only if you offer a service to third parties
> using your modified version, or distribute it to others that do. The
> latter part (distribute to others that do) is unfortunate; I expect it
> is not the intention of the AGPL writers.

As written, suppose you modify it and distribute it (in source form) and 
it reachs the original copyright holder, they can run it and complains if 
it does not "prominently offer all users interacting with it remotely through a
computer network". So in practice the clause is triggered as soon as your
version supports such interaction.

> Distribution is the same
> trigger than what triggers the "copyleft" clauses of the ordinary GPL;
> so that trigger cannot in itself be a problem for DFSG freedom.

The trigger seems to be "modification" rather than "distribution".

> Even if the clause is triggered, the most additional "extra amount of
> code" you have to write is provide a link to a download
> location.

This assumes the program is a CGI script or at least can display text content
to the users interacting with it through a network.

> Adding exactly one string in a relatively prominent
> place. That's not "a substantial amount", especially as typically an
> AGPL-covered software will already have the download link or
> mechanism, you only have to change the URL or something like that. I'd
> be sympathetic to a statement along the lines of:
> 
>  Software licensed under the AGPL, that does not itself provide an
>  "opportunity to receive the Corresponding Source" in the meaning of
>  clause 13, or is structured such that changing this opportunity to
>  the source of modified version is not easy, is non DFSG-free, if it
>  is not free for other reasons (e.g. dual license BSD / AGPL).

What if you are reusing only part of the software ?
What if your version (but not the original) implement a limited protocol that
does not allow to convey arbitrary messages to the users ?

> > 2.2 This clause forces the developer modifying the software 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
> > the software.
> 
> Ah, I see. That's probably unfortunate wording; the onus should be on
> the person providing a service to third parties through the software,
> not the developer having made the modification. But indeed, the latter
> seems to be what the license is technically saying.

I am unsure it is "unfortunate wording": copyright law does not permit to
impose arbitrary restriction on usage, and generally free software avoid
to restrict usage. Thus they can only restrict distribution (usual) or
modification (here).

> > 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.
> 
> I have difficulties imagining a scenario where "complying with it is
> not technically feasible"; also, it seems similar to the GPL's
> mechanism of "if you cannot legally obey both the GPL and patent law /
> a contract you have signed / ..., then you are not allowed to
> distribute at all".

That would be "not legally feasible".
Not technically feasible would mean you have technical requirement such that:
1) your program must fit in 8kB or
2) your program interact with users in a low-level way that preclude
from "proheminently offering" or
3) your program can send notice of "offering source" but clients
programs for this protocol generally never display such notice, so it is not
"proheminent" or
4) etc.
(e.g. a pop3 server can display a message when you telnet to it, but
almost nobody ever does that).

Cheers,
Bill


signature.asc
Description: Digital signature

Re: GR proposal: the AGPL does not meet the DFSG

[Lionel Elie Mamane]

On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:

> RATIONALE (to be amended if necessary):

> 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 can require you to
> write a substantial amount of extra code to comply with this
> clause.

No, it does not. Merely modifying the software does not trigger the
clause. It is triggered only if you offer a service to third parties
using your modified version, or distribute it to others that do. The
latter part (distribute to others that do) is unfortunate; I expect it
is not the intention of the AGPL writers. Distribution is the same
trigger than what triggers the "copyleft" clauses of the ordinary GPL;
so that trigger cannot in itself be a problem for DFSG freedom.

Even if the clause is triggered, the most additional "extra amount of
code" you have to write is provide a link to a download
location. Adding exactly one string in a relatively prominent
place. That's not "a substantial amount", especially as typically an
AGPL-covered software will already have the download link or
mechanism, you only have to change the URL or something like that. I'd
be sympathetic to a statement along the lines of:

 Software licensed under the AGPL, that does not itself provide an
 "opportunity to receive the Corresponding Source" in the meaning of
 clause 13, or is structured such that changing this opportunity to
 the source of modified version is not easy, is non DFSG-free, if it
 is not free for other reasons (e.g. dual license BSD / AGPL).

> 2.2 This clause forces the developer modifying the software 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
> the software.

Ah, I see. That's probably unfortunate wording; the onus should be on
the person providing a service to third parties through the software,
not the developer having made the modification. But indeed, the latter
seems to be what the license is technically saying.

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

I have difficulties imagining a scenario where "complying with it is
not technically feasible"; also, it seems similar to the GPL's
mechanism of "if you cannot legally obey both the GPL and patent law /
a contract you have signed / ..., then you are not allowed to
distribute at all".

-- 
Lionel


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Kurt Roeckx]

On Mon, Mar 23, 2009 at 12:31:01PM -0700, Russ Allbery wrote:
> MJ Ray  writes:
> 
> > I hope that others will support this debian and co-op view.
> 
> I continue to object to this GR as currently worded because it is a
> stealth delegate override that doesn't clearly state its implications and
> effects.  I encourage all DDs to not second it until it's been fixed, even
> if you agree with the substance.

The options I can see that might end up on the ballot would include:
- 4.1.3: override a delegate [1:1]
- 4.1.5: position statement about the AGFL [1:1]
  (Either the same as ftp-master, or the opposite.)
- 4.1.5.3: override a foundation document [3:1]

The last option is probably unlikely.

The problem I see with a position statement is that it's
non-binding and that the delegate's decission would still hold.
What ftp-master does with that is up to them.

I currently see no problem putting it under both of them,
and would like to see that clearly in the text of the
proposal.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Matthew Johnson]

On Mon Mar 23 15:08, Russ Allbery wrote:
> > Also, I think we should let the secretary to decide if a GR proposal
> > modifies some foundation document, overrides a delegate decision, or
> > requires amendment to be valid, rather than withholding seconds.
> 
> I don't think the secretary currently has that power under the
> Constitution.
> 
(sorry to hijack the thread) this is exactly what I want to clarify in
the other thread over <- there about constitutional issues. And why
I was trying to get that in _first_

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: GR proposal: the AGPL does not meet the DFSG

[Russ Allbery]

MJ Ray  writes:

> Did the delegates decide this particular matter or was Bug #495721
> merely a summary of current practice?  The statement there seemed
> incomplete in significant ways.

The ftpmaster statement about the AGPL was remarkably explicit.

recently we, your mostly friendly Ftpmaster and -team, have been asked
about an opinion about the AGPL in Debian.

The short summary is: We think that works licensed under the AGPL can
go into main. (Provided they don't have any other problems).

I'm not sure what requirements you have, but I have a hard time imagining
much done in the project that is more obviously a delegate decision.

> Also, I think we should let the secretary to decide if a GR proposal
> modifies some foundation document, overrides a delegate decision, or
> requires amendment to be valid, rather than withholding seconds.

I don't think the secretary currently has that power under the
Constitution.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Luk Claes]

MJ Ray wrote:
> Russ Allbery  wrote:
>> MJ Ray  writes:
>>> I hope that others will support this debian and co-op view.
>> I continue to object to this GR as currently worded because it is a
>> stealth delegate override that doesn't clearly state its implications and
>> effects.  I encourage all DDs to not second it until it's been fixed, even
>> if you agree with the substance.
> 
> Did the delegates decide this particular matter or was Bug #495721
> merely a summary of current practice?  The statement there seemed
> incomplete in significant ways.

Yes, they did.

> Also, I think we should let the secretary to decide if a GR proposal
> modifies some foundation document, overrides a delegate decision, or
> requires amendment to be valid, rather than withholding seconds. I'm
> not that great at bureaucracy, so I think it's better that only the
> secretary decides the rules, rather than having every DD try to use
> the rule book as a weapon.

I think it's wrong to leave the decision on whether a GR proposal
modifies a foundation document to the secretary. I do think it's a good
idea to request withholding seconds if anything is unclear.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[MJ Ray]

Russ Allbery  wrote:
> MJ Ray  writes:
> > I hope that others will support this debian and co-op view.
>
> I continue to object to this GR as currently worded because it is a
> stealth delegate override that doesn't clearly state its implications and
> effects.  I encourage all DDs to not second it until it's been fixed, even
> if you agree with the substance.

Did the delegates decide this particular matter or was Bug #495721
merely a summary of current practice?  The statement there seemed
incomplete in significant ways.

Also, I think we should let the secretary to decide if a GR proposal
modifies some foundation document, overrides a delegate decision, or
requires amendment to be valid, rather than withholding seconds. I'm
not that great at bureaucracy, so I think it's better that only the
secretary decides the rules, rather than having every DD try to use
the rule book as a weapon.

Hope that explains,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Steve McIntyre]

On Mon, Mar 23, 2009 at 12:31:01PM -0700, Russ Allbery wrote:
>MJ Ray  writes:
>
>> I hope that others will support this debian and co-op view.
>
>I continue to object to this GR as currently worded because it is a
>stealth delegate override that doesn't clearly state its implications and
>effects.  I encourage all DDs to not second it until it's been fixed, even
>if you agree with the substance.

+1

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Russ Allbery]

MJ Ray  writes:

> I hope that others will support this debian and co-op view.

I continue to object to this GR as currently worded because it is a
stealth delegate override that doesn't clearly state its implications and
effects.  I encourage all DDs to not second it until it's been fixed, even
if you agree with the substance.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Bill Allombert]

On Mon, Mar 23, 2009 at 12:09:39PM +, MJ Ray wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Bill Allombert  wrote:
> > - - - - - - -
> > General Resolution made in accordance with Debian Constitution 4.1.5:
> >
> > The Debian project resolves that softwares licensed under the GNU Affero
> > Public License are not free according to the Debian Free Software Guideline.
> > - - - - - - -
> 
> I second the above Resolution, although I note it is missing the world
> "General" before "Public".  My personal rationale is three-fold:

Thanks!

I like to say that I am in the process of improving the wording of this GR,
to address issues raised on this list.

In particular, I am considering making the rationale part of the GR text
(to make it a position statement from the project), but we would need more
discussion on this topic so we can agree on a rationale.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[MJ Ray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill Allombert  wrote:
> - - - - - - -
> General Resolution made in accordance with Debian Constitution 4.1.5:
>
> The Debian project resolves that softwares licensed under the GNU Affero
> Public License are not free according to the Debian Free Software Guideline.
> - - - - - - -

I second the above Resolution, although I note it is missing the world
"General" before "Public".  My personal rationale is three-fold:

firstly, the uncertainty about whether we have to ensure availability
of the whole software or only our modifications (in other words,
whether our app should go offline if savannah, debian or whatever
upstream hosting service goes offline to our users) could be a
significant cost of use (this is broadly Bill Allombert's point 2.2);

secondly, the AGPL contradicts the freedom to distribute "when you
wish" which I always thought was a fundamental part of free software.
It has often been mentioned by RMS and others, in speeches such as
http://fsfeurope.org/documents/rms-fs-2006-03-09.en.html
and some forced-publication licences (such as Reciprocal Public License)
have been listed on
http://www.fsf.org/licensing/licenses/index_html#NonFreeSoftwareLicense

finally, the AGPL is grounded in the self-contradicting idea of being
"specifically designed to ensure cooperation" as described in its
preamble (which also differs from the GNU GPL).  I believe cooperation
is necessarily voluntary (and I am not alone in that - see
http://www.ica.coop/coop/principles.html#1) and that "ensured
cooperation" is coercion, not freedom.  This is broadly in line with
debian's constitutional idea that "A person who does not want to do a
task which has been delegated or assigned to them does not need to do
it."

I hope that others will support this debian and co-op view.

Regards,
- -- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFJx3v4mUY5euFC5vQRAq4PAKCAILfH4vqC9mNfZEisA89K1bOtjQCgmKeh
Z+cEKLJLzYnqDSMKBXZuXY8=
=7dWJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Kurt Roeckx]

On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:
> Dear developers,
> 
> I respectfully submit this general resolution proposal to your consideration.

Please make clear what is part of the proposal and what is not.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Joerg Jaspert]

> Of course, had the FTP master rejected packages under the AGPL from the
> archive, I would not have bothered with a GR. However I would like this
> GR to be considered independently of the FTP master resolution. They are
> not the target, the AGPL is.

It is not seperate. You do want to override a decision from us, which is
that the AGPL is fine for packages in our archive. You do want Debian to
decide that this is not true and the AGPL is not ok.

Fine, have it, if you find seconders, but clearly name it after what it
is please.


-- 
bye, Joerg
Some NM:
>A developer contacts you and asks you to met for a keysign. What is
>your response and why?
Do you like beer? When do we meet? [...]


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Russ Allbery]

Bill Allombert  writes:

> I proposed my resolution explicitly under 4.1.5, not under 4.1.3.  The
> purpose of this GR is to take a public stance whether or not the AGPL
> meet DFSG.
>
> I am pretty confident that the FTP master will comply with the outcome
> of such determination, and I think it would be uselessly confrontational
> to draft it as overriding them.

I believe that you're mistaken in your belief that it's less
confrontational to override their decision without saying so.  However, I
will defer to the FTP team; if they see this distinction and agree with
it, I withdraw my objection.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Bill Allombert]

On Wed, Mar 18, 2009 at 07:32:48PM -0700, Russ Allbery wrote:
> Bill, could you please change the GR to explicitly say that it's
> overriding a delegate decision so that it's clear in its implications and
> motivation?

I proposed my resolution explicitly under 4.1.5, not under 4.1.3.
The purpose of this GR is to take a public stance whether or not the
AGPL meet DFSG.

I am pretty confident that the FTP master will comply with the outcome
of such determination, and I think it would be uselessly confrontational
to draft it as overriding them.

My view is that the FTP masters are delegated the power to decide 
which software belong in the archive at any given time. They are also
required to make this determination in a limited timeframe and with
limited resource than might be insufficient for the most complex issues.
As long as this proposal is not calling explicitely for packages
such-and-such to be moved in or out of the archive, it does not
override them.

Of course, had the FTP master rejected packages under the AGPL from the
archive, I would not have bothered with a GR. However I would like this
GR to be considered independently of the FTP master resolution. They are
not the target, the AGPL is.

(For those of you who believe in Montesquieu separation of powers, the FTP
masters delegated power is executive while a GR under 4.1.5 is legislative.
For the others, thanks for reading so far.)

Cheers,
-- 
Bill.  (Please CC me)

Imagine a large red swirl here. 



signature.asc
Description: Digital signature

Re: GR proposal: the AGPL does not meet the DFSG

[Russ Allbery]

"Felipe Augusto van de Wiel (faw)"  writes:
> On 18-03-2009 20:55, Russ Allbery wrote:
>> Bill Allombert  writes:

>>> General Resolution made in accordance with Debian Constitution 4.1.5:

>>> The Debian project resolves that softwares licensed under the GNU
>>> Affero Public License are not free according to the Debian Free
>>> Software Guideline.

>> What is the current ftpmaster ruling on this license?  Possibly the
>> same question in other words: why are you proposing this as a GR, when
>> that's not normally how license evaluation is done?
>
>   FTP Master team had announced their position on debian-legal:
>
> | The short summary is: We think that works licensed under the AGPL can
> | go into main. (Provided they don't have any other problems).
> Quoted from: http://lists.debian.org/debian-legal/2008/11/msg00097.html

Ah, so this is actually a delegate override.

Bill, could you please change the GR to explicitly say that it's
overriding a delegate decision so that it's clear in its implications and
motivation?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18-03-2009 20:55, Russ Allbery wrote:
> Bill Allombert  writes:
> 
>> - - - - - - -
>> General Resolution made in accordance with Debian Constitution 4.1.5:
>>
>> The Debian project resolves that softwares licensed under the GNU Affero
>> Public License are not free according to the Debian Free Software Guideline.
>> - - - - - - -
> 
> What is the current ftpmaster ruling on this license?  Possibly the same
> question in other words: why are you proposing this as a GR, when that's
> not normally how license evaluation is done?

FTP Master team had announced their position on debian-legal:

| The short summary is: We think that works licensed under the AGPL can
| go into main. (Provided they don't have any other problems).
Quoted from: http://lists.debian.org/debian-legal/2008/11/msg00097.html


Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBrhAACgkQCjAO0JDlykZKQgCfW8i2d8DfTiDaQI15t96j9ViK
Pb0AnRoCt/IYS0cB9BK9R1vZBdxh8I5w
=q+O6
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG

[Russ Allbery]

Bill Allombert  writes:

> - - - - - - -
> General Resolution made in accordance with Debian Constitution 4.1.5:
>
> The Debian project resolves that softwares licensed under the GNU Affero
> Public License are not free according to the Debian Free Software Guideline.
> - - - - - - -

What is the current ftpmaster ruling on this license?  Possibly the same
question in other words: why are you proposing this as a GR, when that's
not normally how license evaluation is done?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

GR proposal: the AGPL does not meet the DFSG

[Bill Allombert]

Dear developers,

I respectfully submit this general resolution proposal to your consideration.

Asking for seconds.

- - - - - - -
General Resolution made in accordance with Debian Constitution 4.1.5:

The Debian project resolves that softwares licensed under the GNU Affero
Public License are not free according to the Debian Free Software Guideline.
- - - - - - -

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 can 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 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
the software.

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. 

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature