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
Although allowing independent implementations is certainly consistent with the principles of software freedom (as well as open source!), it wouldn't affect Swift's status as "free software" as no part of GNU's Free Software Definition says anything about it.
[Note: this is one of two comments I previously tried to make on a different account, which was automatically put on hold presumably for posting links; I think this comment outright failed to submit rather than being held, so I'm posting it again, but sincere apologies if this ends up appearing multiple times.]
1 Like
Prior art has not been made meaningless in the U.S. You're thinking of the America Invents Act switching the U.S. from "first-to-invent" to "first-to-file", but to quote the Wikipedia article about it,
The law also expanded the definition of prior art used in determining patentability. Actions and prior art that bar patentability under the Act include public use, sales, publications, and other disclosures available to the public anywhere in the world as of the filing date, other than publications by the inventor within one year of filing (inventor's "publication-conditioned grace period"), whether or not a third party also files a patent application.
If Alice privately invents something, Bob later re-invents it and tries to patent it, and finally Alice tries to patent it, Bob wins the patent under "first-to-file" (whereas previously Alice would have won). But if Alice published her invention before Bob filed the patent application, it counts as prior art to his application; there is a 12-month grace period during which Alice may still file a patent. In other words, "first-to-file" as implemented in the AIA in many cases would better described as "first-to-publish".
2 Likes
So, I took a look at the actual claims of patent 9,952,841. Note that legally speaking, only the claims are significant in determining the scope of the patent, not the description.
The independent claims are 1, 11, 16, and 22; the other claims are all dependent on one of those (i.e. they're further elaborations with more specific limitations).
All four independent claims require, among other things:
- The system must support two different high-level languages "using a modular compilation system including multiple front-end compilers";
- The "first high-level language" must be "a C language based object-oriented programming language".
Claims 1, 11, and 22 each further require that the "second high-level language includ[es] object-oriented elements and procedural elements" and "include a data type... to indicate absence of a value of any type".
Claim 16 does not have those limitations, but instead requires that the compiler for the second high-level language "includes performing one or more compile-time type safety operations in conjunction with one or more type inference operations".
Please note that if a given system doesn't fit all of the limitations of at least one claim, it's not infringing, but on the flipside it wouldn't generally count as prior art if it predates the patent. (A patent can be invalidated if the claims are "obvious" given a combination of multiple pieces of prior art, but the legal standard is hard to meet; it has to be very obvious.)
In short, this is mainly a patent on supporting multiple languages in the same compiler, with various specific limitations. One of those limitations is that one of the languages in question must have an optional type. As for chaining, although the description mentions optional chaining, I don't see anything in the claims that mentions it at all (although they're wordy enough that I might have missed something). But in any case it is not a patent on optional types and it is not a patent on optional chaining.
It is, on the other hand, a patent that would presumably be infringed by an independent implementation of the Swift compiler, assuming it included Objective-C compatibility. And it would be infringed if another language wanted to add a similar built-in compatibility layer. For the same reason, if you want to find prior art, that's the kind of functionality you're going to have to look for.
10 Likes
The Apache 2 license protects derived work as well. You just need a credible argument that your work is derived according to the terms of the license to be covered.
-Chris
5 Likes
You're better informed than me about how lawyers are interpreting the Apache 2 license, but for what it's worth, I find that hard to reconcile with the text:
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
On the face of it, the patent license is a license to use "the Work", not any derivative works. In contrast, the copyright license explicitly mentions the ability to reproduce derivative works:
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
What if in a parallel universe Microsoft patents C and C++ and releases Microsoft Visual C/C++ with Apache 2.0? And then if Clang and LLVM are developed independently from scratch as they were, how could they be considered as Derivative Works of Microsoft Visual C/C++ in that scenario?
1 Like
Why is this necessary? What problem does this solve?
1 Like
it is good for the Swift project that Apple has this patent and has contributed it to the project
By the same token it is arguably bad for any other existing programming language project inasmuch as they need to consider whether this patent touches upon their language and project.
And bad for new software projects in the same regard.
And, inasmuch as the spirit of freely sharing ideas in fields such as mathematics and software is a universal good (one that was essentially the norm prior to Microsoft's rise in the 1970s), bad for software and all involved in its creation and use.
Yes, this patent makes rational sense for the Swift project, and perhaps for Apple, if you ignore externalities. But is that wise?
I don't see this as just an academic discussion. I will reply to Comex's comment about the patent claims to get into the potential for a serious practical issue for at least one free software project that I consider vitally important.
1 Like
So I have in mind a serious free software programming language system, one worked on for nearly two decades by thousands of free software developers including some world famous ones, that consists of the following pieces:
-
supports multiple different high-level languages "using a modular compilation system including multiple front-end compilers";
-
The "first high-level language" could be described as "a C language based object-oriented programming language" in the sense that it is object oriented, could be classified as a C family language, interoperates with C, and has a run-time that's written in C. That said, it relies on some pieces that are not associated with C such as garbage collection and pointer arithmetic, perhaps two defining characteristics of C. Then again, the interoperation mechanisms discussed in the next two bullet points involve glue C code...
-
the "second high-level language includ[es] object-oriented elements and procedural elements" and "includes a data type... to indicate absence of a value of any type" and an optional type that indicates either a value of an absence of value.
-
the compiler for the second high-level language sometimes does what could be described as "performing one or more compile-time type safety operations in conjunction with one or more type inference operations". (I'm stretching things in this part. There isn't an academically known type theoretic type inference algorithm involved.)
Your analysis and my (possibly mistaken) recognition that it looks like it may well cover the programming language system I have in mind leads me to feel some concern.
it wouldn't generally count as prior art if it predates the patent.
This system has been working as described above for at least 4 years and arguably 10 or more.
A patent can be invalidated if the claims are "obvious" given a combination of multiple pieces of prior art, but the legal standard is hard to meet; it has to be very obvious.
This project included many smart minds dealing with and thinking deeply about this problem for up to a decade prior to developing the existing solution. It seems obvious to me but I'm not at all sure it would be seen to be "very obvious", especially to non technical folk or those who haven't deeply explored the problem space.
[The patent] would be infringed if another language wanted to add a similar built-in compatibility layer.
Or, it seems you're saying, even if it was prior art but the art wasn't obvious.
This is a project that is both famous and infamous in the free software world. Consider me concerned.
Can we please stop making up theoretical armchair law examples and get back to the real world? Yes, given the broken state of US software patents and the practice of filing defensive patents it’s very easy to come up with a scenario that would leave one vulnerable to getting sued by any of a multitude of big companies. Now how often does it happen that a big company sues a free software project for something like this?
3 Likes
It has happened in 2017 and is still ongoing. Another example is problems that Mono and other alternative implementations of .NET had, caused by Microsoft's patents. Fortunately, Microsoft has provided a legally-binding promise not to sue alternative implementations, but only after a significant pressure from the open source community. Another possibility would be to transfer these patents to an independent non-profit, which is exactly what Linux contributors did. But looks like there's no communication from Apple on their intentions to do any of this.
The big problem here is not only ongoing lawsuits, but projects that won't ever be started because of the risk of lawsuits. Great example here is that Clang and LLVM (and Swift probably too as directly based on Clang and LLVM) wouldn't be as easy to start or to develop at all if C and C++ were patented.
6 Likes
Thanks for that analysis of the 841 patent.
It sounds like if Kotlin/native, which uses LLVM, were to add a C++ front-end, it would infringe. Does that sound right?
There is also 9,329,844.