Re: AGPL and Debian

2008-12-06 Thread Francesco Poli
On Fri, 28 Nov 2008 12:42:09 +0100 Joerg Jaspert wrote:

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

First off, thank you for explaining the rationale of your decision.
I wish Ftpmasters did so more often...

However, I disagree with your conclusion, and I would like to respond
to your points as a (disappointed) Debian user.
Just to be clear: IANAL, TINLA, IANADD, TINASOTODP (...it's a *response*
to a statement of the official Debian position).

 
 Reason:
[...]
 Citing the three main concerns from Bug #495721:
 
  1) It can might add a cost to the usage of the software that restricts
 its usage.
 [this is also raised in #506042]
 
 We do not think that this is a severe enough problem to restrict the
 freeness of a work licensed using the AGPL.
  - Offering a publically accessible network service already comes with a
cost that might be hard to calculate. Think about DDOS attacks for
example.

I am not convinced that the fact that a use cost might exist anyway
justifies adding other costly requirements.
I don't remember seeing use restrictions accepted as suitable for
main, before.

 
  - For practical matters the distribution costs via the internet are
close to zero for free software.

A cost which is negligible for some people, might be significant for
other, less lucky, people...

While bandwidth does cost money, and
having a (say) 20MB app downloaded a million times would create a
large cost, the license text reads from a network server at no
charge. This means it is not required to be your own server, so you
can use any of the free services, like Alioth, Savannah, SourceForge,
Launchpad or Google Code. While those are only there for Free
Software - that is the case for AGPL applications.

As already pointed out by other people, there's no guarantee that
running a modified AGPLv3'ed application, while the third-party hosting
service is off-line, will not be considered a breach of the license
conditions.
Hence, I think there's no guarantee that using a third-party hosting
service like Alioth is an acceptable way to comply with Section 13
requirements.

This leaves us with two options: setting up our own source distribution
server (which may be a significant cost) or put source on the same
server/device which runs the AGPLv3'ed application (which may be
unfeasible due to resource constraints, think about a small embedded
system which talks a limited network protocol).

[...]
  2) It might forbid private usage of software that uses any kind of
 network.
 
 We do not see that it would forbid the private usage of the software. If
 you use the software privately, the users of that software are a pretty
 limited group. And as soon as they can reach your system to use the
 software that means they are able to either download the source from your
 private server or get a link to a download location on a machine
 accessible to them.
 
 Why might it forbid the private usage of software? Section 13 only
 requires to offer the source to the users of your service. As such you
 only need to give it to the limited user set your private usage has.

The term user is not clearly defined.  If I get an access denied
error page through a browser, am I a user of the web application?
This ambiguity is really problematic, since it implies that there's no
clear way to tell who I am compelled to make source available to.

[...]
 In conclusion we will continue to access AGPL works into main subject to
 the rest of the checks that we also normally perform.

Sadly, another bunch of non-free software will be accepted in main.  :-(
As a Debian user, I am disappointed by the decreasing strictness with
which the SC and the DFSG are applied.


-- 
 On some search engines, searching for my nickname AND
 nano-documents may lead you to my website...  
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpY1AS5EXdW7.pgp
Description: PGP signature


Re: Building from source required?

2008-12-06 Thread Marco d'Itri
[EMAIL PROTECTED] wrote:

Must packages in main derive the contents of binary packages from the
sources shipped in the source package, or can they simply copy
pre-generated, not directly editable files which have been derived
using some other process (not available in the package sources)?
I remember a fair number of packages (and discussions here) whose
Debian source package contains some pre-built components.

It is not mandatory to fully rebuild a package every time the Debian
binary package is generated, and in some cases it may be impractical
and undesirable, but the following issues must be considered:
- the package must contain source for all components, otherwise it would
  need to be uploaded to non-free
- the main Debian archive must contain all the tools needed to fully
  rebuild the package from source, otherwise it would need to be
  uploaded to contrib
- the release manager (and probably the security team as well) must be
  comfortable with the result

-- 
ciao,
Marco


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



Suggested removal: yocto-reader (RC bug, depends on remote scripts).

2008-12-06 Thread Charles Plessy
Dear release team,

yocto-reader has a RC bug that was filed for multiple licensing issues. After
discussing with the bug reporter and getting advice from debian-legal (thanks
for the input), it seems that at least one of the issues is a clear violation
of our Policy (I will not discuss others in this email, you can read
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579 for more details).

Le Thu, Dec 04, 2008 at 10:12:30PM -0800, Walter Landry a écrit :
 Charles Plessy [EMAIL PROTECTED] wrote:
  Can you have a look to 
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579
  and help to resolve the issue?
(…)
   - Wether it is acceptable to have html pages that include a link to a 
  remote
 non-free Google javascript.
 
 If I understand correctly, the Google javascript is required in order
 for the page to work properly.  In Debian parlance, this means that
 yocto-reader depends on the Google javascript.  So at a minimum
 yocto-reader would have to go into contrib.

My first objection was that if yocto-reader is a server, then the dependance of
the Google javascript happens privatley on a remote computer and is not an
issue for Debian. However, people may also want to install yocto-reader on
their machine through the Debian package to use it locally. In that case,
relying on the download of a remote component makes the package unfit for
Debian. I checked that commenting the script section that downloads the
Google javascript breaks yocto-reader.

Since yocto-reader was not distributed in Etch, is a leaf package and has a
Popcon score of 5, I suggest to remove the pakcage from Lenny in the absence its
the maintainer.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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