Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

[David Weinehall]

On Tue, Dec 31, 2013 at 02:54:50PM +, Clint Adams wrote:
> On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote:
> > Apart from the termination clause, the GPLv2 is far more concise,
> > I don't see tivoization as a problem (it's the software I want to
> > protect, not anyone's combination of it with hardware), nor do I care
> > about compatibility with Apache 2.0 -- I do, however, care about
> > compatibility with GPL v2, which GPL v3 isn't.
> 
> So your doomsday scenario is that if you license something
> GPLv2+, someone might fork and modify it to be GPLv3+, and
> then someone else with a different doomsday scenario can't
> incorporate those modifications into GPLv2-only software?

In essence, yes.  While I do realise that no version of the GPL
guarantees that I can fold back downstream modifications into my
codebase (since the modifications need only be released further
downstream), there's a huge difference between "there's a theoretical
chance that the awesome improvement written by downstream user X will
never reach you" and "You cannot include said improvement even if you do
get hold of the modification".

While the situation is probably familiar to many developers who choose
BSD licenses for their software only to see their code folded into GPL
or proprietary software without being able to merge back the
improvements, they have in the first place chosen a license that has
this possiblity as one of its intentions.  The BSD allows for this, I
would almost say that it encourages it.  BSD licensed code is folded
into proprietary software all the time.

That's also why I *don't* use BSD-style licenses for software that
I write, but rather GPLv2 or LGPLv2.1.

The fact that the GPLv3 changed the license to be incompatible with, and
(at least in my opinion) not equivalent to the GPL v2, violates what I
saw as one of the attractive things with the GPL, being the "share and
share alike" way of thinking.  I always envisioned the (or later) clause
to be meant for fixing minor issues (unclear phrasing, inadvertent
stuff, etc.) like the changes from LGPL v2 to LGPL v2.1.

If someone really feels that some portion of codes I've written would be
useful for their project I'm more than happy to license that particular
bit -- almost -- whichever way they want (GPLv3, BSD, MIT, ...),
but I'm very uncomfortable with the notion of having forks of my
projects use a different license than my software does.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101095832.gc25...@hirohito.acc.umu.se

Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: pond
  Version : 0:git~2014-01-01
  Upstream Author : Adam Langley 
* URL : https://pond.imperialviolet.org/
* License : BSD
  Programming Lang: Go
  Description : Forward secure, asynchronous messaging for the discerning.

For secure, synchronous communication we have OTR and, when run over Tor, this 
is pretty good. But while we have secure asynchronous messaging in the form of 
PGP email, it's not forward secure and it gratuitously leaks traffic 
information. While a desire for forward secure PGP is hardly new, it still 
hasn't materialised in a widely usable manner.

Additionally, email is used predominately for insecure communications (mailing 
lists, etc) and is useful because it allows previously unconnected people to 
communicate as long as a (public) email address is known to one party. But the 
flip side to this is that volume and spam are driving people to use centralised 
email services. These provide such huge benefits to the majority of email 
communication, so it's unlikely that this trend is going to reverse. But, even 
with PGP, these services are trusted with hugely valuable traffic information 
if any party uses them.

So Pond is not email. Pond is forward secure, asynchronous messaging for the 
discerning. Pond messages are asynchronous, but are not a record; they expire 
automatically a week after they are received. Pond seeks to prevent leaking 
traffic information against everyone except a global passive attacker.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140101140014.10109.87951.reportbug@localhost.localdomain

Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.

[Philip Rinn]

Hi,

I think it's important to add also the paragraph about actual usability for the
homepage:

Dear God, please don't use Pond for anything real yet. I've hammered out nearly
20K lines of code that have never been reviewed. Unless you're looking to
experiment you should go use something that actually works (e.g. GnuPG).[0]


I general I'd ask if it's not better to wait for code reviews before packaging 
it.

Best,
Philip

[0] https://pond.imperialviolet.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c44ccf.7080...@inventati.org

Re: GnuTLS in Debian

[Bastien ROUCARIES]

Le 30 déc. 2013 10:06, "Florian Weimer"  a écrit :
>
> * Bastien ROUCARIES:
>
> > Fedora created a open SSL compat library based on libnss.
>
> It doesn't work all that well because there is no way to implement
> host name checking.  The OpenSSL API it's based on did not have an
> interface for host name verification, and the compatibility library
> does not duplicate enough of OpenSSL's ASN.1-related functionality so
> that applications can implement the verification themselves.

Could we  list on a wiki the lack this library?

I will upload it and you could open a bug.after it.

Bastien

Re: GnuTLS in Debian

[Thomas Hochstein]

Russ Allbery schrieb:

> "Bernhard R. Link"  writes:
>> Could you please stop using that word "idiosyncratic".
>
> I believe idiosyncratic is exactly the correct term:
>
>   idiosyncratic
>   adj 1: peculiar to the individual; "we all have our own
>  idiosyncratic gestures"; "Michelangelo's highly
>  idiosyncratic style of painting"
>
> and therefore decline to stop using it.

At least for the non-native speaker of English "idiosyncratic" may
rhyme very unfortunately with "idiotic"; that may be Bernhard's point.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ldd.1401011926...@landroval.ancalagon.de

Bug#733880: ITP: mediaelement -- HTML5 or player with Flash and Silverlight shims

[David Prévot]

Package: wnpp
Severity: wishlist
Owner: David Prévot 
Control: affects -1 owncloud wordpress

* Package name: mediaelement
  Version : 2.11.3
  Upstream Author : John Dyer  
* URL : http://mediaelementjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : HTML5  or  player with Flash and Silverlight 
shims

 Instead of offering an HTML5 player to modern browsers and a totally
 separate Flash player to older browsers, MediaElement.js upgrades them
 with custom Flash and Silverlight plugins that mimic the HTML5
 MediaElement API.


This code is currently embedded in owncloud and wordpress, and this
package aims at getting rid of these copies.

Regards

David


signature.asc
Description: Digital signature

Re: GnuTLS in Debian

[Russ Allbery]

Thomas Hochstein  writes:
> Russ Allbery schrieb:
>> "Bernhard R. Link"  writes:

>>> Could you please stop using that word "idiosyncratic".

>> I believe idiosyncratic is exactly the correct term:

>>   idiosyncratic
>>   adj 1: peculiar to the individual; "we all have our own
>>  idiosyncratic gestures"; "Michelangelo's highly
>>  idiosyncratic style of painting"

>> and therefore decline to stop using it.

> At least for the non-native speaker of English "idiosyncratic" may rhyme
> very unfortunately with "idiotic"; that may be Bernhard's point.

Yeah, I saw that also in Bernhard's reply.  That confusion had honestly
never occurred to me before since, despite the visual similarities, the
words are completely unrelated in English.  The etymologies are disjoint:
idiot comes from French and hence from Latin and dates back to the 1400s,
whereas idiosyncratic has an independent derivation from Greek root words
meaning "mixed together" and has existed independently with roughly its
current meaning since the 1600s.

Idiosyncratic and idiosyncrasy have not, historically, had a negative
connotation beyond the definition that they are peculiar to individual
organizations or institutions.  Consider, for example, some of the
following citations from the OED:

1839   H. Hallam Introd. Lit. Europe III. vi. 596   The elaborate
   delineations of Jonson, or the marked idiosyncracies of
   Shakspeare.

1918   F. E. Pierce Currents & Eddies in Eng. Romantic Generation
   i. iii. 85   The frame of the old ballad even..was a legacy of the
   ardour, the life, and the idiosyncrasy of the Northmen who left
   their descendants in our glens.

1949   Punch 13 May 636/2   Universities do not exist to lay on degree
   courses to follow the idiosyncratic requirements of a particular
   employer.

2003   E. Gregg & R. Trillo Rough Guide to Gambia 50/1   The Gambia's most
   idiosyncratic Christmas tradition is its fanal processions, unique
   to the Kombos.

I'm sorry for the confusion for non-native speakers.  English has a bad
habit of drawing words from all sorts of different languages and thus
creating a lot of accidental similarities between words that have no
relationship to each other.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2kbijiy@windlord.stanford.edu

Re: Bug#733634: ITP: gevent-socketio -- Socket.IO server based on the Gevent pywsgi server

[Piotr Ożarowski]

[Benjamin Drung, 2013-12-30]
> * Package name: gevent-socketio (binary: python-gevent-socketio)

please follow Debian Python Policy's recommendation and use
"python-socketio" as binary package name (module name is "socketio")


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101212541.gi4...@sts0.p1otr.com

Bug#733903: ITP: libmodule-want-perl -- module to check @INC only once for wanted modules

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmodule-want-perl
  Version : 0.6
  Upstream Author : Daniel Muey 
* URL : https://metacpan.org/release/Module-Want
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to check @INC only once for wanted modules

Sometimes you want to lazy load a module for use in, say, a loop or function.
First you do the eval-require but then realize if the module is not available
it will re-search @INC each time. So then you add a lexical boolean to your
eval and do the same simple logic all over the place.

Module::Want encapsulates that logic so that have_mod() is like eval {
require X; 1 } but if the module can't be loaded it will remember that fact
and not look in @INC again on subsequent calls.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101225614.ga11...@jadzia.comodo.priv.at

Bug#733910: ITP: ckon -- automatic build tool for ROOT analyses

[Patrick Huck]

Package: wnpp
Severity: wishlist
Owner: Patrick Huck 

* Package name: ckon
  Version : 0.6.1
  Upstream Author : Patrick Huck 
* URL : http://tschaume.github.com/ckon
* License : MIT
  Programming Lang: C++
  Description : ckon is an automatic build tool for C++ software developed 
within the CERN ROOT data analysis framework.

ckon is a C++ program/tool which automatically takes care of compilation, 
dictionary generation and linking of programs and libraries developed for data 
analyses within the CERN ROOT analysis framework. This includes parsing include 
headers to figure out which libraries the main programs need to be linked to. 
It uses automake/autoconf to be platform independent and GNU install compliant. 
In addition, m4 macros are automatically downloaded and the according compiler 
flags included based on a list of boost libraries provided in the config file. 
For the purpose of YAML database usage, a m4 macro can be downloaded during 
setup to link against the yaml-cpp library.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140102055132.1524.32518.reportbug@precise32