Kvazaar HEVC/H.265 encoder released under GPLv2
github.com
github.com
Quoting the GPLv2:
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
What this basically means in the words of every legal advice I've gotten over the years is that by distributing software that is under GPLv2 you run the risk of having to stop distributing it. While this is fine in an academic setting, if you actually build a product using this software, you are toast.
This section of the GPL is actually the major reason why many companies will go to great lengths to avoid using GPLv2 software in their products. Many people think it's the requirement to release the full source code — it's not. Releasing sources is rarely a problem.
Please, if you reply to this, don't fight straw men: software authors can choose any license they please and it is their decision to make. I'm not criticizing that choice. I'm just pointing out some consequences which might not be obvious to everyone, and which are particularly relevant in the case of heavily patented video standards.
In any case, many popular open-source encoders are also under either GPLv2 or LGPLv2.1. Examples include libx264, libmp3lame, libfdk_aac, libfaac. The license hasn't prevented them being very useful to many people.
That is true. But in that case it is not the license that prevents me from distributing and I can negotiate with the patent holders, pay royalties and have the problem resolved.
The anti-patent clause in the GPLv2 prevents that: even if I get all the patent licensing in place, I cannot distribute the software if I cannot pass the same rights onto others. That is the whole point of it: as I understand it, it is a tool to fight the freedom battle.
> In any case, many popular open-source encoders are also under either GPLv2 or LGPLv2.1. Examples include libx264, libmp3lame, libfdk_aac, libfaac. The license hasn't prevented them being very useful to many people
That is also true. I'm just providing a different point of view, one which you might not have heard about: many commercial products cannot include those libraries because of the legal risk.
I will not respond to people that shout "FUD" without any arguments. What I wrote was not a rant, and was based on my experience in several companies, each of which got legal advice about this. So, if you believe I'm wrong, please imagine for a moment that I'm building tablets (hence, "distributing" software), I have licensed all the relevant patents (thus, I pay royalties) and describe how you think Section 7 of the GPLv2 permits me to distribute software that requires payment of royalties.
EDIT: after reading all the (unnecessarily heated) responses, I think I will have to draw some diagrams. People seem to misunderstand the problem. Again: with many other licenses I can license the patents, and the patent license will cover all my (and my users') usage. With GPLv2 this is not possible, because Section 7 requires that no restrictions be placed on anyone.
In other words: yes, it is true that patents are problem for all licenses. No, it is not true that GPLv2 is equivalent to BSD/MIT/other licenses in this regard.
Edited to add: it occurs to me that adding such an ability to RAND requirements might be a very interesting half measure.
If you are under contract that says you can not use a patent within a BSD licensed software (that grants redistribution), you will suddenly not be able to distribute software as under BSD license. The contact forbids you, and if you remove the bsd copyright notice then BSD license forbid you.
If this happen often to you, my advice is to not get into contractual agreements that contradicts with what you are trying to do.
> because Section 7 requires that no restrictions be placed on anyone.
False. Section 7 require that recipient of the software can redistribute the software. The lawyer for the European Commission was very explicit in that analysis.
The situation is this:
You have some software you wish to distribute in binary form (with source available). You also have a patent licence that allows you (and only you) to distribute software covered by that patent.
If the software is BSD licensed there is no problem. The licence allows you to distribute the software, and so does your patent licence. Other people who receive the software from you will need to get a patent licence if they want to distribute it, but that is their problem. The BSD licence says nothing about your responsibility to ensure that recipients can also distribute the software - only that you have to convey the copyright notice and the text of the licence. The bit at the start of the BSD licences saying that redistribution is permitted etc is not a condition of redistribution. The conditions are the 2 or 3 numbered conditions.
If the software is GPL licensed as soon as you try to distribute the software to somebody who doesn't have the same distribution patent licence as you then the original GPL licence becomes invalid and you can no longer distribute the software because you have violated clause 7 since the recipients of your software are not able to redistribute it.
Now I'm not a lawyer and I don't even live in the USA, so I can't talk about the validity of the restrictions the GPL tries to apply here, but that is the situation we are talking about.
Anyone is free to do a proprietary work and combine that with BSD. You can even put Microsoft's Shared Source license on it and provide source. Providing source does not mean that you got a permission to distribute (Ms-SS allow only non-commercial distribution, which would had to be permitted by the patent holder if used).
What you can not do is put BSD on the whole work, as that would conflict with the patent license. The BSD is a license that grant recipients full permission to distribute, which in this scenario the patent owner to do allow (ie, its a condition/restriction that the developer is under).
And yes, BSD and GPL is different. One is permissive, and one is copy left.
Secondly, you are not allowed to re-licence code that you do not own the copyright to (I guess a licence like WTFPL would permit it as well). Your example of taking BSD source and removing the BSD licence to replace it with a Shared Source licence is not something that is permitted. The text of the BSD licence is very clear on that point. I don't know why GNU fans continue to be confused about this. The BSD parts of a combined work will remain BSD licensed and the recipient of that source is fully able to utilise those BSD sections of the source code in ways the BSD licence allows. Putting a more restrictive licence on the combined work does not change that.
>What you can not do is put BSD on the whole work, as that would conflict with the patent license. The BSD is a license that grant recipients full permission to distribute
Again, it sounds like you are pretty confused about the issues here. The BSD licence merely covers copyright concerns. You do not need to provide a patent licence if you release code under a BSD style licence. The licence says that the copyright holder grants the recipient permission to copy, modify and redistribute the code. Any other obligations the recipient might have, such as patents, don't affect the copyright holders ability to grant that permission. I've said this several times now and I'm not sure how much clearer I can make it. Yes there is a conflict for the recipient in the sense that they may only have the copyright licence to redistribute a binary, not the patent licence. But that is an issue for the recipient and does not affect the author's right to licence their work under a BSD style licence.
For somebody going around accusing other of spreading FUD it certainly seems like you have a very weak grasp of the issues here.
If you give me software, and tell me that I have full permission to distribute it, I might do so. If the day after you try to sue me for distributing your work, I will go to a judge and say: "judge, anon1385 told me that I had full permission to distribute the work, and here is the documentation that proves it."
In the case that its the patent holder that sue me, I will still say the exact same thing to the judge. At that point, the patent holder will simply say that you did not have permission to grant such permission.
Its not a complicated concept. If you have a contract with someone, you got to follow the contract. If the contract do not allow you to give free permission for distribution, you are not allowed to give free permission for distribution. Surely, you can understand that?
downvoted for ad homenim
I am by no means the "be nice police". For some reason I found your post a bit less acceptable. Maybe because the other was more broadly painted, and yours seemed a bit more... personally directed?
> 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.* You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
* Including unlimited redistribution in source or binary form as per sections 1 and 3.
Now there's a problem. Guaranteeing the text of the GPL implicitly allows the user to infringe the patent license, while honoring the patent license violates the guarantee of the GPL. Such a binary becomes completely un-distributable. With permissive licenses that have no such clause, there's nothing preventing Company X from distributing the licensed binary and source and telling the user that if they want to redistribute a binary, to buy a patent license of their own. That's why the BSD license would not pose a problem for distribution in the presence of an extra, more restrictive license such as a patent package.
You can permit redistribution to recipients of a program even if a patent license forbids you to grant that permission. This is the case of BSD.
GPL says that all recipients of a program must be permitted to redistribute. jwr claim that this makes it incompatible with patent licenses.
The license choice of this program do absolutely nothing to the fact that infringing patent rights run the risk of forcing a company to stop distributing a product. BSD, GPL, MIT, Apache, proprietary license, public domain. It. Does. Not. Matter. Copyright law and patent law are two different area of law.
That someone might come and impose condition on the distributor for "other reasons", is quite irrelevant. Of course someone might go to Microsoft and use a rubber hose to impose condition on then, but what the ... does that has to do with copyright licenses? Someone can equally easy impose restriction that prevent a company to comply with the BSD license.
Patent agreements are also not even covered by the GPLv2. This has been said by the lawyers who made the license. If you do not trust that, then trust all the lawyers who argued with Stallman to not include such provisions in the GPLv3 draft, which include many of the largest software companies in the world. So again, I call FUD on such claims. If your claim was true, GPLv3 would not be said to had adding it.
Last, companies such as blizzard included LGPLv2 software in their flagship product called Starcraft 2. If companies would go for such great lengths to avoid using GPL licenses (the LGPLv2 code itself is under same requirement as GPLv2 except for the linking exception), then how come they couldn't spend the few extra weeks to replace a small library? Or should we all expect that blizzards lawyers are incompetent and this flagship product was just extremely lucky to not been sent to the grave? again, I call FUD.
So Please, stop with the FUD. Why ruin more comment threads about interesting software with it? Some people come here to discuss technology.
What about section 7?
BSD license says "Redistribution and use in source and binary forms, with or without modification, are permitted". If the distributors is under contract that forbids granting such permission, the result is again quite expectable. The only option would be to add restriction on distribution on top of the BSD license, making it proprietary licensed. I will grant jwr that GPL is different from BSD in that aspect, since it do not allow proprietary licensing.
Neither has anything to do with patent agreements, because it all focus on permission for redistribution, use and modification. Patent agreements are one company contractually promising not to sue the other company or their customers over patents, and thus we have GPLv3. Since such promise are not conditions placed on either company, section 7 "if ... conditions are imposed on you" do not get invoked. Microsoft-Novell agreement is likely an example of this. See the wikipedia article for more details, including what the lawyers said at the time.
https://en.wikipedia.org/wiki/Microsoft-Novell_agreement#Agr...
I think I see why you are confused here. That permission grant in the BSD licence is granted by the copyright holder, and is not a condition of redistribution by any intermediary (you don't own the copyright to the code so you don't have the ability to grant that permission anyway). To redistribute you must merely follow the 2/3 terms of the licence which boil down to keeping the copyright notice and text of the licence (and for the 3 clause not using the authors names to promote it).
You can distribute BSD licensed code in binary form as long as you have the required patent licences. The original author does not need those licences (if they never distribute the binaries) and neither do your customers (if they never distribute the binaries).
That term at the start of the BSD licence is not a condition of redistribution.
You are confusing the steps. One is a person taking BSD work and adding an additional license to the binary result (proprietary licensing).
The other way, is someone taking BSD work and redistribute it as BSD (under no additional license).
If you attach the BSD license to the binary, you are giving permission to redistribute further than the patent owner permitted. Thus the only allowed scenario with a patent with restriction on distribution, is the first one which is called proprietary licensing.
And BSD allow it, GPL do not. Thus one can summarize it as as: Some patent licenses require proprietary licensing, which can only be added to a BSD/MIT work. GPL do not allow proprietary licensing, and thus do not work with such patent licenses.
However, that is not the message he made, which is why I called FUD on it. It is also not very interesting statement since anyone who knows about GPL and BSD knows about how they differ regarding proprietary licensing.
x264 is under GPLv2 too and has not run into any such issues despite being in nearly the exact same place patent licensing wise.
And patents had nothing to do with them offering a dual-licence model, it was in order to be able to make money from their work when companies wanted to use x264 in a proprietary fashion (GPL is not compatible with proprietary), and from what I understand they have been doing great business this way.
And there's a new x265 project (not by the same authors) which is using the exact same model, which is that they release it under GPL and will also be selling proprietary licences.
but - i'm not saying its black!
yes, you are criticizing both the license and the choice. personally, i disagree both with the cheap way you argument it while defending yourself (its your opinion, stand by it) and that this license is a bad choice.
Let's not give the Apples and similar patent-trolls of the future more ammunition to shoot with than strictly necessary.
Give us free and open alternatives. Give us a future where we can focus on the technology being delivered, not the lawyers which will need to get paid in order to avoid takedown notices.
Just because courts let you do something doesn't make it ethical.
The law/case law is far too loose with the requirements for novelty.
Being upheld by a court does not mean something is a good patent.
Mathematics are not supposed to be patentable at all but people manage to sneak in pure algorithms by gluing them to an arbitrary machine. The system is quite clearly broken.
The only good patent is the one that stands up in court.
The Star Trek PADD is not too far off either.
The patent is bogus to any sane and honest individual.
Apparently it wasn't.
>The Star Trek PADD is not too far off either.
Neither was this
https://www.google.co.uk/search?q=star+trek+padd&num=30&clie...
The actual issue is broad and vague patents on obvious things, where the novelty is confined to their obfuscated wording.
Techniques that are commonly independently reinvented should not fall under the patent system at all. But then some lawler figures out how to make a tenuous connection with a completely lineage-unrelated patent and they go trolling for settlements, regardless of whether they're a small company that does only this or staff counsel for a large company that also happens to manufacture things.
But no shit large companies like IBM, Apple, Oracle, etc want to limit patent reform to "non-practicing entities" and continue their general low-stakes protection racket while screwing over the little guys (genuine patent holders and patent victims alike).
Would you use a implementation has unknown software patent license issues or would you use a implementation that has known software patent pool to protect you from patent bully?
I am not saying this is the best solution (you still pay royalty fees for some software patent), but the general idea of having a patent pool to protect you from unknown patent trolling is a positive thing.
MPEG-LA doesn't give you a licence to all known H.264 patents.
The only way they protect you from trolls is if the troll is happy to take a cut of their existing take, which if you had a solid patent with no FRAND obligation, would probably be silly.
They will troll the people offering you alternatives though.
Patent pools are an inefficient government solution to a government created problem. They looked like they might actually fix this, but the amount of rent the government lets these corporations collect as a tax on digital communication means they have the lobbying power to keep it rolling.
Unfortunately, that's not something you can reasonably expect, ever. Mike Pall made a statement about the IP of LuaJIT [1], and made the point that while his own contributions are freely donated to the public domain...
"I cannot guarantee it to be free of third-party IP however. In fact nobody can. Writing software has become a minefield and any moderately complex piece of software is probably (unknowingly to the author) encumbered by hundreds of dubious patents."
The H.264 MPEG-LA patent pool is really pretty reasonably priced for any commercial use I can imagine. The only company outside the pool and suing for massive license fees that I am aware of is Google (Motorola).
I'm not sure of the current state of the H.265 pool and license so I make no comment on them.
I think this is all left intentionally vague by patent owners, since they want you to just pay to be on the safe side, there's plenty of straightforward things you technically can't do with patented codecs, but which you'll never get sued for e.g. the person you pay to video your wedding has no licence to sell you the H.264 file the camera produced, and no way of getting one.
So I think it's at least partly based on what they haven't bothered to sue anyone over, though perhaps free speech comes into it in the USA.
Of course, you'd better not plan on using anything you learned from it until you negotiate licenses for your users (or the patent expires).
I suppose not many people are qualified to comment on the program, though.
Anyway, this code is unusually clean and actually structured, which is rare considering the horrors of most encoder codebases (libavcodec mpegvideo, android, any commercial source…). That's probably because it's not optimized for speed; most people act as if writing optimized code literally requires you to leave out comments and make the program ten times longer.
But it is pretty much an academic codebase and doesn't really do much. Following x265's progress would be better for the moment if you want to use HEVC for anything.