On Friday, June 19, 2015 at 9:39:55 PM UTC-5, Ryan Kelly wrote: > I don't have any deep thoughts on what the Pocket(TM) Terms of Service > do or do not define. I'm sure there are things downstream of ToS > agreement that it would be great to get clarification on. > > My question is simply: by what mechanism would these ToS come to apply > to a user just because they have installed Firefox?
I tried to touch on some of the problems for users/developers in my recently reply to Fred Wenzel. But I will try to go into more details. Mozilla Foundation's position seems to be based on being able to disable the Pocket from the bar is enough to keep it from ever transmitting data to Pocket. I am more than willing to admit that seems to be the behavior of the current integration. However, lets say, just for the sake of argument, that Pocket decides it want a web site popularity/rank feature. Something similar to Google PageRank or Alexa add-ons. As part of this (again for the sake of argument), the Pocket integration links into the http/https submissions such a log of websites visited is periodically compressed and transmitted to Pocket. I'm not claiming I have proof Pocket intends to do this. What I am claiming is the current Terms of Service give themselves the permission to add this type of behavior even if the user never clicks on the Pocket icon and disables the icon from the bar. I also am claiming there is little transparency into what Pocket is planning for the future of this integration. The full functionality of the "/v3/firefox/*" namespace or even the full set of options available as part of "/v3/firefox/save" are not documented. According to a reply from Pocket, that is not by accident but by design that it is private. Even worse, the Firefox user is expected to visit Pocket's Privacy Policy every 30 days to see if it has been updated to discover what new provisions may apply to the data collected. Compare this situation with "Reconciling Mozilla's Mission and W3C EME." Here, the EME's API is clearly documented and not only the behavior of the current EME code but all future EME code are sandboxed such that transmitting logs back can not take place. As such, if for example Adobe is providing the EME, the user does not need to check Adobe to see what their privacy policy is since the EME will not collected any information. If the Terms of Service was based on *use* instead of claiming rights due to being *installed* then Pocket wouldn't be entitled to anything until the user uses Pocket. If it is Mozilla's position that disabling Pocket is sufficient, then just like with the EME sandbox, this position should protect the rights of the user not only for the current version of Firefox but for all future versions. The user shouldn't have to worry about current and future Pocket privacy policies when they don't make use of the feature even if the data is being stored in aggregate. > If "the ToS themselves say that they apply" is all it takes, then AFAICT > we've discovered a meta-circular licensing mechanism of unprecedented > virality, strong enough to override the pretty clear open-source > licensing applied to the code you claim will trigger it. There is a couple ways in which the Pocket integration is able to apply the *letter* of an open source license while possibly not following the *spirit* of open source. According to the Open Source definition item #6, commercial use must be allowed. Currently, the only servers that support the Pocket integration protocol used by Firefox is under a Terms of Service that prohibits commercial use. Unless another pro-commercial server is made available, the code is not practical for commercial use despite being "open source." So, that brings me to my next point, can there be a pocket-protocol clone server under different terms? This is the area where a statement of intent from Pocket would go a long long way. Under the current situation, the only way to clone Firefox's use of the private/undocumented "/v3/firefox/save" call is to first figure it out. Based on the case of Oracle v. Google, even when an implementation is open source does not make the API open for use outside the scope of that implementation. So, the open source section of Firefox provides the scope of the API call for client use. And reading/modifying the code in the context of a client is clearly intended use of the open source contribution. However, a jury may still find that reading the code for purposes of writing a server which honors the private "/v3/firefox/save" call constitutes an act of prohibited reverse-engineering of Pocket's intellectual property. Further, Blizzard v BNETD shows that even monitoring the network to figure out the protocol may also be prohibited reverse-engineering. If Pocket has no intention of taking legal action for creating third party servers which honor the private "/v3/firefox/*" namespace of calls then they lose nothing by providing clarification of that fact. Otherwise, there is a chilling legal environment where "/v3/firefox/save" could be considered a vendor lock-in giving Pocket a monopoly on Firefox's use of the protocol. Under such a lock-in, the only server used by the code again prohibits the commercial use that OSD #6 required. > > That is good to know. Is there anyplace as part of Mozilla's effort to be > > transparent where Mozilla's lawyers provide the details or synopsis of the > > Terms of Service documents the reviewed? > > > > Also, how does Mozilla lawyers take into account the impact of a new > > currently unpublished Privacy Policy that goes into effect 30 days after > > publication? Are they continually monitoring and reviewing the documents > > as they are updated? Are they able to always accomplish a full review in > > less than 30 days? What is Mozilla's stated policy/method for giving > > notice to the impacted users when a change no longer adheres to Mozilla's > > mission? > > And just to be clear, I'm not ignoring the rest of the questions you > asked in your reply - I just won't pretend I'm able to speak to them > with any semblance of authority. I understand--thank you for specifying you aren't ignoring them. I wasn't expecting you specifically would be able to but rather you might be able to get the right person involved in this thread. Ultimately, clarification really needs to come from Pocket and they are probably the only ones that can clear up my issues of install-time activation of the ToS and use of private/undocumented API calls. If those two things were addressed, I would feel much more comfortable than I do now about this integration. _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
