4 tips for developers selling software

Say you’re a software developer and your customer wants to buy your app, do you know what you should be thinking about when selling software? Here are a few contract tips:

Can you legally sell your app?

Unless you have developed the code for the app from scratch and haven’t used any previous code of your own or any third party code, your app is likely to be a composite of code you’ve written in the past for other projects and which may even form part of your general toolkit.

You may also be using code from other developers which could be licensed under a variety of licenses, including open source licenses like GPL and BSD.

When you sell something, you generally transfer all the rights in the thing to the purchaser. You have to have the rights to transfer in the first place and if you don’t own all the rights in that thing you are selling, you can’t really sell it to someone else. If you attempt to do that, you’ll find yourself with a contract you are legally unable to comply with and that is a problem.

Tip 1: Check the rights you can transfer in a sale first.

Know what you are selling

This sounds pretty obvious but it’s a more complicated question that you may have thought. From your perspective you’re selling your app but what is that app, really? Are you selling the finished product alone or does your customer want the source code too?

Many software purchasers want the source code because they are concerned that if they don’t have the source code, they could find themselves in a pickle if the app breaks and they can’t reach you to fix it. It is basically a business continuity concern and the more your customer relies on the app to operate its business, the more important have access to the source code will be.

The challenges with selling the source code include disclosing your secret coding sauce that makes your code so valuable. Those trade secrets could give your customer or even a competing developer who encounters the code later an additional competitive edge over you. Another challenge is that selling your source code outright could have an impact on other projects which leverage elements of that source code because you will have far fewer rights to use that code once it is sold. This means you have to consider the impact on your obligations towards existing customers too.

Tip 2: Carefully consider precisely what you are selling and what the implications are of selling it to your customer.

Clearly define what you are selling

This also sounds obvious but it isn’t. In your mind you are selling an app but how would a person outside the deal be able to identify what you are selling, objectively? Is the app totally self-contained and in a box that can be easily identified? Chances are it may be a bit more complicated than that.

The reason why you need to be able to clearly define what you are selling is twofold: your contract needs to be clear on this and your customer’s expectations of what it will receive from you must correspond with your understanding of what you are selling.

How you define your app may depend on the nature of the app but here are a couple ideas:

  • Include detailed and app-specific functional specifications;
  • Depending on the app, possibly use a hash derived from the app’s code as a sort of fingerprint to identify it;
  • When describing the software’s functionality, avoid generic descriptions that could apply just as easily to software you are not selling;
  • Consider versioning your software and referencing specific versions being sold, if appropriate.

Tip 3: Define or describe the software being sold very clearly to avoid any confusion later.

Consider alternatives to an outright sale

A sale may not be appropriate because of its implications. Often a license agreement meet your customer’s requirements and help you avoid the problematic consequences of a sale so don’t be afraid to suggest that instead.

Licenses can be customised to suit most requirements and can, for example, be exclusive to the customer. The benefit of that sort of license is that the customer has the comfort of knowing you won’t make that software available to someone else and you retain enough rights to meet your other obligations.

If you go ahead with a sale and your customer insists on source code too, consider placing the source code in escrow with a trusted escrow agent with specified conditions which would trigger the source code’s release. Those conditions may include your business closing, you and your team failing to respond to requests for support for a period of time or some other set of conditions that would address your customer’s concerns.

If you sell your source code along with your app and you require elements of the source code to meet existing obligations to other customers or based on other licenses you agreed to, you may want to make sure you either withhold certain rights for yourself or license what you need back from your customer as part of the deal.

Tip 4: A sale may not be the best deal type and even if it is, this isn’t a one size, fits all approach. Customise the deal to suit everyone’s requirements.

Law is code too

Just because your sale agreement is a legal construct doesn’t mean similar rules you apply to your code don’t apply. Work with your lawyer or legal advisor to develop a contract that works properly and doesn’t leave you with bad dependencies and worse consequences.

Look at your contract as an app in its own right. Does the code make sense and does it function effectively given all the constraints and requirements?

Update (2014-06-10): Something else to bear in mind is the new VAT on digital goods sales. Developers who make more than R50 000 will have to register with SARS to pay VAT. It’s a pretty low revenue threshold.

Take a look at this article on MyBroadBand titled “Get ready for VAT on e-books, apps, digital music” for more information about how this affects you.

Wikipedia text, Creative Commons licenses and #HummingbirdGate

One of the concerns about Woolworths’ hummingbird scatter cushions is that the retailer used text from a Wikipedia article about hummingbirds as a background to the hummingbird image which attracted most of the attention in the controversy which raged over the weekend.

Woolworths Hummingbird Scatter Cushion - licensed CC BY-SA 3.0 Unported
Woolworths Hummingbird Scatter Cushion – licensed CC BY-SA 3.0 Unported

One of the concerns about Woolworths’ hummingbird scatter cushions is that the retailer used text from a Wikipedia article about hummingbirds as a background to the hummingbird image which attracted most of the attention in the controversy which raged over the weekend. As I pointed out in yesterday’s post –

As Mr Scott pointed out, this leaves the issue of Woolworths’ use of Wikipedia’s text without complying with the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported license which governs Wikipedia content use. This license requires Woolworths to do a few things in order to comply with the license which include –

  • correctly attributing the Wikipedia article the text was drawn from; and, more significantly,
  • licensing the Woolworths design “under the same, similar or a compatible license”.

Woolworths spoke to its lawyer and tweeted the following in response to a query from @WikiAfrica:

Unfortunately the lawyer Woolworths spoke to missed the real issue. This isn’t about Wikipedia owning the Woolworths design. Wikipedia doesn’t even claim ownership of the content on its site, it is all about licensing the content and complying with the relevant Creative Commons license conditions. In this case, we’re talking about the Creative Commons Attribution-ShareAlike 3.0 Unported license.

I wrote about a terrific guide to Creative Commons licenses which Ars Technica published a couple years ago and, instead of repeating what they have already written, take a look at the guide instead. The guide is titled “Creative Commons images and you: a quick guide for image users“. The key license element is the ShareAlike license element which Ars describes as follows:

The “Share Alike” attribute is intended to mimic the function of the GNU Public Licence’s “copyleft” provision, and it stipulates that anyone who creates a derivative work has to license that work under the same Creative Commons license that you used for your original work.

Because this particular clause matters only to those who plan to make new, derivative works based on Creative Commons-licensed content, it’s generally not that important for publishers, advertisers, and most end-users.

What this means is that the Woolies design, as a derivative of the Wikipedia article because it incorporates the text (the license uses the term “Adaptation” which is basically a work based on another work covered by the license), has to be licensed under the same license (I originally read a description of the license as permitting a similar license but the CC version of the overview specifies the same license). To comply with the Creative Commons Attribution-ShareAlike 3.0 Unported license attaching to the Wikipedia source text, Woolworths will have to license its design under the same license. It would also have to attribute the source of the text which is easy enough to do (the Ars guide has a great description of this process too although implementing that practically may be a little challenging just from a logistical perspective).

Of course licensing the Woolies design under a CC license has its own challenges which depend partly on the source license for other design elements (for example, the hummingbird image) and Woolies’ attitude towards releasing its design into the Commons for others to use under the license. Other than that, this is a pretty easy issue to fix.


p>The big takeaway here is to pay attention to content licensing issues when sourcing material for your products. Sourcing material from Wikipedia is great, just comply with the license requirements. There is a wealth of Creative Commons licensed content out there which is terrific. Using that stuff requires a different mindset to the usual content licensing approach but the opportunities are inspiring.

Media myths about the new Instagram Terms of Use

A number of media services are clinging to the idea that Instagram is selling users’ content and that Instagram has the right to do this in perpetuity. As usual, many of these media services have not taken the time to actually read and understand the Terms of Use or the changes that are coming next month.

The user-centric license model

The fundamental shift from the model in the current Terms of Use and in other services like Twitter and Flickr to the model in the new Terms of Use is pretty dramatic. The current model is, essentially, that Instagram can present ads to you, drawing on your personal information to make the ads more relevant to you. If you accept that you will be presented with ads to support the service that you otherwise use at no cost (aside from your attention and personal information), this model is not all that surprising.

This is what Flickr’s terms and conditions (actually, Yahoo’s, considering that Yahoo owns Flickr) say:

With respect to photos, graphics, audio or video you submit or make available for inclusion on publicly accessible areas of the Yahoo! Services other than Yahoo! Groups, the license to use, distribute, reproduce, modify, adapt, publicly perform and publicly display such Content on the Yahoo! Services solely for the purpose for which such Content was submitted or made available. This license exists only for as long as you elect to continue to include such Content on the Yahoo! Services and will terminate at the time you remove or Yahoo! removes such Content from the Yahoo! Services.

Similarly, Twitter’s terms of service have a slightly different approach and focus more on the license required to make Twitter users’ content (including photos) available both on Twitter.com as well as through companies working with Twitter to publish Twitter users’ content:

You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).

Tip: This license is you authorizing us to make your Tweets available to the rest of the world and to let others do the same.

You agree that this license includes the right for Twitter to provide, promote, and improve the Services and to make Content submitted to or through the Services available to other companies, organizations or individuals who partner with Twitter for the syndication, broadcast, distribution or publication of such Content on other media and services, subject to our terms and conditions for such Content use.

Tip: Twitter has an evolving set of rules for how ecosystem partners can interact with your Content. These rules exist to enable an open ecosystem with your rights in mind. But what’s yours is yours – you own your Content (and your photos are part of that Content).

Essentially, the licenses found in the current Instagram Terms of Use, the Flickr/Yahoo Terms of Service and the Twitter Terms of Service focus on the following permissions:

  • Using users’ content and personal information to present targetted ads based on users’ preferences and profile data; and/or
  • Allowing the service and companies working with the service to publish users’ content as part of making the service available.

Typically these licenses are limited to the purpose for which the users make their personal information and content available.

The social influence license model

The new Instagram Terms of Use’s provisions dealing with users’ content and personal information mirror the Facebook Statement of Rights and Responsibilities. Both sets of terms and conditions have a different focus based on some user psychology which Facebook exploits pretty effectively. The basic idea here is that you, as a user, are more likely to be influenced by what your friends are doing on Facebook and Instagram. Unlike the user-centric license model where the emphasis is more on the user more or less in isolation, the social influence license model exploits the underlying social nature of these services and how they are architected.

This model is a smart evolution of a popular legal framework by adapting it to fit the social sharing model far better. This model focuses on associating users, their identities and their content with a brand or product based on their personal information and activity on the service (the example we used in our previous post was of a Facebook user who “liked” a brand).

So far this isn’t new to anyone who has used these services but two things emerge from the new paragraphs in the new Terms of Use. Firstly, Instagram isn’t so much selling users’ content as it is selling access to users, their content and personal information to brands. Secondly, by relieving itself of the obligation to point out when ads are ads (or similar sponsored content or promotional updates), Instagram gives itself the freedom to present these ads and sponsored content as if they were updates and posts voluntarily published by users as endorsements of the particular brands or products.

Why do they do this? Well, it’s pretty simple. Other users will be more likely to take more of an interest in brands or products their friends seem to be interested in. The catch is that the users apparently endorsing those brands and products through an apparent association with them may not even be aware that they have been associated with those brands or products. In fact, as some commentators have pointed out, the person associated with the brand or product may not even be the user who published the content but rather other people in the photos concerned.

You could find that a photo of your kids has been used to promote kids’ toys or some recreational activity without your knowledge. Kids between the ages of 13 and 18 could be used to promote some trendy service and Instagram creates a presumption that the teenagers’ parents or guardians have consented through assumptions in the Terms of Use (which may not have occurred anyway), leaving these kids to prove they didn’t obtain the consent in the first place. This may not even be legal in countries with stricter privacy laws.

Put another way

Comparing the current Instagram Terms of Use to the new Terms of Use could also be framed as follows:

Targeted ads vs selling social engineering to advertisers

Content sales is an indirect benefit of the new licensing model but it is not what the new licensing model is all about. Exploiting our relationships with each other and the underlying social referral dynamic of the social Web is what the new Instagram Terms of Use and Facebook’s revised legal framework are designed for.

Google Drive and the data ownership panic

Google Drive launched a couple days ago and some new publications are already writing about possible data ownership issues. It’s a common concern whenever a new service launches or website terms and conditions change. Darren Smith pointed me to an article by C|Net titled “Who owns your files on Google Drive?” which had a somewhat confused focus and an unnecessarily alarming conclusion represented by this tagline:

Dropbox and Microsoft’s SkyDrive allow you to retain your copyright and IP rights to the work you upload to the service, but Google Drive takes everything you own.

I took a look at Dropbox’s, Microsoft’s and Google’s terms and conditions to test this conclusion.

Dropbox’s terms and conditions

The C|Net post focused on this clause in the Dropbox terms which are only part of the story when it comes to Dropbox’s terms:

By using our Services you provide us with information, files, and folders that you submit to Dropbox (together, “your stuff”). You retain full ownership to your stuff. We don’t claim any ownership to any of it. These Terms do not grant us any rights to your stuff or intellectual property except for the limited rights that are needed to run the Services, as explained below.

This clause clearly states that Dropbox doesn’t claim ownership of your data but the more important set of provisions are those dealing with the license Dropbox takes from its users when it comes to accessing and making use of the data you upload to Dropbox. Bear in mind that all of these services will have a license of some sort. A license is a set of permissions you, as the user, give to the provider and that enables the provider to receive, manipulate and otherwise handle your data. It’s an essential component and nothing to be alarmed by in itself (at least not if you are comfortable with the basic idea of a provider having access to your data as part of your use of the particular service).

Dropbox’s license provisions are pretty vague. Here are the key clauses:

We may need your permission to do things you ask us to do with your stuff, for example, hosting your files, or sharing them at your direction. This includes product features visible to you, for example, image thumbnails or document previews. It also includes design choices we make to technically administer our Services, for example, how we redundantly backup data to keep it safe. You give us the permissions we need to do those things solely to provide the Services. This permission also extends to trusted third parties we work with to provide the Services, for example Amazon, which provides our storage space (again, only to provide the Services).

To be clear, aside from the rare exceptions we identify in our Privacy Policy, no matter how the Services change, we won’t share your content with others, including law enforcement, for any purpose unless you direct us to. How we collect and use your information generally is also explained in our Privacy Policy.

Sharing Your Stuff

The Services provide features that allow you to share your stuff with others or to make it public. There are many things that users may do with that stuff (for example, copy it, modify it, re-share it). Please consider carefully what you choose to share or make public. Dropbox has no responsibility for that activity.

The basic idea is clear, though. Dropbox requires your permission to run its service and you agree to give it whatever permissions it requires to do that. The problem with this simplistic approach is that it is too simplistic and vague. As a user you don’t really know what the license’s parameters are beyond whatever is not required to operate the service.

Microsoft Services Agreement

These terms and conditions are not limited to SkyDrive but apply to a range of Microsoft services:

It’s a contract that governs your use of any Windows Live, Bing, MSN, Microsoft Office Live, or Office.com services or software, or other Microsoft services or software that directly display or link to this agreement (the “service”). By using or accessing the service, you confirm that you agree to these terms. If you don’t agree, don’t use the service. Thanks.

This is significant because, unlike with Dropbox where your license relates to a fairly specific service, the license you grant to Microsoft encompasses a variety of services which are increasingly interconnected. This is very similar to Google’s terms (below). These terms and conditions are more specific than Dropbox’s licensing provisions and also contain a statement that Microsoft doesn’t claim ownership of users’ data:

5. Your content

Except for material that we license to you, we don’t claim ownership of the content you provide on the service. Your content remains your content. We also don’t control, verify, or endorse the content that you and others make available on the service.

You control who may access your content. If you share content in public areas of the service or in shared areas available to others you’ve chosen, then you agree that anyone you’ve shared content with may use that content. When you give others access to your content on the service, you grant them free, nonexclusive permission to use, reproduce, distribute, display, transmit, and communicate to the public the content solely in connection with the service and other products and services made available by Microsoft. If you don’t want others to have those rights, don’t use the service to share your content.

You understand that Microsoft may need, and you hereby grant Microsoft the right, to use, modify, adapt, reproduce, distribute, and display content posted on the service solely to the extent necessary to provide the service.

Please respect the rights of artists, inventors, and creators. Content may be protected by copyright. People appearing in content may have a right to control the use of their image. If you share content on the service in a way that infringes others’ copyrights, other intellectual property rights, or privacy rights, you’re breaching this contract. You represent and warrant that you have all the rights necessary for you to grant the rights in this section and the use of the content doesn’t violate any law. We won’t pay you for your content. We may refuse to publish your content for any or no reason. We may remove your content from the service at any time if you breach this contract or if we cancel or suspend the service.

You’re responsible for backing up the data that you store on the service. If your service is suspended or canceled, we may permanently delete your data from our servers. We have no obligation to return data to you after the service is suspended or canceled. If data is stored with an expiration date, we may also delete the data as of that date. Data that is deleted may be irretrievable.

A couple things emerge from these terms and conditions. Firstly, when you share your data with other people, you give them a limited license to use your data “solely in connection with the service and other products and services made by Microsoft”. Similarly, the license users grant to Microsoft in respect of their data is limited to permissions required “solely to the extent necessary to provide the service”.

Google’s terms and conditions

Google Drive is governed by Google’s Terms and the license provisions are fairly similar to Dropbox’s and SkyDrive’s, at least when it comes to the basic approach. As with the other two services, Google doesn’t claim ownership of your data. Here are the license provisions:

Your Content in our Services

Some of our Services allow you to submit content. You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.

When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services (for example, for a business listing you have added to Google Maps). Some Services may offer you ways to access and remove content that has been provided to that Service. Also, in some of our Services, there are terms or settings that narrow the scope of our use of the content submitted in those Services. Make sure you have the necessary rights to grant us this license for any content that you submit to our Services.

You can find more information about how Google uses and stores content in the privacy policy or additional terms for particular Services. If you submit feedback or suggestions about our Services, we may use your feedback or suggestions without obligation to you.

The license Google users grant to Google is notionally for the “limited purpose of operating, promoting, and improving our Services, and to develop new ones” but it is somewhat open ended in that Google could develop new services or modify existing ones that require your data to be used in ways you couldn’t have anticipated when signing up. This is fairly similar to Microsoft’s Services Agreement which also uses one license for all its services.

What does this all mean?

The C|Net article contains this rather alarming set of statements:

The last sentence makes all the difference. While these rights are limited to essentially making Google Drive better and to develop new services run by Google, the scope is not defined and could extend far further than one would expect.

Simply put: there’s no definitive boundary that keeps Google from using what it likes from what you upload to its service.

The chances are Google’s terms will never be an issue — and it is likely over-zealous lawyers making sure Google doesn’t somehow get screwed in the long run by a lawsuit — but it may be enough to push away a great number of entrepreneurs and creative workers who rely on holding on to the rights to their own work.

The fact is, according to its terms, Google may own any code or product you ultimately upload to its new Google Drive service, whether you realise it or not.

These statements, particularly the last one, are factually incorrect and misleading. They are also not uncommon when journalists attempt to navigate terms and conditions without the time or inclination to read them carefully. Google doesn’t claim ownership of its users’ data. Its license is fairly broad and that is understandable given the wide range of services it offers. At the same time, there is scope for the already broad license to be applied in ways users may not have considered. The specific permissions users grant to Google are substantially the same as those users grant to Microsoft (Google is more specific and lists more individual permissions but they are not fundamentally different). 

The big difference here is between Dropbox’s terms, on one hand, and Google’s and Microsoft’s on the other hand. Dropbox offers a fairly specific set of services so users have more certainty as to what they are licensing Dropbox to do with their data. Google and Microsoft offer a range of interconnected services governed by a single legal framework and the potential scope for their licenses is far broader when you consider that their users may be using a variety of Google and Microsoft services with different functionality.

I’ve seen license provisions which are far more onerous in the past. The big culprit back in 2007 was Facebook with this gem:

When you post User Content to the Site, you authorize and direct us to make such copies thereof as we deem necessary in order to facilitate the posting and storage of the User Content on the Site. By posting User Content to any part of the Site, you automatically grant, and you represent and warrant that you have the right to grant, to the Company an irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to use, copy, publicly perform, publicly display, reformat, translate, excerpt (in whole or in part) and distribute such User Content for any purpose on or in connection with the Site or the promotion thereof, to prepare derivative works of, or incorporate into other works, such User Content, and to grant and authorize sublicenses of the foregoing. You may remove your User Content from the Site at any time. If you choose to remove your User Content, the license granted above will automatically expire, however you acknowledge that the Company may retain archived copies of your User Content.

This license was as close to an assumption of ownership as Facebook has ever come. It was so close to assuming ownership that the difference between ownership and licensing user content was a matter of semantics. The controversies over the Facebook terms did a lot to create more awareness of users’ expectations and what it means to be a better licensor. The current generation of terms and conditions reflect that, for the most part (there are still some shockers). These modern licenses are clearer, limited in varying degrees but are often necessarily broad to enable these services to function effectively. I agree with the one statement in the C|Net article, though –

It always pays to read the fine print.