"Helix DNA Client" source released

Posted Oct 30, 2002 18:21 UTC (Wed) by pj (subscriber, #4506) [Link]

Posted Oct 30, 2002 22:31 UTC (Wed) by Peter (guest, #1127) [Link]

I can't comment on the patent issue (our legal staff doesn't like me doing that), but I can talk about some other things.

Well, I read the RPSL - haven't tackled the other one yet. It is actually not a bad little (well, not so little) license. It looks to have been offered in good faith to the free software community, unlike (say) the infamous SCSL. I guess I came on a little strong the other day - sorry.

For those who haven't read it yet, here's my take:

It's viral, like the GPL, but §4.2 has an interesting twist: it contains a built-in exception for a list of 30 other free software licenses, saying that you can create derivative works by combining RPSL code with code under these other licenses without putting the other code under the RPSL. Any modifications not "independently developed without use of Covered Code" must be released as RPSL. The license even acknowledges the problem with combining RPSL code with (e.g.) GPL code but punts on that, effectively saying that it is the responsibility of the copyright holder of the GPL code to grant an exception for linking with RPSL code.

In other words, both GPL and RPSL are viral, so if I take a GPL library and link it into an RPSL application, the RPSL grants me permission to do so, but the GPL does not, unless the library author adds a rider granting me an exception. In any case, the combined work is neither fully GPL nor fully RPSL. Very interesting approach indeed. Same story with the other 29 licenses, although most of them do not present the same problem of having to have an exception granted by the original author.

(Real reserves the ability to add to the list of 30 licenses by specifying a web site where they can list additional "Compatible Source Licenses".)

Patent licenses. Their wording is interesting. They give me a perpetual (plusgood!) license to applicable patents for use with their code, provided of course that I abide by the RPSL. Furthermore, if I distribute derived works, I have to do the same for any applicable patents I may hold on the derived work. But it goes a little bit further. Their patent grant (§2.3) does not explicitly mention the right to make or distribute modifications (ie derived works), whereas my patent grant (§3(b)) does mention modifications. This seems rather carefully worded, so I wonder if it's an intentional difference or just noise.

As to the question I had originally, regarding whether ffmpeg code is authorised to use patented algorithms, the license seems to say no: "No patent license is granted separate from the Original Code or combinations of the Original Code with other software or hardware" (§5). §12.3 acknowledges that competing software is allowed to exist (amusing, in a way), but does not grant patent licenses.

One final point on patents: according to §11.1(c), I get my license revoked immediately if I ever sue Real over patent infringement. Note that my suit does not have to concern the software in question - basically, if I want to use their helix library, I cannot ever sue them about any patent infringement. Which is fine by me, as I don't have any patents, but I would strongly recommend that IBM not put themselves in a position to depend on RPSL code! At least if they care about defending their vast patent portfolio, which I don't necessarily agree with either (software patents are evil, by and large). Oh - I also get my license revoked (§11.1(d)) if I sue any third party over patent infringement for the RPSL code - but not other patent suits, in this case. Interesting.

Versions. The RPSL has a built-in "or any later version" clause (§7) - but it takes care to apply itself only to "Original Code", not derived works. For derived works, I gather, I get to decide whether to trust Real's future license revisions. Actually, it seems that if I hack on a Real application, I can choose not to allow §7 to apply, but if I create a brand new application and release it as RPSL, I implicitly allow future RPSL revisions. Hmmm, is that the intent?

One other notable point: the license claims to be a click-through EULA, which I disagree with, though I understand why a company like Real (whose previous licenses have all been EULAs) would think this way. The first section includes two sentences clearly borrowed from the GPL: "You are not required to accept this License. However, nothing else grants You permission to use, copy, modify or distribute the software or its derivative works." (Emphasis mine.) The GPL, on the other hand, does not restrict use, only modification and distribution. It is my understanding that the RPSL is misleading in this way: copyright law does not in fact restrict simple use of the software. §1 then goes on to distinguish between different kinds of use - personal, R&D, deployment, and external deployment (which seems to me to be a case of "distribution", and in any case is treated the same way). Fortunately, these distinctions do not matter much in substance - they pretty much only affect whether or not you have to publish your source modifications. But in any case, I do not like being misled about what copyright law allows me to do. I also do not care for the idea that I have to agree to this license merely to download RPSL code (§1 again).

Just thought of something - by asserting that you have to agree with the RPSL before downloading the code, this seems to erect a major barrier to redistribution. For example, if Debian packaged this library, they would have to add a mechanism to dselect and apt-get to display the license before commencing the download process. This would be doubleplus-annoying - Real, are you listening? Can you please revise §1 to remove this restriction?

Most of the rest of the license seems to be legalese.

In summary, I don't have a lot of problems with this license, but I do disagree with the assertion that I need to accept it in order to download or use (as opposed to modify or distribute) Real's code....