State of Pidgin: Reverse Engineering FUD

Ethan Blanton elb at pidgin.im
Tue Oct 3 11:22:48 EDT 2017


Gary Kramlich wrote:
> On a few occasions now, I have had individuals contact me in regards to
> wanting to contribute to the project but are weary of the legality of some
> of our code.  The code in question is of course the proprietary protocol
> implementations.

I am unmoved by this argument.

> It has also been brought to my attention that employers won't allow their
> employees to contribute due to the gray area that our protocol plugins
> exist in as well.  This is unfortunate as it starts to limit our
> contributor base which as we're all aware could use

Ditto.

> We've skirted around these concerns in the past, but I would like to
> honestly put them behind us.  What I am proposing is theoretically simple,
> but a kind of a logistical nightmare.  What I would like to see is
> libpurple ship with just open standard protocols in tree.  That is IRC,
> SILC, XMPP, Matrix.org and maybe Zephyr which is simple enough.  We would
> then put all of the proprietary protocols into their own repositories which
> creates the logistical nightmare.

I have no problem with removing prpls that are a technical problem.
In general, though, I'd rather see moving some of the popular third
party prpls (particularly the ones maintained by regular contributors
or developers) moved in-house.

Splitting things out just means *more* stuff to keep track of.  We
already have trouble keeping track of the things we have.

The one *valid* reason I see for breaking out proprietary prpls is the
ability to fix them when the provider changes something and breaks
things.  This is historically difficult for us because it involves
pushing an entirely new release.  However, it also doesn't happen
particularly often.

Ethan



More information about the Devel mailing list