[In Development] Bitcoin.jl - A Julia bitcoin library

Package Announcements
21

Are you implementing a full interpreter for Script or do you just want to figure out to what wallet address a transaction is going?

I just saw, that I don’t have a dedicated Script type, BTCParser just uses Array{UInt8}, I should change that :slight_smile: .

22

Aiming for a full interpreter: OP_CODES are mostly implemented already.

Nice parser you did :+1:

23

I meant with no restrictions (be free software; not wasn’t talking about cost here, you can still charge for software) not allowed by the GPL.

At least Stallman defines proprietary/non-free this way.

24

A new milestone has been reached and package with be shortly published.
It now provides functionality that allows to fetch bitcoin transaction from nodes, get transaction ID, serialization, fee, signature hash and script evaluation.

More to come of course!

4 Likes
25

Just to mention: Ripemd.jl is a MIT licensed package…

After having a look at https://www.brane.cc [fixed wrong link, sorry] and Simon C. - Épinal, Grand Est, France | Professional Profile | LinkedIn I can understand that you feel the urge to keep the package under GPLv3 wraps.

It’s completely your call, but this decision could/will also bite you:

  • in case people contribute to your package you are also bound to the GPLv3. From the links above I get that you are interested ‘in business’, but you wouldn’t be able to use the package in proprietary settings (without ripping out the contributions)
  • you talk about collaboration but with your license choice you are not able to collaborate with the wider Julia package ecosystem. It’s a one way street :stop_sign:. Most likely less people will bother.
  • (I’m not interested in Bitcoin, but if I were, I’d start from scratch. And I also would certainly not look at your code at all because this taints)

This said, I’m not generally against GPL. One of the most beautiful Julia package I know, is: GitHub - chakravala/Dendriform.jl: Dendriform di-algebra algorithms to compute using Loday's arithmetic on groves of planar binary trees (edit: ups, I meant GitHub - chakravala/Fatou.jl: Fatou sets in Julia (Fractals, Newton basins, Mandelbrot) - and this is MIT). In your case I wonder, if not find funding and develop a normal MIT licensed package would be the better choice.

1 Like
26

Hum… My business idea is about data, software would/should be open source and so I think this would not be an issue but I didn’t realize GPL would be such a problem (especially considering your third point), that for pointing it out.

I’m now seriously considering switching over to LGPL which would only force amendment of the library itself to be released under LGPL - therefore making any improvement open source as well - while allowing the library to be used in proprietary code.
Would this license ease collaboration in your opinion? Or is MIT the only collaborative friendly license?

That would be https://www.brane.cc for whomever is interested at reading about my wider project.

27

As long as you are the only author you have time. Ask around, think it through (e.g. what exactly would I loose when someone takes my (your bitcoin) code and does proprietary stuff on top of it, how likely is this, what are my longterm plans) and then decide, no hurry, you should be comfortable.

I don’t have a clear opinion and I also don’t have insight into the (professional) Julia ecosystem. My thoughts go along:

  • do I want to stick out or go with what is custom? Do I need to stick out?
  • do I need/want to attract other developers, how likely are they to help with the different licenses?
  • is there a ‘risk’ that someone starts anew with MIT license and there are two ‘competing’ packages (on the other hand there are quite often different possibilities with Julia packages…:wink: )
  • if I had to choose, I would probably either go proprietary or ‘full free’, i.e. GPLv3 or AGPLv3 (because in ‘bitcoin-world’ services might be important?) or then ‘full open’, i.e. MIT. – Regarding LGPL (and MPL, Apache,…) there’s imho no clear benefit, it is just different from what most Julia users use. ([Edit:] JuMP.jl uses MPL 2.0, should have mentioned)
  • without an important personal business case I likely would switch to MIT. For an R package I’d choose GPL, but for Julia I’d go with MIT. I think the chance is bigger to find oneself in the center of a project (Julia-based bitcoin) if sticking to mainstream!
  • (by chance I came yesterday across this R blogger article: How GPL makes me leave R for Python :-( | R-bloggers. There were some very morally comments and I quite appreciate that with MIT this is much more relaxed. Also I believe the license (except agpl) is maybe no longer as important as in earlier times due to SaaS)
3 Likes
28

Thanks again @swissr

After careful consideration, I have decided to switch to an unlicense which I guess should not be an issue for collaboration since it cannot be more permissive.

What is the Unlicense?

The Unlicense is a template for disclaiming copyright monopoly interest in software you’ve written; in other words, it is a template for dedicating your software to the public domain. It combines a copyright waiver patterned after the very successful public domain SQLite project with the no-warranty statement from the widely-used MIT/X11 license.

Why Use the Unlicense?

Because you have more important things to do than enriching lawyers or imposing petty restrictions on users of your code. How often have you passed up on utilizing and contributing to a great software library just because its open source license was not compatible with your own preferred flavor of open source? How many precious hours of your life have you spent deliberating how to license your software or worrying about licensing compatibility with other software? You will never get those hours back, but here’s your chance to start cutting your losses. Life’s too short, let’s get back to coding.

Further to the above, I am not inventing anything with this Bitcoin library, just implementing it in Julia…
I would also have no means to enforce any license I would choose, so why bother?

1 Like
29

IANAL, but GNU recommends CC0 over the Unlicense, considering it “more thorough and mature” for the same purpose.

30

Which I find rather weird since CC0 is not intended for software per se :thinking:
Another hint in favor of The Unlicense is that CC0 isn’t available as a license template on Gihub/Gitlab whereas the former is.

1 Like
31

Historically, no, but the demand is now recognized and the issue was discussed with the FSF.

I think that license templates just reflect popularity/demand. In any case, you can use an arbitrary license.

Personally, I would just stick to MIT if I was aiming for the widest user base, if only because it is familiar. Anything like the Unlicense, the WTFPL, or even CC0 will just make the user pause and search the web for opinions, or skip the software entirely (in a risk averse/corporate setting). The fact that you readily switched from GPL to Unlicense suggests that you don’t have a strong preference, so you may as well go for MIT.

(Apologies if this is a distraction to your announcement of an interesting library. But I think these discussions are important for Julia packages in the long run.)

1 Like
32

For permissive licenses I recommend,
Apache 2.0 Safeguard against potential patent issues
ISC Updated version of MIT
BSD-3-Clause for protecting brand
Zlib for academic software

More than legal tools such as copyleft, the first best is a change in social norms which has progressed a lot and such the rise of permissive over copyleft licenses in many communities.

33

The LGPL is also good (I wouldn’t say the GPL, or AGPL is bad). Some have a linking exception for the LPGL (or GPL) to make all use even easier.

Then it seems you could go with MPL (version 2.0). It’s the weakest form of copyleft license I know of, shouldn’t scare anyone (well would keep collaborators with relevant patents away); also popular. The MPL and Apache licenses help users knowing they will not get into patent issues.

34

JuMP.jl uses MPL 2.0. (Only thought of this after I wrote my post above).

35

I was going for GPL for ideological reasons but had never thought of its implication up to now. All things considered, I then thought The Unlicense would be the best option since I do not care much if my name is not mentioned if my code is used somewhere else - being the sole requirement of MIT license if I understand correctly. But legally, it seems that the Unlicense isn’t even applicable in some jurisdiction:

So, after some days reading about licenses, MIT seem to make the most sense:

  • GPL-3.0 could render my code unused
  • LGPL-3.0 could have the very same impact, but at a lesser extend
  • MPL-2.0 / Apache-2.0 offers patent protection that I do not see a need for since I’m not inventing anything but simply implementing existing software in a new language

*** now we start with licenses that non-lawyer can understand ***

  • ISC isn’t that popular in general
  • BSD-2-Clause / BSD-3-Clause would both work
  • MIT achieves the same as the previous understandable licenses and has the advantage of being well known

I’ll finish with satoshi’s motivation for choosing MIT for bitcoin:

https://satoshi.nakamotoinstitute.org/posts/bitcointalk/451/

No bother, it is indeed important - I should have maybe moved /added this discussion to this Package License thread…

6 Likes
36

v0.1.1 has just been release, under MIT license

Anyone may test functionalities using Pkg.add("Bitcoin")

12 Likes
37

If you’ve wondered if it was possible to sign bitcoin transaction with GPG, check-out this tutorial using Bitcoin.jl and a quick and dirty PGP parser in julia

2 Likes
38

v0.1.6 has been released adding op_checkmultisig and P2SH support

39

v0.1.8 has just been released

Package now allows for basic functionality of peer to peer network communication.
My first steps using Sockets and async macro, a new world :slight_smile:

Once again, comments are more than welcome.

Next release to add more network and Merkel tree functions

2 Likes
40

Keep up the good work @roshii. I’m enjoying these updates :slight_smile:

2 Likes