Mozilla Add-ons Community Blog
Categories: developers policy

New Developer Agreement

10 responses

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

10 comments on “New Developer Agreement”

  1. Philip Chee wrote on

    Hi,

    My extension is tri-licensed (MPL/GPL/LGPL) but there wasn’t an option for this when I uploaded an update recently so I had to choose “Custom Licence” and then c&p the tri-licence boiler-plate.

    Phil

  2. Michael Kaply wrote on

    Where can we get a copy of the previous agreement? Was this always in there?

    . Mozilla may also (i) bundle and/or package your AMO Contribution with third party add-ons for delivery and promotion of the AMO Contributions to users and (ii) maintain and/or update your AMO Contribution for the purpose of providing compatibility with current and new versions of Firefox or other Mozilla software that the AMO Contribution interoperates with.

  3. nick wrote on

    Michael, the bullet point you included was not always in there. We found that the previous agreement wasn’t clear enough regarding how we help developers promote their add-ons, particularly when we featured add-ons in groups like Fashion Your Firefox.

  4. Jesse Ruderman wrote on

    “if the AMO Contribution is an add-on, such add-on is accompanied by an accessible license that describes the rights of users”

    “Please note that you must include an accessible copy of your license terms with your add-on (such as in a parent directory).”

    I don’t understand this. Am I supposed to toss a copy of the MIT license (for example) into my xpi zip? Expose it through some kind of UI once my extension is installed?

  5. Anonymous wrote on

    As a FOSS developer and a user of Firefox, I greatly appreciate Mozilla requiring license terms for add-ons, so that I can verify the FOSS status of an add-on before installing it.

    Now if only the official add-ons site would stop permitting proprietary add-ons.

  6. nick wrote on

    Jesse,

    AMO stores these license preferences on a per version basis and shows this pref on the Add-on listing page, so there’s no need to include a license file, as we also include links to the text of the license.

  7. malte wrote on

    I also miss an option for MPL/GPL/LGPL. (I’d think that there are more extensions using the tri-license than MPL alone…)
    I’ve just selected MPL for my extensions now, but since the user actually has the right to use it under the terms of the GPL or LGPL 2.0 or higher, I’d prefer to tell them so.

  8. David wrote on

    It would be nice to have a side by side comparison of the old and the new version with all the changes highlighted. I think it’s just a matter of transparency.
    Besides that, I think the changes are good and necessary.

  9. Someone wrote on

    AMO should stop reviewing on the “I’m interested”-base.
    Please start to review on the “first in, first out” base.

  10. Michael Kaply wrote on

    So can Mozilla Corp. take something I produce and use it for any purpose without my permisson? Even producing revenue opportunities?

    And they can modify it without my consent?

    Even if it doesn’t use an open source license?

    That doesn’t seem right.