Apple is indeed patenting Swift features

a. they encouraged people to adopt Swift, even going so far as to release Swift before it was ready for production use;
b. they didn't warn people that using some feature or other might in future require a patent royalty payment;
c. they didn't come out publicly and say "here is our policy" about these patents to put people at ease.

By licensing its contributions under the Apache license, Apple has granted you a perpetual, royalty-free license to use all of its patents that are necessary in order to use Swift. That is a legally-binding statement written plainly in the license text. Your complaint is that we didn't make a second, non-legally-binding statement about our "policy" which promises to never charge you a royalty that we've already legally given up our right to charge. Even if we made that statement, I can't imagine why you'd trust it more than the plain terms of the license. I can only encourage you to talk to an IP attorney who hopefully can explain these things to you in a way that you do trust.

26 Likes

The intention of using the Apache 2 license goes beyond this as well. This isn't just about Apple's contributions to the Swift project, but any company that has a significant patent portfolio such as IBM and Google. A contributor whose contributions implies one or more of their patents is effectively contributing the use of those patents to the Swift open source project. This was intentional and by design.

Any company making a contribution to Swift is intentionally licensing implied patents to the project. This is a business decision. Speaking on Apple's behalf, that business decision is clear and deliberate: we want Swift to be successful and to be used widely. The Apache 2 license provides a form of IP licensing as well as IP protection for the project, and thus its users.

48 Likes

I understand that there's a ton of legal implications, but hope someone could help with this even with "I am not a lawyer" disclaimer. Would anyone be able to clarify a few points here please?

  1. If a separate open-source programming language under Apache 2.0 license implements an optional chaining feature, would it be a violation of the patent then?
  2. What if there's a separate implementation of a Swift compiler developed from scratch independently from Apple, does mean that it's not able to implement optional chaining without licensing the patent?
  3. Here's the most interesting part: let's say there's a fork of a Swift compiler that significantly diverged and is developed independently from Apple. It seems to me that forks like these still don't violate the patent, otherwise any GitHub fork with unmerged PRs would be a violation. But let's say Google's fork no longer wishes to contribute its changes upstream, at what point does this separate development could trigger a patent violation? Does amount of divergence have any impact, let's say 90% of the codebase changes? Does the name of project matter, if someone names their fork as "Sparrow", not "Swift" is it considered a patent violation at this point if there's no license and royalties paid for optional chaining?
8 Likes

Sorry, I'm not sure I understand this. If optional chaining was open-sourced before any patent on it was claimed by Apple, it would make any subsequent attempt by patent trolls to attack it invalid via prior art:

If an invention has been described in the prior art or would have been obvious over what has been described in the prior art, a patent on that invention is not valid.

If I understand this correctly, Apple didn't need to patent it for any "defence", just open-sourcing it and making "prior art" was enough. But as a contributor to Swift's ecosystem I feel unsafe now as we have a precedent of Oracle ruining Java's ecosystem with its patents. Can we be sure that Apple never ever does this to any 3rd-party open-source project related to Swift as a "business decision"?

2 Likes

Prior art has been meaningless in US patent law for several years and has been replaced by first-to-file. In addition to the legal clarity that filing would have lent even when prior art had meaning, this is a huge reason why defensive patents must now be filed, especially for ideas intended to be a gift to the public.

Caveats: I am not a lawyer. Further, I am employed by Apple in an engineering capacity, but do not represent any officially held position. Thus, my comment above is both a non-professional and a personal opinion on a legal matter and should be lent as little gravitas as that implies even though it is also correct. ;-)

4 Likes

Unfortunately, while it may protect again patent troll, it does not protect us from all kind of trolls ;-)

15 Likes

Disclaimer: I'm not an apple employee and not am not lawyer, this is just my understanding of the situation having spent lots of time talking to lawyers and other experts about this:

I agree with much of the sentiment that software patents are often silly and the system is broken in many ways. This patent is a reasonable example of that (patenting syntactic sugar for monads, really?). I have no idea if there is prior art, but I wouldn't be surprised. For sake of discussion, lets assume the patent is valid.

Even if I and others don't like it, the software patent system exists. As is pointed out upthread, one of the major reasons that Swift uses the Apache 2 license is to provide more certainty for the community w.r.t. licensing and patents. An additional bonus of the Apache 2 license is that the open source project as a whole benefits from companies having and contributing their patents under the terms of the license: to say more directly, it is good for the Swift project that Apple has this patent and has contributed it to the project.

The reason for this is the Apache patent revocation clause, the end of bullet 3:

If You institute patent litigation against any entity (including a cross-claim or counterclaim
in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes
direct or contributory patent infringement, then any patent licenses granted to You under this
License for that Work shall terminate as of the date such litigation is filed.

This basically says that if someone sues someone else over Swift then they lose access to the patents contributed to the project, and are therefore subject to countersuits. This is a significant part of the protection that the Apache license provides (it is a big deterent to lawsuits in general) but it only has teeth if there are actually patents in play!

The LLVM.org community is actively working on a multi-year relicensing effort specifically to achieve these sorts of protections for LLVM as well.

-Chris

29 Likes

Thanks for the clarification @Chris_Lattner3! There's still a main concern here that this seems good only for the only Swift implementation from Apple and Apple's business at the expense of other open-source projects. In my understanding (please correct me if I'm wrong, this specific point is what's mainly interesting to me) is that an alternative open-source implementation of a Swift compiler developed from scratch or an open-source language made compatible with Swift through features described in the patent would infringe on the patent. That's because these projects wouldn't be covered by the license and count as Derivative Work (even if these projects use Apache 2.0 as well) due to this clause:

For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

Obligatory I Am Not A Lawyer disclaimer comes here, but that's why I would like this to be clarified as much as possible to understand the implications.

I am surprised that optional chaining was granted a patent. It is similar enough to prior art in Scheme that I would not have granted it. See and-let*:

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/and_002dlet_002a-_0028SRFI-2_0029.html

if c had the same restrictions/patents as this, then there would never have been a clang compiler would there? i guess there will never be independent implementations of swift...

3 Likes

What about companies (such as us) implementing the Swift language from scratch?

4 Likes

It strikes me that while Apache licensing creates more certainty for users of Swift, it actually reduces the diversity of the ecosystem overall.

Now if someone wants to make something Swift-ish with features that "infringe" on the patents granted to Swift, they now have exposure to patent litigation.

I can't decide if this exposure is unfortunate collateral damage or brilliantly disguised subterfuge.

1 Like

There are right now, but this right here might just mean that it's going to go away, yes :(

3 Likes

for one second I was stunned by hearing the news regarding patenting, but chris made it clear. thanks

In my humble opinion, if Apple was able to get a patent on this, a patent troll might have also been able to get the patent. Which, in this case, I would prefer Apple to have the patent.

Also, let's say this patent gets sued for prior art (which some have alleged). Apple would be able to defend it, and if Apple loses, that patent is free for everyone. Far better than some patent-troll making "discounted licensing offers" to small businesses who can't afford a lawsuit.

5 Likes

Hi all.

My questions:

Are Apple willing to provide assurance that those involved in developing programming languages other than Swift do not now have to start thinking about whether the architecture, API, code, and so forth related to the way their language implementations work infringes these Apple patents?

If they can't, are they willing to provide assurance that they will not apply these patents to the people involved in, and the artifacts of, a project stewarding a programming language, provided that project's artifacts do not include an implementation that works with Objective-C or Swift, even if they happen to have some of the right architecture, API, code or other interoperational features to do so, and even if someone chooses to fork their language and the fork does interoperate in a manner that leads to legal action by Apple?

And if they can't do that, are they willing to concede that an unfortunate by product of this patent application might be a chilling effect on all programming languages that include interoperation with existing technologies in a grass roots open source programming language?

[removed unnecessary detail]

3 Likes

It would be great if we relied on the past experience with this. I don't know of any public case of a patent troll getting a patent against prior art and attacking an open source project and causing any harm to its users, but I'd be happy to read about it. We do have a very recent example of a big for-profit company using its patent portfolio to harm an open-source community, specifically a programming language (see Oracle and Java).

2 Likes

i think the point is, 1. independent open source implementations are (potentially) vulnerable, and 2. corporations in the future that may implement swift compilers/stdlib would be beholden to apples benevolence but what happens when they compete head-on?

from this experience i think we can say that swift is "open source" but not "free software" in the FSF sense... and its an important distinction i think.

(please note im not saying i think apples acquiring of a patent on swift had a malevolent motive, but the above distinction is important imo)

1 Like

It's probably time to calm down, now.

The patent office doesn't work like people think it does. They don't check whether a patent has prior art; that's on other people, later, after the patent is issued.

All they check is that the patent is procedurally valid.

This patent, if Apple is stupid enough to go through with it, won't be worth the paper it's printed on. Optional chaining has been around since the 1950s. There's prior art out the wazoo. The second they try to lean on this patent, someone laughs them out of court, Apple pays through the nose, and the patent is permanently invalidated.

All Apple is doing is destroying all good will with the programmers foolish enough to use their tools.

And that's nothing new.

Bye bye, Swift. Your owners are throttling you

1 Like

This is incorrect. Patent examiners are supposed to search for prior art and reject the patent if it's found. However, prior art can also be identified after a patent is granted, either by the defendants in a patent infringement lawsuit, or more recently by anyone through an ex parte reexamination request.

3 Likes