Docs: Create app review guide #3391
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,96 @@ | ||
| Apps submitted to the [Sandstorm App Market](https://apps.sandstorm.io/) go | ||
| through an app review process. This page serves to both inform developers | ||
| and the community about the process, and serve as a guide to app reviewers. | ||
|
|
||
| ## New app approval process | ||
|
|
||
| When an app is submitted to the app market, it becomes immediately available | ||
| on the [experimental market](https://apps.sandstorm.io/?experimental=true) for | ||
| testing and evaluation. App reviewers are notified that a new package is in | ||
| the queue. | ||
|
|
||
| During app review, an app reviewer will email the developer at the contact | ||
| email listed in the package metadata, introducing themselves and covering the | ||
| review process. The reviewer will provide feedback and advice on the submitted | ||
| app, which may included both approval-blocking issues and suggested changes or | ||
| fixes. The reviewer will also make sure the metadata displays correctly in the | ||
| market and appears to accurately depict the submitted app, and if applicable, | ||
| may look at the source repository with an eye for Sandstorm-specific changes | ||
| to the code. | ||
|
|
||
| The app developer can then incorporate that feedback and resubmit, or if none | ||
| of the feedback was approval-blocking, request the app be approved as already | ||
| submitted. When the app reviewer approves the package, they will notify you as | ||
| the App Market does not contact developers directly. | ||
|
|
||
| ## App update approval process | ||
|
|
||
| Generally speaking, app review for app updates moves significantly faster. An | ||
| app reviewer should test both new grains and grain updates of the app, with a | ||
| focus on ensuring users will not lose data in existing grains when they get the | ||
| update. If the app is open source, the app reviewer should verify that the update | ||
| was pushed to the source repository as well prior to approval. | ||
|
|
||
| The reviewer may look at the changelog and commit history to narrow down | ||
| what new features or changes should be tested, and may reach out to the | ||
| developer with suggestions or feedback. However, in many cases, the app reviewer | ||
| will simply approve the update after verifying its functionality and notify the | ||
| developer that it has been approved. | ||
|
|
||
| ## Approval-blocking issues | ||
|
|
||
| The Sandstorm App Market is a fairly permissive environment. While you may | ||
| receive feedback about performance, functionality, or usability, we largely | ||
| require only that your app works and that it does not lose data. | ||
|
|
||
| We will reject an app which crashes immediately and does not function as | ||
| advertised, for example. This can often occur when the package is missing files | ||
| that were present in the dev environment and wasn't adequately tested prior to | ||
| submission. | ||
|
|
||
| The latter concern often occurs when a pure client app is submitted up that | ||
| implements localStorage as its storage medium, which Sandstorm does not effectively | ||
| support. This can often be tested by storing some information in a grain, allowing | ||
| Sandstorm to shut down that grain, and then opening it again and seeing if things | ||
| persisted that an ordinary user would expect to persist between sessions. | ||
|
|
||
| Finally, the App Market may reject apps which present security or privacy issues | ||
| that fall outside of what a Sandstorm user would expect when using the app. This | ||
| can mean it requests overly-broad permissions when making Powerbox requests or | ||
| uses client-side loading to load scripts which share unexpected information outside | ||
| of the Sandstorm sandbox. For example, we may block approval on an app which attempts | ||
| to load an analytics script from an outside server, or does not make it suitably | ||
| clear to a user why it needs certain outside network access prior to requesting it. | ||
|
|
||
| **Note:** Client-side loading is a known gap in Sandstorm's security model that we | ||
| intend to close. Not only is misuse of it a security or privacy issue, its use may | ||
| lead to apps that break when Sandstorm closes this gap. | ||
|
|
||
| ## Commercial or proprietary apps | ||
|
|
||
| The Sandstorm App Market permits both commercial and proprietary apps, however | ||
| official support for app purchase and licensing is not currently available. For an | ||
| app that is merely closed source, but free, this may not pose an issue. For apps | ||
| which require some form of licensing to function, we expect at minimum that the | ||
| app description clearly and prominently specifies the licensing requirements and | ||
| activation method. We would also encourage the app to have at least a minimal level of | ||
| 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,
At some point I'd like to have a more well defined "user's bill of rights" or such that |
||
|
|
||
| ## Copyright and copyleft | ||
|
|
||
| The developer is responsible for ensuring their packages comply with all relevant | ||
| copyright or copyleft limitations. If a package is reported to us as in violation of a | ||
| license, it may be pulled from the App Market. | ||
|
|
||
| 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.
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.
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.
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.
This sounds good to me; I think we should basically leave it at that and avoid giving any further advice re: licensing. |
||
| to comply. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 unpackwould 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?