On 27 October 2014 20:53, Mikel Artetxe <[email protected]> wrote: > >> > 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...
Ouch, sorry :P > 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". Correct. > 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: A great point, well made... up to here :) > 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). > This is a little like saying that if you dye a zebra, because it looks like a horse it's no longer a zebra; but aside from that, it's specifically addressed: "For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product." Of course, if you built the signing mechanism into lttoolbox-java rather than the app itself, that actually would fit the "variety of devices" argument, and I'll happily concede on that. It's been fun to be able to debate something for a change, but now seems a good time to let this end (by extension, your argument would apply to anything written in Java... let's not get into that!) > 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 think you've misread this; the keys are listed as part of the "Installation Information". There is no separate requirement for "Installation Information" and keys, it's the same 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. > Yes; the licence of the language pair(s). > 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. In general, you won't see a whole lot of interest in a security issue until *after*, and there aren't too many people on this list who are going to have much to say on the matter anyway, because Android is not our primary focus. But don't let that discourage you! If you want to do it, please do. -- <Sefam> Are any of the mentors around? <jimregan> yes, they're the ones trolling you ------------------------------------------------------------------------------ _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
