[XviD-devel] License/legal discussions
jan at rychter.com
Fri Dec 12 18:27:03 CET 2003
>>>>> "Christoph" == Christoph Lampert <chl at math.uni-bonn.de>:
Christoph> your plans do sound very promising to me. A free DSP port
Christoph> would certainly be very welcome!
It is good to hear that. I think it will become more useful when
consumer devices using TI DSPs become available (and we plan to
introduce such device soon).
Christoph> We have nothing in principle against commercial solutions
Christoph> based on XviD. We just don't like the (sadly very common)
Christoph> argument that we _must_ permit a company to use XviD under
Christoph> some non-free license, because otherwise they would not be
Christoph> able to use it, and they already invested lots of time in
Christoph> adapting it to their needs.
Well, I think can understand what you are trying to say. But the above
paragraph can have many meanings depending on how you define non-free.
Personally, I think that the fear of someone taking the code and
distributing a binary-only version is a bit of a red-herring. It is no
longer possible to "dominate" the free-software world by forking a
version and closing it. Yes, it happened in the BSD case a long time
ago, but world was different then. Right now the free software movement
is much too strong for that and the speed of code development is much
too good for this to be possible. And let's even imagine that someone
does take the code, make a product, and does not distribute the
source. So what? Just don't buy his product. If people care, he won't
make any money. Ironically, thanks to Richard Stallman's efforts, the
world has changed, and some of the restrictions he invented are no
longer necessary. IMHO of course.
But this isn't really what I wanted to discuss. I can understand that
some people do care about enforcing that the source always be available,
and I do not want to dispute that requirement. Actually, we are talking
about contributing to XviD directly here, so we certainly do not intend
to take our toys and hide.
Now, I have my personal gradation of "freeness" of Open Source Licenses
(I specifically exclude all non-open-source licenses from this
discussion), which I'll outline here:
1) A *really* free license is the modified BSD license, which lets the
users of your code do absolutely whatever they want. That's real
freedom, but this means that someone can take your code, improve it,
and distribute it without distributing the improvements.
2) For some people a free license is a copyleft license, which lets the
users do whatever they want, but adds a restriction that if they
distribute anything, they have to distribute the source, too, on the
same terms. Many people seem to think that this is all that copyleft
licenses cover, but that's simply wrong: I do not know of any
licenses that would be of the "copyleft" type and not touch the
3) The next level corresponds to licenses that additionally enforce that
there be a grant of patent license for patents owned by the
contributor, related to the code in question. I think most
open-source licenses that have been reviewed by company lawyers fall
in this category (the MPL, OSL and the Nokia OSL are some examples,
to name a few).
4) Licenses that wage a total patent war. All of the above restrictions,
plus a requirements that _NO RESTRICTIVE PATENTS_ apply to the code
being distributed. This means that if there are any patents, held by
anyone, which might restrict the users rights with respect to the
license, you may not use the license at all. GPL and LGPL fall in
this category. It is hard to understand what the point of such a
restriction was, as it basically tries to make the patent world "go
Lawrence Rosen (http://www.rosenlaw.com/) additionally differentiates
between licenses containing weak patent retaliation and strong patent
retaliation. Weak patent retaliation means that patent-based
claim/lawsuit from a licensee against the licensor, that is related to
the licensed code, terminates the licensee's rights under the
license. Strong patent retaliation means that any patent-based
claim/lawsuit (possibly unrelated to the code) against the licensor
terminates the licensee's rights. That issue is actually orthogonal to
my classification, but if you really want you could place it as 3.5 in
the gradation above.
I personally think it is very unfortunate that the anti-patent clauses
were put into the GPL and LGPL, as they basically undermine anyone's
ability to distribute any code under these licenses. Using the GPL
and/or LGPL becomes therefore a political statement: "I want to fight
binary-only distribution and patents, at all costs". "All costs" here
includes not being able to distribute the code at all and serious
inconveniences to users (because they will all have to get the source
directly from the authors and compile it themselves).
But, the GPL/LGPL being what they are, I'm suggesting that you consider
using a license from the category (3) above. As I understand, that would
still be compatible with your goals with respect to copyleft, but it
would not prevent people from redistributing the code just because
*someone* has patents on algorithms used in MPEG-4.
Christoph> On Thu, 4 Dec 2003, Jan Rychter wrote:
>> Would the authors be willing to either dual-license the code or
>> change the license to one that does not include the "anti-patent"
>> restriction? There are many licenses that could be used,
>> guaranteeing that the code will remain free (in the GPL "pass the
>> source" sense), while not totally blocking redistribution.
Christoph> We are aware that the patent situation makes GPL and XviD a
Christoph> rather bad couple. That's one reason why we had to restrict
Christoph> distribution in the last release to exclude the USA and
Christoph> Japan, where software patents are valid.
Yes, I noticed that restriction appearing. It has then been removed
after a while, right?
That restriction of course didn't solve the problem. There are probably
many other countries where there are valid patents that apply to this
code. Excluding USA and Japan just meant excluding the major legal
Christoph> What license exactly did you have in mind? We certainly
Christoph> don't want to create "just another selfmade license". Maybe
Christoph> we can come up with a solution.
Creating a license is a formidable task, so it is certainly not a
I have spent some time reading various licenses from
http://www.opensource.org/ and looking at
http://www.fsf.org/licenses/license-list.html. It seems to me that the
Open Source License v2.0 would be the best choice, but I am worried by
the FSF's statement about copyleft being unclear in the OSL
Point to note: the FSF page is outdated and refers to the version 1.0 of
the OSL license. Having just compared versions 1.0 and 2.0 of the OSL
license, the differences might be significant enough (they changed
non-sublicenseable to sublicenseable!) to make OSL 2.0 a valid choice.
Unfortunately, the FSF is being very vague on why they don't like OSL
1.0, vague enough for their statements to qualify as FUD. I have sent a
question to the FSF, but I wouldn't expect a reply anytime soon.
OSL 2.0 grants you a license to use the software and additionally
1) when you distribute the code, you must either include the source,
or give a pointer to an easily accessible location with the source,
2) grant rights to all patents _owned by you_.
You might also find the term "External Deployment" interesting. It goes
further than the GPL, IMHO: it says that if you use the software to
provide services to third parties, you already have to fulfill the
requirements of the license.
The OSL 2.0 also has a patent retaliation clause, so if any users of
your software decide to make patent claims against you, they no longer
have any rights. In an interesting twist, they also lose all rights wrt
software when they make patent claims against *anyone*, if the claimed
patents are applicable to the licensed software (I find that
I am sorry that this posting came out so long. Unfortunately, these
things are complicated, and if you try to simplify them, long flamewars
result, mostly becase of misunderstandings. I hope I have managed to
explain what the issues are in our opinion and what we're looking for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20031212/4a5d60c8/attachment.bin
More information about the XviD-devel