Indie Code Catalog Free License v1.2.3

Purpose

This license allows you to use and share this software for noncommercial purposes and kids’ projects for free, and to try the software for commercial projects. However, you must give credit and share any improvements you make.

Acceptance

To receive this license, you have to agree to its rules. Those rules are both obligations to the developer and conditions to your license. Don’t do anything with the software against any rule you can’t or won’t follow.

Use

Noncommercial

You may not use the software to make money or for work, except for Free Trials and Kids’ Projects.

Free Trials

You may use the software for brief trial periods to verify that the software works as described, such as by running on test data or integrating into private, proof-of-concept prototypes.

Kids’ Projects

You may use this software if you are a child below the legal age of adulthood where you live, usually eighteen years, or you are helping a child with a project of theirs.

Obligations

Notify of License

Make sure that everyone who gets a copy of any part of the software from you, with or without changes, also gets the text of this license or a link to https://indiecc.com/free/{{{version}}}.

Give Credit

You must give this software and the developer credit for contributing to projects you develop, test, produce, or provide using this software.

How to Give Credit

You must give credit in such a way that others can freely and readily find a written notice identifying this software and the developer, by name, as contributing to your project. You must not do anything to stop others from sharing, publishing, or using those credits.

Conventions

If widespread convention dictates a particular way to give credit for your kind of project, such as by end credit for a film, citation for an academic paper, acknowledgment for a book, or billing for a show, follow that convention. For software provided to users to run on their own computers, give credit in documentation, notice files, and any “about” page or screen. For software run as a service for users to access remotely, give credit in a credits.txt file according to https://creditstxt.com.

Who to Credit

If the developer provides their name or the name of this software along with the software in a conventional way, such as in software package metadata or on an “about” page or screen, you may rely on the names they provide that way to be accurate and complete. If the developer doesn’t provide names that way, but includes a link to a homepage for this software, investigate that homepage for names to credit. If the developer provides neither names to credit nor a link to a homepage, you do not have to do independent research to find names to credit.

Declining Credit

On written request from the developer, you must remove their name, the name of this software, or both, as they ask, from credits for your project going forward.

Share Improvements

With two exceptions, Prototypes and Applications, share all changes and additions you make to this software, as well as all software that invokes this software’s functionality, with the developer. When in doubt, share.

Prototypes

You don’t have to share any change, addition, or other software that meets all these criteria:

  1. You don’t use it for more than thirty days.

  2. You don’t share it outside the team developing it, other than for non-production user testing.

  3. You don’t use it on behalf of anyone outside the team developing it.

Applications

You don’t have to share any software that only invokes this software’s functionality through the interfaces this software exposes, unless it exposes so much of this software’s interfaces or functionality to users, programmers, or other software that it becomes a practical substitute for this software. Interfaces exposed by this software include all the interfaces this software provides users, programmers, or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces.

How to Share

To share software with the developer:

  1. Send all the source code to the developer in the preferred form for making changes through the system the developer uses to manage and distribute the source code of this software. If the developer uses a public source code repository that accepts pull requests, send a pull request. If the developer accepts patches via e-mail, send a patch to their e-mail address or mailing list.

  2. Make sure every new part of the source code is available under the Blue Oak Model License 1.0.0, the BSD-2-Clause Plus Patent License, or terms with substantially the same legal effect. If you can choose the license terms for part of the source code, license it under the Blue Oak Model License 1.0.0.

  3. Take these steps within thirty days.

  4. Note that this license doesn’t let you change the license for this software. Follow Notify of License.

Intellectual Property

Copyright

The developer licenses you to do everything with the software that would otherwise infringe their copyright in it.

Patent

The developer licenses you to do everything with the software that would otherwise infringe any patent claims they can license or become able to license.

Patent Defense

If you make any written claim that this software or any other software offered through indiecc.com infringes or contributes to infringement of any patent, this license ends immediately. If an organization you work for makes that kind of claim, this license ends immediately for work for that organization.

Excuse

You’re excused for unknowingly breaking Notify of License, Give Credit, or Share Improvements if you take all practical steps to comply within thirty days of learning you broke the rule.

Reliability

The developer cannot revoke this license.

No Liability

As far as the law allows, the software comes as is, without any warranty or condition, and the developer will not be liable to anyone for any damages related to the software or this license, under any kind of legal claim.

3 Likes

Looking good!

What is the definition of “for work” in Noncommercial?

Should the Free Trials section link to Prototypes?

1 Like

Personally it feels like a tough sell vs Parity+Prosperity or dual-AGPL. Maybe I’m just not in the right target market.

In my mind, using this on its own, there’s the advantage of calling out commercial use by its name, the disadvantage of weaker copyleft, and the disadvantage of discouraging potential contributors (or just getting more heat for that, regardless of whether it’s a real effect.)

1 Like

Woot! Looking good. When do you want this widely promoted?

I’d love to host a video call with you around this.

LMK when / where / how I can help promote.

1 Like

My layman’s definition for this within the context of Prosperity has been — if you use this in the context of a for profit business, you need to pay for a license.

The first part of that is “to make money” — eg selling the software in whole or in part, but a license.

This second part, for work, means that say you run something internally to a for profit company — it’s still providing value to the entity making money, and so any “for work” usage should also be licensed.

This should also cover the inverse — a non-profit using this in pursuit of its mission doesn’t need to buy a license.

I’d like to know if my rough working definition is correct!

1 Like

Really great blink reaction. I think everyone’s personal reactions are very valid as they’ll mirror some segment of people. It’s useful to understand how many of “you” there are.

Having just finished Nadia Eghbal’s Working in Public, “discouraging multiple contributors” is mostly a myth for a lot of projects today.

One of the things that I would offer in usage of something like this is — “get a free license if you contribute”. With contribute defined by the context of the project.

And, mostly, all new licenses are going to be in the receiving end of FUD for a while.

I think this more simply combines Parity & Prosperity in a defined way. I hadn’t thought about it until you mentioned it in this way and it took me a bit to figure out what you meant. Am I getting that right, that in your mind this is like combining those two licenses?

I think Dual AGPL as you say doesn’t call out commercial, and is essentially custom.

IndieCC has some strong opinions baked in with a defined set of defaults, which I think is easier to reason about vs “some kind of Dual AGPL”. And — is less off putting for consumption on the corporate side than anything that has AGPL on the box.

1 Like

My interpretation of “for work” in older iterations of this license has been that someone wouldn’t be allowed to use the software as part remunerated employment, whether as an employee or independent contractor, regardless of field of endeavor (health care, education, non-profit, etc).

Putting this under the Noncommercial label is a bit confusing, because licenses like Prosperity and Polyform Noncommercial explicitly allow many uses that I have thought this license excluded.

I don’t think the sharing requirements of this license have much in common with Parity. The Applications exception is so broad that it’s closer to LGPL, though it’s stronger because sharing isn’t conditional on “distributing” modified software to a third-party.

1 Like

Not defined! Leaning on everyday meaning here.

I hadn’t thought about that.

Really appreciate the enthusiasm!

It’s number one on my projects list to return to IndieCC pronto. But I’ve been laid up for two weeks with an old back/spine issue, and I still have too much pain to sit up or reliably take calls.

Hopefully next week I’ll be able to work properly. Right now I’m typing all this on an iPad in bed. :stuck_out_tongue_winking_eye:

Can we circle back in a few?

2 Likes

That’s my view, as well. There are good reasons for all the clarifications and whitelist-style sections in Prosperity. They come from PolyForm Noncommercial. But I think the intuition and use case for IndieCC is a bit stricter, covering, say, folks working for nonprofits or universities. Part of it is that IndieCC users are assumed to be selling licenses for use at work, so it’s not that they’re shut out so much as told to pay.

That’s how I see it. This is not a “free for open source” license. It’s a “patches back” license.

All the copyleft terms come from Round Robin.

2 Likes

No hurry, just wanted to say I’m here to support whenever you want it.

1 Like

My tribe is what we used to call “indie mac developers”. There were once about 10k of us. As the market changed many of us got varying degrees of “real jobs” and we can be tougher to spot on LinkedIn now, and some of us came in afterward so never did mac per se. But I think we’re mostly around, waiting for conditions to be right again.

I realize I can come across as a critic, but I hope it also comes across that I really want you to succeed :rocket: If you can build a sustainable way to create this sort of software it would mean a lot to me personally. I also know what it is to get derailed by that one guy on the comment thread and I want to be very careful about that.

Am I getting that right, that in your mind this is like combining those two licenses?

I’m mostly comparing this to what I would do instead. Recently, what I’ve done instead has been Parity/Prosperity (thanks Kyle!). I do think it draws on two licenses I like, so that’s very nice.

Having just finished Nadia Eghbal’s Working in Public, “discouraging multiple contributors” is mostly a myth for a lot of projects today.

I agree with you but the thing is, the concerned emails about it are not mythical. AGPL or Parity heads that off at the pass, there’s no room to speculate about what what would have happened. On the other hand I worry about an explicitly un-reciprocal license being a magnet for flamebait. I would probably want to see someone else do it first. Whereas with many of Kyle’s other licenses I’m comfortable being an early adopter.

One of the things that I would offer in usage of something like this is — “get a free license if you contribute”. With contribute defined by the context of the project.

IMO there’s an unrecognized opportunity in license tech here. In some sense, the raison d’être for licenses is because it’s too hard to track down some person on a different continent ten years ago to link their library, there’s a lot of value in having a Standard Deal.

Similarly if me and 3 indies have to negotiate how much to pay vs contribute on some plumbing library it will never happen. It’s like cats negotiating a license. We’ll send half an email, immediately give up and each write 3 bad libraries. When one app fails it will be “parted out” with an MIT licenses and live with all the other bad libraries you didn’t want to use and the cycle will repeat. I strongly suspect there is some sort of legal tech that would disrupt this cycle and unlock collaboration, but that problem may be outside the goals of indiecc.

2 Likes

And, not stated, but “I’ll do the hard work of accepting those patches and maintaining them over time, no EXTRA charge, you’re welcome”. This … SHOULD have a higher than zero cost. But that’s not how we’ve been conditioned.

I know your tribe’s work! It was really important to me as a young contract developer in the early 2000s. I was proud to pay for the excellent tools I used at that time.

I miss that feeling. I miss sharing it with other coders, designers, artists, and production people.

The obvious marketplace for OS X and iOS software will likely remain the App Store, unless the EU completion law or US antitrust enforcers really push hard. I know there are serious problems with the App Store, and that Apple hasn’t always been a fair and impartial merchant. But I’ve seen some folks make okay money, independents and small specialist software companies.

However, I don’t see a good trade in software components—libraries, frameworks, and so on—through Apple’s marketplaces. That needs to exist.

I am very interested in this project. We’ve discussed it a few times here on the forum.

License Zero, the predecessor to IndieCC, reified some solutions to dev-to-dev deals. But it was complex, and exposing that complexity alienated both potential customers and many developers. Another way in which License Zero was just Too Big Not to Fail.

I could see a project that is essentially a set of contract forms:

  1. I pay you a flat fee for some contribution to my project on delivery.

  2. I pay you an hourly rate to make some contribution to my project.

  3. I pay you x% of my gross licensing revenues in return for your contribution.

The assumption here is that there’s someone or some company leading the project and the business of licensing it. I feel pretty confident in that assumption, overall, though I’m very interested in exceptions.

From the legal point of view, the above is a weekend project for MVP. The longest lead item may be finding a name and domain.

I might try an honor system model, where I ask folks who manage to do deals using the forms to pay my company a flat fee or small percentage.

I don’t know how much license subheadings are taken into account judicially, but noncommercial licenses within the industry are generally perceived as being for software not intended for making money, which is covered by the first part. This normally includes commercial activities run by voluntary/non-profits - for example I developed something as a freelancer for an educational charity based off an NC license, but because the charity was asking schools for a fee to use the software, I had to advise them they could not use the code they wanted and so I wrote a clean codebase for them. The ‘for work’ bit sounds really broad to my ears… it seems to catchthe obvious ‘work for hire’ (employment) in ANY kind of organization, and maybe (less inuitively) even voluntary work (gratis)… done for charities even if there is no money changing hands… if so… that’s a VERY strong NC… it might unsettle some who work in the voluntary/non-profit sector like me, who may offer something gratis as part of a larger project… and the freebie snippets or whatever would also seem to trigger a demand for a license which feels slightly weird…

2 Likes

I definitely agree that there is a big opportunity here. In terms of the solution though, I think there are some details that need to be worked out.

One significant detail is that we exist in the superposition of simultaneously not caring at all about these components, because we’re focused on the actual product we’re trying to build, and caring a lot, because we are cats. This duality explains otherwise unexplainable behaviors like our libraries going from unpublished proprietary to MIT in a single step, or our strange interest in the backs of cabinets, the attraction of which is that it’s a metaphor that holds both perspectives in tension.

The assumption here is that there’s someone or some company leading the project and the business of licensing it. I feel pretty confident in that assumption, overall, though I’m very interested in exceptions.

While this does certainly happen, a prerequisite to it happening is that we “collapse the wavefunction”. That is, we have decided Company A cares the most and will lead, Companies B/C care less and are licensees, and we can find some single number(s) that reflect everybody’s interests in the project that is stable over reasonable periods of time. I can certainly understand why encoding this sort of understanding is of great interest to lawyers. The trouble is that from our perspective, it tries to represent more certainty than really exists in the world. Company A will go out of business this year, Company B will do freelancing for awhile and be difficult to get ahold of, before reappearing in a year with lots of free time. Company C will become wildly successful and try to become the defacto lead, but because they cannot get ahold of Company B to negotiate they rewrite internally and leave the coalition.

I’ve floated in the past auto-apportioning based on # of commits. Not attached to it specifically but I do notice it avoids collapsing the wavefunction and we can continue along in our superposition of maybe we’ll take over the project and maybe we’ll drop it completely.

I don’t think that flexibility is strictly required by everybody. Particularly in more mature products (or more opinionated authors) we will have crossed this rubicon and have made the sorts of % decisions you imagine. On the other hand the nature of indie developers is we like working on products that are immature, so it’s a complication.

where I ask folks who manage to do deals using the forms to pay my company a flat fee or small percentage.

I think you will find folks pretty agreeable to paying for this, particularly if you keep the fee well below what appstores charge (for smalltime LLCs, that’s 15%. So maybe 5-10%). This is doubly true if you lean on the “this isn’t your real product” side of the superposition, since from that perspective any money is free money for software we needed to write anyway. This is another advantage of keeping the uncertainty alive.

The real risk is getting us to work together and $ to change hands at all, since we are cats. I believe it can be done, but if it were easy to do it would have already happened.

1 Like

I think the definition of “for work” needs to be more clearly pinned down. As it stands, there’s a lot of ambiguity.

For example, would an unpaid PhD student be allowed to use the software? What if they receive a stipend? What about an undergrad that receives a taxable student allowance? What about paid vs unpaid work for a non-profit? What about an unpaid internship? What if that internship is a mandatory part of getting a degree?