Friday, October 5, 2018

Dear Anyone #2 - October 5, 2018

Book I'm Reading: Bored and Brilliant: How Spacing Out Can Unlock Your Most Productive and Creative Self. Normally I avoid anything that looks like a business or self-help book. This book was recommended to me by a colleague at a different university, so I felt obligated to at least read it. I did so thinking I would give it the yeoman's effort and then give it up about 1/2 way through. It's been more interesting than I expected. The folksy writing gives it the air of a transcribed podcast (not too surprising, I think). But, I was also looking for justification (to myself) for less "phone time." It turns out, in the grand scheme of things, I'm actually not that bad with my phone; I thought I was a "heavy user" but it turns out I'm barely on the heavy side of average.

Best Thing I Read This Week: The Myth of the Infrastructure Phase - Dani Grant and Nick Grossman. A great article about blockchain protocol development. This feeds into my theories on blockchain governance that we (software developers) typically think of things like governance as being an application-level issue. But recent problems with security, and with building robust usability in blockchains themselves, have many experts thinking security and governance need to be built into the protocol itself.

Best Music I Listened to This Week: I went to the We Were Promised Jetpacks show at The Majestic Theater in Madison last week. The opener was a lady/band called Jenn Champion. Openers can be really hit or miss; she was a grand slam.

Tuesday, October 2, 2018

Open Source Licenses as Blockchain Governance

Bitcoin Core is licensed under the MIT License - a permissive, non-copyleft, open source license. Ethereum is licensed under GPL v.3. IBM Hyperledger is closed source core, but its Fabric (smart contract development framework) and Composer (application development framework) products are licensed under Apache.

The choice of how to license the core of the blockchain is a governance decision and it has consequences for the future of these chains. For example, by failing to put any significant conditions on its license, just about anyone is free to fork Bitcoin Core for any purpose. For example, a joke coin designed as a satire for cryptocurrency itself, or a coin whose every transaction is truly anonymous and thus a facilitator for global terrorist transactions.

Clearly, and without judgment, Bitcoin Developers are OK with these forks. But we could imagine a universe where a blockchain developer were not OK with these applications. In such a way, one mechanism for avoiding undesirable forks would be to impose license conditions that prohibit the undesired activity. Provided that a fork followed the conditions (e.g., don't use this code to directly or indirectly aid terrorist activity - a condition that, for example, ZCash could not fulfill because it can't guarantee its compliance). Of course, post hoc compliance isn't exactly optimal; if (in our example) ZCash violated the license, then, Bitcoin may feel that its complicity in terrorist activity is complete despite the violation of the license.

On the other hand, Bitcoin could institute multiple governance methods to ensure compliance with its license. It could create a license approval process that every developer, user, node, or miner (or an approval panel) in the Bitcoin chain could vote whether to permit the fork or not. It could institute Digital Rights Management schemes that enforced license compliance. There are a universe of other mechanisms that could be instituted that wouldn't require taking the drastic step of making the code closed source.

I know a lot of these words are "bad words" to the crypto and blockchain purists, but I see them as tools of governance - of creating a platform/protocol for doing business and transacting on the web. Moreover, I've railed incessantly about "private blockchains" being stupid (they are). Adding licensing restrictions wouldn't close the chain's permissions, just the permissions for forking and further chain development; in other words, to paraphrase Hashgraph, it's a permissionless chain, but permissioned source code.

Friday, September 7, 2018

Dear Anyone #1: Friday September 7, 2018

This series of posts was inspired by a friend of mine. We'll call her Erika. Erika was a reading a book by a guy (doesn't really matter) and this guy, apparently, sends out weekly emails to his loyal followers with a quick hit of things that interested him that week. Articles, videos, music, books, whatever. It didn't have to be work-related, though often it was. It was just a good way to introduce people to things the author thought was cool that week.

So, "Erika" said "Jeff you like cool things." To which I immediately agreed. And, with that, we're off...

---------------------

Dear Anyone,

This is the cool stuff I've been looking at this week.

Currently Reading: Still slogging through Michael Chabon's Moonglow. Don't get me wrong, I've actually come to really like this book and as I'm wrapping it up, it is surprising that the book it most brings to mind is Everything is Illuminated by Jonathan Safran Foer. A book that was also at times a bit of a slog to get into because of the strange frame of reference (quasi-first person), which made it hard to pick up and put down.

Best News/Article I Read This Week: I mean, it has to go the New York Times Anonymous Op-Ed, "I Am Part of the Resistance Inside the Trump Administration," right? But, it could also go to Bruce Kogut and Anca Metiu's Open-Source Software Development and Distributed Innovation, Oxford Review of Economic Policy, Vol 17, No. 2 (2001). I was a software developer in the 80s (as a kid) and through the 90s (as a newly minted college grad and even into my MBA). I was deep into open source software and policy and its licensing and legal nuances is the reason (or one of the main reasons at least) I went to law school. While the article completely bungles the legal concept of "public domain" and intellectual property ownership, it's largely besides the point, as the authors dissect how programmers from around the world organized themselves to create such monumental pieces of software as Linux and Apache and Mozilla (it was still Netscape at the time). I'll admit that I giggled gleefully throughout most of it and it kind of blew my mind.

Best Music I Listened to This Week: Yello's 1981 second album "Claro Que Si." Great dance-y, early EDM best listened to alongside Bowie, Kraftwerk, Devo, the Talking Heads, and Gang of Four.

Tuesday, September 4, 2018

Governance in Blockchain in the Government

I was asked to supervise an independent study for an undergraduate student in International Studies. The student came to me interested in the use of blockchain in Government, and, in particular, the use of blockchain in Estonia in creating their digital identification system that underlies many of the social and financial services.

I thought I would share the course outline and initial readings for anyone interested in this subject. I'm wondering how and if this might turn into a course, but I haven't gotten that far yet - so ignore the non-teacher-y parts of these data dumps.

COURSE OUTLINE


  1. Technical Governance v. Meta Governance
    1. Blockchain Basics
    2. What is Consensus?
      1. Proof of Work
      2. Proof of Stake
      3. Hashgraph
    3. What is a Fork and why do they happen?
      1. Ethereum Forks
      2. Kogut Article - What can Open Source Development teach us about decentralized governance?
  2. What is the Role of Government
    1. Anarchy: State-to-State Negotiation and Accountability
    2. International Organizations
    3. Decentralized/Network Governance
  3. Technological Issues
    1. Interoperability
    2. Scalability
    3. Decentralization
    4. Institutional Legitimacy
    5. Security
      1. Blockchain Security Issues(Upper Tier Attacks)
        1. Lack of Governance: Who determines what happens with the chain when something goes wrong and what are their motivations? Transparent democracy or closed dictatorship?
      2. Bad Contract Code (Middle Tier Attacks)
        1. Replay (51%) Attack: duplicate transaction on each node in chain
        2. DDoS Attacks: Forks 2 and 3
        3. Lack of Quality Control and Certification (The DAO Attack)
      3. Wallet Security Issues (User Attacks)
        1. Phishing, Spoofing (wallet, address), etc.
  4. Case Studies
    1. Case Studies: Decred and Hashgraph (Governance)
    2. Case Studies: Z-Cash (Privacy)
    3. Case Studies: Ripple (Blockchain in Banking)
    4. Case Studies: Cicero/Accord (Blockchain in Law)
    5. Case Studies: Estonia (Blockchain in Government)

Reading List (so far, this is very incomplete - the outline is pretty set, particularly the first half of it, but I'm still working on the reading list; if you (is there a you out there??) have any thoughts, let me know.
  • Hashgraph White Paper (see Readings)
  • https://qz.com/730004/everything-you-need-to-know-about-the-ethereum-hard-fork/
  • SEC DAO Report (see Readings)
  • https://www.etherchain.org/hardForks
  • Kogut & Metiu - Open-Source Software Development and Distributed Innovation (see Readings)

Tuesday, August 28, 2018

A Short Rant About Dates in Filenames

If you are going to use a date in your filename, use YYYY-MM-DD (with or without dashes). Any other date system is wrong. Yes, that's right. If you use a different date system in your file names you are wrong.

Why?

Because YYYY-MM-DD (not YY-M-D or YYYY-DD-MM or, god forbid, MM-DD-YYYY or M-D-YY) sorts chronologically. Watch what happens when I have three files with dates, we'll call them

2018-11-28.File3.docx, 2018-06-17.File2.docx, and 2017-12-08.File1.docx

If I sort ascending by file name I get:

2017-12-08.File1.docx
2018-06-17.File2.docx
2018-11-28.File3.docx

See? Nice, chronological order.

If I use a different date system the order if fucked up, thus defeating the purpose of using the fucking date.

I will demonstrate with two variants - non-two-digit Month/Day and the standard US format of MM-DD-YYYY

Non-Two-Digit Month/Day sorted ascending file name

2017-12-7.File1.docx
2018-11-28.File3.docx
2018-6-17.File2.docx

See? 1 comes before 6, so without the leading "0" the "11" comes before the "6" in "alphabetical order" and that is not chronological order. Thus, it's wrong.

Now, let's see the travesty of MM-DD-YYYY

06-17-2018.File2.docx
11-28-2018.File3.docx
12-07-2017.File1.docx

Should we even make an attempt at M-D-YYYY?!

11-28.2018.File3.docx
12-07-2017.File1.docx
6-17-2018.File2.docx

How the fuck can anyone find what they are looking for in that garbage naming convention!?

Ok. End of rant. STOP WITH THE AWFUL DATE FORMATS PEOPLE!!!!

ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times

Tuesday, July 24, 2018

Wisconsin Geographic Indications

You can ask Erin, I've been railing at this for ... what? ... let's see I graduated law school in 2004, I took my first Trademarks class in ... 2002 or so? ... 16 years?

As you might expect from a lawyer that spends a lot of time thinking about how law applies to the food and beverage business, I am obsessed (obsessed!) with Geographic Indications, the TRIPS word for Appellation d'Origine Controlle (FR), Protected Designation of Origin (EU), Denominazione di origine controllata (IT), Certification Marks (US), etc.

Historically, the US has looked to take advantage of European intellectual property by "borrowing" their designations of origin for things that bear little passing resemblance to "cheese," let alone "parmesan" or "asiago" or "feta."

The chicken is now coming to roost, so to speak, with the current trade war. It turns out that when you slap huge tariffs on your trading partners, they don't like that and they look elsewhere. When they look elsewhere, the others ask that you play by their rules. If their rules are better (e.g., aren't huge tariffs), then you play the game. So, when our bumbling fool of a head of state imposed tariffs on Mexico and pulled out of the Trans Pacific Partnership, the partners to those looked to get their goods elsewhere - namely Europe. And Europe came in and say, we'd be happy to send you all the Asiago cheese you can handle, but you have to agree to play by our Asiago rules - so, no Asiago from anywhere other than Italy.

In response, and I can only imagine cartoonishly hopping mad, Wisconsin cheesemaker Sartori renamed their "asiago" cheese "Sartiago" so that Mexico wouldn't stop importing it.

In an event that I assume Sen. Tammy Baldwin has no recollection of, I actually spoke to her about Geographic Indications and how we, Wisconsin, were missing the boat. [ed note: the short version of this story is that we were both being interviewed for a documentary about beer]. And, she responded with something like this. I think her position, the typical American position, and definitely the official "Wisconsin Food Producers" position is that anyone should be allowed to call their hard white salty cheese "parmesan" because "What else would you call it?" Well...maybe Asiago?

Look, this full discussion is much longer. I actually get most of the way into the full rant in a podcast that I did with Edible Alpha about trademarks in food [ed note: that was part 2, you can find part 1 here.

But, the short of the argument is this: if "terroir" in food means anything - and I think the whole premise of the sustainability, locavore, slow food, whatever-you-want-to-call-it movement is fundamentally based on it meaning something - then, we [ed note: the "royal we" not literally you, the reader, and me, Jeff, the author, but yes, us too] need to protect Designations of Origin as meaning something. And that means, that when someone in a particular place creates something that you like and they call it something to show their pride in their place that you - manufacturer in the middle-of-nowhere foreign country - can't create something that vaguely resembles that thing and call your thing the same thing. Because that's misleading the public, it's deceptive trade practice, it's counterfeiting, it's infringement.

The State Journal article mentions that "The U.S. has been battling the EU over the geographic naming restriction during trade negotiations dating back to the Obama administration." This is wrong. This "battle" dates back to arguably, the Paris Convention in 1883 and certainly to TRIPS in 1995, but even back to the adoption of the American Viticultural Areas in 1981 and a first attempt at such a thing back in the 1930s.

Friday, July 13, 2018

Design Thinking and Lawyers

I am going to start by saying that I am not trained in "Design Thinking" or any of its sub or related fields. I'm not going to spend a lot of time giving backstory on Design Thinking. For that, go check out the Stanford d.school and/or the work of Margaret Hagen at Stanford's Legal Design Lab. So, with the "what this isn't" out of the way...

I believe that one of the most underrated skills of a lawyer is problem solving. Clients don't often think of lawyers as "problem solvers." We are more often thought of as "technicians" or, in other words, people who act at the instruction of the client.

Indeed, many clients dread lawyers because we aren't seen as problem solvers at all, but problem causers. Lawyers have a reputation for saying "no, you can't do that because laws x, y, and z say it's illegal." As a result, clients are reluctant to come to lawyers in the first place. I'm not saying I'm immune to this problem [hands over ears "lalalalalalalalala"], but I am saying that lawyers can and should be better.

Moreover, We can have a relatively long discussion about why lawyers-as-technician is a dead business model, but the short of it is that no-longer-that-advanced-technology will soon be doing the "technician" piece of being a lawyer. Advances in technology such as artificial intelligence, smart contracting, blockchain, not to mention industry pressures from rapidly increasing innovation cycles will put pressure on lawyers to modularize, standardize, and mechanize the drafting of contracts and other transactional documents.



There will be (already is) increased pressure on lawyers to be problem solvers. To work with clients to understand facts (products and businesses processes), the analyze "the law" (regulatory, case law, whatever), and to work with clients to align appropriately. Once this framework is in place, our robot overlords will take it from there and draft the contracts that define the way forward.

Thus, lawyers have a need for an arsenal of tools to engage in problem solving. Law school, the analysis of fact and conclusion of law, is one such tool. The business world has many such tools - Design Thinking, Lean Startup, Six Sigma, just to name three. As business lawyers we will need to be conversant in these business tools, not just our legal tools.