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?
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
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.
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.
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"?
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.
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.
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.
iPhone is written with lowercase "i", not uppercase. It is very worrying that wrong spelling is used on the site as well. I hope that application is much better than the spelling on the site.
You can just alt-click on the variable in Xcode and see the inferred variable type instantly, no matter what the type is or where the variable is declared. No need to search. You can't do this in Objective-C.