That's a fair point, a non-free license will repel devs willing to spend their time spreading your work. But I guess when an author's objective is to put food on the table 1000 distributions x $0 = $0, so exposure isn't really a factor for them. The only selling point I can think of regarding exposure through OSS is happenstance referrals/support work from some company that has a problem with it which they can't fix themselves or don't want to spend time on. Not exactly sustainable, and it punishes programmers who write their code correctly in the first place :)

That was genuinely interesting, cheers for the link. Having never had any inclination to look up a formal definition I've always just presumed that the spirit of open source licensing was that it remain openly accessible and modifiable and remain as such, not necessarily always free, as in beer. The end-products that rely on them sure as fuck aren't. I suppose what's needed to make things a little more economically sustainable for authors is a new class of "open" licensing that puts dollars in the programmer's pocket whilst still allowing the community at large to benefit from reading, modifying, learning from, security auditing or debugging the publicly visible code. Maybe one could call it Visible Source, VS for short. ;)

We have collaboration tools up the wazoo, what's missing is a fair and obvious way to get paid for open source work. I propose a simple OS license to help actually put food on the table for open source developers. Let's call it the "Pay Me License" (PML for short.) It goes quite simply:
/*
  * PAY ME LICENSE (PML)
  *
  * Product Name: [Project bundle goes here]
  * Copyright (c): [list of owners]
  *
  * Public Key: [owner's base 64 RSA pub key]
  * Purchase Link: mailto|https://whatever?subject=[ProjectName license me]
  * Receipt File: [ProjectName].pml
  *
  * If a the above *.pml receipt file is not in the root of your source
  * tree, then this code is not licensed and you are not allowed to use
  * it. A license can be obtained from the purchase link above.
  */

That's it. Put it on every source file like any other OSS license. The contents of a *.pml obtained from the source code owner goes something like:
/*
  * Example *.pml receipt:
  *
  * From: [Owner(s)] # Must match header
  * To: [Your Company you@address.com]
  * Product Name: [must match header]
  * Receipt: [any text, transaction receipt number]
  * Public Key: [base64] # Must match header
  * RSA Signature: [base64] # RSA_SIG_OF_UTF8(LOWER_AND_REMOVE_WHITESPACE('From' + 'To' + 'Product Name' + 'Receipt'))
*/

Any project missing the .pml in its source code tree root, or any .pml file whos signature can't be trivially validated against the public key in the source header is not licensed.

Obviously there's no enforcement, but at the end of the day, even closed source commercial software with complex secret license key validation systems still ultimately depend on people behaving in a civilised manner and not circumventing them. There's also nothing stopping an author from providing license keys to certain worthy causes free of charge.

Same here. So you me and the two ACs make 4. Foolishly I've even just released an app which I use on mine. Just one problem though, and it's now evident that it'll never be fixed -- the WinRT broker infrastructure that's responsible for throttling or allowing apps to run beyond their energy usage quota (on the user's request) is busted, so it's impossible to write a truly reliable connected-standby TCP socket app for Win10 mobile build 15063, the final build we'll probably ever see.

Economics reboot? "Here's one I've prepared earlier!" - https://civil.money/about

Hilarious :) no doubt named after the kiwi song - https://flightoftheconchords.b...

Giving everyone in the world their own HTTP REST endpoint for granting information access to 3rd parties isn't a bad idea on the surface, but I think the implementation here might be a bit too convoluted. I would make an extension to DNS and flow everything based on e-mail address alone, similar to how MX works:

- Your e-mail address is your unique identifier. Just as most sites already use today.
- To participate, domains expose a new DNS record of type, let's say "IX" (information exchange)
- An IX record on domain.com points to an IX server endpoint... which is nothing more than a REST/WebSocket protocol defined by some spec.

The user's experience for logging in to a 3rd party website becomes:

Email: [ Enter your email ]
[ Login ]

User hits Login. The 3rd party does a DNS IX lookup on "domain.com", redirects the user accordingly. By convention:
front-part-of-email@domain.com routes to whatever-ix-dns-record.domain.com/front-part-of-email

With GET params ?scope=[attributes]&callback_url=[3rd party url with state information]. Not too dissimilar to OAuth2.

User is now on their personal "IX portal" and can login and grant the 3rd party access to
the requested attributes or data stores (predefine /photos, /music, /ical, /mail etc with configurable RWX rights.)

Upon grant, the callback url is hit with access token information and the 3rd party can do whatever with the user's data.

There was an interesting segment regarding shit replacement therapy in a documentary "Life on Us". One of the patients had reported an inexplicable sudden loss of a long term depression after the treatment.

More research in this area would be really great, since a correctly balanced microbiome seems to have positive impacts on a pretty wide range of maladies from obesity to cognitive defects. I've recently been wondering whether or not the only difference between the skinny guy and the fat guy, both eating more or less the same garbage with the same sedentary activity level, is simply gut bacteria/digestive efficiency.

I've implemented UBI in a unified monetary system which attempts to solve most of these issues - https://civil.money/about

The way it attempts to prevent people abusing its UBI is:
- Makes all transactions/data publically quantifiable, and uses a number of peers to corroborate all data in a consensus model.
- Has a simple credit rating system as well as attributes to infer a person's particular life circumstance "at a glance" for day-to-day essential purchases, however ultimately it is up to each individual on whether or not to accept a person's money. Transaction history can be closely scrutinised/sources traced for higher cost purchases to determine level of legitimacy (its implicit taxation system does this very thing as well behind the scenes.) This is conceptually not much different to what banks do today for any loan.
- Turns the concept of money on its head and removes the that artificial sense of scarcity (debt) that we're all so scared of today.
- Pegs its value at a constant of time/labour to prevent inflation.
- UBI along with inverse-taxation is actually the money creation source.

Figure the main problem in the world today is its monetary system, so have built this:

https://civil.money/about

The trick will be convincing anybody to use it.

Features:
- A generous universal basic income. Basically the equivalent of USD $60k/yr.
- Seeding based on regional productivity (inverse taxation.) Tax is actually a money "creation" process and happens implicitly.
- A democratic voting process for any fundamental changes to the system.
- A low barrier to entry. Should work just as well for a village in Kenya sharing a single smartphone as anybody standing at a Point-of-Sale terminal.
- Transparent transactions and accountability.
- Implicit dispute resolution.
- A consensus-based scalable distributed P2P architecture.
- An efficient and easy to work with messaging format.
- End-to-end TLS between all peers and user clients.

Draft technical bits here: https://civil.money/api

Should be releasing it for general "server download" availability and source code on GitHub until around December. Currently held back waiting on critical bug fixes in .NET Core 1.1 to be released.

Lately I've been working on a monetary system. Bit different to fiat or blockchain currencies. It's using a p2p distributed hash table for data storage, encryption happens strictly "on the client" for RSA signing procedures, it includes a basic cost of living, implicit taxation, and it has more of a focus on "good standing" rather than debt. It's probably not exactly ready for prime time, but I'd be interested in yours, or anybody else's thoughts: http://pretend.money/preview My account for example is http://pretend.money/preview/#... Mostly I just wanted to see what a monetary system that is not based on "debt" might look like. Bit of fun.