Exactly this, thank you for summarizing this so well! I've tried to clarify this exact point at Swift Forums, but I haven't seen even a clarifying answer from anyone in the core team on this point. Everyone says "it protects Swift", but looks like this protection comes at a cost of the overall ecosystem.
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.
> 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.
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 ;)
Including from suits from Apple itself for using concepts of Swift elsewhere in projects that were developed from scratch, not forked from Apple's projects, right?
From what we see, software patents have caused more harm than good, but would be great if there were enough concrete public examples listed somewhere that prove otherwise.
Could you please provide an example? From what specifically have any patents protected users of an open source product? I know plenty of examples when patents were used to harm the users, the most notorious one being Oracle and Java. But I don't remember a single case where users of an open source product were protected from anything with a patent owned by a big for-profit company, would be happy to know a concrete example that shows that this protection outweighs the risk of a company harming open source users.
Could you please elaborate on this? Is there any direct confirmation of this? There wasn't any single answer from anyone affiliated with the Swift core team on this specific point. Or from any lawyer for that matter.
Patent claims define the legal scope: if "using Swift" isn't in the claims then using another language, provided it fits the language of the claims, is also covered by the patent.
ok, does it mean that if you implement only parts of the patent (say only a single feature) there's no infringement because then it doesn't "fit the language of the claims"?
If you look at the main claims (any that don't add to a previous claim, ie don't include "the invention of claim X wherein ...") then you need to be doing something that matches all clauses in the claim to infringe.
When drafting the claims writer (patent attorney or agent usually) will add clauses to work around prior art. You can't just add unrelated features though, the features need to have synergy to represent a single invention.
[I've read a lot on USA patents but only worked directly with UK and EU patents.
The biggest question here is whether this means they lose the patents when they sue something that's not covered by Derivative Works as defined in Apache 2.0?
Looks like an implementation of a compiler not from Apple (that is, not a fork, or one that diverged too much from the original) or different languages that overlap with the patent would be infringing even if they used Apache 2.0 as well.
The main reason for that is lack of hygienic macros in Swift. Currently you can use code generation tools like Sourcery and SwiftGen, but I expect 1st-class meta-programming support to come after Swift 5.0 release. After ABI stability I imagine macros are pretty high on the priority list of the core team.
They might also go in the opposite direction and add runtime APIs to construct types dynamically. Various initiatives (like the Python interop for TensorFlow) are pulling Swift in that direction:
I have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites. See Joe Groff's talk for details: https://www.skilled.io/u/swiftsummit/swift-s-reflective-unde...
> I have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites.
I've heard many people on the mailing lists talk about wanting to add hygienic macros–so when you're talking about "full-fledged macros", are you talking about unhygienic or hygienic ones?
> See Joe Groff's talk for details
I'm actually curious how much is possible, in terms of reflection capability, both currently and in the future. How close can I get to the dynamism of say the Objective-C runtime? Can I grab a function pointer knowing its mangled name? Can I list every class in a binary by consulting the runtime metadata? Can I "swizzle"?
> How close can I get to the dynamism of say the Objective-C runtime?
Well, right now the compiler emits a lot of metadata that is mostly used for runtime generics, dynamic casting, and the (somewhat limited) Mirror type. But these features have enough generality that a surprising amount of stuff has to be encoded. However there’s no nice API for looking at it yet.
> Can I grab a function pointer knowing its mangled name?
That’s just dlsym().
> Can I list every class in a binary by consulting the runtime metadata?
The metadata is there, but there’s no exposed API for doing this.
This is interesting; I haven't been really been following the lists recently but I took the time to read the linked thread and the pull request. While the functionality contained in the pull request is interesting, it's not quite the same as swizzling since it's done unconditionally at load time rather than runtime (so it's much more similar to DYLD_INTERPOSE in that sense). While this covers many of the cases when swizzling is necessary, it leaves out a rather important one where the correct method override is selected at runtime, generally conditionally.
Also, as a sidenote, it seems that there is some sort of motivation to have compiler type checks for the replacement, i.e. @_dynamicReplacement(for: bar())–how will this actually work in practice? If I compile a bundle without access to the source of the application I'm going to be loaded into, how would bar() be accessible to the compiler at all?
Except that in Objective-C it's a runtime feature, which is by definition slower. Swift's Codable implementation is generated by the compiler or is hand-written with an obvious benefit of a stronger type system.
I appreciate such detailed feedback, thank you! Parsing of workbook.xml is implemented in the library itself in `parseWorksheetPaths` function I mentioned it briefly in the article, but decided to omit it as main focus was on Codable protocols.
I will definitely update the "s" attribute parsing to have a more sensible name. Will also link to the standard from the README file, although not sure that will help with a document of this size.
