Up until now, we’ve had a fairly basic developer agreement that hasn’t changed with the needs of our developers and our service. Today, we’re launching a new agreement that clarifies and protects our developers’ rights and ensures that we can continue to promote add-ons via multiple ways and channels as our service expands.
That’s why we’ve launched an updated developer agreement. For those of you not well versed in legalese, here’s what we did and why we did it:
We had four primary goals in revisiting the language in our agreement with add-on developers:
- 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 language to more clearly define how developers may use the AMI API feature.
Please let us know if you have any questions via the AMO Newsgroup.
Edit: See both versions of the developer agreement here