OSS licensing question

[kekekeks]

We are currently using Wyam for http://avaloniaui.net/

Avalonia itself is free and MIT licensed, the source code of the website is also open source and built by Azure Pipelines, anyone can submit a PR, so such contributors need to run Wyam locally to test the changes beforehand.

However there are commercial support services provided by some of Avalonia contributors.

So the question is, can we safely migrate to Statiq or does every single person who is trying to contibute to the website's github repo have to purchase a Statiq license?

[daveaglick]

Thanks for reaching out and asking. I anticipate part of the challenge with this new licensing scheme will be to ensure ambiguity is addressed on a case-by-case basis. What I’d hate to happen is for people to assume the license either applies (or doesn’t apply) in cases like this.

More specifically, my intent is for the non-commercial clause to apply to stereotypical business cases. I don’t want it to hinder use by other open source projects, non-profits, etc. even if there’s a small commercial component. That’s hard to quantify so I suspect you’re probably the first of many in this situation. To make things crystal clear and remove any risk on your part I have the option to grant a licensing waiver. I’ll send one over and you’ll be good to go.

To anyone else who stumbles on this issue and falls into the category of “not really a business but still making a little money” please reach out or file an issue requesting clarification if you have questions.

[daveaglick]

Note that I'm also going to continue investigating - you've raised what I think is a problem with the license language. Just as the framework is in alpha (getting really close to beta though!) so is the licensing scheme. This style of license is new for me, so I expect there will be a few things like this to work out as we go.

[daveaglick]

I think this comment from @kemitchell (the lawyer who wrote the Prosperity license) in another thread relates to the same problems you had interpreting how the license applies:

As a practical matter, many overwhelmingly noncommercial organizations refuse to whitelist CC-NC by policy, because they can't effectively monitor occasional arguably commercial uses. That induces widespread false negatives: many individuals within those organizations can't practically use CC-NC works, even though they qualify under the license terms.

Prosperity is similar to CC-NC in intent and so the same problems probably exists with it as well. How do you distinguish between clearly commercial enterprise and occasional commercial uses that were not intended to fall under the license restrictions (such as yours and other OSS projects)? Perhaps I should be investigating the Polyform Small Business license as an alternative.

[withinboredom]

Hello @daveaglick, I stumbled across this project and had an interesting idea/use case for it. However, it's not clear how projects must be licensed that use this project downstream.

[daveaglick]

@withinboredom That's a very good question. My interpretation is that since the license is granted per-user, any downstream users would be subject to compliance if they fall under the non-commercial clause (I.e., it's up to the eventual user, not the upstream project that includes Statiq, to ensure compliance). That's one of the reasons I don't think this licensing model is that appropriate for purely library style projects - since Statiq is (mostly) a platform/application, uses by upstream libraries will be limited (though there certainly could be some like yours).

Note that I'm also leaning pretty strongly towards shifting to PolyForm Small Business with PolyForm Free Trial as well. That helps remove confusion over "am I subject to the non-commercial clause?" since "Use of the software for the benefit of your company is use for a permitted purpose if your company has fewer than 100 total individuals working as employees and independent contractors, and less than 1,000,000 USD (2019) total revenue in the prior tax year." is pretty clear that it doesn't apply for most users while still maintaining the underlying intent of participation in economic gain though use. I haven't 100% decided and need to do a little more research, but it's looking likely.

Does that help answer the question? If not, feel free to reach out directly with specifics if they can't be shared here.

[withinboredom]

Sure, I was thinking of wiring up the platform to run as part of an azure function (serverless publishing?) but I’m contractually obligated to only publish GPL code so I can’t contribute here, but if the library could be used in a GPL application, then that could work. However, that seems to go against the spirit of your license, so I don’t think it’s a good fit for me :)

[daveaglick]

@withinboredom

but if the library could be used in a GPL application, then that could work

The license isn't viral and the only restriction is on commercial use, so I think you're fine as far as embedding in a GPL application goes.

However, that seems to go against the spirit of your license

On the contrary, I have no intent or interest in GPL-style viral licenses. The relevant clause is "You must limit use of this software in any manner primarily intended for or directed toward commercial advantage or private monetary compensation..." and the escape hatch is a one-time license fee of $50 per developer (covering a major version in perpetuity and all releases including majors for a year) that essentially converts the default license into something like MIT by removing that clause. So if your project is either non-commercial in nature or you don't mind a $50 license fee (given it sounds like you're the only developer working on this), then running it as a service for users and/or embedded in another GPL application seems acceptable to me.

At the end of the day this is a bit of a licensing experiment because I'm trying to strike a balance between helping normalize commercial participation for openly developed software as a sustainability strategy while still favoring more open MIT-style (mostly) permissive licenses. The last thing I want or intend to do is "get" users or make a fuss about licensing violations.

[MichaelKetting]

@daveaglick I'm considering Statiq.Docs as one of my options for doing documentation in my framework. The framework's open source on Github, but mostly developed by my team (a handful of people) who are all employeed at our company and our legal department will want to clarify things. Our company exceeds the exemption rules as far as employees and revenue is concerned.

• I'm assuming that regular developers in our team fall under the commerical-use license if they work on the Statiq-project - i.e. commit code to the Statiq page generator.
• From the FAQ on the support page, anyone just writing documentation (directly or indirectly via API documentation) doesn't need a license.
• Given that those two bits are located in the same repository, is it enough to just check that the correct number of users are licensed when they commit changes inside a specific folder?

Other questions:

• We usually do an intern program once a year for a couple of months and if our interns work on Statiq stuff, we need to get licenses for them, too, correct?
• What about contributions to our Statiq stuff? I.e. someone (internal or externally) contributes but is not part of the regular maintainer team - can we only accept PRs if each contributor is licensed?
• What about changes in the team? Is it okay to simply have the maximum number of concurrent team members (as tracked internally by our company) licensed or is there a more formal approach?
• How often do you plan on releasing a major version? More than once a year, roughly yearly, or bi-anually and longer? Of course, I guess no one's forcing me to upgrade more than once a year and once we reach yearly bugdeting, it doesn't matter if there's a gap-year.

Sorry about being nitpicky, but these sort of details are needed to correctly do a budget forecast and satisfy the legal department.

Oh, and I haven't gotten around to actually doing a trial phase yet, but I'm hoping to evaluate Statiq.Docs some time in the next couple of months. The video you did with JetBrains was certainly interesting!

Thanks, Michael

[daveaglick]

The license is intentionally short to try and make it easy to parse, including for lawyers. It was written by a team of lawyers under the Polyform Project, but as you can guess I am not personally a lawyer so my interpretation is more about intent so hopefully that's helpful to your own legal team.

That said - it's not like I'm keen to go around suing anyone or anything either. I thank you for getting clarifications and trying to stick to the spirit of the license - I'm doing it as much to help normalize open source licensing alternatives as anything else and I appreciate your interest in making sure we both get it right. Happy to clarify anything below further.

I'm assuming that regular developers in our team fall under the commerical-use license if they work on the Statiq-project - i.e. commit code to the Statiq page generator.

That's the intent, yes. I tried hard to find a set of licenses that leaves the project as open as possible except for larger revenue-earning companies. Unfortunately the working-on-open-source-but-within-a-big-company scenario gets caught in that net. I'm not sure how I feel about that, but creating even more exceptions for that scenario would just make things more confusing so it is what it is.

From the FAQ on the support page, anyone just writing documentation (directly or indirectly via API documentation) doesn't need a license.

Correct - whether the documentation is source file comments (which Statiq converts to inline docs in the API pages) or Markdown, etc. they are not "directly" using Statiq and therefore do not require a license. Another good example of this distinction is when pulling content from a headless CMS - authors through that system also wouldn't require a license, though the developers that set up the integration in Statiq would.

Given that those two bits are located in the same repository, is it enough to just check that the correct number of users are licensed when they commit changes inside a specific folder?

Totally. If it were just up to me I'd say even a best-guess is fine - not sure how strictly your legal team will want to be about it though.

We usually do an intern program once a year for a couple of months and if our interns work on Statiq stuff, we need to get licenses for them, too, correct?

That's correct, though the licenses are unnamed so an extra one that you can "pass around" is fine.

What about contributions to our Statiq stuff? I.e. someone (internal or externally) contributes but is not part of the regular maintainer team - can we only accept PRs if each contributor is licensed?

That's probably a grey area, but if a developer is only using it for a short time and other licenses have already been obtained, I'd say they don't need yet another license just for that little bit of work.

What about changes in the team? Is it okay to simply have the maximum number of concurrent team members (as tracked internally by our company) licensed or is there a more formal approach?

Yep, absolutely. The licenses are unnamed so swapping them around is totally fine. It's more intended to be a reflection of the scale of usage.

How often do you plan on releasing a major version? More than once a year, roughly yearly, or bi-anually and longer? Of course, I guess no one's forcing me to upgrade more than once a year and once we reach yearly bugdeting, it doesn't matter if there's a gap-year.

I tend to focus on incremental improvements for a while before planning out large-scale work that would move the major version number (and while I appreciate semantic versioning, I favor more feature-focused major versions so it's not like the major will be increasing with every breaking change).

If history is a guide the major versions that require relicensing will happen infrequently. I'd guess the 1.0 version will be around for 2 - 4 years given historical trends in the project (both in getting 1.0 out the door and with Wyam which was a successor before Statiq). And that's not even considering when it cycles over to 1.0 either (which is included in licenses purchased now) - I think it's close technically, but could still be another 6 - 12 months before I finally stamp it as 1.0 final.

Sorry about being nitpicky, but these sort of details are needed to correctly do a budget forecast and satisfy the legal department.

Absolutely no reason to be sorry!

Oh, and I haven't gotten around to actually doing a trial phase yet, but I'm hoping to evaluate Statiq.Docs some time in the next couple of months. The video you did with JetBrains was certainly interesting!

Awesome - Statiq Docs is the newest member of the family, and while it's based on code going back years from Wyam, it's still got a few rough edges and is where I'm spending most of my time right now. When you do get around to a trial, let me know if you find any bugs or missing features!

[MichaelKetting]

Thanks a lot @daveaglick! Being able to go with the typical/average teamsize will help a lot. Spending a bit of thank-you money on a good OSS project should never be an issue.