On Fri, Nov 18, 2011 at 12:39:25PM +0100, Nils Kneuper wrote: > 3.1.d) OUTSCH! That one is possibly really problematic. It is about the > support and I don't know how we can possibly handle this one. We have to > promptly respond to comments, queries and complaints (which we already do in > our own forums and bug tracker) but there is no specification where those > comments reach "us". So they probably think about their forums and boards, > meaning that we would have to monitor an external source for issues. We also > have to provide tech support which can be problematic. Is providing tech > support (in weird cases!) to say "then don't use this program, your system is > simply borked!"? We also have to issue patches (though we basically do this > during our normal development)
If I 3.1.d.iv we have to provide support according to some local law, which is really problematic. > 3.1.e) This one states that once we enter the agreement we *have* to continue > supporting our binaries with *all* patches and updates in a very timid manner > (7 days). So what happens if I release when gambit is on 3 weeks holidays? The way I interpret it we even have to provide it for *every subversion commit* since our repository is public. > 3.1.f) We have to follow their policies. This one does not really state too > much but yeah, sounds okayish. > 3.1.g) Okay, no RE. I see a problem with this, who has to sign this? What if somebody who works on Wesnoth decides the reverse engineer their software. (/me remembers the Bitkeeper fiasco.) Can we be held responsible for that? > 3.1.h) In 'i.a' we have to make sure that the description of the game is > correct, sounds possible. On the other hand 'i.b' is a strange one that I > don't understand 100%. The main problem I see there is "content rating" like > it is eg required in Germany. Here content rating is done by some state based > institution and *not* by the publisher, so what to enter regarding rating? I > don't know what else might be covered by this clause, though it can probably > easily break our necks. In regards to 'ii': what about stats upload (code)? > This would count under the formulated wording. Was this really completely > removed? If we (re)added it, we would have to make sure that the users are > informed about this feature, too (informed probably being more than just > displaying it in the tips of the day box). I also see problems with 3.1.h.B. > 3.2) Their API might change, no problem if we basically make no use of it > inside our code, right? I can't see whether or not we are required to, but if we are we're adding non-GPL code to a GPL project. > 3.3) No problem, they are allowed to change their website/product placement. > 3.4) We get no rights to their system, fine. > 3.5) We have to keep the bills. In case that we make it available for free, > this would not be an issue, right? > 3.6) OUTSCH! A big one at that. This one states that we actually have the > right to relicense the stuff since we warrant in that one that we have the > rights to grant the rights under the agreement, which might not be the case. > Yes, I am not sure if those suffice for the GPL, since we only give them the > right to continue distributing but don't force them to give the same rights to > those they give the prog to (and other similar stuff). Also OUTSCH here. > 4) This one is about payment. If we don't charge for the program then it > should not be relevant, right? > 5) We have to keep the agreement confidential. Ups, failed, this is a public > ML. What to do now? ;) Yup and we might want to talk on IRC about it... > 6) We might have to provide warranty. A "refund" should always be possible, > right? Especially if the program is made available for free... Beside they > also state that their systems are no backup systems, so any data there might > get lost. > 7) The stuff regarding when this agreement terminates. Yeah, the usual > business stuff. > 8) Where to handle disputes. Nothing too exciting there besides us having a > "senior representative with authority to settle the dispute" available. Is > every core dev qualified for this? And where to meet? Must be a face to face meeting and if so where? They are based in Australia and as far as I know we have no developers over there. > 9) The lovely closing terms. > > Yes, as I pointed out there are several issues listed in '3' that are > problematic for us and that can't be met without relicensing which we don't > have the required rights to do. Relicensing would require asking every > contributor if this was okay (and possibly directly asking for a transfer of > ownership of the code to Wesnoth Inc.) which was once upon the time deemed > impossible. So yeah, I fear that we as Wesnoth Inc. can simply not follow this > agreement due to our "products" strict license terms. I agree with this assessment. I'm also not fond of the amount of assistance we might have to provide. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
