Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> Yes, it phones home regularly.
>
> It is well written in the docs
> http://meshlab.sourceforge.net/wiki/index.php/Licenses
Thanks for the reference.
> It seems to me that it is not against the Debian social contract nor
> against the Debian Free Software Guidelines (DFSG).
This kind oof thing is written down anywhere in those documents
because at the time those documents were written it would have been
obvious to everyone concerned that it would be considered
unacceptable.
Not everything that we think is unacceptable is in those documents. I
don't want to make outrageous comparisons, but just to give a more
clear example (and I'm not saying this phoning home is as bad) we
don't have a statement saying that Debian packages shouldn't install a
backdoor allowing the developers to take over the user's computer, and
we don't have one saying that Debian image display programs shouldn't
send copies of all of the pictures to a private Debian mailing list
for our personal entertainment.
Given that software which phones home is becoming more and more
common, and it seems that even honest and reasonable developers like
yourself are starting to implement such functionality, I think we will
have to update the Debian policy documents to make it clear that this
is not acceptable in a Debian program. This is something that I will
take care of internally.
> If I am wrong forgive my ignorance. In any case i need this feature so
> i could disable it but only for Debian builds.
If you don't want to disable it then of course you are free to make
that choice. Your website is clear enough I think. But, in our
Debian builds we will have to disable it.
It would be acceptable from a privacy point of view to ask the user's
permission but I think this is a poor way of addressing your needs.
If I were the Debian maintainer for the program I would want to
compile it out.
> Is it possible to know at compile time if the runnining system is a
> 100% debian?
> I mean, i need that feature, and disabling it for 'easy' distribution
> like ubuntu seems me non very reasonable.
It would probably be best if you simply provided a configuration
option to completely remove it from the build.
Teemu Ikonen writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> I don't like this either, but is this really against the letter of the
> DFSG, policy or the social contract?
As the Debian maintainer you have the responsibility to provide the
software which best meets the needs of our users. With Free Software,
you have the ability, and in Debian the duty, to modify the software
as appropriate - even if upstream disagrees.
It is of course good to work cooperatively with upstream. It is best
if everyone keeps on good terms, and it is of course a good idea to
find out why upstream did something before changing it in our
package. But ultimately if the upstream maintainer and the Debian
maintainer disagree about something, then each is free to distribute
to their users the software in the form and with the behaviour that
they prefer. Hopefully that won't cause friction.
> On the other hand Paolo
> (perhaps?) needs to collect statistics in order to secure funding for
> his work. [...]
I think that a better option would be for us to help Paulo interpret
popcon data. That won't give him information about what kind of
meshes people are using, but it will give some estimated deployment
figures.
> At least when open source software phones home, one has the
> possibility to check what information is being sent. Maybe the best
> solution would be to have a pop-up dialog asking permission to phone
> home, with an "Always allow / deny from now on" option. In Windows
> this dialog comes with the firewall :)
Debian systems do not come with firewalls configured to defend the
user from programs on the computer; we rely on the programs themselves
to behave in an appropriate way.
If we are to make this configurable, then a better option would be a
debconf question feeding some configuration files. It is important to
make this machinery fail-block: that is, to ensure that at every level
of the configuration processing, the default is not to phone home.
Many users get very upset about unannounced phoning home and we
must absolutely prevent doing so by accident.
> Patches to the packaging are of course welcome. Unified diffs by mail
> are probably the least inconvenient option.
Right.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
