hello Mark, On Thursday 23 March 2006 22:06, Mark Wielaard wrote: > On Thu, 2006-03-23 at 21:16 +1100, Raif S. Naffah wrote: > ...i'd like a second opinion on a legal-related issue. > > > > the tool reads and uses private and public cryptographic data from > > a keystore that is in a proprietary format: "JKS" from Sun. the > > code i use to do the reading from such a keystore* is available at > > <http://metastatic.org/source/JKS.java>. > > > > i'd like a ruling on whether it's ok to import and use this code in > > GNU Classpath. > > Unfortunately no. The last time this came up FSF legal didn't like us > using code which was written by reverse engineering the original code > and format. And for which no public documentation was available at > all. We can ask again of course. And maybe just using the description > of the format (which I believe is also documented outside the code > you reference itself) and then letting someone else write a new > implementation for it is OK. > > The question is also whether we really need to support this > undocumented keystore format. There are open formats. And we can also > work towards something like > http://metastatic.org/text/gnu-keyring.txt > > What is your opinion? Is it important enough to support this JKS > format to try and jump through some legal hoops? Or can we just stick > to open keystore formats?
i think yes for two reasons: 1. for everything Java, Sun sets the pace. in practice if Sun offers a format, an API, etc... Java programmers will use it in preference to any other alternative. an example would be the log4j logging API v/s jdk logging. 2. if the alternative is not a drop-in replacement, there will always be a reticence, by Java programmers, to that alternative compared to what Sun offers. an example is our endeavor (GNU Classpath), to match the behavior of Sun's JDKs, incl. bugs! cheers; rsn
pgpLSm0rPacPC.pgp
Description: PGP signature
