My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements.

Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement.

You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.

Secondly, "intimidation" carries a very specific legal meaning, for example here's the Montana statute [0]:

    (1) A person commits the offense of intimidation when, with the purpose to cause another to perform or to omit the performance of any act, the person communicates to another, under circumstances that reasonably tend to produce a fear that it will be carried out, a threat to perform without lawful authority any of the following acts: 

     (a) inflict physical harm on the person threatened or any other person; 
     (b) subject any person to physical confinement or restraint; or 
     (c) commit any felony. 

What we are talking about is refusing to do business with you, which is very legal. There are some exceptions, such as if the basis for that refusal is due to your race/sex, or if GRSecurity is a cartel, or if they are refusing in order to obstruct an investigation into some other illegal activity, but I'm not aware of those kinds of facts here.

[0] http://leg.mt.gov/bills/mca/45/5/45-5-203.htm

Of course they prohibit it. e.g. from [1]

> This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement with Red Hat authorizing such commercial redistribution, or (b) you remove and replace all occurrences of Red Hat trademarks.

from [2]

> Distributing the Software and Services (or any portion) to a third party outside the Portal or using the Software and/or Services to support a third party without paying for each Instance is a material breach of this Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages

from [3]

> Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as... (d) using Subscription Services in connection with any redistribution of Software

[1] https://www.redhat.com/f/pdf/licenses/GLOBAL_EULA_RHEL_Engli...

[2] https://www.redhat.com/licenses/cloud_CSSA/Red_Hat_Cloud_Sof...

[3] https://www.redhat.com/licenses/GLOBAL_Appendix_one_English_...

It is a fundamental misunderstanding of the law, and it is not (an open) question of law.

In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it. Whether that threat is a restriction on your rights is perhaps a question in philosophy or ethics, but from a legal point of view it's very clear: your employer is not restricting your speech, they are restricting their own hiring policy.

So it is here. Legally speaking, you are not restricted from redistributing the software. You may be restricted from GRSecurity wanting to do business with you afterwards but you don't have a right to be someone's customer under the GPL, you only have the right to corresponding binaries.

This is a fundamental misunderstanding of the GPL. The GPL merely requires corresponding source to be made available alongside binaries, so if you get a binary from someone you have a right to the corresponding source from that person. It does not require anyone to offer you a binary; it merely says if they did, you can get the corresponding source.

GRSecurity has no obligation to provide you a binary, they can decline to offer you one because you have a silly walk or a 13-character username or you exercised your rights under the GPL. The GPL does not entitle you to product updates or to continue to be a customer of someone who doesn't want you as a customer, it merely entitles you to corresponding source for binaries.

Some would say GRSecurity's practice violates the spirit of the GPL, but the GPL is not a spiritual entity, it's a legal document, and if you want a legal document that produces a different outcome you can write one up.

Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.

It was not until the 1970s and the Lucasian rationalist critique that microfoundations became an important inquiry. And that shift didn't occur because people were sentimentally attached to micro (if anything, they were attached to prevailing macro theories), it happened because Lucasian rationalism explained an empirical phenomenon (a shift in the Phillips curve) that was not explained by the other approaches. Since that time support for microfoundations has waxed and waned a few times, in response to several other empirical shifts.

In practice, economics is much like the other sciences, with a slightly wider diversity of thought. Like the other sciences, most people only understand a caricature of it that is given through the lens of politics. Unlike the other sciences, more people seem inclined to accept this caricature and criticize it on that basis, which is unfortunate.

[1] Everyone, but see https://www.jstor.org/stable/2231707?seq=1#page_scan_tab_con... for a plausibly-readable overview

Believe it or not, this compiler option is named `-disable-objc-interop`.

> Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products?

Possibly because you have an affinity for value types, performance, or safety. A language is a lot more than just a checkbox of platforms it supports, although iOS is a pretty large checkbox right now.

> the long list of benefits suddenly looks much, much smaller compared to e.g. JVM, .NET, Go, etc etc.

Swift isn't trying to compete with any of those. I mean sure in the "world domination 10 year plan" sense, but for the forseeable future the bullets that make Java attractive to enterprises (lots of developers, lots of libraries, lots of platforms) are not on anyone's todo list in the Swift community.

Rather, the short-term goal is to compete with C/C++/Rust. So you are writing a web server (e.g. nginx alternative, not a webapp) or a TLS stack or an h264 decoder and buffer overflows on the internet sounds scary, you are doing pro audio plugins where 10ms playback buffer is the difference between "works" and "the audio pops", you need to write an array out to network in a single pass to place your buy order before the trader across the street from you, but still have a reasonably productive way to iterate your trading algorithm because Trump is elected, etc.

As far as JVM/.NET, a cardinal rule of software is that it bloats over time. So JVM/.NET/Go can never "scale down" to the kinds of things C/C++ developers do, but it is less known whether a low-level language can "bloat up" to do what .NET developers do. In fact, C++ kinda does "bloat up", because C++ .NET exists. But that is basically an accident, because C++ was not designed in the 80s with .NET developers in mind, and perhaps for that reason it is not the most popular .NET. To the extent we have a plan, the plan with Swift is to try that "on purpose this time" and see if it works better when we're designing it to do that rather than grabbing a round peg off the shelf and hammering it into our square hole. It probably won't ever be as good at .NET problems as .NET, but perhaps it can get close, for useful values of close.

> you can never just "forget about it for the first draft" the way you can a VM's GC.

Similarly, ARC does not exist to compete with your VM on ease-of-use, it competes with malloc/free on ease of use (and your VM on performance). If your VM is performant enough (or you can afford the hardware to make it so), great, but that just isn't the case for many programming domains, and that's the issue we're addressing.

There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation. Most VM memory models are unbounded in that resources never have to be deallocated, but in a system like ARC we have fairly tight guarantees on when deallocation will take place. So if your objects have handles to finite resources in some way (think like open file handles, sockets, something to clean up when they blow away) the natural Swift solution will be much more conservative with the resource use relative to the natural JVM solution. Because of that it may be more useful to think of ARC as a general-purpose resource minimization scheme (where memory is merely one kind of resource) rather than as a memory model or GC alternative itself.

Except we can, and we did, and society was better for it. So as it turns out, the "right to exclude" is more of a guideline than a rule, riddled with dozens of exceptions. And "the current regime has existed for a long time" is not very predictive of long-term societal shifts.

So it is here. You are right that there is fundamental tension between the right of free speech and the right of exclusion.

But one of those is a right so fundamental that it appears first when you ask people to list freedoms. The other is something we regularly cede in large and small ways when we live with other humans in a society. Where the two oppose, there is only one way the arc of history can go.

Our grandchildren will be just as puzzled by the "right to exclude" argument as we are when it is made by the generations before us.

> you won't find any reputable study on the web where the average person lost 10%+ of their body weight and kept it off for five years. Not even one.

To refute this, it's sufficient to present a counterexample. Since many studies exist, and they are reputable, the only argument is whether the people in them are average.

You say they are not, because they lost weight. But that cannot be your whole argument, because if we assume average people don't lose weight we assume the premise you have taken up to prove.

So again: other than the fact that these people lost weight, what exactly is exceptional about them?

Of course there is: http://www.nwcr.ws/Research/published%20research.htm.

Here's a good question: other than the fact that these people lost weight, what is identifiably unusual about them?

[0] https://www.google.com/patents/US8646100

Swift 4 (unreleased) has source compatibility with Swift 3 [0], so all Swift code working today should work in the next version, no migrator necessary.

Additionally, the goal of Swift 4 is to finalize the ABI. Once that is done, you can mix and match different Swift versions in the same project.

The real "problem" here is that Swift wants to be a "big" language, in the vein of C++ or Rust, as opposed to a "small" language like C or JS where you can read one book. (Swift does have a book, it's 1200 pages.) There's a lot of "stuff": a complex typesystem, many basetypes, generics, extensions, both static and dynamic dispatch, programmer-assisted memory management, closures, visibility, ephemerals, optionals, a mutability-based memory model, etc. etc.

Inevitably some of that stuff won't be quite right and so you have churn. But ideally you only need 10% of those (it's just that everybody needs a different 10%) and so the amount of churn you personally have to deal with should be low, and can be lower with the appropriate tooling.

[0] https://swift.org/blog/swift-4-0-release-process/

[1] https://github.com/apple/swift-evolution

In short: of course not. Or at least "not at any cost".

Open source projects do loads of things that reduce the potential ecosystem. People choose to work on projects that aren't web browsers, for example. Or they choose languages that aren't the #1 most popular. They target a platform that has less than 50% marketshare. All of those things turn away potential users in exchange for authorial convenience of some form or another.

It is a foreign concept to me to write e.g. a developer tool for a minority environment and then all of a sudden worry about the license being some major barrier.

But more broadly your position is very strange to me in its wider implications. Let us say that some voice actor could donate some spare reel to Disney. Or that some author could donate a manuscript to Penguin. Or that some musician could donate their track to Sony. Do you believe they should do so, under the theory that this in some way "grows the ecosystem" for their work?

I think this is really the core of the issue. For someone to "adopt" my software but not contribute in any way (whether that be patches, documentation, support, financial, repetitional, etc.) it's not an especially desirable outcome. I suppose there is something to be said for merely living generously (and I do license quite a bit of code that way) but as a society we have unfortunately not yet solved how to sustainably develop software projects without the sticks and carrots in the general case.

It is fair to look at whether e.g. AGPL limits adoption, but I think it is equally fair to ask if it makes sense that a software developer in a broom cupboard is donating his time to AWS, or whether AGPL allows software to be written that might otherwise not exist, or might not exist in the open.

You can't say that micropayments doesn't work when ads ARE micropayments. They're just micropayments with a particular set of properties.

The only question remaining is which of those properties are necessary. Is it actually necessary that your nickel causes an ad to be displayed, or is it just easier and the way we've organized things so far?

[0] http://www.nytimes.com/interactive/2015/10/01/business/cost-...

> Mr. Edison, I was informed, had been up the two previous nights discovering ‘a bug’ in his phonograph—an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble. - The Pall Mall gazette, 1899

which seems to be reporting a bit of jargon in use at Menlo Park at that time that would be completely unfamiliar to the reader.

At some point the jargon spread more widely in engineering culture, this usage from The Journal of the Royal Aeronautical Society 1935 assumes some familiarity with the term, and attributes it to a whole country instead of a lab:

> Casting, forging and riveting are processes hundreds of years old, and, to use an Americanism, ‘have the bugs ironed out of them’.

In this context, the "First case of an actual bug being found" would be the first time that a problem was traced to a literal bug, instead of a figurative one. This would have been engineering humor, as if Google Cloud Platform went down due to a thunderstorm.

As the term "bug" became more closely tied to computer culture, we started thinking of its origins in strictly computer terms (and so you pose the question about the invention of the "computer bug"). The moth story is certainly an early usage in computing, and was a major inflection point for the computing usage, so as origin stories go it is a reasonable answer to the question.

It's just that the label of the computer bug does not reflect the real development of the term. Bugs were part of the engineering jargon long before computers, so the extension of this vocabulary to yet another engineering field would not have been notable at the time.

The Newtonian model works brilliantly at human-scale resolution. But if you are a quark, it is totally unconvincing. So the quarken-creatures' understanding of physics would have developed totally differently.

Similarly, SM/GR seems basically fine at solar-system resolution. But at an intergalactic scale it's completely unworkable – "regular" matter is only 5% of the universe! You are not going to get very far through the galaxy on that.

In reality, even "hard" science is very squishy. It's closely tied to the sort of creatures doing it, and different creatures would have done it differently. "Our" physics can answer a lot of questions – unless you want to leave the galaxy or learn about 95% of the stuff in the universe in which case we have no idea. But that doesn't matter (yet) because what we've got is good enough for a bunch more planetary expeditions.

Similarly, economics has solved some problems and not solved others. The difference is, lots of the "unsolved" problems seem quite urgent. Dark energy might be useful someday, but minimum wage theory would be useful right now.

But that has nothing whatsoever to do with science, or with correctness (all models are incorrect). It has more to do with our goals as a society, and how closely our discoveries map onto problems we think are urgent. A quarken society would have completely different set of priorities than we do, and the way they think about "sturdiness" would be entirely different as a result.