Re: [vorlon@netexpress.net: Re: Bug#181969: [mdadams@ece.uvic.ca: Re: JasPer licensing wrt Debian Linux]]
On Fri, Jan 02, 2004 at 11:42:09AM -0800, Michael Adams wrote:
> I am not sure if you are suggesting that JasPer use the GPL. For what
> it's worth, the GPL license was considered as a potential license for
> JasPer. The problem with the GPL is that many commercial organizations
> will not use GPL'd software. For this reason, the GPL was not chosen
> for JasPer.
I think you can achieve your goals (discouraging non-complaint forks and
protecting yourself from patent liability) without the usage
restrictions that makes your license non-free now. The GPL would do
that in my opinion. But I can understand the issue for commercial
organizations, so I'm not necessarily advocating a specific license.
Rather I was trying to hilight a particular clause (in this case the
patent poison pill) as a way of achieving your goals. My interest is
simply to find a license that meets the various definitions of free/open
source software while still achieving your goals.
> Speaking as someone who has attended a number of the JPEG Working Group
> meetings including the most recent one held last month, I can say that
> it has always been the intention of the Working Group that the JPEG-2000
> Part-1 standard be royalty and license-fee free. Unfortunately, some
> ambiguity still exists as to the patent status of JPEG-2000 Part 1.
> So, whether the Working Group's objective (of a free-to-use standard)
> will be achieved remains to be seen. Also, due to this uncertainty,
> one needs to be particularly sensitive to patent issues.
Understood. But I don't think the patent issues here are in particular
any worse than any other piece of open source software. It's very
difficult to write a piece of software that you're positive doesn't
violate any patents. Certainly not without an army of lawyers looking
over your shoulder.
The problem I see with this license is that it doesn't really protect
you against the patent problem. It makes three flawed assumptions in
getting your protection:
a) That the standard is a "free-to-use standard." As you just pointed
out this remains to be seen. If this doesn't turn out to be true then
your protection from contributory infringement (someone modifying the
software to be non-compliant) doesn't get you anywhere.
b) That the patent holder will be a user and thus will have waived their
right to come after you for such a violation. A patent holder you don't
even know could show up, look at the JPEG2000 standard, realize that it
must violate their patent and sue you. Without ever even so much as
downloading your software.
c) It assumes that your software license can require someone to waive
their patent rights. Essentially, you're requiring the user to grant
you license to their patent. I'm not sure about Canada but in the US,
the law only accepts a written and notarized document as prima facia
evidence of a such an action. If this was a document that you were
actually signing with each licensee then I'd say you could enforce this.
But I don't think it'll work. If it did I'd expect to see Microsoft
putting clauses like this in their licenses, what company doesn't have a
copy of Windows? It would make Microsoft immune to patent claims
against them. (see Title 35, Part III, Chapter 26, Section 261 of the US
Code [1]). This is of course not to say that other forms of grants
aren't permisable. But I think you'd have a hard time getting a judge
to accept this particular one.
Now consider the GPL patent poison pill. It protects you from these
problems as well as what you're trying to achieve. Simply by taking
away the right to distribute the software if there is some other legal
requirement that prevents you from doing so (e.g. a patent).
So I see a couple of situations where such a license wouldn't protect
you:
a) Your software violates a patent if used unmodified (e.g. the standard
isn't free-to-use). As I pointed out above I don't believe your
existing license covers you here. However, everyone would immediately
no longer have the ability to distribute your software anymore. Your
liability would effectively be limited to existing copies. Which I
think is also the case under your license.
b) Your software is modified by a user in a way that is inconcsistent
with the standard, making the software violate the patent (e.g. the
standard is free-to-use). The user never distributes the software but
only uses it individually. I don't see this as a realistic threat.
For someone to come after you for this they'd have to find the person,
which I think would be relatively difficult.
It does cover you under these situations:
a) User modifies software to violate the standard and distributes the
software (this is the case where the patent holder is likely to notice).
The protection here is the same. The user doesn't have a license to
distribute their changes.
b) User uses modified or unmodified software and gets sued for patent
infringement. The user then tries to sue you for that infringement.
You're covered here still because of the warranty disclaimer.
> I could certainly ask the other JasPer Contributors whether they would
> be willing to approve such a change. I should note, however, that this
> precise issue has been discussed before, and at that time, the other
> Contributors were not willing to drop the above compliance restriction.
> Therefore, I am not very optimistic that such a change would meet with
> their approval at the present time.
>
> Placing the above patent issues aside for the moment, I am still having
> some difficulties understanding why the compliance clause prevents you
> from using JasPer. Can anyone give me an actual example of a project that
> would like to use the JasPer JPEG-2000 codec in a non-interoperable
> way? If not, then why is the compliance restriction an issue IN PRACTICE?
> Is there a problem with the wording of the clause that makes it more
> burdensome than intended? If so, there is a better chance that I would
> be able to convince the other JasPer Contributors to correct such
> an ambiguity (than removing the clause altogether).
Well there's the issue of not being DFSG, OSD, etc... compliant.
But there are also practical issues with complying with this license.
If a flaw is found in your software which proves to make it
non-complaint then all the existing previous versions without the fix
Are technically violating your license. Say a distribution had produced
CDs of a version of their distribution with your software. They now
have to stop distributing those CDs, update your software, and make new
CDs. And they still haven't cured all the pre-existing copies
violation. Nor is there any reasonable way for them to do so.
Your license is based on the fundamental idea that you are responsible
for how people may modify your software, including ways that you don't
approve of and might be illegal. By extension if we accept this license
we're accepting that we're responsible for anything someone whom we
distribute your software to does with it. In fact your license even
grants us the right to sublicense and in doing so gain the rights you
have under the license. The problem here is that a sublicense means
that we're responsible to you (the original licensor) for what people do
with our sublicensed copies. This is not something we're generally
willing to do.
Let's take a more concrete example of a problem. Let's take ayttm for
example. We're interoperating with Yahoo. Let's say that Yahoo has a
bug in their implementation of the JPEG2000 (I'm not aware of one at
this time though). Because of your license we can't follow a common
Internet axiom. Be liberal in what you accept, be strict in what you
send. Making your library more liberal in what it would accept would
violate your license. Further, your license extends this restriction,
not just to your software but to ours. We can't even write code to fix
the data sent to us by Yahoo before feeding it to your library. Our
options at this point are: not interoperate, find a different library,
or interoperate and tell the user that Yahoo violates the standard and
that we can't fix their software. You might able to fix this by
defining what you mean by complying with the standard. But trying to
define that could get really ridiculous.
The problem with use restrictions is you tend to run into issues like
this. Where there's no reasonable way someone can be sure they are
compliant with your license and cases where you probably don't object
to the particular use but the license is unclear. If you try to fix all
of these cases then you end up with an insanely complex document that
nobody really understands anyway.
> Although I may not have explictly mentioned this before, please keep in
> mind that the JasPer JPEG-2000 codec was developed in order to promote
> the use of the JPEG-2000 standard. It is clearly in the interest of
> the success of the standard to discourage the creation of
> non-interoperable (i.e., non-compliant) implementations. This purpose
> is also served by the compliance clause in the JasPer license.
> Anyways, I just thought that this was worth mentioning. I think that
> the patent issue is probably the more serious one.
Between your license and the unclear patent status, the adoption of
JPEG-2000 is being hurt. None of us wants another GIF on our hands.
I really do understand you and your other contributors fears on the
patent issues. I don't think they are entirely unrealistic. But at the
same time I don't think the open source communities fears and concerns
about use restrictions are unrealistic either.
We both have to be willing to take some risks in order for the community
to work. You have to take the risk that someone is going to sue you
over patent issues. This risk exists no matter what the license says.
The only question is if the license protects you. We as a community
have to take the risk that your software does violate patents and that
we individually can be liable for our potentially infringing use.
Any attempt to eliminate or shift the risks entirely onto one side or
the other is going to by necessity involve restrictions that aren't
useful in an open source context to both sides. Right now I think
you're trying to eliminate the risk on your side. I don't think this is
realistic. At best you can mitigate some of that risk.
If I can help in anyway just let me know. I'm more than willing to give
some of my time to help make the case to your contributors. At the same
point I don't intend to continue to hassle you (I don't think I really
have yet, but from previous emails it seems that others have). If we
really can't come to some sort of compromise then I guess I'll just have
to look elsewhere for a JPEG-2000 impelmentation. This is not meant as
a threat. It's just the reality of the licensing situation.
Standard disclaimers apply. I'm not a lawyer nor is this legal advice.
It's based on my own lay understanding of the law. And it's mostly
based on US law which may not be entirely applicable to you since you're
in Canada.
[1] http://www4.law.cornell.edu/uscode/35/261.html
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Reply to: