On 28 October 2014 08:34, Mikel Artetxe <[email protected]> wrote:
>
>> > 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 think that it is you who misread me ;). As I understand it, the
> installation information is basically whatever that is needed to run a
> modified version of the covered work in a user product. In our case the
> covered work would be the language pairs and the user product would be the
> android device. So we would need to provide the necessary information to run
> modified versions of the language pairs in android devices. That might be
> our private key, but it doesn't necessarily have to be our private key (the
> license doesn't explicitly make such requirement). Giving instructions on
> how to modify the app so that it could run modified (and unsigned) versions
> of the language pairs would suffice.
Ah, you're right -- I did misread that, and that is also a good point.
> In other words, I think that we
> wouldn't have to publish our key because our key would *not* be strictly
> "required to install and execute modified versions of a covered work in that
> User Product". In the case of TiVo there was no such alternative: the only
> way to run a modified version of their software was by signing it with their
> key.
>
> But, well, we all know that you are the expert in licensing here, so you are
> probably right, anyway. I give up! One last question though. You have shown
> that my solution is not valid, but you haven't proposed any alternative. Can
> you think of some way to address the security issue without violating the
> GPL terms?
Well, I did misread your second point, which is quite valid :)
Allowing people to install their own builds of language pairs
(unreleased pairs, etc.) would be useful enough on its own merits. Of
the options you listed earlier, if you could add both 1 (add your own
key) and 2 ("this is untrusted, do you want to continue?"), that would
probably make the maximum amount of people happy. I did suggest adding
the signing to lttoolbox-java; having the same easy installation would
be useful for, e.g., the OmegaT plugin, which cannot (to my knowledge)
currently run on Android.
> Didn't the FSF geniuses foresee this kind of situations?
I have no idea, and not enough interest in the FSF to find out :)
--
<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
