The complicating factor there is Facebook actually has a patent covering the GraphQL specification (along with the fact that they're applying PATENTS to a specification, vs an implementation): https://www.google.com/patents/US9646028
> As our business has become successful, we've become a larger target for meritless patent litigation. This type of litigation can be extremely costly in terms of both resources and attention. It would have been easy for us to stop contributing to open source, or to do what some other large companies do and only release software that isn't used in our most successful products, but we decided to take a different approach.
Never heard Facebook answer: why didn't they just follow Red Hat's model and make a "Patent Promise"[1]?
Then accumulation of software patents would help deter meritless litigation while staying out of the way of FLOSS developers getting their work done.
the one in Go basically says if you sue google for any Go related patents then they revoke the license. that patent retaliation clause is nothing different from the one used in Apache Licence Version 2. the one in react says they revoke your license when you sue facebook for any patent related matter.
Aslo called a "weak patent retaliation clause" vs React's (current) strong patent retaliation clause.
I found the explanations in [1] to be very helpful to understand patent clauses.
different people have different opinions, the problem is as long as there are many people who have such legal concerns about react's BSD+PATENT, using react would be considered as suicidal for startups.
Can somebody who speaks legalese translate Red Hat's Patent Promise into more parseable English? I'm curious how it works, but the wording is pretty obscure to me.
Red Hat holds patents but promises not to enforce them. This means anyone can use the IP without worrying about being sued for infringement. No one else can claim they own the IP because Red Hat already owns it. They also have a clause saying that if Red Hat sells the IP, the buyer needs to uphold the same promise.
The way I'm reading it, if you develop free/open source software that infringes Red Hat's patents, Red Hat promises not to sue unless you sue them first.
The "combined" part seems to be saying you can also develop a system that's partly proprietary, as long as the proprietary parts are simple and not using Red Hat's patents.
If they sell a patent, the buyer must agree to the same promise.
The promise won't protect you if you infringe someone else's IP, even if it's related to one of Red Hat's patents.
Red Hat: You can use our patents if we can use your software.
Facebook: You can use our software if we can use your patents.
That's my severely over-simplified interpretation. The most significant difference is that Red Hat's promise extends to FOSS in general, though apparently not proprietary software. Facebook's license applies only to specific Facebook FOSS code, but it can be used in proprietary software.
Your interpretation is wrong. RedHat’s promise is revoked if you sue them for any patent infringement:
>Our Promise also does not extend to the actions of a party (including past actions) if at any time the party or its affiliate asserts a patent in proceedings against Red Hat (or its affiliate) or any offering of Red Hat (or its affiliate) (including a cross-claim or counterclaim).
So RedHat can hypothetically use all of your software patents and still sue you for infringement based on their patents if you sue them.
To rephrase again... regarding patents, assuming you don't first sue RedHat or Facebook, then:
RedHat won't sue you over your FOSS project that infringes any of RedHat patents, but your proprietary software is fair game.
Facebook won't sue you for infringement caused by using one of their libraries in your software (FOSS or not), but your independent project (FOSS or not) that infringes any Facebook patent is fair game.
if Facebook [...] files a lawsuit alleging patent infringement against you
in the first instance, and you respond by filing a patent infringement
counterclaim in that lawsuit against that party that is unrelated to the
Software, the license granted hereunder will not terminate
To the extent a party makes, uses, sells, offers to sell, imports, or otherwise transfers Covered FOSS, Red Hat agrees not to use such actions as a basis for enforcing its patents against the party ("Our Promise"), subject to the limitations herein.
If I read this right, Red Hat promises to not sue anyone for using/transferring FOSS whether or not such an action infringes on Red Hat's patents - they will only use patents to defend against litigation. (IANAL.)
I've been trying to tell everyone licensing is more important than they realize, but there are so many people who fundamentally misunderstand licensing and therefor just don't care (dwtfyw license for example), or have falsely been trained by subpar instructors at uni and $othertraining about how bsd/mit is the superior license for business because $reasons.
The four freedoms and free software solve so many of the problems I see around modern tech-infrastructure. No, free software doesn't solve every issue and has some of it's own, for example I think at the code complexity levels we are at the many eyes theory is starting to crumble, but it doesn't change the core truisms about freedom in computing that are important for us to move forward in a free and open society if we actually want to start solving prolems.
Now that we have a concrete example of how picking tooling with bad licensing can bite people in the butt, please take this time to at least consider GPL varients (A/L/GPLv3) for as much of your tooling as you possibly can. (perhaps CC0/CCBY/CCBYSA for content)
In my opinion, MIT/BSD licenses like FB moved to in this case simply aren't good enough to be future-proof, primarily because of the ability of future tivoization of a product that removes freedom from the user (think BSD on playstation).
Remember, either the user controls the program, or the program controls the user.
If the GPL scares you for some reason or you have question about it (commercial sales of gpl software for example), feel free to ask. I've spent enough time wading through just about every license so I think I might be able to cut through some fud.
Usually it is the lawyers doing people a disservice actually. That said, Eben Moglen is who I would refer you to. (Has been the lawyer for the FSF and RMS I think)
The lawyers who would actually have to put their neck on the line says no. Eben Moglen is a campaigner, not anyone's lawyer (in the matter of defending a software product including GNU licensed components). The license actually isn't that long and the only argument on what it really means is going to take place in a courtroom in a carefully chosen district in Texas in front of a judge and jury that aren't quite comfortable operating 4-function pocket calculators. (And the defendant, by the way, isn't going to be some wholesome main street software outfit, it's going to be the nastiest, most ruthless gang you can imagine. 90% of the software community is going to on the record hating their living guts, you can bet Moglen, never mind RMS, is going to be nowhere to be seen given an impassioned defense of the legality of this company's use of GPLv3, regardless of how perfectly compatible it is with the promises they make now (FSF will submit a brief, but they are going to be very discreet about it). But the result will decide the legal interpretation of GPLv3 forever.)
That is the mental image of your company's lawyers when you ask about GPLv3.
This discussion sometimes feels like like the PHB telling Dilbert to go base the product on Oracle because of an article in CIO Monthly ("written by an EXPERT!") says it's the best database.
> Are you a lawyer? If not, you would be doing a disservice to anyone curious about the topic.
> My own company's lawyers consider the GPLv3 toxic and not allowed at all for company use in any software we create - that's enough for me.
Don't just blindly defer to lawyers. Yes, including GPL source code in a proprietary product could sink your company's business model. But using a GPL webserver is no threat. Nor using Linux as a set top box to run your local application (Roku). Nor using GCC to compile the program. (Alot of Playstation 1 games used GCC.)
Your own company's lawyers may be very ignorant on the GPL and it's benefits.
They may simply not understand and are relying on other people to inform them. (I believe Microsoft's old attacks against the GPL used the word toxic.)
I knew a contract lawyer who called the GPL 'very restrictive'. I pointed out the Windows EULA. He never really read it to understand it's far more restrictive terms. He never really looked at a EULA through a lawyer's lens and how much his business would suffer if the the terms were actually exercised. Nor that he didn't have to accept the GPL to use GPL software. Only to redistribute it. I doubt he could find that permissiveness in an EULA.
Lawrence Lessig made a few comments that his lawyer friends couldn't understand how Creative Commons licenses worked. People that have never met each other had legally agreed to binding license. This was in the early 2000's.
> My own company's lawyers consider the GPLv3 toxic and not allowed at all for company use in any software we create - that's enough for me.
Isn't that often because the GPL would require you to release your source code? Which is different from possible patent problems? I can understand why companies don't want to release their source code, but at least it's clear ("release your code and you can't be sued"), right?
Your lawyers probably don't know the difference between a tool and a library that is used in a published product. The code of a GPL licensed internal tool is not linked to the product (in the programming sense: there's no "object linking" or mixing of the code). You don't even need to release the source to the public if the tool itself is not available to the public.
Why you ask lawyers on a matter concerning computer programmers?
I have yet to see a single "professional IP lawyer" who knew more about GPL than an average IT pro. The was majority simply puts forwards claims without doing a minute of actual research on GPL
Licensing and patents are legal matters, and as such, one should consult a lawyer (to be sure, one knowledgeable in the domain) if it may impact one's business.
Not only that, there is legal precedent where just the act of software developers discussing IP matters has a negative effect in cases. It absolutely is a matter for lawyers, as the reason they are around is to guard against such pitfalls - it is their domain of expertise.
>I've been trying to tell everyone licensing is more important than they realize, but there are so many people who fundamentally misunderstand licensing and therefor just don't care
Maybe they don't care because in reality its not a problem?
In the sense that it's not a problem people generally have -- not that nobody ever has had it.
A lot of people worry too much about all kinds of BS eventualities and technicalities, and this could be one of them in most cases.
>Now that we have a concrete example of how picking tooling with bad licensing can bite people in the butt
It only bit FB in the butt (in the sense that some developers complained about their license choice) -- not those using the tooling with FB license.
A common misconception is that under GPL all your code must be released to the public. This is not true. You only have to give code to the user after purchase. Now, it's true that the user could then upload your software to the public (under gpl), but many of the issues surrounding that (such as lost sales #) aren't as bad as people imagine they are, and in the foss world are generally made up for by high-maintainence intervals (so forks would be behind feature-wise), and support/service contracts to augment the traditional sales model. (Redhat model)
> You only have to give code to the user after purchase.
IANAL.
You don't really require to give the source code unless the purchased person asks for the source. Most people don't care about the source. And you require only to provide source for people who obtained the binary legally. Nobody else can demand for source code.
Say for example, most of the D-Link routers come with a warranty card saying the software is GPL and is available on request. Period.
You can also void the warranty of the software (and hardware) in case the software you sold was replaced with a modified version (afaik, requesting for source can't make the warranty void).
There are a few things to consider: GPL v2 requires you to produce the source code in CD/Floppy (or like media), while GPL v3 allows you to have the source uploaded to net (or sent via email).
> You don't really require to give the source code unless the purchased person asks for the source.
I think you're mixing mutually exclusive options. As I understand it, GPL requires you to either provide source code up-front on the same terms as the binaries (I think the relevant phrase in GPLv3 is "equivalent access"), or alternatively provide a written offer to provide the source code to anyone who requests it. The reason the offer must be to anyone is that your customers can distribute that offer with the binaries in lieu of source code. That way, they have the ability to redistribute/"convey" the software in a compliant way even though they don't have source code.
> GPL v2 requires you to produce the source code in CD/Floppy (or like media)
Unless I'm missing something, GPLv2 just says "a medium customarily used for software interchange", not specifying that it must be any sort of disk/tape.
There’s one other clause that you’re missing: you may not further restrict the redistribution of GNU GPLed software (either source or binary). So D-Link may restrict distribution to “on request” by “people who bought our hardware”, but they cannot stop one or more of those people from redistributing the software obtained thereby.
That, plus the fact that if you incorporate any GNU GPLed software in your own software your own derivative software must be licensable under the GNU GPL, or be more liberally licensed, makes for the uncomfortable discussions with lawyers about use of GNU GPLed software in any company.
No. But as ddwrt and openwrt source codes are already available in public, people may not be interested (because you are not going to get the source of binary-blobs in any case, blame Linus Torvalds for that).
I have found a person that requested source of BMW i3 car software, and he have uploaded the source online[0].
>A common misconception is that under GPL all your code must be released to the public. This is not true. You only have to give code to the user after purchase. Now, it's true that the user could then upload your software to the public (under gpl), but many of the issues surrounding that (such as lost sales #) aren't as bad as people imagine they are
That's because they don't sell software, they sell support and services.
Now, about actual software as a product success stories, where you don't sell to companies that need someone to blame (and thus opt for support contracts)?
I wouldn't say about what available on GitHub today, but up until year ago all source code was included and they only sold precompiled binaries and support. Also I doubt they can really change anything about that because Synergy never required CLA and it's under GPLv2.
I pretty sure their "core" naming is just another way to promote usage of paid version, but you can still compile it yourself and easily remove all license checks.
Previous model was usual open source community-driven project with donations and it's obviously didn't worked, but Synergy was developed by different team at different times and looks like they find what works for them. It's tarted 3 years ago:
Of course it's not shiny VC funded company with 10000% growth, but I guess it's profitable business. Though it's not that much different from what Red Hat doing by selling support even if it's on small scale.
I feel like this works for some things, like Redhats core businesses for instance, as you noted. If I’m an indie software developer though and release say a tool for managing Wordpress sites or maybe I release an app that is like a crazy good bookmarks manager, how can I justify losing revenue when most users don’t care if the source is open and those who do probably won’t buy my product. Yet the inverse - one user getting that code and uploading it online - could damage me greatly?
>please take this time to at least consider GPL varients (A/L/GPLv3) for as much of your tooling as you possibly can. (perhaps CC0/CCBY/CCBYSA for content)
I'm sorry but Creative Commons themselves declare that their licensing should not be used for software.
The MIT license does not explicitly mention patents. However, depending on the lawyer, an argument could be made that it contains an implicit patent license. I think that Facebook would have an uphill battle arguing that their relicensing didn't include patents after this kerfuffle.
PyTorch uses NVIDIA NCCL for multi-GPU communication (under BSD license). Gloo is only one of the three backends that can be used for distributed communication out of the box.
I count:
* ReasonML - https://github.com/facebook/reason/blob/master/PATENTS.txt
* GraphQL - https://github.com/graphql/graphql-js/blob/master/PATENTS
* react-native - https://github.com/facebook/react-native/blob/master/PATENTS
* PlanOut - https://github.com/facebook/planout/blob/master/PATENTS
* Flow - https://github.com/facebook/flow/blob/master/PATENTS
* Haxl - https://github.com/facebook/Haxl/blob/master/PATENTS
* Flux - https://github.com/facebook/flux/blob/master/PATENTS
Just a few that I found.. Please reply if you know more project that are still BSD+PATENTS licensed.