Docs: Create app review guide #3391
Conversation
Kinda a preliminary take on this.
|
This may not be something to get into immediately, but I've noticed a certain tendency for apps on sandboxed platforms (note: this may be opposite of the causality that phrase implies) to do whatever the system technically permits them to do, as opposed to "traditional" desktop-OS applications where there's nothing stopping them from misbehaving except their reputation. Insofar as this is a concern I'd suggest calling out such misbehaviors as:
|
|
@kpreid Yeah, I touched on overly broad permissions in this PR. It's impossible for the Sandstorm platform itself to both enable all types of applications and also prevent overly broad requests, because what's reasonable for a given app is wildly different. (Many Sandstorm apps might need access to only one pre-defined domain to function such as a Gmail exporter connecting to Gmail, whereas TTRSS requires close-to-arbitrary levels of access for it's main functionality.) I think defining an app review policy is key to ensuring that we human-curate apps that need the former requesting the latter. And the Sandstorm App Market should only provide apps which behave well. (Re: copy configuration data example, this is interesting because you might in that case want to revoke Powerbox capabilities you've already granted, which Sandstorm does not yet support in the UI. The safest bet here might be to extract data from a backup, although even that, Sandstorm essentially currently requires you to open the app to access that UI button as well.) |
There was a problem hiding this comment.
Some comments inline. Also:
Apps which require raw IP networking (@zenhack's IRC Bouncer) probably should not be accepted, as they require you be a server admin, rather than an ordinary user, and raw IP networking is too broad a capability.
I think ultimately what I'd like to do here is:
- Make it so the platform can fulfill requests for TcpPort, so an app like this could just request one host/port, rather than the whole internet.
- Implement the ability to request permissions from an admin.
- Have some way of marking apps as needing privileged caps
Once all that's in place, I think such apps should be allowed, provided that their use case really requires it, but we may reject an app for requesting permissions it shouldn't need, even if it would require some re-architecting to fix.
| make it suitably clear to a user why it needs certain outside network access | ||
| prior to requesting it. | ||
|
|
||
| ## Commercial or proprietary apps |
There was a problem hiding this comment.
I think what to put here is going to be a larger discussion. some thoughts below, but maybe for a first pass we should cut this and merge the uncontroversial bits.
I think there are a couple things we need to sort out before we're really ready to accept proprietary apps:
-
Copyleft compliance. These apps are almost always going to be bundled with GPL and LGPL binaries, which require both (1) distribution of source code and (2) the ability to swap in a modified version of the code.
We're probably not really compliant with (1) right now even; technically we ought to be shipping the source for all of the distro packages included in the .spk. I'd like to address that at some point, but the docker world is similarly sloppy about this, and as long as we're complying with the "spirit" (it's easy enough for users to get the source, even if we're not mirroring it), I don't think we need to stop the presses. But we should work towards doing that by the book.
But when we start throwing proprietary code in the mix that makes me nervous, because then if we're not doing this right we're really running afoul of the spirit of the license and are more likely to run into trouble. Furthermore the tooling doesn't really make (2) easy except by re-building the app from source, so we need a clear story re: how a user is supposed to go about doing that if they don't have the source.
-
Licensing policy. If we're allowing "proprietary apps" we probably still need to set some bounds on what kinds of licenses are acceptable. At a minimum the license has to be consistent with the way the app market works and our other policies. I'd really want some lawyers' eyes on this...
Additionally, I really don't like the idea of apps that you can download from the app market that then immediately say "enter license key;" I think if something is not going to work out of the box (for whatever reason) it really needs to be clearly delineated. I also don't want to spend precious developer resources making it easier to build apps with DRM.
I'd prefer most apps (regardless of license) don't do that in the first place, and I think if we're going to spend brain cycles on it at all someone who actually wants it should be paying us. My inclination in the meantime is to just
make it clear that we don't really have a great story there, feel free to come talk to us if you want help figuring stuff out.
There was a problem hiding this comment.
We accepted draw.io when it was proprietary, so while we don't have one now, I would say "we already started" accepting proprietary apps.
Copyleft is interesting because in addition to your point, it's very plausible a given Sandstorm app package might have dependencies carrying a scattering of different licenses. I think we've had one or two questions about how to mark a given app's license if it might depend on code with other licenses. I think we (and other containerized platforms) have to look a layer deeper for compliance: If you open up the SPK, the proprietary app is using the open source bits that you can already easily get elsewhere. As long as the proprietary app isn't making closed source modifications to those open source parts, they should be okay.
With licensing policy, I feel like our solution of "recognize acceptable open source licenses, you're on your own outside of that" is fine: We're not responsible for enforcing someone else's license. Things like site licenses should have no problem with allowing "anyone on this Sandstorm server" even to use an app. But most sophisticated licensing schemes don't actually have strong enforcement in the code: They rely on the legal issue your business would be in if found outside of compliance. For instance, Microsoft CALs (required to cover all users of the software) aren't even entered into the software, you just have to have them.
Regarding the "enter license key", the recent Apple App Store/Hey debacle is a good example, but many apps on app stores require login to work, such as Netflix and the like. I think a good expectation here might be that your paid app should ideally offer some minimal/demo functionality if possible, with the ability to unlock full functionality.
I would agree that we probably shouldn't be heavily investing in supporting DRM, in-app purchases, etc., which is why I feel it's probably worthwhile to just go ahead and say "you're able to do this, but you have to code it yourself". And that last sentence or so was definitely suggest people ask us before working on this to see if it'd even fly with the community.
I am alright with cutting this section and/or cutting it back to just the part about talking with the community before trying it, but this PR was in part to provide a good place to have some of this conversation more formally than the occasional chats, so I don't want to do so immediately.
There was a problem hiding this comment.
(As an aside, sandstorm-io/vagrant-spk#249 may be particularly helpful in letting people identify the open source components and the exact source of such included in a given SPK.)
There was a problem hiding this comment.
Regarding the ability to swap in a modified version of the code, there's nothing in an SPK preventing you from unpacking it, swapping out some files, and repacking it, other than that you'd need to swap the appId, right? To me, that would mean we're meeting the requirement, as long as the proprietary app isn't modifying the open source components pulled in by packing the SPK.
There was a problem hiding this comment.
I suppose a process of unpacking the spk, pulling out the relevant bits, and repacking might be acceptable, but ideally someone shouldn't have to basically reverse-engineer the contents of the package to figure out how to swap something like that out. Lack of instructions may run afoul of GPLv3's rules around "Installation Information," though I'm uncertain.
Maybe what we could recommend is to basically publish a repo with build scripts (vagrant-spk and such) but that may pull in binaries of the app proper (or ask you to supply them) and bundle them with stuff from the distro.
My feeling is that the broad-strokes version of this section should be something like "We're not opposed to proprietary apps, but bear in mind they haven't been our focus, you'll probably have to roll some stuff yourself, and here some issues to think about (including some of the stuff around license compliance). Come talk to us if you're unsure about something." I'd be in favor of cutting the specific recommendations about licensing servers; my preference would be to wait for folks to come to us with questions about how that should work and see what the common concerns actually are. We may end up having to put a thing in there at some point that says something to the effect of "ultimately Sandstorm favors user autonomy over developer control. We recognize this limits technical options for enforcing licensing, but you'll have to live with that."
There was a problem hiding this comment.
Would it help if we added vagrant-spk unpack? (spk unpack is already a thing, but we run into that whole packaging tool confusion nightmare.) I think having a proprietary app publish a "source" repository that doesn't really include the app's source is just going to add confusion.
I suppose I should look at the GPLv3's rules around installation information though, so I can have an informed thought on it.
There was a problem hiding this comment.
So, I am reading https://en.wikipedia.org/wiki/GNU_General_Public_License#Communicating_and_bundling_with_non-GPL_programs and I would definitely say that an SPK is an "aggregate" rather than a single program. It is an unpackable partial operating system, and contains many various programs which use things such as pipes and arguments to communicate. (I think adding a vagrant-spk unpack would be good to ensure someone can unpack/pack with the same tool.)
How would you feel about a line/section that specified that developers are responsible for ensuring their packages do not run afoul of copyleft or any other open source licensing terms and that we will de-list a package reported as in violation of open source licenses?
|
Re: Bouncer/IpNetwork/TCPort/etc. yeah, I know we've discussed that before. It may be, in that we have no apps using the overly broad IpNetwork currently supported, proposed for the market, etc., that we don't add any mention of it, and let that be covered by existing text of disallowing overly broad permissions. |
|
My second commit fixes some grammar and language use. I also added a note about verifying updates were pushed to the source repository, which is a common gotcha for app updates. I added a note about the client-side loading issue that I hope addresses Ian's comment there. And finally, I added the suggestion that a paid/licensed app should have at least some limited or trial functionality out of the box. |
|
Quoting Jacob Weisz (2020-07-22 13:41:12)
How would you feel about a line/section that specified that developers
are responsible for ensuring their packages do not run afoul of
copyleft or any other open source licensing terms and that we will
de-list a package reported as in violation of open source licenses?
This seems like roughly the right approach, though if the app is
distributed through the market it means we should have sources on-hand
for anything GPL-ish whose license requires it. This is true *now* even
of the packages we're distributing as-is, but per the above for
proprietary apps I want to be extra careful about doing this by the
book.
Frankly, while I'm not opposed to proprietary software in the app market
in principle, I don't think our act is sufficiently together to manage
it right now.
Probably to do this correctly we need some way for developers to also
submit required source packages for any copyleft binaries in their spks,
as we can't legally distribute the binaries if we're not also
distributing the source.
|
I feel like having a methodology/requirement to distribute source for unmodified Debian packages because they're pulled in by vagrant-spk would be sort of extreme, regardless of if the package is open source or not. https://www.gnu.org/licenses/quick-guide-gplv3.html also has an interesting note here, under "Less Source to Distribute: New System Libraries Exception" essentially suggesting most things pulled in from the Debian repository probably need not be included if unmodified (at least for GPLv3). I feel like this very likely covers "all software included in an SPK that isn't in someone's source repo" for our existing apps. (Linux itself is GPLv2, but apparently one of Torvalds' chief complaints is actually somewhat ironically regarding v3's prohibition of use in DRM?) Many parts of the Linux operating system use more permissive licenses than the GPLv3, and at the least, this provision in GPLv3 strongly supports the idea that we're compliant with the spirit of the license at minimum. Furthermore, the app developer is allowed to provide a written offer to provide the source on request, so I am not sure we are beholden (by the GPLv3, at least), to maintain a copy of the source of packages people distribute through the market. I think our obligation lies at removal of copyright/left violators, not directly verifying license compliance ourselves. I do feel like the end of this discussion will probably be "we can drop this section until someone actually asks about doing it", but I will still probably try to do a little better at this paragraph in my next pass. |
|
Maybe you're right re: the system library thing. Fwiw, the Llinux kernel is probably irrelevant, since spks aren't going to include a kernel (though there may be other gpl2-only packages). |
Yeah, I'm aware the kernel's not included, but I figured it was worth noting that perspective on a very large part of the Linux platform. The system library thing of course, only officially covers the way we build SPKs fully for GPLv3 licensed packages, but I think it means we are probably very far from running afoul of open source folks as long as we're predominantly just grabbing a bunch of Debian packages. Many things installed outside of Debian packages are explicitly downloaded by build scripts (such as when we explicitly install MySQL so Debian doesn't install MariaDB or the Node installers) but by the very nature of the build scripts, we are providing links to where to get them, where source is generally available as well. Though I suppose I haven't checked: Are vagrant-spk build/setup scripts actually included in SPKs? If so, the unpack->swap some files->pack method should work, but if not, that'd be a potential problem. I think ultimately at some point we should probably have a statement on the position of how we feel licenses apply to components of SPKs (as it's come up in conversation numerous times before) with references, irrespective of the proprietary/open package debate. |
|
Quoting Jacob Weisz (2020-07-22 17:01:54)
Though I suppose I haven't checked: Are vagrant-spk build/setup scripts
actually included in SPKs? If so, the unpack->swap some files->pack
method should work, but if not, that'd be a potential problem.
They are not. I would be satisfied with having the build scripts on
hand.
|
|
Okay, third pass might be getting close, I think. I dropped the discussion of licensing strategies, and added a section about SPK open source license compliance. I felt like it was valuable to put the system libraries exception there, but I wanted to make it clear that it's a developer's responsibility to ensure they are compliant (not ours), and that proprietary apps might wish to consult a lawyer before assuming they're in the clear. |
| Sandstorm package files (or SPKs) are an archive format which includes a variety of | ||
| components needed to run a given application. Often the process of building an SPK pulls | ||
| in components and libraries from open source distributions such as Debian. We believe | ||
| these fall comfortably within the GPLv3's [system libraries exception](https://www.gnu.org/licenses/quick-guide-gplv3.html#less-source-to-distribute-new-system-libraries-exception) and falls well within the spirit of most open source licensing models. |
There was a problem hiding this comment.
I don't think the system libraries exception applies here. The system libraries exception says GPL'd programs are allowed to link against proprietary libraries that any user of the platform is expected to have anyway. That's not what's happening here, though... the spk is bundling its own copies of libraries that the user may or may not have -- after all, the user might not be running Debian.
However, I don't think the system libraries exception is important here. In real life, if you distribute an spk containing Debian libraries, you satisfy the source code redistribution requirements by pointing at Debian's source repositories. Nobody really expects that the developer of a Debian-based container should be required to mirror the Debian source repo.
I don't remember to what extent the GPL is explicit about that vs. it just being unwritten rules of reasonableness...
There was a problem hiding this comment.
My read on "For example, it now also includes the standard libraries of common programming languages such as Python and Ruby." (which I would argue most software users don't, by default, have in their OS) means that if it's trivial to find and acquire the source of commonly-known packages, we need not include the source for them.
I think I was most interested in how this would apply to proprietary packages, where perhaps the build scripts aren't posted anywhere (as was the case with draw.io before it went open source). But presumably I think the requirements may be satisfied if there are no modifications to the open source binaries, and those are commonly well-known components you can find the source for online. Though as discussed above, I think we probably need to better support unpacking and repacking, such that you could swap out the open source components of a proprietary SPK and repack it (with a different app key, of course).
There was a problem hiding this comment.
I think the point about Python and Ruby is that the the user of a Python program likely has to install Python first. A person distributing a Python script, then, is not required to provide the complete source code for Python. Python itself is effectively "the OS" here.
|
|
||
| Open source Sandstorm packages generally provide all of the information necessary to modify | ||
| and recreate them, including where to get any other components required to build the SPK, | ||
| however, proprietary apps may need to seek legal counsel on what requirements are needed |
There was a problem hiding this comment.
Hmm reading this paragraph I wonder if you were interpreting the system libraries exception backwards? The system libraries exception is about GPL apps built on top of proprietary platforms, not proprietary apps built on GPL platforms.
Proprietary apps definitely can't use GPL libraries at all. Most common Linux system libraries are LGPL or permissively licensed. Anyway, I'm not sure if we should be advising people on implications of GPL here...
There was a problem hiding this comment.
I don't see how the section I linked can be read the way you seem to be reading it. Python and Ruby are both open source, for instance, and have now been included in the system libraries exception. Furthermore, "The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries" suggests that GPLv3 adds the clarification it can also be read the way you are reading it.
That being said, I think we can remove any guidance on licensing to reach a final state for this PR. Do you feel the "may need to seek legal counsel" line should be left with regards to proprietary apps on Sandstorm? Ian had suggested he wasn't sure a proprietary SPK was possible if it was grabbing from Linux packages as well.
There was a problem hiding this comment.
Python and Ruby are both open source, for instance, and have now been included in the system libraries exception.
They chose confusing examples here. What they are saying is: "If you distribute a GPL'd Python script, you are not required to distribute the complete source code of Python, even though the GPL normally requires you to produce code for all underlying libraries you use." This has nothing to do with Python's license. Probably a better example language would have been, say, Matlab.
There is definitely no exception that allows GPL'd libraries that happen to be distributed as part of an operating system to be used by proprietary applications.
Do you feel the "may need to seek legal counsel" line should be left with regards to proprietary apps on Sandstorm?
I think I would just say: Sandstorm app packages normally include all of an app's userspace dependencies, which typically includes many third-party libraries. App developers are responsible for complying with the licenses of all libraries that are included in their app package.
Ian had suggested he wasn't sure a proprietary SPK was possible if it was grabbing from Linux packages as well.
All essential Linux system libraries are licensed in such a way that proprietary apps can use them. E.g. glibc is LGPL. So I don't see why a proprietary SPK would be a problem, as long as it restrict itself to LGPL or more-permissive dependencies.
The LGPL does require that proprietary apps using the library make it possible for users to relink the app against a modified version of the underlying library. This is easily satisfied by dynamic linking. A proprietary app that statically links against glibc would be problematic, though.
There was a problem hiding this comment.
I think I would just say: Sandstorm app packages normally include all of an app's userspace dependencies, which typically includes many third-party libraries. App developers are responsible for complying with the licenses of all libraries that are included in their app package.
This sounds good to me; I think we should basically leave it at that and avoid giving any further advice re: licensing.
|
Aside from my two comments, looks pretty good. |
| functionality such as a trial or limited version, such that users can experience the | ||
| app before deciding on a purchase. As this is a territory the Sandstorm app review | ||
| team hasn't spent a lot of time on, interested parties may wish to reach out to the | ||
| Sandstorm community for feedback prior to committing significant work here. |
There was a problem hiding this comment.
So I'm still unhappy with this section. I'm not as worried from a legal perspective if we just keep it to the blurb @kentonv outlined below. But I think it tries too hard to accommodate anticipated industry expectations around DRM that nobody's even asked us about yet. I don't think we should be making concessions before we've gotten any pushback at all. Also the wording here is a bit confusing in that you use the word "licensing" when what I think you mean is DRM.
Here's an alternate attempt at this section:
The Sandstorm App Market permits both commercial and proprietary apps. However,
they are not our primary focus. Developers of such apps should be aware that:
- The App "Market" is missing some features you might expect from platforms
built around proprietary software, such as a payment system of any kind, or DRM/copy
protection. - Since most apps in the app market are currently Free & Open Source, users may be
surprised to find that yours isn't; you should display this fact clearly and prominently. - Sandstorm as a project focused on user autonomy. This creates an inherent conflict
with DRM or any other technical mechanism for enforcing licensing requirements,
and technical decisions made in building the platform will always favor user
autonomy over developer control. Furthermore, we do not consider DRM/license
enforcement to be a valid reason for requesting broader permissions than would
otherwise be required; see the section above regarding approval blocking issues.
If you feel you need to implement some kind of DRM for your app, talk to us first,
before investing time and effort into a solution that we may not find acceptable.
At some point I'd like to have a more well defined "user's bill of rights" or such that
defines what things we really aren't willing to budge on, but for the time being I'd rather
err on the side of strongly discouraging doing anything funny without talking to us.
Kinda a preliminary take on this. I totally spit out my own opinion on commercial and proprietary apps, since that was the question that spawned the "we should probably define this somewhere" thought. (But this definitely means @kentonv needs to review this.)
A written guide for the app review process is potentially valuable to both app reviewers and app developers, and we can use it to define "policy" opinions on what does and doesn't belong in the App Market. There exists potentially apps that "work in Sandstorm", and apps that are "acceptable for the App Market", and we need to be able to define the difference between those two things. This comes a little close to "what makes a good Sandstorm app?" in some ways, but is kind of a different focus.
I also think this guide needs to address two topics I haven't covered yet: