Implement updated developer agreement flow

VERIFIED FIXED in 5.0.5

Status

addons.mozilla.org Graveyard
Developer Pages
P2
normal
VERIFIED FIXED
9 years ago
2 years ago

People

(Reporter: osunick, Assigned: jbalogh)

Tracking

unspecified
5.0.5
x86
All
Dependency tree / graph

Details

Attachments

(9 attachments, 3 obsolete attachments)

(Reporter)

Description

9 years ago
To roll out the updated developer agreement, we need to make a few changes to the upload/submission flow as well as changes to the listing pages to reflect their licensing.

http://docs.google.com/Doc?id=dds6vwb4_19gwndg5cg&invite=24177104
(Reporter)

Comment 1

9 years ago
Spec has been updated with mocks for implementation in 5.0.5.  I'll also attach the developer agreement text and hi res mocks.
Assignee: neilio → nobody
Summary: Design updated developer agreement flow → Implement updated developer agreement flow
Target Milestone: 5.0.4 → 5.0.5
(Reporter)

Comment 2

9 years ago
Created attachment 370908 [details]
When a user who hasn't agreed to the developer agreement updates their add-on, present this flow.
(Reporter)

Comment 3

9 years ago
Created attachment 370909 [details]
mock for new add-ons
(Reporter)

Comment 4

9 years ago
Created attachment 370910 [details]
How licenses appear on add-on listing pages
(Reporter)

Comment 5

9 years ago
Created attachment 370911 [details]
How licenses appear for individual file versions
(Reporter)

Comment 6

9 years ago
Created attachment 370913 [details]
If a user has already selected a license for an add-on, they can change this version from the file versions screen.
If the user wants their add-on copyrighted, they will select "Other" and put nothing or "Copyright Justin Scott" I suppose?
(Reporter)

Comment 8

9 years ago
Created attachment 370922 [details]
Updated developer agreement
(Reporter)

Comment 9

9 years ago
Justin- correct.  They could just say "All rights reserved" in the other box.
(Reporter)

Comment 10

9 years ago
here's the rationale for the new agreement, if people are curious:

•    To ensure that users have the opportunity to access and understand their
rights to your add-ons.  Access to relevant license agreements was hit or miss
in years past, some developers provided a license agreement and others did not.
 Under our new agreement and registration process, developers will need to
identify and provide a copy of the license agreement that governs use of their
add-on.  We believe this process will provide greater transparency for users
and will help protect developers from unwanted/unauthorized use of their
add-on.
•    To ensure that Mozilla has the rights it needs to provide the add-on
service.  As we continue to promote the service, it’s become clear that the
rights that Mozilla will need are not always identical to the rights that
developers give to individual users (such as the right to distribute an
add-on).   As such, we’ve introduced a license specifically for Mozilla that
will enable us to continue providing and enhancing the add-on delivery service
and that also provides developers with a better idea of how we use their
content and the limitations/boundaries of such use.
•    To ensure that our rights and activities relating to management of the
add-on service are more clearly articulated.  While this point was addressed
briefly in our prior developer agreement (for example, it referred to our right
to re-categorize or change an add-on’s listing), we wanted to make sure that we
have the flexibility needed to address concerns/issues that arise in the future
and to also provide our developers with a more detailed description of how we
currently manage the service. 
•    To more specifically address the AMO API.  We’re delighted that the AMO
API has become a popular feature of the add-on service.  However, along with
this popularity, we’ve experienced some individuals using the feature for
purposes for which it was not designed or intended.  So, we’ve included
(Reporter)

Updated

9 years ago
Blocks: 400996
(Reporter)

Updated

9 years ago
Assignee: nobody → jbalogh
Priority: -- → P2
(Reporter)

Comment 11

9 years ago
Created attachment 373233 [details]
developer agreement (PDF)
(Reporter)

Comment 12

9 years ago
"Please select the appropriate license for your add-on.  This license specifies the rights you grant on your source code."
(Reporter)

Comment 13

9 years ago
Created attachment 374294 [details]
revised 'edit add-on' page
Attachment #370913 - Attachment is obsolete: true
(Assignee)

Comment 14

9 years ago
Created attachment 374648 [details] [diff] [review]
Implementing most of the dev agreement

Here's 1437 lines of love.  But take heart!  600 of those lines are prose or license headers.

The missing pieces are:
server side validation of licenses
links to the page showing a license
link to the license faq

Getting this out now so it's not *quite* as last-minute.
Attachment #374648 - Flags: review?(clouserw)
(Assignee)

Comment 15

9 years ago
Created attachment 374718 [details] [diff] [review]
Implementing even more of the dev agreement

Building on the previous patch, implementing the license link parts.
Attachment #374648 - Attachment is obsolete: true
Attachment #374718 - Flags: review?(clouserw)
Attachment #374648 - Flags: review?(clouserw)
Comment on attachment 374718 [details] [diff] [review]
Implementing even more of the dev agreement

r+ after a couple things we talked about:

- Broken html entities
- missing license.thtml
- add ___() around license names

Things I'd like to see added:
- a "what's this?" link on the version edit page next to the dev agreements
- we'll need to delete all the existing translations of developer_agreement.thtml
- any tests?

And not blocking but something for future reference and consider changing later:
- queries in loops are very bad and has killed us before
- Need to check the return value of save().  You can use transactions.
Attachment #374718 - Flags: review?(clouserw) → review+
Comment on attachment 374718 [details] [diff] [review]
Implementing even more of the dev agreement

...
>+global $licenses;
>+$licenses = array(
>+    'Mozilla Public License, version 1.1' =>
>+      'http://www.mozilla.org/MPL/MPL-1.1.html',
...

The Mozilla Trilicense (MPL/GPL/LGPL) should be added to the list - ie. the same license that source code of Firefox is licensed on. I guess MPL only extension couldn't be integrated with Firefox?
Also, how about adding "GPL2 or later" and "GPL3 or later"?
(Assignee)

Comment 18

9 years ago
r24932, with extra problems moved to bug 490387.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

9 years ago
Created attachment 374844 [details]
db changes for this patch
(Assignee)

Comment 20

9 years ago
Created attachment 374845 [details]
db changes for this patch
Attachment #374844 - Attachment is obsolete: true
Depends on: 490575
OS: Mac OS X → All
Looks like we need an Apache restart to pick up the gettext() changes for <input type="button" value="devcp_uploader_button_agree"?
Depends on: 490584
This is fixed in r25126.  I also added the missing but important "Learn more about open source licenses" link that was in the mockup.

Looking at the page I find the agreement confusing (and I imagine developers will also).  We're asking developers to agree to our new developer agreement in addition to choosing the license of their add-on, two unrelated choices.
Dependent (regression) bugs are fixed, and overall the feature works -- maybe we should revisit Wil's comments in comment 22 at a later date.

Verified FIXED
Status: RESOLVED → VERIFIED

Updated

9 years ago
Depends on: 491209

Updated

9 years ago
Blocks: 491212

Updated

9 years ago
Blocks: 491215

Updated

9 years ago
Blocks: 491908

Updated

9 years ago
Depends on: 446361
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.