Joining forces vs. starting from scratch (was Re: Proposal to start a new implementation...)

Phillip Hallam-Baker phill at hallambaker.com
Thu Apr 13 13:36:55 UTC 2017


On Thu, Apr 13, 2017 at 9:12 AM, Ben Bucksch <ben.bucksch at beonex.com> wrote:

> Gervase Markham wrote on 13.04.2017 14:41:
>
>> On 12/04/17 18:44, Jim Jagielski wrote:
>>
>>> But certainly the selection of a license semi-defines the community that
>>> rallies around a s/w project... As well as how said community wishes to
>>> distribute the s/w project itself.
>>>
>> But, particularly when building on existing codebases and libraries,
>> licenses are not selected in a vacuum.
>>
>> Here's my point in a nutshell. We could:
>>
>> a) have a big argument about licenses, come to a conclusion which
>> results in some people going off in a huff, and then try and find code
>> to achieve our goal compatible with those license choices; or
>>
>> b) find the codebase(s) to start from which we think will give us the
>> best chance of success, and then look at their licensing, and see if
>> they can be combined and if the result upsets anyone. If so many people
>> don't like the result that you think your chances of success are now
>> small, repeat the process with different choices.
>>
>
> To be fair, b) is exactly how we arrived here. We talked about Nylas N1,
> Kent briefly considered it as base, and then saw that it's GPL. That's how
> this discussion came to be.
>
> But you're right. This is not the time to have this discussion. It's
> rathole and distraction, indeed.
>
> Your point about being specific about what codebase we need is
> particularly well-suited right here. I just double-checked the license of
> Nylas N1, and it's in fact GPL v3. Which, if I remember correctly, is not
> compatible with GPL v2. So, that's again an entirely different problem.
>
> OTOH, emailjs.org libraries (which asutherland called 'excellent', IIRC)
> are under MIT license, so the question might not even pose itself. MIT is
> compatible to pretty much everything else, and we already have MIT code in
> the Mozilla tree. And such libraries are probably the part that we need the
> most.
>

​If you are committed to really open source then MIT or BSD are by far the
best options. There is a reason they are compatible with pretty much
everything - they make no demands.

GPL does make demands which is why quite a few semi commercial projects I
have worked on used it. In one case we bought out a crypto library a couple
of people had put together and released it under GPL to stop our
competitors using it in their product. I think we would have done better to
have just asked them to chip in a fair contribution and make it MIT License.

One of the big concerns I had with GPL3 was that it is a very long and very
complicated contract written with the objective of achieving a particular
set of ideological goals. And it is very much rooted in the
techno-political debates of the 1990s, not today.

https://www.gnu.org/licenses/gpl-3.0.html

The part that affects me, security is that RMS had been going off on an
anti-DRM jihad which is a problem because at a technical level it is really
difficult to distinguish DRM measures and use of hardware protections for
public keypairs. Using a private key that is bound to the machine and
cannot be exported from it is a really useful and powerful technique. Does
GPL3 permit that? Well I have no idea and neither does anyone else as you
have to wade through a very long contract that uses a lot of language and a
lot of principles that have never been tested in court.

Trying to force other people to follow your idea of freedom really isn't
freedom, its something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170413/c00c6bf4/attachment-0001.html>


More information about the tb-planning mailing list