245198 - Add-ons policy needs to be defined and published

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Policy, defect, P1)

Description

[alanjstr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040518 Firefox/0.8.0+ (Darkstar)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040518 Firefox/0.8.0+ (Darkstar)

u.m.o needs a policy document explaining what themes/extensions/plugins can be
listed, the licenses they can come with

Reproducible: Always
Steps to Reproduce:

Comment 1

[alanjstr]

The items listed on this site are NOT supported by mozilla.org unless
specifically listed as such.  All are free for use and should be considered
copywritten unless other license is provided.  

Website errors should be reported using <a
href="http://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&format=guided">bugzilla</a>.
 Extension and theme requests, as well as support requests can be made on <a
href="http://forums.mozillazine.org">MozillaZine</a>.  

Comment 2

[Alfred Kayser]

Regarding the discussion on licensing, may be it is good 
to let the authors/submitters explicitely name the license(s) 
valid for the submitted material?

Comment 3

[Wolf [:wolf]]

*** Bug 247321 has been marked as a duplicate of this bug. ***

Comment 4

[Wolf [:wolf]]

Updating summary, since there was a dupe... Also, who at the Mozilla Foundation
handles stuff like this? we need to work with them on this one.

Comment 5

[Wolf [:wolf]]

See Bug 252680 and Bug 252679, this'll likely become a dupe of one of those.

Comment 6

[alanjstr]

*** Bug 252680 has been marked as a duplicate of this bug. ***

Comment 7

[Wolf [:wolf]]

Updating Summary to be clear what this bug is about.

From Bug 252680 Comment #0:

------- Comment #0 From Ben Goodger  2004-07-22 13:37 PDT -------

Independently of when we come up with a solution for extension signing, we need
some kind of disclaimer for umo that states effectively:

"Extensions, themes  are distributed by mozilla.org but the content is not
necessarily verified or waranteed by us etc" We are working on getting a set of
EULAs - I suspect this text can be attached when we get it. See bug 252679 for
details. 

If we get signing working this needs to be extended to say that "Signing means
that the extensions are provided by us, but not necessarily verified by us etc"

Comment 8

[Wolf [:wolf]]

Rafael: I haven't heard anything on this particular document. Ben G. filed Bug
252680 (his comments are quoted in Comment #7 here.) This is supposed to be
related to the work on Bug 252679 for the Firefox EULA. I have a placeholder in
update-beta for this info when its finalized, but I can't personally act on this
bug, it needs the blessing of somebody from the Foundation. Can you or somebody
else official take over with this one?

Comment 9

[Wolf [:wolf]]

*** Bug 271380 has been marked as a duplicate of this bug. ***

Comment 10

[Wolf [:wolf]]

Moving more bugs to new component.

Comment 11

[Wolf [:wolf]]

Status on this? 1.0 is close and this is not likely to make it.

Comment 12

[Wolf [:wolf]]

Changing target milestone to 1.1. Though as soon as we get this, I'll post it,
regardless. :-)

Comment 13

[Chris Beard]

Taking ownership and escalating to get legal engagement and review ASAP.

Comment 14

[Rafael Ebron (:rebron)]

Attachment: policy 0.1

Comment 15

[alanjstr]

> All hosted software must function as described, without additional behaviour 
> and/or side effects, intentional or not.

I'm a little unclear on that one.  To me it is saying that the description
provided to us must enumerate all functionality.  

Comment 16

[O. Atsushi (Torisugari)]

(In reply to comment #14)
> Created an attachment (id=193070)

Even if both a software and its description
are fine, reviewers might not be able to read it.

Then, ... 
 - The description should be written in English,
   or at least, include English translation part.
 - The title should be ascii.



> 8. We may refuse ... , poorly written, ...

By "poorly", it implys the software code sucks,
but reviewers should also reject apps such as...
 - its title/desc includes words which sound
   dirty, insulting, etc.

In short, improperly written softwares.

Comment 17

[Daniel Veditz [:dveditz]]

Comment on attachment 193070 [details]
policy 0.1

> 1. [...] It does not have to be open source, but code must be licensed
> such that it can be viewed and read by [...] potential end-users.

This precludes hosting any with proprietary binary components? There are useful
tools out there that I would be willing to host in theory (assuming
non-evilness of installers, etc) like the Netcraft or Yahoo toolbars. Sure,
they advertise or tie to a service, but it's a useful service for some number
of users. Is there a line we could draw, like willingness to let umo-admins
review the code under NDA, or a signed contract of non-evilness in situations
like this.

>  6. All hosted software must not interfere with the normal operation of any
>  third-party services in such a way as to be considered malicious or damaging.

AdBlock/FlashBlock/Greasemonkey/etc ? Considered damaging by whom?

Comment 18

[alanjstr]

(In reply to comment #17)
> This precludes hosting any with proprietary binary components? There are useful
> tools out there that I would be willing to host

If we just link to their site (like Yahoo wants us to), where does that fall in
there?

Comment 19

[alanjstr]

*** Bug 310154 has been marked as a duplicate of this bug. ***

Comment 20

[Chris Neville-Smith]

Hi,

I've just joined you from 310154 (sorry I didn't spot this one earlier - I did
search for duplicates but missed this), and my request is slightly different.
I'm more interested in a having a message on the extensions download page
clarifying whether the extensions are vetted in any way, and, if not, what duff
extensions can do to your computer. (Last bit may be obvious, but it will be
very important to prevent stupid people we're attempting to herd from Internet
Explorer blaming everything going wrong on Firefox. I'm not so keen on only
putting it in the EULA because I, like probably most people, usually accept it
without reading it.)

Now that there seems to be a policy for extension developers in the pipeline,
here's my suggestion for what to put on the front extensions page (just a
starter, tinker as you please):

"All extensions hosted by mozilla.org are expected to conform to a policy
setting standards of security, privacy and stability. [Link to policy.] However,
mozilla.org does not necessarily verify extensions, and all extensions are
installed at the user's own risk."

And I suggest with following it with one link to a user guide in layman's terms
explaining what can happen when you install extensions (in short, what's the
worst that could happen), plus another link to a page should anyone wish to
complain about an extension not conforming to the policy.

Finally, if you've got time, could mozilla.org create a "seal of approval" or
something for extensions they have vetted and found to conform to policy.
Obviously, you couldn't vet all of them, but, say, vetting the 50 most popular
extensions would increase my confidence a bit.

Comment 21

[bugzilla]

See also bug 275197

Comment 22

[Cameron]

http://wiki.mozilla.org/Update:Policy
draft.

Comment 23

[Michael Morgan [:morgamic]]

shaver is going to help combine feedback and solidify the draft (with everyone else helping of course) -- reassigning.

Comment 24

[Michael Morgan [:morgamic]]

*** Bug 317647 has been marked as a duplicate of this bug. ***

Comment 25

[Mike Shaver (:shaver emeritus)]

*** Bug 291565 has been marked as a duplicate of this bug. ***

Comment 26

[Mike Shaver (:shaver emeritus)]

*** Bug 275197 has been marked as a duplicate of this bug. ***

Comment 27

[Mike Shaver (:shaver emeritus)]

*** Bug 271466 has been marked as a duplicate of this bug. ***

Comment 28

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 29

[Mike Shaver (:shaver emeritus)]

http://wiki.mozilla.org/User:Shaver/AMO_Extension_Policy is what I've been slowly concocting, I'm pretty happy with it now, though it needs some wordsmithing before it's published and linked from AMO proper.  Comments welcome here on on the talk page.

Comment 30

[Oliver Saier]

Yes it clearly begins to take shape nicely. 2 thoughts:
1. "Creator responsiveness: We expect that add-ons on AMO will be maintained to ensure compatibility with new stable/security releases"
Not that I disagree but it seems inconsistent with the fact that maxVersion was capped with 2.0.0.a3 yesterday. If they maintain their addons then why not let them continue to declare 3.0?
2. Perhaps add something against bypassing restrictions set by AMO. I know 2 extensions that check for updates on custom servers although there's no updateURL in install.rdf as AMO demands.

Comment 31

[Cameron]

(In reply to comment #30)
> Yes it clearly begins to take shape nicely. 2 thoughts:
> 1. "Creator responsiveness: We expect that add-ons on AMO will be maintained to
> ensure compatibility with new stable/security releases"
> Not that I disagree but it seems inconsistent with the fact that maxVersion was
> capped with 2.0.0.a3 yesterday. If they maintain their addons then why not let
> them continue to declare 3.0?
Maxversion stuff is being tossed around and worked on atm I believe.

> 2. Perhaps add something against bypassing restrictions set by AMO. I know 2
> extensions that check for updates on custom servers although there's no
> updateURL in install.rdf as AMO demands.
Report them. As Shaver said, it's about spirit, not letter.

Comment 32

[Oliver Saier]

Spirit's a fine thing but if I commented about on here it's because I did report one about 3 days ago on IRC and no action has been taken yet, possibly because it's not mentioned in the policy :)

Comment 33

[Mike Shaver (:shaver emeritus)]

Mmm, I didn't notice such a report; my bad.  Mail me the details?  Sorry!

Comment 34

[Mike Shaver (:shaver emeritus)]

(In reply to comment #30)
> Yes it clearly begins to take shape nicely. 2 thoughts:
> 1. "Creator responsiveness: We expect that add-ons on AMO will be maintained to
> ensure compatibility with new stable/security releases"
> Not that I disagree but it seems inconsistent with the fact that maxVersion was
> capped with 2.0.0.a3 yesterday. If they maintain their addons then why not let
> them continue to declare 3.0?

We'll be adding 2.0b1 and 3.0a1 as "hidden" values in a day or two, once we fix some issues on the server side (bug 342998).  They can't declare 3.0 meaningfully, because it's impossible for them to know that their extension will work with 3.0 when a Firefox with that version number ships.  We're going to have the released alphas/betas as public versions, and the next one as "hidden", but I don't want a bunch of old extensions in the field that claim 3.0 compatibility when that day comes.

And though we might well take abandoned extensions off the site, that doesn't help people who have them installed, and should get them disabled upon upgrade. Also, I'm more concerned about authors keeping their extensions working with updates to a stable release they were compatible against than keeping people to predictive promises that we shouldn't be letting them make in the first place. :)

> 2. Perhaps add something against bypassing restrictions set by AMO. I know 2
> extensions that check for updates on custom servers although there's no
> updateURL in install.rdf as AMO demands.

Please report these to umo-reviewer@, or via the IRC channel, or something.  I'll add something about that, though, in the overview section.  (I know of one extension that has a bogus updateURL because it's been in there for ages, and we didn't notice until just before I got sick, but I'm "on that", as I say.)

Comment 35

[James H]

(In reply to comment #29)
> http://wiki.mozilla.org/User:Shaver/AMO_Extension_Policy is what I've been
> slowly concocting, I'm pretty happy with it now, though it needs some
> wordsmithing before it's published and linked from AMO proper.  Comments
> welcome here on on the talk page.
> 

I like it. The things I would like to see different in the listed draft are:

"Categorization") Only allow listing in one category. Pick the most appropriate category to list your extension in.

"Categorization") Add a Multiple Function Category and/or Toolbar category.

"Categorization") Allow site admins to move an extension to a different category if they feel it is improperly listed.

"Rating systems") Allow uses to only rate an extension once. 

"Rating systems")Do not allow ratings/comments to be deleted. Allow the extension author (and only him) to have 1 reply to each rating if he chooses to debate any comment (such as Ebay's feedback system). Only allow a rating/comment to be deleted if "both" the author and the person making the comment agree to it. Ordinary users are smart enough to sift through comments and make an informed decision.

Comment 36

[DonGato]

Just added some comments at the talk page. I'm amazed that this necessity was found more than two years ago and it's still not satisfied. When released it should be mailed to all existing extension/themes developers for acknowledge of the "new" rules.

Comment 37

[Cameron]

(In reply to comment #35)
> "Categorization") Only allow listing in one category. Pick the most appropriate
> category to list your extension in.

I think many add-ons should have more than one tag. eg. del.icio.us clearly belongs in Website integration and Bookmarks.

> "Categorization") Add a Multiple Function Category and/or Toolbar category.

What would go in a "toolbar" category? Anything that ads a toolbar to the browser? How does this category help the user? It doesn't really as far as I can see, unless you combine it with only allowing things to be in one category.. but most conduit toolbars belong in "website integration" too...

> "Categorization") Allow site admins to move an extension to a different
> category if they feel it is improperly listed.

We already can.

> "Rating systems") Allow uses to only rate an extension once. 

Sounds practical.

> "Rating systems")Do not allow ratings/comments to be deleted. Allow the
> extension author (and only him) to have 1 reply to each rating if he chooses to
> debate any comment (such as Ebay's feedback system). Only allow a
> rating/comment to be deleted if "both" the author and the person making the
> comment agree to it. Ordinary users are smart enough to sift through comments
> and make an informed decision.
> 
In remora we expect comments to be separated from reviews, and probably have ratings separated again. We still want to be able to delete comments and reviews which contain foul language, are lies, etc.

Comment 38

[Mike Shaver (:shaver emeritus)]

This isn't really a great place to debate the policy proposals back and forth -- it'll just end up being way too noisy.  Can people use the talk page instead?  Thanks!

Comment 39

[Mike Shaver (:shaver emeritus)]

https://addons.mozilla.org/en-US/firefox/pages/policy ftw.

Comment 40

[Flaky Jake]

I don't see a link on the main page to the policy, where is it?

Should be on there imho https://addons.mozilla.org/en-US/firefox/

Comment 41

[Chris Wood]

I eventually found there's a drop-down menu, it's in there, however IMO it should also be mentioned at https://addons.mozilla.org/en-US/developers/docs/getting-started