I still don't know if the algorithms are covered by patents, and don't have more time to look into it today. They seem to be saying that its access to the 'algorithm specifications' (which in this case includes a reference implementation) which is restricted. So if we couldn't re-implement the algorithm without reading the spec, it wouldn't do us any good.
I used the reference implementation to test that I was correctly gathering the inputs and passing them to the f8/f9 functions. Again, I believe that interface is generic (a form of the same args described in non-restricted specifications, and passed to the one algorithm we can use). Removing the calls to the f8/f9 functions wouldn't cause any variable-not-used warnings as they won't be compiled either without HAVE_SNOW3G being defined. Assuming we can't include any implementation of snow-3g (I hope I'm wrong, and thanks for the offer, Jeorg), I'd like to leave it as it is, but with the #include removed, and maybe more information given in a comment. Anyone can get the code, and anyone working for an organisation that has paid the fee can use it. Is it not OK to link GPL code with whatever you want, as long as you don't distribute it? Checking in the code I did was more so that it would be easy for me to maintain a small diff and easily continue to contribute to the dissector, rather than give people an easy way to violate license agreements. I will check in a minimal change described above for now, but will respect the consensus this doesn't go far enough. Martin On Thu, Jan 16, 2014 at 10:30 AM, Joerg Mayer <jma...@loplof.de> wrote: > On Thu, Jan 16, 2014 at 09:54:48AM +0000, Martin Mathieson wrote: > > Re-reading the terms quoted by Guy, my impression is that its the > algorithm > > rather than the reference implementation that the administrative charge > > gives an organisation access to, so re-implementing would not help. > > I don't care about "impressions" about license agreements :-) It's either > patented or it isn't. In case it isn't, there's nothing prohibiting us from > doing our own implementation if we want to. > So if you could provide a sample capture plus the necessary keys, I could > try my luck in implementing this (OK, that would be time not spent on cmake > stuff, but I can live with that ;-) > If it is your own implementation, it would be nice to get at least the > .h file into the source, that way I could make a complatible > implementation. > > If we don't do anything, the the include statements and the lib invocations > would have to be removed. > > Ciao > Jörg > > -- > Joerg Mayer <jma...@loplof.de> > We are stuck with technology when what we really want is just stuff that > works. Some say that should read Microsoft instead of technology. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
