Yes, I am using something essentially equivalant to optional chaining in professional work for over 15 years now, where the code
applies the function "myfunction" only if the variable *a does not have value null, else the statement returns null. It is really stupid that this should be part of a new patent, it is prior art in a very clear way. So what is the point of bringing this into a patent? Is it about a certain combination of features? Will Apple sue anyone using such a feature? Dear Apple, am I allowed to continue to use this feature or will you sue me?
Not that relevant to this discussion, as I understand it. The patent part of this case is settled (no infringement), and the major point of discussion/contention has been about the copyright part. You should probably continue to avoid violating copyright and license terms, though.
Several days later and we still don’t have an answer to this. Maybe this is pessimistic of me, but I suspect this is because we’re not going to be happy with the answer and they’re trying to figure out how to handle the communication.
I suspect the answer is that yes, this does give Apple the right to sue people who use optional chaining in unrelated programming languages, regardless of their intent to do so.
For reimplementations of Swift you could argue that they’re a “derivative work” and as such the Apache license allows use of the patent, but it’s very much a stretch to claim that for the case of completely separate languages.
If Apple genuinely intends to use this only for defensive purposes, or as counter-suits against patent trolls, then they should put it under something like Twitter’s Innovator’s Patent Agreement, something that legally enforces the idea of only using the patent for defensive purposes.
I’m still interested in hearing the official answer if possible, but I’d rather it be direct about these concerns and not beat around the bush.
Like most software engineers I'm not qualified to analyze what will or won't infringe on a specific patent, so I'm not going to make any such claims, but attempting to patent programming language features from Swift is certainly a chilling move by Apple. @Chris_Lattner3, @tkremenek, and other (former/present) Apple people have emphasized how great this is for the Swift community, but that's a very limited perspective. What about other languages? What about other communities? Is a new, from-scratch language design that uses optional chaining open to legal attack by Apple?
If Apple's intentions are honorable here they need to make it abundantly clear what they will and will not do with these patents, preferably in a legally-binding manner. Otherwise they're just spreading the software patent minefield into new territory and poisoning the well of goodwill that they've built by open-sourcing Swift in the first place.
Legalese is a program that runs in attorneys' brains. I'm not sure how many registers and status bits are in those brains but I know the architecture is OISC, i.e. Obfuscating Instruction Set Computer. It would be nice is real programmers could decode legalese, or run it in a simulator, but the OISCs are basically black boxes so it's all guesswork.
This article about Tesla completely avoids the subject of patent trolls. I'm not a patent expert at all nor a lawyer, but from what I understood reading this thread and from other conversations, patenting is needed to be protected against patent trolls.
If open source licenses alone aren't enough for a company/community to protect itself against patent trolls, patenting is definitely understandable, especially if further statements can be published by those compagnies to allow people who truly need those patents to use them freely without the risk of legal action.
But now thanks to the "protection from patent trolls", we won't see any alternative implementations of Swift as one would infringe on the patent. We've lost the diversity of Swift's ecosystem and the only thing we've gained in exchange is "the protection", which apparently no programming language needs anyway.
Alternative Swift compiler implementations is definitely something I'd love to see, and that's why I hope Apple will officially give an answer to this, so that things can at least be clear on what's allowed and what's not.
On the subject of protection, as I said I'm not an expert and I would need to be one to be able to truly judge of what's right or wrong. I do believe you when you say there are no examples of open source projects not being able to protect themselves, but just because this didn't happen yet doesn't mean there is no risk at all IMO.
I really just hope that Apple will give an official answer not too far in the future, enabling the community to know the general direction Apple wishes to take for Swift.
Sure, I agree there might be a risk, but we have to consider if the risk outweighs the current uncertainty with alternative implementations. A strong and diverse community and ecosystem would be able to easily fend off any attacks including legal attacks through crowdsourcing and other means of mutual support. But how many alternative implementations weren't (and probably won't be) started until the patent situation is clarified? How much stronger the Swift community would be if there were no patents in the first place? We can rely on the history of other programming languages which is publicly available, and decide for ourselves.
Well, that would be unfortunate if Apple never answered. But, as some people said, we might need to be a little patient.
How much stronger the Swift community would be if there were no patents in the first place?
I'd see it more as a problem for the (not too far) future than as an issue that would already strongly affect Swift today. While patents were filled several years ago, it looks like it's only recently that people from the open source Swift community noticed it (at least, I don't remember ever seeing such concerns anywhere prior to those posts).
Anyway, back to the actual question of what should be done: as a Swift user, I'm more concerned about what people will be concretely allowed to do than just about the presence or absence of patents.
Again, this is my own, non professional, opinion on this matter, but, let's say I'm worried of not being able to do X because of a certain patent, and I receive a clear, legally binding, authorisation to do X, doesn't the presence or absence of the patent become irrelevant?
Absolutely, getting that authorisation would be great, but for now we have neither the authorisation itself nor a clear timeline when (if at all) that would happen. And until then people are discouraged from starting or continuing to develop any projects (including a few mentioned in this thread) related to alternative implementations of Swift due to the risk of patent infringement.
It's also worrying that there was no proactive communication about these patents. If Apple at the time of patent application issued a statement upfront and clearly said "we've applied for these patents because this and that could happen and here is the precedent and here's the best plan to avoid that" it would have been perceived in much better way.