> > OK. Now I understand what you were referring to. But I think that what I > > propose has nothing to do with Tivoization, because our signature would > not > > be hardware checked but software checked, which means that anybody would > be > > free to modify the app and skip the check if they wish. In fact, this is > > what the GPL FAQ says ( > http://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys): > > > > The FAQ says that; the licence does not. The FAQ is quite specific, > while the licence itself is quite vague -- presumably, deliberately > so, to cover unforeseen circumstances, and/or to try to prevent > lawyers from finding ways to argue around it: "hardware" is not > mentioned in that section; what might be considered "hardware" for > purposes of the FAQ might not be hardware in reality. > > Nobody applies the terms of the GPL3 _FAQ_ to their code, and there is > no reasonable basis to assume, in the case of divergence, that > additional clarifications could or would apply, if the licensor has > not provided them. >
I get your point. So I've read the actual license... and now I am even more convinced of my position. If I'm not wrong this is the restriction that you were referring to: "If you convey an object code work under this section in, or with, or specifically for use in, a User Product, [...] the Corresponding Source conveyed under this section must be accompanied by the Installation Information". I can think of at least two reasons why that wouldn't force us to release our private key: 1) We don't convey the transfer bytecode "in" or "with" anything. It might be arguable if we convey it "specifically for use in" our app, but then an app does not fit the definition of a "User Product" (it is neither (1) "tangible" nor (2) "designed or sold for incorporation into a dwelling"). It is true that the transfer bytecode ultimately runs in a user product, but for obvious reasons that applies to practically any software that I can think of. But, as I see it, it is not true that we would convey the transfer bytecode "specifically for use in" any given user product: the bytecode could be run in a variety of devices (smartphones, tablets, TVs, PCs...), a variety of architectures (android runs in at least ARM, x86 and MIPS) and potentially a variety of apps (possibly even some that would not verify the bytecode's signature). 2) Even if you are able to refute my first point (and you probably are ;-)), we would only be forced to publish the "Installation Information". According to the license, “Installation Information for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.". As said before, our app doesn't fit the definition of a user product. And if we take the android device as the user product, then giving instructions on how to modify the app so that it can run unsigned language pairs would be enough to fulfil the requirement. I also think that it would be convenient to clarify whether the app and the language pair(s) can be considered as two separated pieces of software for this matter and, if so, the license of which of them would we be violating according to you. In any case, I guess that this thread was not meant to discuss about licensing... If people here don't like my idea and/or don't think that we should address the security issue in question then there is no need to have this discussion here.
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
