And this is one very real reason to avoid languages owned by huge companies like Google's Go and Apple's Swift. They can and will do evil things, instead of supporting them please consider supporting smaller languages which are often just as good or better as Swift/Go.

Such as? Many of the newer languages I’m seeing, notably Swift and Go, but also TypeScript, ReasonML, and Rust have their development backed by one corporation.

Such as Julia (https://julialang.org/), which is general-purpose and open-source.

> julialang.org > no mention of "license" > "Julia is a NumFocus project"

it is a non-profit corporation, but still a corporation. Whose life depend on donations from the owners of the other languages you compared julia against.

This is definitely not true of ReasonML. ReasonML is just one part of a larger ecosystem that is pushed forward by a combination of academia and industry, and ReasonML is is very community focused/driven.

dom96 was probably thinking of Nim[0], as they're one of the developers in the project.

[0] https://nim-lang.org

Yes, as well as libraries, tools, applications that are not in the hands of one or few companies only.

Plenty of technologies get hyped up by companies and later on bent out of shape or dropped.

C++.

And also, "it protects Swift" in their context always means "it protects Apple's Swift" unfortunately

No, it definitely applies protections to the entire Apache licensed work. People can fork it and make changes, rename the project and they will retain their patent license as long as they abide by the terms of the license.

but what about reimplementing a compiler from scratch without reusing any of Apple's code? It wouldn't fall under a definition of Derivative Work under terms of Apache 2.0 then

If your going this way you must also take account for "reimplementation from scratch under restrictive licence”.

Apache license don’t say anything about clean room reimplementation under other licence because it’s a tricky subject beyond the scope of the license. I personally think that if someone reimplement Swift, name it Schwift, guarantee it’s 200% faster (for some reasons), and then sell commercial licence of that it should be sued (but with such business plan I believe he’ll go bankrupt first).

Apple logically won’t comment on what they will do in case of a "clean room" implementation because they have zero interest in anybody doing such a thing.

And actually nobody have any interest in such a monstrosity (except maybe for theological reasons?). The project is goddam Appache2, fork it if you want, but spending any second trying to reimplement years of works is a total waste of time. Want to start something from scratch? Fine but do something original. Want to improve swift ecosystem ? Fine but work on the main project or on a clean fork!

Sorry, I'm not sure I understand this point. Why would I need a different license for this from scratch implementation? What if I want Apache 2.0 as well?

Also, I'm convinced that many many people do have interest in this. Many people were interested in GCC existing in parallel with whatever other compilers were available. Heck, Chris Lattner's Clang wouldn't exist if C and C++ were "protected with patents from patent trolls". Are you saying that all these alternative compilers were a total waste of time?

> I personally think that if someone reimplement Swift, name it Schwift, guarantee it’s 200% faster (for some reasons), and then sell commercial licence of that it should be sued

Should? What rule, law, or moral code does it break to reimplement something?

If you start from a position of strong support for broad legal protection of "intellectual property", I can see that there would be an argument that a programming language as a whole could be locked up by a patent. As a possible analogy, (my understanding is that) Lego held a patent on the bricks at some point, and no clones could be produced because of that.

Like you, I would have a pretty hard time being convinced that this was actually a good idea, though.

The trick would therefore be to pull in a little bit of Apple's code so you can argue that it's a derivative work and therefore covered by the patent license grant ;)

I agree, that is the real issue. I was responding to the comment that the protections were only for "Apple's Swift".