Some Marketplace policy issues

[Gervase Markham]

Hi Marketplace team,

Over in .governance, we have been reviewing the Legal team's draft of
the Marketplace Terms and Privacy Policy. A few issues were raised which
turn out to be policy issues for the product team rather than legal
drafting issues. So Jishnu suggested I bring them over here :-)

1) The agreement says:

"* Failure to provide adequate support for your App(s) may result in low
App ratings, less prominent App exposure, low sales, billing disputes,
and suspension or removal from the Mozilla Marketplace."

On that latter point, I think it's unreasonable to boot an app if the
developer fails to provide support, particularly if they make it clear
that no support is offered. Much open source software comes this way.

We can warn people about potentially negative consequences of providing
no support, but I think that it should never result in being removed
from the Marketplace. Would you agree?

2) The agreement says:

"* (iv) you must provide meaningful notice and have a procedure for end
users to opt-out or opt-in (depending on applicable law and industry
standards) to any tracking that leads to you or third parties tailoring
advertisements or promotions to users."

Would it not be more consistent with Mozilla principles to require
opt-in, unless applicable law actually forbids it (which I suspect is a
rare or non-existent case)?

3) The agreement says:

"(c) that you and your Apps or Add-ons will not use the Firefox Sync
APIs for any application or service that replicates or attempts to
replicate Mozilla’s hosted Firefox Sync services or experience unless
such use is non-confusing."

Perhaps I need to take this up with the Sync team instead/as well, but
that looks dangerously like an Apple-style nasty "don't compete with our
functions on iOS" clause. How is "non-confusing" defined?

My suggestion is that we make it into a permission: "You may use the
Firefox Sync APIs to create any application or service, including one
that replicates or attempts to replicate Mozilla’s hosted Firefox Sync
services or experience, as long as you do not mislead users into
thinking your service is our service."

Gerv

[Justin Scott]

Gervase Markham wrote:
> Hi Marketplace team,
>
> Over in .governance, we have been reviewing the Legal team's draft of
> the Marketplace Terms and Privacy Policy. A few issues were raised which
> turn out to be policy issues for the product team rather than legal
> drafting issues. So Jishnu suggested I bring them over here :-)
>
> 1) The agreement says:
>
> "* Failure to provide adequate support for your App(s) may result in low
> App ratings, less prominent App exposure, low sales, billing disputes,
> and suspension or removal from the Mozilla Marketplace."
>
> On that latter point, I think it's unreasonable to boot an app if the
> developer fails to provide support, particularly if they make it clear
> that no support is offered. Much open source software comes this way.
>
> We can warn people about potentially negative consequences of providing
> no support, but I think that it should never result in being removed
> from the Marketplace. Would you agree?

Support can mean a few things: direct 1:1 customer support (replying to
emails), general support (knowledge base, forums, etc.), or supporting
the app's continued functionality.

If an app is paid, we expect that some level of support will be provided
to users.

For all apps, free or paid, we expect that developers will continue to
support their apps and we would absolutely remove apps that stop
functioning due to lack of support. For example, if an app's server goes
down for weeks leaving it no longer functional, we would remove the app.

>
> 2) The agreement says:
>
> "* (iv) you must provide meaningful notice and have a procedure for end
> users to opt-out or opt-in (depending on applicable law and industry
> standards) to any tracking that leads to you or third parties tailoring
> advertisements or promotions to users."
>
> Would it not be more consistent with Mozilla principles to require
> opt-in, unless applicable law actually forbids it (which I suspect is a
> rare or non-existent case)?

It would be, yes. However, just as we don't require all submissions to
be under an open source license, we want to ensure developers have
freedom to build their products as they see fit even if Mozilla would do
things differently, as long as they do not infringe on a user's privacy,
control, security, and experience. In this case, we've required that any
tracking must be clearly stated and allow users to have control over that.

>
> 3) The agreement says:
>
> "(c) that you and your Apps or Add-ons will not use the Firefox Sync
> APIs for any application or service that replicates or attempts to
> replicate Mozilla’s hosted Firefox Sync services or experience unless
> such use is non-confusing."
>
> Perhaps I need to take this up with the Sync team instead/as well, but
> that looks dangerously like an Apple-style nasty "don't compete with our
> functions on iOS" clause. How is "non-confusing" defined?
>
> My suggestion is that we make it into a permission: "You may use the
> Firefox Sync APIs to create any application or service, including one
> that replicates or attempts to replicate Mozilla’s hosted Firefox Sync
> services or experience, as long as you do not mislead users into
> thinking your service is our service."

This piece was added to the AMO Developer Agreement a few years ago by
Legal. I don't know what prompted it or where it came from, and I don't
have an opinion on it.
>
> Gerv
> _______________________________________________
> dev-marketplace mailing list
> dev-mar...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-marketplace

[Gervase Markham]

On 18/06/12 04:51, Justin Scott wrote:
>> "* Failure to provide adequate support for your App(s) may result in low
>> App ratings, less prominent App exposure, low sales, billing disputes,
>> and suspension or removal from the Mozilla Marketplace."
>>
>> On that latter point, I think it's unreasonable to boot an app if the
>> developer fails to provide support, particularly if they make it clear
>> that no support is offered. Much open source software comes this way.
>>
>> We can warn people about potentially negative consequences of providing
>> no support, but I think that it should never result in being removed
>> from the Marketplace. Would you agree?
>
> Support can mean a few things: direct 1:1 customer support (replying to
> emails), general support (knowledge base, forums, etc.), or supporting
> the app's continued functionality.

I don't think "making sure it keeps working" falls into the normally
understood computer-y definition of "provide support". If that's what we
mean, we should say so explicitly, e.g.:

"* Failure to provide adequate support for your App(s) may result in low

App ratings, less prominent App exposure, low sales, or billing
disputes. If your app ceases to function, this may lead to suspension or

removal from the Mozilla Marketplace."

> It would be, yes. However, just as we don't require all submissions to
> be under an open source license,

Side question: do we require that the licence be defined in the
metadata? ("Proprietary" could be an option.) Just like on AMO, this
would provide a lot more certainty for users wanting to take over
popular but abandoned apps.

> we want to ensure developers have
> freedom to build their products as they see fit even if Mozilla would do
> things differently, as long as they do not infringe on a user's privacy,
> control, security, and experience. In this case, we've required that any
> tracking must be clearly stated and allow users to have control over that.

OK.

> This piece was added to the AMO Developer Agreement a few years ago by
> Legal. I don't know what prompted it or where it came from, and I don't
> have an opinion on it.

Jishnu says he's on the case here, so that's great.

Thanks :-)

Gerv

[Ibai Garcia]

If the app is malfunctioning, it doesn't deliver the experience that is promised and users request a refund after the automatic-refund timeframe we expect developers to react accordingly (i.e. provide a manual refund if adequate or an answer explaining why not).

If this doesn't exist the experience of our users (they are Mozilla users after all) will have a poor experience.

In my opinion, this clause is more about having the ability to execute than actually executing on it. If something goes completely wrong with an app we want to have tools to protect our users.

On Jun 18, 2012, at 9:48 AM, Gervase Markham wrote:

> On 18/06/12 04:51, Justin Scott wrote:

>>> "* Failure to provide adequate support for your App(s) may result in low
>>> App ratings, less prominent App exposure, low sales, billing disputes,
>>> and suspension or removal from the Mozilla Marketplace."
>>>
>>> On that latter point, I think it's unreasonable to boot an app if the
>>> developer fails to provide support, particularly if they make it clear
>>> that no support is offered. Much open source software comes this way.
>>>
>>> We can warn people about potentially negative consequences of providing
>>> no support, but I think that it should never result in being removed
>>> from the Marketplace. Would you agree?
>>
>> Support can mean a few things: direct 1:1 customer support (replying to
>> emails), general support (knowledge base, forums, etc.), or supporting
>> the app's continued functionality.
>

> I don't think "making sure it keeps working" falls into the normally
> understood computer-y definition of "provide support". If that's what we
> mean, we should say so explicitly, e.g.:
>

> "* Failure to provide adequate support for your App(s) may result in low

> App ratings, less prominent App exposure, low sales, or billing

> disputes. If your app ceases to function, this may lead to suspension or

[Gervase Markham]

On 20/06/12 20:18, Ibai Garcia wrote:
> If the app is malfunctioning, it doesn't deliver the experience that
> is promised and users request a refund after the automatic-refund
> timeframe we expect developers to react accordingly (i.e. provide a
> manual refund if adequate or an answer explaining why not).

I agree that for paid apps, there could be significantly higher
requirements.

> In my opinion, this clause is more about having the ability to
> execute than actually executing on it. If something goes completely
> wrong with an app we want to have tools to protect our users.

I don't think we should put in the agreement that we could do things
that are unreasonable. One thing I think we should try and do is
contrast ourselves with some of the more draconian App Store policies
out there. And that means putting our money where our mouth is. I don't
think it's good enough to write an "I can haz all the rights" agreement
and then simply promising not to do the most egregious things it lets it do.

If I wrote some Free software and put it in the Marketplace, for free,
say "no support provided", and then refused to answer email of the form
"How do I do X with your app?", then it should not be possible for
Mozilla to give me the boot for that reason. No matter how many people
complain.

Gerv

[Ian Bicking]

On Fri, Jun 22, 2012 at 10:28 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 20/06/12 20:18, Ibai Garcia wrote:

> > If the app is malfunctioning, it doesn't deliver the experience that
> > is promised and users request a refund after the automatic-refund
> > timeframe we expect developers to react accordingly (i.e. provide a
> > manual refund if adequate or an answer explaining why not).
>

> I agree that for paid apps, there could be significantly higher
> requirements.
>

> > In my opinion, this clause is more about having the ability to
> > execute than actually executing on it. If something goes completely
> > wrong with an app we want to have tools to protect our users.
>

> I don't think we should put in the agreement that we could do things
> that are unreasonable. One thing I think we should try and do is
> contrast ourselves with some of the more draconian App Store policies
> out there. And that means putting our money where our mouth is. I don't
> think it's good enough to write an "I can haz all the rights" agreement
> and then simply promising not to do the most egregious things it lets it
> do.
>
> If I wrote some Free software and put it in the Marketplace, for free,
> say "no support provided", and then refused to answer email of the form
> "How do I do X with your app?", then it should not be possible for
> Mozilla to give me the boot for that reason. No matter how many people
> complain.
>

If it's not a quality app, or it doesn't operate as advertised, or it is
insecure, or is otherwise flawed then why shouldn't we remove it? If it's
a free app it can always do self-installation. If as an app developer you
don't want to participate in the Marketplace feedback/support/listing
process then don't list on the Marketplace.

Our choice to leave an app out of the Marketplace isn't as putative as with
other app stores, as we don't exclude apps that don't choose to use the
market.

[Gervase Markham]

On 22/06/12 19:05, Ian Bicking wrote:
> If it's not a quality app,

We should not be kicking apps out of the store for being low quality.
Seriously. That's what ratings are for. Who knows what the next version
will bring?

> or it doesn't operate as advertised,

Misrepresentation should be corrected, but I suspect that again, ratings
will deal with this.

> or it is
> insecure, or is otherwise flawed then why shouldn't we remove it?

Because we should be very wary of starting to be "quality policeman".
That way lies the Apple App Store model. We're all about user choice,
and one person's sucky app may be another person's "just what I need".

> Our choice to leave an app out of the Marketplace isn't as putative as with
> other app stores, as we don't exclude apps that don't choose to use the
> market.

That is true :-)

Gerv