Unlicense is flawed enough to scare me off

[ssokolow]

I'd like to depend on this for an experiment where I'm rewriting a Python script which examines GIF files in a performance-optimized manner.

However because of flaws in the Unlicense, it's on my blacklist to ensure proper safety for my users, regardless of the jurisdiction they're in.

Is there any chance you'd be willing to offer byteorder under something more carefully designed like the Creative Commons CC0 public domain dedication?

(CC0 is also what the FSF recommends if you want to release your code into the public domain.)

[BurntSushi]

I'm sympathetic to your concerns. Hopefully we can work something out.

I'm quite familiar with all the material you've linked, but to my knowledge, neither the CC0 nor the Unlicense have actually been tested in a jurisdiction like Germany, so I'm skeptical of claims that one is better than the other. The CC0 FAQ admits that they aren't sure it works everywhere.

There are also some comments by the creator of the Unlicense which indicate that jurisdictions like Germany were clearly on his mind when he wrote it: https://groups.google.com/forum/#!topic/unlicense/GrjYlqmF92Q

I can appreciate the notion that the CC0 feels less risky than the Unlicense, but there are no guarantees associated with using it in all jurisdictions. I take this risk knowingly and purposefully, mostly because I am against copyright law. (I consider the Unlicense to be an explicit declaration of this fact, which is why I use it.)

However, I hate that this may alienate some users. Is there anything I can do to convince you to use byteorder short of changing its license? For example, I could, send you an email granting you permission to use byteorder under any license of your choosing.

I might consider dual licensing too, although that seems a bit ridiculous.

Finally, consider that there exists other popular software that is used internationally that is also under the public domain. For example, SQLite.

[ssokolow]

Keeping track of a specific permission grant would be more hassle and bother than just using the uglier APIs offered by bswap (MIT) or endian (LGPL3) so I'd rather avoid that option.

My preference for the CC0 over the Unlicense stems from the fact that:

1. While I've seen various specific concerns regarding the Unlicense, concerns with the CC0 seem to be primarily of the "can't prove a negative" variety.
2. Unlike the Unlicense, the CC0 has an explicit "Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law" fallback clause which switches it from "I relinquish all my rights" to "I explicitly grant you a license to every right the CC lawyers could think of". (Which could be thought of as a built-in analogue to dual-licensing)
3. It's the FSF's preferred approach to releasing things into the public domain and they tend to be pretty thorough and risk-averse when it comes to the four freedoms.

(Plus, for point 2, the fallback clause has its own internal fallback that says "if any of this can't be applied, the grants that can be applied are still valid" and includes something similar to a patent pledge but for copyright non-enforcement.)

As for SQLite, I do tend to develop against SQL expression generation shims so swapping in PostgreSQL and/or MySQL is an option, both for scalability and protection's sake, but it's also something of a special case for a variety of reasons I'd rather not exhaustively enumerate unless necessary.

[BurntSushi]

I've given this a lot of thought over the past few days and allowed myself to sleep on it. I am considering dual licensing under both the Unlicense and the MIT license. I think this maximizes expression (hate copyright) and use (MIT is battle tested (more so than CC0) with nominal requirements). Would that be enough to set you at ease?

(Sorry about taking so long. But I wanted to be sure I was OK with this, as I'll probably extend this licensing scheme to most other projects I own.)

[ssokolow]

I'd definitely be satisfied with that and I don't mind you taking however long you feel you need. "Probably extend[ing it] to most other projects I own" is something that's definitely worth the wait. (I filled the time by translating gif.py's optparse code over to clap's API and doing some spring cleaning.)

I was already interested in QuickCheck for Rust and, looking through your repo listing, erd, pdoc, tabwriter, xsv, rust-csv, and qcsv also look interesting.

(Do your CSV-related projects have support for processing TSV? I have a tendency to use that over CSV in my creations since it dramatically reduces the likelihood that quoting will be necessary and it would be a bit awkward and silly to write ungainly scaffolding just to flip from TSV to CSV and then back again after the processing was done... especially if it's Python scaffolding for something like rust-csv.)

[BurntSushi]

(Do your CSV-related projects have support for processing TSV? I have a tendency to use that over CSV in my creations since it dramatically reduces the likelihood that quoting will be necessary and it would be a bit awkward and silly to write ungainly scaffolding just to flip from TSV to CSV and then back again after the processing was done... especially if it's Python scaffolding for something like rust-csv.)

Yeah of course! My CSV parser in Rust is meant to be the real deal. You can twiddle a lot more than just the delimiter. It's just that the default is ,.

xsv is the same. You can control the delimiter with -d for all (most?) commands. Not using the default is a little less convenient though, since most of your commands will end up looking like this:

xsv cmd -d '\t' | xsv cmd1 ... | xsv cmd2 ... | xsv fmt -t '\t'

It's probably worth supporting an environment variable or something that sets the default delimiter.

[ssokolow]

For xsv, an environment variable probably would be a good idea but I'm glad to hear it nonetheless. :)

I've been working on defining a stricter code quality policy for my projects and, given how much of applying it to Python is just reinventing Rust's type system and manually taking on the role of tools like QuickCheck, I suspect I'll be moving a lot of my data processing stuff to Rust as the APIs stabilize and the ecosystem matures. (Especially if I can find a good way to incrementally migrate the larger stuff with the help of ctypes)

[skade]

Given that I'm usually the opening these kinds of tickets[1], I just wanted to say that the dual licensing option sounds 👍, especially as I do support your views on public domain/copyright.

[1]: /u/fgilcher on reddit

[BurntSushi]

Done in eb4486b

I'm in the process of doing the same for the rest of my crates.