[zeromq-dev] [ANN] zmq.rs - native stack of ØMQ in Rust

[Pieter Hintjens]

This kind of thing happens, when we intersect communities.

Software licenses are not an easy area. Most projects on Github
haven't even got an explicit license, let alone a clear rationale for
their license choice.

I'm pretty sure that a MIT/BSD licensed project cannot accept pull
requests without an additional step ("I license this patch/all my
patches under MIT"), which most people will not know about, or skip.
Meaning the codebase can become tainted with unlicensed code.

GitHub could in fact fix this with a one-time contributor agreement
for people sending PRs to a new project. Until then a share-alike
license like MPLv2 is safe by default. (This is my current analysis,
I'm always happy to be corrected.)

-Pieter


On Thu, Jul 3, 2014 at 5:08 AM, Fantix King <fantix.king at gmail.com> wrote:
> Ah I see. I will keep MPLv2 :) Thank you!
>
> (see also discussions here:
> https://mail.mozilla.org/pipermail/rust-dev/2014-July/010660.html )
>
> Fantix
>
> On Wed, Jul 2, 2014 at 6:42 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>> Fantix,
>>
>> I'd recommend keeping the MPLv2 license, since otherwise you cannot
>> merge pull requests without further clearance.
>>
>> The problem is that a fork of an MIT-licensed repository will not
>> necessarily be MIT licensed. It's trivial to add code and relicense
>> the lot under a different license. Then, when you get a pull request
>> you have to explicitly check or ask that the patch be licensed
>> properly. It's significant work and if you don't do it, your entire
>> project may end up with an inconsistent, even unusable license.
>>
>> Sticking to MPLv2 (or LGPL as for libzmq) avoids that work and
>> eliminates the risk. By definition a pull request is safe to merge.
>>
>> This aspect is so important that C4 makes it mandatory. If you use an
>> MIT license, you cannot be compliant with C4.
>>
>> There is also the argument that a share-alike license increases the
>> incentive to send patches back. I've made MIT licensed libraries that
>> were widely used and yet got very few patches.
>>
>> -Pieter
>>
>>
>>
>>
>>
>> On Wed, Jul 2, 2014 at 11:44 AM, Fantix King <fantix.king at gmail.com>
>> wrote:
>> > Thanks a lot! I'll take a look at CZMQ and libzmtp.
>> >
>> > btw I may change the license to MIT :)
>> >
>> >
>> > BR,
>> > Fantix
>> > --
>> > http://about.me/fantix
>> >
>> >
>> > On Wed, Jul 2, 2014 at 5:36 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> >>
>> >> Very nice. The only comment I'd make is that the libzmq API is a
>> >> little clunky and you might look at the CZMQ zsock API as a model. The
>> >> code classes in CZMQ are zsock, zactor, and perhaps zbeacon and zmsg.
>> >> There's also an interesting API in libzmtp, which expresses separate
>> >> socket types as separate classes.
>> >>
>> >> -Pieter
>> >>
>> >> On Wed, Jul 2, 2014 at 8:16 AM, Fantix King <fantix.king at gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Here is zmq.rs, a native implementation of ØMQ in the Rust
>> >> > programming
>> >> > language in MPLv2. I've just got a very ugly prototype running till
>> >> > now,
>> >> > and
>> >> > I'm expecting to hear more comments on anything.
>> >> >
>> >> > https://github.com/zeromq/zmq.rs
>> >> >
>> >> > For who wants to know more about Rust, it is a systems programming
>> >> > language
>> >> > from Mozilla, that runs blazingly fast, prevents almost all crashes,
>> >> > and
>> >> > eliminates data races (according to http://www.rust-lang.org/).
>> >> > Guaranteed
>> >> > memory safety and concurrency without data races is what I liked it
>> >> > most.
>> >> >
>> >> > Back to the project, I did a few iterations and got what it is now,
>> >> > in
>> >> > the
>> >> > hope that more discussion can be raised over some actual code to talk
>> >> > about.
>> >> > zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0.
>> >> > I
>> >> > also
>> >> > blogged a bit about the design here (more to come):
>> >> >
>> >> > http://blog.segmentfault.com/fantix/1190000000593564
>> >> >
>> >> > You are more than welcome to:
>> >> >  * comment on the design
>> >> >  * suggest different solution
>> >> >  * complain about whatever you don't like
>> >> >  * open issues on github
>> >> >  * send me PRs and code reviews
>> >> >  * join me developing and maintaining it
>> >> >  * or even star it on github ;)
>> >> >
>> >> >
>> >> > BR,
>> >> > Fantix
>> >> > --
>> >> > http://about.me/fantix
>> >> >
>> >> > _______________________________________________
>> >> > zeromq-dev mailing list
>> >> > zeromq-dev at lists.zeromq.org
>> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> >
>> >> _______________________________________________
>> >> zeromq-dev mailing list
>> >> zeromq-dev at lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>