Apple is indeed patenting Swift features

Fortunately, Microsoft has provided a legally-binding promise not to sue alternative implementations, but only after a significant pressure from the open source community.

This is what is needed (from contibutions/contributors as well), at the very very least.

4 Likes

I'm very concerned that we still don't have satisfactory answers for what seem to be the most important questions (although I am appreciative that Lattner and Apple folks have chimed in).

  1. What does this mean for independent implementations of Swift?
  2. What does this mean for completely separate languages that have similar features?
4 Likes

You'll need to be a little patient; those questions are beyond any individual's ability to answer.

15 Likes

Thanks, John. I was mainly concerned that they'd be lost in all the chatter. I'm totally fine waiting.

Yes, I am using something essentially equivalant to optional chaining in professional work for over 15 years now, where the code

*a.\myfunction

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?

Anyone can use an assemblage of ternary operators in C++/C for this as well.

let value = object1?.array?.count

becomes, in C++ or object-oriented C:

int value = object1?
    (object1->array? object1->array->count() : kNoValue) 
    : kNoValue;

No extra objects required. The null pointer means no object present.
Less elegant than Kotlin or Swift perhaps, but C/C++ could have supported a better syntax years ago if they'd wanted it.

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.

I think this is more because this is legals questions that can't be answer by anyone here. If you want a definitive answer, I think you should directly ask to a lawyer.

3 Likes

I don't know any lawyer, but if you know one, ask him to join.

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.

5 Likes

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.

1 Like

What about something similar to what Tesla did (for the patents that are about Swift or parts of Swift): All Our Patent Are Belong To You | Tesla ?

1 Like

I'm not quite sure that Tesla's approach with patents would be an ideal model, especially given that it mostly seemed to be a PR move with more shenanigans with patents going under the hood. A better example could be the interaction between Microsoft and Mono, where the legally-binding promise from the former have boosted .NET and C# ecosystem significantly. I bet it helped Microsoft quite a bit after it lost all traction in mobile.

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.

This is a very interesting explanation, which unfortunately is repeated many times without providing any concrete example. Could you please provide a few cases where an open-source project in general and a programming language specifically were attacked by patent trolls and needed any kind of defence? Python, JavaScript, Haskell, C, C++ and many more programming languages weren't ever patented, why don't we see any patent trolls attacking those communities?

Another good example is that those communities have multiple implementations of those languages. Python has CPython and PyPy, JavaScript has scores of multiple implementation for whatever imaginable use case, Haskell has Hugs and GHC, C and C++ have GCC, Visual Studio, Clang and LLVM (!) and all of these alternative implementations have tremendously helped those ecosystems. None of them had any problems with patent trolls as far as I know, but I'd be happy to hear concrete examples if I'm wrong.

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.

3 Likes

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.

1 Like

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.