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 <[EMAIL PROTECTED]> http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken
