Sure but it dramatically lowers their profits/revenue, and it will run through their reserves much faster. If they drive everyone out of business at 25-30 a barrel, that'll work for a while (and I'm not clear if even the Saudis or all of OPEC can supply the world's needs without significant investment in infrastructure). Even if they sell it at a low price, there will still be a market above that price for everybody else (at which point Saudi Arabia is just losing money). Sooner or later they'll run out of oil, or they'll want to generate a higher profit margin or more revenue.

There are lots of factors going on here, and you're way oversimplifying them. For starters, OPEC currently provides 40% of the world's oil and about 60% of the exported oil to the international market (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.eia.gov%2Ffinance%2Fmarkets%2Fcrudeoil%2Fsupply-opec.php). So a 10% drop in overall oil demand and maintaining the price means they lose 25% of their revenue, given large fixed costs, that's a larger percentage drop in profits.

One thing worth noting: If there's a 40% drop in oil demand, it means OPEC could be shut out of the market. That's unlikely to be true, because OPEC can pump gas cheaper than most, while there are any number of sources that aren't economical unless the price of gas is higher so if gas got down to 1USD per gallon (laughable I know, but conceptually possible, and it has been that low in my lifetime in the US), OPEC might be the only one that can turn a profit, but as they try to drive the price up, the more other sources can generate gas economically, this caps how much revenue/profit they can make... This is why gas rarely gets up to 4-5 USD in the US (at that price shale oil sources become economically viable, and OPEC knows it'll incentivize moving away from oil

There's a tremendous amount of competition in the international oil market, it is just that OPEC controls the biggest bloc and is the most motivated to drive the price of oil up as it is a huge way to draw dollars into their countries. The people who control the last barrel of oil sold get to set the price. So if OPEC isn't the one controlling that last barrel sold. If there were a 30% drop in global oil demand, that'd drop the revenue by 75%, which would apply serious pressure to the OPEC nations where that represents a significant fraction of their GDP. Saudi Arabia facing a 75% drop in revenue will present a serious problem for the gov't and their ability to stay in power.

Also, at least the US has been a major purchaser on the international market, but we also have a tremendous amount of oil we can generate. It is just that we have needed a huge amount of since the early 1970s (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.eia.gov%2Fdnav%2Fpet%2Fhist%2FLeafHandler.ashx%3Fn%3Dpet%26amp;s=mcrimus1&f=a). Notice that the US has been trending down for ~2 decades now (peaked around 3.9mil to 2.2mil recently although there is an uptick from the recent low point... to be honest I'm not sure about the units if those are barrels per day over the year or total per year).

Saudi Arabia and the OPEC nations know this. They know they play a precarious game, and that being too greedy will kill the golden goose. They also know the world is looking to move away from oil for various reasons, and that the golden goose is going to die. They'll need to replace that, prior to becoming a modern version of the "buggy whip makers".

That's not really true. Most folks make small scale experiments to sort out likely costs and benefits before they move forward. Look at virtually every engineering model ever built. You'd try to do it on paper/computer. Then you'd expand to a smallish scale model and make sure that the model works are predicted. Lather, rinse, repeat through cheap experiments that move closer and closer to the real thing until you have enough confidence to declare: This is likely enough to work, to justify more investment, or this isn't likely enough to work out to justify enough investment (there's also likely some amount of opportunity cost, if I had to pick between this and curing all cancers, it would be hard for me to decide how to apportion the investment dollars, they're both valuable).

Doing these sorts of studies is a way that can help to validate various models of anti-poverty efforts at a modest cost (as far as I can tell, without public tax payer money). This won't help us sort out the inflationary issues, and larger monetary issues with a system that gives money to people no-strings attached, but it can help us sort through the question of: Will people continue to work? At what level of income would people stop working? If given money will people put it to uses that are deemed "productive"?

Ultimately, these people are finding and putting their money where their mouths are, and investing in small scale experiments to discover the answers to some important questions that should be understood to some degree before larger investments in UBI are made.

The question is: Is UBI going to similar to the discovery of the steam engine in terms of how dramatically it will change modern society? Or is this an even more over-hyped version of the Segway that in 2000 while still in stealth mode was predicted to completely change how cities are laid out? My guess is definitely somewhere in between.

I know which one you think it is, but as far as I can tell, they aren't spending gov't money, and I think data and knowledge in this area is useful in understanding humans, their motivations, and how they react to incentives...

I think if this small investment can show promising results, we can invest in larger scale ones that might show greater value. I've long considered UBI a sub-optimal idea, but I think it is better than the complex array of poverty programs currently used in the United States. So I'd love to see the US explore ideas that end up with more universal benefits (health and financial), as they're more efficient and hopefully accommodating of edge cases.

I don't think it is technically illegal. I believe it'd be illegal if you were required to pay debts in that currency or if it is non-transferrable. In fact, based upon some quick websearches, I think you've got that exactly backwards. Non-transferrable (meaning it can't be turned into US dollars), is unconsititutional if companies are paying you in it. The reason for this is to avoid Company Scrip and Company Towns (where you can effectively turn workers into slaves, as was commonly done in remote areas for mining and logging). It is perfectly legal for folks to barter anything of value in US dollars. If I want to trade little slips of paper for US money, I don't know of any reason why that'd be illegal vs. paying for blank paper or any other good or service.

Search for: "Coal scrip was deemed unconstitutional if non-transferable in the early-twentieth century" in https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F... -- They don't have a good citation for the case law.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FList_of_community_currencies_in_the_United_States -- That's a list of currencies that exist and are doing what this article is talking about. So I'm pretty sure they're legal.

The gov't printed the money, clearly they're just trying to collect their property... </sarcasm>

Actually it's not at all a democracy. It's a market. There are two different marketplaces, which are distinct. One market is for developer time, and one market is for users. Each of those affects the other. For the most part, developers aren't going to pour huge amounts of resources into a project no one uses. Users can vote with their feet. If enough users are fleeing because of dumb decisions by developers, a fork might happen, or Shuttleworth might back down. See Pidgin/Gaim/Empathy.

The developer arena is generally a meritocracy. If you've shown up and written lots of code, your opinions carry more weight. If you show up and snipe on a list, and never contribute your opinion carries less weight. User's just want code that helps them get stuff done. If you do that by voting, by fiat, or some other mechanism, they generally don't care. So a developer can fork a code base, and that forces them to take on the burden of doing a lot of work. If they can attract more users, they'll generally attract more developers. That's exactly what Ubuntu has been doing to Debian (and most other Linux distro's for that matter, they built the stuff everybody wanted to use, so they have scores of users, which makes developers want to hack on that). Debian still has users and developers doing a lot of heavy lifting in development and testing. XFree86 vs. Xorg was a revolt over license terms by the devs (Thanks Keith P, et al.). A couple of guys decided that what was happening was stupid, and they fled and put up their own playground, bringing over the last copy of the "free" ball. The users followed, and XFree86 has pretty much dried up (I haven't heard anything about it for years). Look at the old gcc vs. egcs and you'll find that the developers got tired of stupidity, and the users followed the best code base (so much so that the "fork" became the "offical" version after the dust settled). Look at Lucid Emacs vs. GNU Emacs, there it sounds like there's enough compatibility that a clear winner/loser never appeared. Look at the various BSD's, they all split off due to various issues. NetBSD was the "original" and wants to be really portable, FreeBSD decided to make the fastest x86 version of BSD they could, OpenBSD was when Theo had pissed enough folks off they told him to go away, and Dragonfly BSD exists because one guy thought that the new threading/process change over from FreeBSD n to FreeBSD n+1 was a bad idea (I think that was 4->5, but it might be 5->6). Linux ran roughshod over all of those mostly because the Linus was much nicer to deal with, and it wasn't a total distribution. All of the various BSD's are total systems, not just kernels. Linux proper is mostly just a kernel. The reason forks are so uncommon especially of large/critical components, is the burden of doing all the work. Especially as a one man band. You have to start gathering a bunch of followers to help, or you'll fall behind the base code base, at which point, you'll have an old version of the software with a tweak or three. Unless you can attract enough folks to pull over the fixes from the mainline code base, or enough developers that the mainline code base essentially dies, you're an island and an evolutionary dead end for the code base.

Some OpenSource groups *MIGHT* run there things are meritocracies, or as oligarchies, and some might run the choices as "democracies", but I believe you're either abusing the term democracy, or you don't know what it really means.

It's a market place, the only question is will this bother enough users to get them to move to a different code base? Will this bother enough developers to get them to fork? My hunch is that as long as there exists a theme that moves the buttons back, most people won't care. I use Mac and Linux, and generally I just don't care. My muscle memory is for them to be on the right, but I got over it. Nobody is going to want to setup all of the infrastructure necessary to do a large scale replacement Ubuntu over this. It's too big, and too much work. If it were something like Pidgin vs. Empathy, it might happen.

Kirby

Fair enough, in the end, I think that Linus got this right by saying: If it exists only to work with this GPL'ed software, then it's a derivative work, if it has standalone functionality then it ain't a derivative work. Which is roughly the resolution to virtually all of the cases described. So lets see if I got the logic on all this right:

• Apple's Objective-C - derivative work as it exists only to work with GCC
• NDIS drivers is not a derivative work as work fine with a Windows kernel
• NDISWrapper is a derivative work, as it exists only to make NDIS drivers work in Linux
• OpenSSL is not a derivative work, because it works outside of OpenRadius
• NVIDIA driver is not a derivative work as works with many non-GPL'ed Operating Systems
• NVIDIA shim layer is a derivative work, as it only exists to link the core NVIDIA driver into the Linux system.

Which seems pretty sensible, and appears to be what you're saying is came out of the IBM case? I think if you use the "line of thought" from the GPL FAQ about "shared data structures implies derivative works", that also lines up with the above thought processes. The FSF might not agree with that interpretation, but it would sure seem a very sensible line of demarcation. I'd have to ponder strange corner cases carefully.

Kirby

I think you missed what I was trying to say, so one more go at that. Replace the legally loaded concept of "derivative work" in the GPL, with "morality". The crux of the GPL is to say: "Here are the properties I consider moral, and if your software when added to these is still moral, then you have my blessing and permission to redistribute the modified version of the software. If I don't consider your software moral, then you can use your modified software and do anything you want with it, but you can't redistribute it to others". I use "moral" because it'd make RMS happy, not because I in any way agree with the whole "free-software-as-morality" movement the FSF is trying to lead. You could change that to be moral to be "baz" and immoral to "non-baz", and nothing about the discussion changes.

A copyright holder has that right. Now the GPL might have mixed legal metaphors and what not, I'm not a lawyer, I don't really want to debate the finer points of copyright law, or the finer points of the legal text of the GPL. The crux of what I'm saying is that the legal definition of derivative work isn't the point, what the copyright holder wishes to allow is. The GPL is about giving you rights you otherwise don't have if the copyright holder approves. The GPL (v2 especially) might have flubbed on that, and I really don't care, that's just a "bug" to be fixed by releasing a new license with better legalese. I thought that was one of the reasons that GPLv3 moved away from the concept of "derivative work".

I grok derivative works, and could have laid most of what you said out for you. I'm a bit fuzzy on the "collective copyright" vs. individual copyright, and how the details work out there, but conceptually I've got derivative work down. It agrees strongly with what you're saying.

Kirby

Well, in that context, I want to think differently. I suppose I could be having my cake and eating it too with this interpretation: The derivative work isn't the "derivative work" in the strictly legal meaning, it's a "These are the terms by which I'll extend to you the right to copy my stuff and redistribute it". In that case, I think that RMS is "correct". So if Microsoft put such a term in their EULA or their copyright license, I believe it would be legally binding assuming I agreed to it.

I mean, they could say: "I consider anyone using this software named 'Bob' to have the right to copy this software and re-distribute it to whomever they want", and that'd be a legitimate (if stupid), license.

I mean the copyright owner has strict controls over how their works are used. Just ask Disney. I'm not sure if it'd hold up in a court of law if put under strict scrutinty, but I think that there is nothing legally stopping RMS from saying exactly what you think is bad, if he assembled the legalese correctly.

For better or worse, I'd like to respect the copyright owners wishes. If they told me: "You can't ship libpq that way", I'd just get over it, and move along. Either write an SSL that is GPL-compatible, or re-compile libpq without SSL support. It's their ball, and I'm thrilled they let me play with copies of it.

Kirby

If I left it out of my post, I was trying to cover the case where the NDIS folks make you download their driver. Obvious if you make the end user do all the work to assemble the pieces, it's all good by the GPL. That's the whole reason the AGPL was constructed.

I agree with your post. I'm willing to concede that it's plausible that NDIS drivers might be found to be a non-derived work and thus you are distributing them "in aggregate" (assuming you had permission of the NDIS driver copyright holder). However, if it were found to be a violation, the only people who could do anything about it are the authors of NDIS, so it doesn't matter. Which was my point. I mean, I could tell a distribution that they are in violation of the terms, but the only folks with legal standing to actually do anything would be the NDISWrappers author. Which is why it can't be "viral", there is no way the GPL can "attach" itself to the NDIS driver itself. That was what I was driving at.

Kirby

No, the GPL is not on "shaky legal firmament", that is FUD. There is tremendous value in the GPL'ed software, if there were a hole somewhere in the GPL, you think folks would be driving a truck through it to get at that valuable source code. Notice that everybody who has gone up against the GPL has uniformly lost or backed down.

The reason it's "bad" isn't that there is something wrong with the Linux kernel, it's "bad" because it sets a very dangerous precedent. Sorta like saying that "human rights" are something the gov't allows us to have because they feel like it, but the could repeal them any time the feel like it. In the US at least, that's not possible. If somebody said: "You have free speech because the SCOTUS feels like allowing it", rather then it being a first principle of the US law, that'd be "bad" too. The GPL isn't a virus, it doesn't have magic powers to overtake IP, it's not black magic. If you violate it, you are in violation of someone's copyright. So every time someone says "That the GPL will 'steal IP', or 'accumulate intellectual rights'" is just flat out wrong. The absolute worst thing that can happen to you is that you're found guilty of copyright infringement and a judge will hand down a remedy. That could be a fine, or jail time. I'd be relatively surprised that they'd force you to open your source code. However, it's highly likely that it will include an injunction against you distributing the copyright violation. Rendering your IP mostly useless until you replace the pieces of GPL'ed software.

You'll have to actually cite any place where someone from the FSF had "acknowledged" that libraries are a problem. The only place I've ever seen anything remotely like that is the "readline" case. Where the BSD folks make a binary compatible API (note, using reverse engineering to duplicate the API and totally avoided any copyright infringement issues). I've seen folks make an argument there, but if the FSF folks really wanted to press the issue they should have a legal leg to stand on.

Kirby

Well if API compatibility is all it takes, then I can say *any* piece of GPL code is an API, therefore I can re-use it as a library. That's a very, very slippery slope. The only piece that makes it strange is that the GPL has specific and explicit exceptions for OS and system libraries, which Linux obviously is the OS, so it is not extremely clear to me how that would apply. However, you can see the same type of care is taken by the FSF with respect to various supporting libraries they ship with GCC, you'll find that the libgcc_s.so.1 library that is linked via GCC are "GPL + exceptions". See this e-mail about the topic, that includes the special exception.

If it is the API nature of the Linux kernel that makes it okay to link with the kernel and not be GPL'ed, that's very, very bad. All I'd have to do is make an API out of any old GPL'ed software I feel like, and then I would appear to be free of any GPL terms. I believe that to be wrong. If it is the fact that it's an Operating System, that's just a flaw in the wording of the license that for the most part doesn't hurt anything. If it is because there's an explicit exception, that's a very good thing.

Kirby

Linus has also stated publicly: "The NVIDIA driver is not a derivative work, because it existed outside of the Linux kernel, and runs almost totally independent of any of the Linux internals". Note, that the small section that is Linux specific, is GPL'ed, and is distributed in source form. I can find the exact quote for you, if you'd like. If we applied the same logic for the NVIDIA to the kernel to a new back end optimizer for the GNU C Compiler (aka GCC), you can bet that the owners of the copyright (the FSF), would come after you with a vengeance. I believe they are highly likely to win. In fact, the FSF does believe that the NVIDIA driver is a GPL violation (and many of the other bits of the various firmwares are a violation), but Linus is far more practical, and says: "I don't care, you aren't using my code in any way that offends me, but you're making the OS more useful, more power to you".

You're thinking that the GPL is viral, again, it isn't a damn disease, you have to analyze who the copyright owners are, and what complaint could be made and who is allowed to make it. As for the NDISWrapper situation, it would break down as follows: The original driver author (read the hardware manufacturer) might take legal action against folks distributing their compiled binaries, because that is likely a copyright violation. The person who is using NDISWrappers could realize that person who distributed the software to them, didn't comply with the GPL (because the binary portions were given to them without source in the "preferred form"). The only person who could could take legal action to remedy this situation is the author of the NDISWrappers as they are the copyright owner. Thus it's highly unlikely that there could be legal action. Alternatively, if NDISWrappers doesn't actually ship the binaries for the actual drivers, there is no violation. The end user is doing what is hypothetically a violation of the GPL. The end user can do absolutely anything they like, the GPL only kicks in when it is distributed.

This is the same loophole that Sun used to make Linux drivers run under Solaris, because they forced the end users to actually compile the drivers from source using a shim compatibility layer. Solaris would load those drivers that the end user compiled, and because they were distributed in source form to the end user, there was no GPL violation according the letter of the license, but was widely viewed as a violation of the spirit of the license. So if you ship the GPL'ed source/binaries in compliance with the GPL, and a separate piece that can operate on that source/binary it's no problem (see the GPL FAQ section about "works in aggregate").

Kirby

I agree with you, but I believe you to be wrong on a technical point. The license applied to the kernel is the GPLv2 with the specific stipulation that the userspace boundary was not considered a derivative work by the author. Otherwise, I believe distributing a binary that linked with the Linux kernel would have been a GPL violation (depending on the weird interpretation about OS/tools libraries "get out of jail free" clause in the GPLv2).

See COPYING from the linux kernel. The absolute top clarifies the copyright owners distinctions.

The thing about the GPL is that it isn't "viral" despite what folks claim. It merely has terms of usage, just like virtually any other software. When found in violation of the terms, the easiest way to comply happens to be to release your source. You could stop using the GPL software and move along. The only person who can take you to court over the GPL is a copyright holder. Your "customers" sure can't. So if Linus says: "I don't consider that a derivative work", in the legal document describing it, he'll have a really hard time telling folks in court: "I think that's a derived work, and they are in violation of my license".

Kirby