(Note: this may be true already; I don't have access to the app admin interface. If it is, apologies. But the data is not, as far as I can see, shown on the page about each individual app, and I couldn't see a search option for it.) It's important for users to know what rights they get, or don't get, when they download an app. Users may want to make decisions about which app to choose based in part on that. We should therefore capture that metadata so we can use it as a search criteria (perhaps in some advanced or custom search interface) and so we can display it to users interested in particular apps. We want to promote choice; we need this metadata to allow people to have that choice. Mozilla also believes that "Free and open source software promotes the development of the Internet as a public resource"; we should therefore be keen to allow people to choose such software if they wish. AMO already has a system like this; you can choose between: * Mozilla Public License, version 1.1 * GNU General Public License, version 2.0 * GNU General Public License, version 3.0 * GNU Lesser General Public License, version 2.1 * GNU Lesser General Public License, version 3.0 * MIT/X11 License * BSD License * Other That would be a fine list to start with, although we should replace MPL 1.1 with MPL 2.0 (bug 605423 for AMO) and add Apache 2.0. Gerv
-> product for decision/requirements
Assignee: nobody → dbialer
We do not currently have any license terms entered by the developer for apps. I will say that this may or may not be an issue (not sure yet). Many of the apps are really web apps, and may (or may not) be copyrighted and are not necessarily products with licenses. They may contain code, like JS code, that they may have used to build their product that uses a license. Or it may be on the server side of an app. I do think we may want to offer this as an option to developers and something that can come up via search, though I think the many of the users of apps that are currently targeted may care more about Free vs Paid rather than license terms. I think this is a requested feature enhancement and we should visit this in v2 timeframe as I don't see it as a blocker. How can change the status to feature request and put a target milestone on it?
I marked it as an enhancement. We don't have a bugzilla milestone that corresponds to what you're calling v2 so leaving the milestone blank.
Severity: normal → enhancement
Priority: -- → P5
dbialer: anything which is written is automatically copyrighted; whether that's good or bad, that's what the law says (worldwide; Berne Convention). It's actually quite hard, and in some countries impossible, to have things which are "not copyrighted" before the term expires. Anyway, the point is, the legal default is that "you can't make any copies". Given that people are downloading these apps to their phones, thereby copying them, it seems right that we can tell people about what permits them to do that, and what additional rights they have or don't have. From the non-open-source side, I'm sure some companies will want users to agree to something before allowing a download. Do we have facilities for that? That could be part of the same system. Again, I believe this is something AMO has. I agree that many users care about free vs. paid (and that should be a search option as well) but that doesn't mean that there are no users who care about this. Gerv
Thanks Gervase. I do think this is a useful feature, especially for Firefox's core community. It is also a differentiator as well, and promotes Mozilla values, so I like the idea. I just need to evaluate it in light of current goals (this quarter). This is something we would like to add to the backlog but its not in the P1, P2 category on the schedule we are working on. So when we start planning future releases, this will be a feature request we should evaluate in light of our goals. I appreciate product input - and am working on a system to collect input like yours as that is the only way we can improve it.
I would very much appreciate if I could clearly label my apps as being open (MPL2 in my case). It would even be nice to be able to point people to a source repo, but that's probably a different bug. That said, I already saw us getting some criticism from others in the FLOSS community (on LWN.net comments in this case) because we don't display the license and therefore "show that Mozilla isn't serious about being open any more" (which I know not to be true, but that was the impression it gave).
Duplicate of this bug: 753304
Summary: App authors should be required to specify license → App authors should be able to specify license
dbialer: what's the current status of this feature request? You were positive about it in comment 5, but that was 14 months ago... Gerv
It remains low priority due to: * very low user demand so far (on our feedback forms in the last 12 months, from ~10,000 users, we got 2 or 3 requests) * very low developer demand. It has not been mentioned (AFAIK) in any forum but I don't really track developer forums, so I might not be attuned to these feedback channels. We have not gotten requests by any of the developers that our BD works with to expose the license. This issue, I imagine, would be of higher concern of those developers having restrictive licenses and wish to communicate that. Nobody yet has expressed an interest in this. While probably not difficult to implement, these issues, and the fact that there are so many other priorities that the team is juggling, haven't made this issue rise to the top. Currently developers have the option to put license type in their app description should it be important to communicate this - and link their website (We support a link to a developer website or URL which can be the github repository). They also have the option to put a license file in their app and expose that however they choose. While we don't outright support a method to surface a license file, so that a user may view it before they download, there are ways that developers who wish to share their code may do that and call attention to that. We are doing a lot of developer submission testing and research this quarter. I have asked to have this tested so we can gauge developer opinion on this - or optionally see if this is something they wish to add.
dialer, it looks like communications including a request like this seem to go through other channels than the ones you see, as I have heard it a few times from different people and I'm not in the Marketplace team (but I have a number of connections to Free and Open Source Software developers and groups and I heard those requests in that community as well as from other Mozillians). (In reply to David Bialer [:dbialer] from comment #9) > Currently developers have the option to put license type in their app > description should it be important to communicate this How many are doing that? FWIW, I mostly expect apps with open licenses to do that, and rarely proprietary ones. Usually open licenses are considered a feature, while proprietary ones tend to be hidden unless required by law. > We are doing a lot of developer submission testing and research this > quarter. I have asked to have this tested so we can gauge developer opinion > on this - or optionally see if this is something they wish to add. Thanks, will be interesting to hear the outcome of this!
I think we are going to investigate the github style license selector or upload your own. We are doing improvements to the app details page and will see if we can include this.
(In reply to David Bialer [:dbialer] from comment #9) > It remains low priority due to: > * very low user demand so far (on our feedback forms in the last 12 months, > from ~10,000 users, we got 2 or 3 requests) At least in the Android case, an entire alternative market (F-Droid) was developed basically because the Google Market/Play Store didn't offer the ability to filter by whether an app was open source or not. > * very low developer demand. It's less immediately important for developers. If a user wants to only run Free software, they are the ones who have to do the work of ploughing through all the listings manually looking for one which has a textual annotation denoting its freeness. So it's a user burden we are alleviating. > Currently developers have the option to put license type in their app > description should it be important to communicate this The problem with that is that it's not structured data - it's not searchable. > app and expose that however they choose. While we don't outright support a > method to surface a license file, so that a user may view it before they > download, there are ways that developers who wish to share their code may do > that and call attention to that. The use case of having to view a license file is normally required only by developers of proprietary apps; that may be something other people want to argue for, but I'm not interested in it :-) > We are doing a lot of developer submission testing and research this > quarter. I have asked to have this tested so we can gauge developer opinion > on this - or optionally see if this is something they wish to add. As noted above, this is a feature for user benefit, not developer benefit. > I think we are going to investigate the github style license selector or upload your own. We aren't a code-hosting site. It could be that some people come to publish on the market without having chosen a license, but I think most people will already have chosen one. Let's not let the additional effort of designing a Github-style selector deflect us from the simpler goal of simply having one structured data dropdown field that developers must choose from, which says something like: Source Code License : ["Proprietary", "BSD", "MIT", "Apache 2", "MPL 2", "LGPL", "GPL", "AGPL", ..., "Other Open Source"] It's OK for Proprietary to be the default. Gerv
There is no plan to add search by license type as a generally available major search feature. Currently, as evidenced in our logs and feedback, there is very low demand for this by end users of the Marketplace. We have had 1 request for this in marketplace feedback forms (several thousand forms that I read and keep track of feature requests) and, over all time, 29 searches for a license (license, gpl, mpl, apl, lgpl, etc) out of several million searches. In all our user research, license has never come up (nor have we asked). It simply does not track as something that there is end user demand for. Users who are interested in license type may view an optional license. Note that this feature is not committed yet. We would measure the usage of this feature, and if it is a high-interest feature, then we would consider it in search. Marketplace has sort-of hidden search features for power users. It is possible that we may be able to index the license type for "Potatosearch" (if you go to the search bar in MP and do :help, you will see what this is). This could be a way to address power users who care about license - but we shall have to see. While I understand that some people (such as yourself) may take into consideration the license type when deciding to install an app, there is no evidence that searching by license is something that most end users of the Marketplace care to do. We need to be careful not to add features that impact usability and performance for all users without significant measurable benefits.
How many searches were there for "open source", "software livre", "software libre", "libre" or other translations of Free Software? https://www.gnu.org/philosophy/fs-translations.html Providing _any_ mechanism would be a great step forward - so let's look at whether we can get "potatosearch" to support it. Then other sites can link to the searches directly, even if we don't provide simple UI for it. The Mozilla Manifesto says: "7. Free and open source software promotes the development of the Internet as a public resource. 8. Transparent community-based processes promote participation, accountability, and trust." Mozilla is in favour of open source software, and a chunk of our contributor base are too. People who want to run only open source are people who help us, and are a constituency we should in turn help. Currently, Firefox OS's target market is a different market to our contributors, so I'm not surprised demand for this is lower there. But I am arguing for this on the basis that it's the right thing for Mozilla to do given our principles. Gerv
I think that out of our spirit, and not primarily out of developer or majority-of-end-user demand, we should highlight free, libre and open source software (FLOSS) on our Marketplace (as well as on AMO). I'm all for listing both open and proprietary software on the Marketplace, but we should 1) highlight FLOSS and 2) enable users that want to keep proprietary software off their devices to exclude it from their listing and only show FLOSS.
Highlighting free software is a different conversation for another day; what I want to focus on here is giving people the tools they need to solve their own problems. The minimum necessary for that is a metadata field holding the license (there is now a bug about that) and some mechanism for searching on it, which could well be "potatosearch". Let's get those two things in place, and then see where we are. Gerv
(In reply to Gervase Markham [:gerv] from comment #14) > How many searches were there for "open source", "software livre", "software > libre", "libre" or other translations of Free Software? > https://www.gnu.org/philosophy/fs-translations.html There have been 44 searches out of over 2 million searches for open software including the translations + 29 searches on specific license types. Most searches in the Marketplace are for specific apps or categorical like 'games' or 'antivirus'.
There is little demand for this that warrants a user-facing interface. Can put in app description if desired.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(In reply to Gervase Markham [:gerv] from comment #16) > Highlighting free software is a different conversation for another day; what > I want to focus on here is giving people the tools they need to solve their > own problems. The minimum necessary for that is a metadata field holding the > license (there is now a bug about that) and some mechanism for searching on > it, which could well be "potatosearch". Let's get those two things in place, > and then see where we are. Yes please.
i reset assignee to default you marked it as wontfix, you're not writing code atm or working on it
Assignee: dbialer → nobody
David Bialer, Please re-open the bug - I'm interested in working on it and finding a solution which doesn't clutter the interface but does provide this functionality to interested users.
It is unlikely to get addressed as a Marketplace priority in the short term. Currently about 24 apps (less that .5%) specify their license. It is not of interest to most developers or users - nor do we want extra steps and more material required during the submission process. Developers who are interested in specifying their license can have links from their app description (for instance https://marketplace.firefox.com/app/connecta2) and users have access to this information. Other developers provide information on their website or source repository (which we allow a link to) in the developer website field. Frankly, there is low demand to expose this feature as a separate mandatory field to developers or users from using apps that has are created under their preferred license types.
(In reply to David Bialer [:dbialer] from comment #22) > Developers who are > interested in specifying their license can have links from their app > description (for instance https://marketplace.firefox.com/app/connecta2) and > users have access to this information. This is not searcheable. If I'm concerned about only installing 100% free apps, do I type names of all free licenses into the search box one by one? > Other developers provide information > on their website or source repository (which we allow a link to) in the > developer website field. This is not searcheable at all. > Frankly, there is low demand to expose this feature as a separate mandatory > field to developers or users from using apps that has are created under > their preferred license types. I didn't say /mandatory/, if course. For some people it is important to /be able to know/ the license in the first place: https://www.gnu.org/philosophy/free-sw.html, and doing so should not involve manual work. Otherwise you're working against the said freedom. I guess I will need to draw some mockups in order for us to agree how to add this in without confusing people or cluttering the interface. I will do so in my next comment, if necessary (I would be happy to write a patch instead, but that's more time consuming where a design question is due.)
For tracking purposes - A user in the SUMO forums is asking about this feature: https://support.mozilla.org/en-US/questions/1036753
Quoting Enrico Zini: 「This made me sad. My view, which didn't seem to be considered in that discussion, is that people concerned about software freedom and security are likely to stay the hell away from such an app market and its feedback forms. Also, that thread made me so sad about the state of that developer community that I seriously do not feel like investing energy into going through the hoops of getting an account in their bugtracker to point this out.」 Source: http://www.enricozini.org/2015/mozilla-facepalm/ I can only agree. I did not even *know* Mozilla had such a thing, and I would not even consider it using. I’m still cursing about two Firefox extensions not being packaged in Debian, so I have to manually add them each time… I’d *really* prefer everything to be cleanly packaged and OSS. Please reconsider the WONTFIX. For a migration strategy, automatically setting all currently existing entries to “proprietary” licence would be okay.
I have to concur with Gerv's and Thorsten's sentiments throughout. I think that to the extent there is no demand for this feature, Mozilla should be actively working to *create* demand for it via user and developer education -- starting with requiring license information from developers, and exposing that in the purchasing interface, as requested in this bug. (And the same should be done for add-ons.)
Please reconsider the WONTFIX, this feature is sorely needed.
Speaking as both a developer and user, I'd like for the licenses to be clearly documented. It's inconvenient to have to track it down otherwise.
dbialer, the above suggests that you may want to re-open this bug report. Please take a look.
F-droid exits because the demand existed for Android. Why would it be different for FOS developers and users? I guess that people interested only on free software in the marketplace silently waste their time searching for the license as I do. That doesn't mean that there is no demand.
There seems to be enough demand to reopen this bug. This would be a good first bug with a mentor. I will write a a PRD and post it here when it is complete.
Assignee: nobody → dbialer
Status: RESOLVED → REOPENED
Priority: P5 → P3
Resolution: WONTFIX → ---
Whiteboard: [goodfirstbug] [mentor=?]
Hi Andy, Can I work on this ?
Yes, please assign it to yourself. Feel free to ping me on irc (andym) or email me and I'll be happy to help any way I can.
Hi Andy / David, Can you please assign me to this bug, I can not do it myself. Andy, I have experience of fixing Gaia bugs only till now, excited to fix first Marketplace bug. Can you please give me initial direction ? like where to start from, exactly what all things are to be done here and useful links etc. I will analyze this from my side also. Thanks - Ram
Assignee: dbialer → vaishnav.rd
Status: REOPENED → ASSIGNED
I created this design brief open for comments. https://docs.google.com/document/d/1SmrZptuscCbCTwedRsmakx0UA92tN2ZLBQx1t35yFBw/edit?usp=sharing Note this is not a specification, just a guide for the UX team to develop the user experience (both for developers and end users).
(In reply to David Bialer [:dbialer] from comment #37) > The license type will be a tag that is searchable. We are planning to do > more with tags in the future. These tags will be a searchable field. So a > search of "GPL" or "Open Source" should display the list of apps fitting > this description. I would avoid using tags for this, especially if we have a finite set of licenses for a user to choose from. I would vote to create a new field where we store which license was chosen (including an "Other" or "Custom" option). From there we could add that field to our search index and filter by it also.
“Other” and “Custom” is unclear. I’d suggest “Other OSS/Free” and “Non-OSS/Proprietary”. I think the split is important, there are several smaller BSD-ish licences around that are not that popular in general (especially as they’re not copyleft) but strong within their communities, for example.
David, Thanks for taking this up :-) I've added some comments to the doc. > This should be optional as many of the apps are simply a website URL, not downloadable. Rather than allowing a "None" option, we should have a "App is not downloadable to device" option, which makes the situation clear. The danger of using tags is that it may be non-trivial to get a list of all the tags which are licenses (or do you have tag categories)? So it wouldn't be easy to programmaticlly determine the license of an app in all cases. It would probably be good to add an "open source" tag to all apps which have an open source license, but I would still suggest storing the license identifier in a separate field on the back end. Gerv
(In reply to Gervase Markham [:gerv] from comment #41) > > This should be optional as many of the apps are simply a website URL, not downloadable. > > Rather than allowing a "None" option, we should have a "App is not > downloadable to device" option, which makes the situation clear. A website has some kind of license as well. That can be a free/open one or a proprietary one or straight copyright (which legally might not even work as you are actually making a copy to your device and running the code locally, so you probably need some kind of license to do that). So I would not give "None" as an option but rather "Default copyright" or something like that.
(In reply to Gervase Markham [:gerv] from comment #41) > David, > > Thanks for taking this up :-) I've added some comments to the doc. > > > This should be optional as many of the apps are simply a website URL, not downloadable. > > Rather than allowing a "None" option, we should have a "App is not > downloadable to device" option, which makes the situation clear. I think this is valid (Look at your own website as an example). > > The danger of using tags is that it may be non-trivial to get a list of all > the tags which are licenses (or do you have tag categories)? So it wouldn't > be easy to programmaticlly determine the license of an app in all cases. It > would probably be good to add an "open source" tag to all apps which have an > open source license, but I would still suggest storing the license > identifier in a separate field on the back end. > > Gerv I think you are right in your suggestion. I think having the "open source" tag as well as specific license types (and storing as an identifier) is probably the right approach, but will wait for our UX/Eng team to advise.
Who will make the final call on this? Also, please provide guidance to Ram re: qualifications needed to take on this bug, and where to get started.
Removing "goodfirstbug" tag as this does not meet the criteria: https://wiki.mozilla.org/Contribute/Coding/Mentoring#Good_First_Bugs
Assignee: vaishnav.rd → dbialer
Status: ASSIGNED → NEW
> I think having the "open source" tag as well as specific license types > (and storing as an identifier) is probably the right approach, > but will wait for our UX/Eng team to advise. Ta; please consider naming it "free" (in this case the term "gratis" may be used to mean free of charge for market stuff) or "libre" in the implementation. ( per http://www.gnu.org/philosophy/open-source-misses-the-point.html ).
Why was this assigned to "nobody" again?
Amy, because nobody is working on it anymore. - dbialer is only the person who committed to closing and reopening the bug, but he did not start working on its implementation. - another person was unassigned because this was considered a bad first bug due to lack of spec.
Status: NEW → RESOLVED
Last Resolved: 5 years ago → 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.