Joining forces vs. starting from scratch (was Re: Proposal to start a new implementation...)
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
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.
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...
More information about the tb-planning