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

Ben Bucksch ben.bucksch at beonex.com
Thu Apr 13 13:12:31 UTC 2017


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.

So, we don't actually have any license problem.



More information about the tb-planning mailing list