Choosing a License for GoatCounter
arp242.net
arp242.net
(Technically you can only convert when distributing a derivative work “based upon both the Work and another work licensed under a Compatible Licence”, but you can just find some GPL-licensed function which can be put somewhere in the codebase. Oh, and you may need multiple people to pull this off.)
This is a feature, if you're trying to make sure that people either share changes or pay you. If some companies avoid it, that means it's doing its job.
(This seems related to classic advice on pricing: if nobody ever thinks your product is too expensive, then your product is too cheap.)
> I don’t like that it imposes restrictions on non-commercial users. If you’re running a private GoatCounter for your personal weblog with some hacks you clobbered together then go for it! No need to send me your ugly hacks. Again, I may investigate some dual-licensing options in the future.
This doesn't need dual-licensing, just a license exception that allows certain groups of people (e.g. personal websites below a certain scale) to ignore certain clauses of the license.
As mentioned, I'm only really interested in preventing people from "leeching" off my work by setting up a competing service with their (unpublished) changes.
I'm not so sure if this is a real issue with end-user program like GoatCounter, but in general I'm not a fan of "viral" licenses.
> This doesn't need dual-licensing, just a license exception that allows certain groups of people (e.g. personal websites below a certain scale) to ignore certain clauses of the license.
The AGPL can't be changed though, it's explicitly mentioned at the top. So as I understand it, the only way is to offer it under two licenses (if personal then this license, else other one). I'm not really sure how this works legally (didn't research).
>> This doesn't need dual-licensing, just a license exception that allows certain groups of people (e.g. personal websites below a certain scale) to ignore certain clauses of the license.
> The AGPL can't be changed though, it's explicitly mentioned at the top. So as I understand it, the only way is to offer it under two licenses (if personal then this license, else other one). I'm not really sure how this works legally (didn't research).
You can't modify the text of the AGPL, but you can offer exceptions to it, and the GPLv3 and AGPLv3 make that even easier than the GPLv2 did. Many pieces of software are available under licenses that consist of the GPL or AGPL plus an exception. This is not at all uncommon. The LGPLv3 itself actually consists of the GPLv3 plus an exception.
As an example, you could write something like "Licensed under the GNU Affero General Public License, version 3 or later. As an exception, if you are using an unmodified version of the software solely for your own individual use on a personal (non-business) site with less than X active users, and not offering the software as a part of a service provided to others, you are not required to provide the source of the software as would be otherwise required by clause 13 of the AGPL."
(Also worth noting: technically you can modify the text of the GPL or AGPL if you omit the preamble and modify the instructions, but the result will not be an OSI-approved license, and if you're not careful it also likely won't be GPL-compatible. See https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL .)
On the one hand, devs should feel empowered to read licenses, get their hands dirty, and choose for themselves. I like seeing more of that.
On the other hand, this is way too complicated. This author's needs and goals aren't rare. They're exceedingly common.
> Choosing a license has always been easy: MIT. It’s the best-known “do what you want” plain language license. Arguably ISC is slightly better [...]
Umh, how exactly? ISC and MIT are functionally equivalent, which really means there are no differences.
Anyway, I agree that choosing a license is often very hard for reasons stated in this post. I'm wondering why nobody ever made a license Martin would describe as perfect.
(But I am aware it's really hard to make a water-tight license, since nowadays it has to work worlwide, which will need some ugly language since the European and Anglo-American laws are so different.)
ISC> [...] use, copy, modify, and/or distribute this software [...]
MIT> [...] use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software [...]
Note that MIT includes "sublicense". ISC does not. This is a big difference. See page 87 in chapter 5 of Rosen's "Open Source Licensing" book [1] for a discussion of the importance of this.
Also, doesn't the Parity Public License violate the OSI definition of "Open Source" by requiring users to “Contribute software you develop, operate, or analyze with this software”. This kinda reminds me of MongoDB's SSPL which (I think?) violated the "license can not restrict other software" rule: https://opensource.org/osd
Yes, it does. It's a license that pretends to be open, but isn't, much like MongoDB, or the Redis "Commons Clause".
The whole rant linked from this article, about the OSI, is very much a case study for why you should ignore any license that claims to be open or uses terminology that vaguely sounds open but isn't actually OSI-approved. (With a dose of "and you should be scared of copyleft" FUD thrown in.)
Also, I think saying 'protect' is quite one-sided, and signalling virtue while at the same time unfairly painting a copy left license like Parity as sorta predatory.
Just my opinion, of course, but I wish every piece of software in the world was copy left licensed. I know that is unrealistic on millions of levels, but I still think it's a valid course of action to try to get us at least a tiny bit in that direction, and choosing a license that restricts a few small parts of select freedoms in exchange for that. Just because OSI has been seen as the champion of open source in the past doesn't mean we all agree that was justified, and a good thing. Most people think differently to me in this regard, or don't really care, but this is not and will never be a settled argument.
To me, it really boils down to this: I dont care that much about the freedom of people who dont care about their users freedom, i think restricting those peoples freedom is an acceptable tradeoff. With Parity, for example, as long as you open up your code you can use everything licensed with it. If you don't, or you use other non free software then parity licensed software doesn't really make anything worse to you as a user, since you already accept non open source code in your infrastructure/project.
Parity might not be the best license ever, although i like it quite a bit, but i think it is at least a very valid attempt to fix a problem some people see as problem. You apparently dont think there is a problem, or its not that bad compared to such a solution, but that doesn't mean there's a guarantee you are right. Nor I.
First, the OSD and DFSG are a line in the sand, a focal point: https://en.m.wikipedia.org/wiki/Focal_point_(game_theory) . If we abandon that line, we lose much of the ability to push back on not-quite-open-source licenses. That's why not-quite-open-source licenses are in some ways a bigger problem than proprietary software, because they seem like such a small compromise, but they would move the Overton window.
And second, in the specific case of Parity's non-FOSS license, there's a specific reason to reject it. It goes beyond the reach of copyright law into contract territory, and it would cause serious problems in toolchain software and developer software.
(For the record, I acknowledge the problem you're referring to. I just consider the above problems much worse.)
Meanwhile, nearsightedness on licensing politics allowed the frame to move out from under licensing long ago. SaaS. Data control. App Stores. Developer SDKs.
As for Parity, GPLv3 has already been enforced under both contract and copyright, and already goes further than derivative works. But a license matters because of its rules, not how they work. Legal implementation details are just that.
As for toolchain and developer software, Parity intentionally sets out to do for those what the GPLs tried to do for libraries, frameworks, and applications. If there's a good reason only some kinds of software---and some kinds of software developers---and only those get a gold star for their copyleft, I haven't read it yet. What I have read boils down to fear or deprecation of copyleft itself: keep it penned in where it is. We only needed it to get where we are now.
End-user rights and developer autonomy are intertwined with software licensing. If we start using licenses compromising those rights and that autonomy, we lose what we're trying to win. Let's not burn down the progress we have. It's not acceptable to give up freedom zero, the freedom to use the software for any purpose.
> But a license matters because of its rules, not how they work. Legal implementation details are just that.
The limits of copyright's reach are a useful Schelling point as well. To a first approximation, they're a good limit on license reach.
> What I have read boils down to fear or deprecation of copyleft itself
On the contrary, I very much like the idea of strong copyleft. But there's a limit. Would you favor a license that claims everything on the same disk must be open and compatible with it? Or a license that says if you ever distribute proprietary software you can't use it? Or a license that does the same but defines "proprietary software" as "everything incompatible with the XYZ license"? How about a license that prohibits developing permissively licensed software, or software you don't share? (See Parity's clause saying "You don’t develop, operate, or analyze other software with it for anyone outside the team developing it.") The "Parity" license goes much too far, throwing away freedom zero, and worse, it claims to be open source.
Also, I find it interesting that Parity, while claiming to favor strong copyleft, specifically references an organization and license that's pro-permissive-licensing and anti-copyleft.
> As for toolchain and developer software, Parity intentionally sets out to do for those what the GPLs tried to do for libraries, frameworks, and applications.
Again, freedom zero: the freedom to use the software for any purpose.
The GPL keeps libraries, frameworks, applications, toolchains, and developer software FOSS; it doesn't prevent using (as opposed to building upon) that software to develop software under incompatible licenses. If it had, people couldn't use Emacs to write software under the Parity license. ;)
The four (actually five) freedoms aren't a very good way to break down what people want to do with software. But RMS and other activists lauded for being uncompromising compromised several kinds of freedom for copyleft, no matter how you slice it. Parity isn't rescinding "run for whatever purpose" wholesale any more than GPLv2 rescinded "patch for whatever purpose". Parity applies share-alike to execution as GPL applied it to patching and extending and AGPL and OSL applied it to ... also execution. How come some freedoms have to be absolute, and others can be qualified with rules that require respecting others' freedom? Because that's how the open source marketers squared feel-good libertarian rhetoric with what RMS and those drafting off him actually wrote in their terms. Nobody outside the small community of wonks and FSF adherents even thinks in terms of the "four freedoms".
As for leaning on copyright law: That law approximates what early FOSS activists opposed, not what they wanted. And we still don't know how far "derivative work" reaches in software under US law. Most FOSS activists aren't happy where the courts seem to be taking it, e.g. under Oracle v. Google.
You don't have to ask me which kinds of copyleft rules I'd support. You can read Parity and API Copyleft for yourself. And I've never referred to those licenses as "open source" myself, though others have. I'm more and more tempted to start.
Saying GPL is FOSS and Parity isn't because FOSS, and defining FOSS to draw the kind at GPL-style copyleft, is circular. That's typical of nearly all the homespun vocabulary, views, and theory of open software licensing. We're trying to apply after-the-fact justifications, theorizations, and rhetoric for what was in essence a marketing coup to new license terms, and they're predictably faltering.
I don't know which pro-permissive, anti-copyleft organization you were referring to, but if it was Blue Oak, you might like to know that I facilitated the drafting processes for both Parity and the Blue Oak model.
The absolutist position I object to is the idea that any condition on particular ways of using software, even a copyleft condition, makes the rule harmful. That's clearly not the case for rules attached to the freedom to make and share changes, to build applications from libraries or frameworks, and so on.
Share-alike rules about those kinds of uses can and have been prosocial in practice. They can be prosocial for dev tools, too. We see that every time developers make code open in order to get free code hosting, CI, coverage, and so on from SaaS companies.
This is incorrect. OSI's approved licenses include copyleft licenses, which do not permit releasing closed-source versions.
I'm not sure if inventing more terms will be successful or useful, so the only way forward I see is to relax and assume good intent from everyone, use "OSI-approved" or "compatible with OSD", and "open source" as a very broad umbrella term for anything where the source is available. This is already how many people use the term, especially those not intimately familiar with software dev/open source. I've never seen a single instance where telling people that "you're technically using that commonly used term wrong" is successful.
There's a difference between an unintentional mistake of loose terminology, and someone intentionally trying to create confusion and FUD for their own benefit. In the former case, I've run into multiple people who did appreciate learning what "open source" actually means. (I'm in a position of providing mentorship on a variety of topics, including on FOSS.) In the latter case, anyone trying to misleadingly brand their software as open while using a license that isn't actually open needs a strong response; the companies engaging in such misleading practices are unlikely to listen to that response themselves, but many of their customers and potential users will listen, and steer clear.
We don't need to invent new terms. We have terms. We need to discourage misuse of the terms we have. If (hypothetically) we invented a new term and that term caught on, then people would try to abuse that term. There's an incentive to latch onto the popular terminology while attempting to work around its requirements; there needs to be a strong disincentive to doing so, as well.
The first group to latch onto "open source" was OSI. "Open" had been a buzzword in computing for a whole generation before.
The media didn't eat up ESR's line because OSI had a definition or a license list. Initially, it had neither. The media ate it up because of the software, which hadn't been called by that name before.
Nobody's abusing anything here but OSI's sense of entitlement. Comment above is right: there's no exclusive right to the term.
OSI did not commandeer the phrase "open source". OSI coined "open source".
English-speakers combining those two to produce the intuitive way ("you can see the source code") gives us our present situation.
Both the comment and the article make a very specific claim about the term "open source": the (frequently encountered) falsehood that the term "open source" preceded OSI, and that the OSI made it their prerogative to wrench it from the mouths (keyboards) of programmers so as to suit the OSI's desires. Not only is that not true, it doesn't seem to be accompanied by any appreciation of the irony involved here, considering that the exact opposite thing is what's actually going on—by the folks who are complaining about retconning language!
Christine Patterson, who proposed "open source" at the freeware summit, has written that she mentioned it to a friend in marketing at the time, and the friend advised against. "Open" was too played out, meant everything and nothing.
How many times are the goalposts going to move in this conversation?
> Christine Patterson
Peterson.
On "open", see:
https://en.wikipedia.org/wiki/Open_Software_Foundation
https://opensource.org/pressreleases/certified-open-source.p...
"Open" wasn't greenfield. "Open" was a marketing buzzword in computing all through the eighties.
If you'd like to send a counter-argument, I'd be happy to read it. If you'd prefer to play referee, I've no interest.
The first, strong-but-indefensible claim is made—the one that argues "open source" was in play and that there was some "original" meaning that predates OSI and their attempt to co-opt the term.
This is disputed.
We then see a retreat from out of the bailey into the motte, where we appeal to the "intuitive" understanding (presumably first mover now doesn't matter). Later we're back somewhere in between, except this time musing that perhaps "open" didn't mean anything at the time the Foresight group decided to embroider "open source" on their crest.
In summary, the only thing we've seen is a bad argument that was subsequently vacated, leaving a void in its place plus nothing more substantial than vague suggestions that some other arguments exist that can quash OSI's stake in the term "open source".
So you'll have to forgive me if I haven't yet responded with a counter-argument that requires guessing what claims your mercurial stance is going to have you calling for me to take down next without you actually going through the effort of arguing them in the first place—and thus pinning them down into a form that can actually be squared. Are you able to commit to laying out what you actually believe here and your rationale for why it's valid line of thought?
In other words, if you want to hear a counter argument, you're going to first need to articulate the initial argument that you expect to be countered—preferably in the form of complete sentences that can be read as a deductive play-by-play, each point following from the last, rather than non-sequiturs appealing to incompatible values and adhering to no common goal besides opposition to OSI.
"Open source" probably got coined/invented multiple times independently, which is not surprising since "open" was very common as well, or perhaps the OSI folks simply forgot they heard it before (human memory is not very good).
https://groups.google.com/forum/#!msg/comp.os.ms-windows.pro...
http://www.xent.com/FoRK-archive/fall96/0269.html
Especially that Caldera announcement for OpenDOS seems fairly high-profile.
I'm not suggesting that Christine Peterson is lying when she claims to have coined "Open Source"; it could be coined independently on several occasions, or perhaps she had seen the term but merely forgot about it.
Even if OSI would have coined the term, that still wouldn't mean they should be in 100% control of all usage of it. That's not how language works.
You can dismiss my points as a rant. In your position, I might be very tempted to do the same. But that is exactly why OSI is where it is right now. When every OSI critic is a heretic to be ignored, OSI becomes more and more insular by the day. The heretics come to outnumber the faithful.
It portrays itself as open, it talks all about being "free for open source", it uses pictures like https://licensezero.com/doors.svg (warning, site contains misleading misinformation), but it's intentionally misleading and equivocating, and benefits from the resulting uncertainty and lack of clarity. It's a proprietary software license that tries to convince people to let it into their ecosystem.
What's more dangerous to leave around unlabeled? The poison that looks like glowing green toxic sludge and smells so bad it makes your eyes water, or the poison that looks like clean drinking water at a glance? Which one is more likely to harm the unwary and the uninformed? Parity's brand of poison might not have a label on it that explicitly says "clean water, drink me", but it's more dangerous if you're not deeply familiar with license minutiae and history. It's an attractive nuisance.
> Unlike scores of OSI approved terms, its rules are plain for all to read and understand.
So are the Creative Commons non-commercial and no-derivs licenses, and they're not FOSS either.
> But that is exactly why OSI is where it is right now.
Wildly successful in maintaining a list of licenses people can trust that describe an ever-growing amount of software, against a multitude of threats? OSI is an extremely cautious and conservative organization, as it should be.
> When every OSI critic is a heretic to be ignored,
Constructive criticism can be useful. Competing agendas advancing not-quite-open licenses are not. And no, not ignored, nor elevated to any position as vaunted as "heretic"; ignoring would be dangerous. FUD needs countering, and software that tries to go from FOSS to proprietary (including "proprietary but we wish you'd pretend it's open") needs forking and the original consigned to a historical curiosity and a reference for anyone thinking of doing the same.
> The heretics come to outnumber the faithful.
Only in their wildest dreams. The self-styled "heretics" are just loud.
As for OSI's success, it predates any license list. AFAICT, OSI launched---and achieved media liftoff---with no more than the example license section at the end of DFSG. Only later did the org drop the examples section and start a list. Principally to provide org blessing to companies writing their own new terms for releases. Which was controversial.
Meanwhile, I've yet to find a situation where I'd recommend incorporating the OSI license list into legal terms or functional policy. I've regretted advising as much in the past. And helped clients make others regret it. See: https://writing.kemitchell.com/2019/05/05/Rely-on-OSI.html
You've left some space for constructive criticism, but only nominally. Apparently any deviation from your definition of "open" means I not only get discounted, but need to be actively opposed. But our disagreement is demonstrably narrow: if I struck one numbered item from Parity 6, I take it you might approve!
As for whose views are how popular, I'd note that a few OSI reformers have called for honest opinion polling of developers. Last I checked, those polling proposals have got as far as their reform proposals: nowhere.
By the by, attractive nuisance is a legal doctrine concerning risks to children. Some programmers are in fact children---I got started young---but as a whole, programmers don't need any licensing nanny. Especially if the legal terms welcomed them to read, which in my experience the CC "legal codes" do not.
I'm also aware of the history of OSI, and in particular that it learned from early mistakes and created a narrower set of recommended licenses, and actively pushed back against further license proliferation. And yet it seems like you now want it to approve licenses again, as long as they're licenses you wrote.
> You've left some space for constructive criticism, but only nominally. Apparently any deviation from your definition of "open" means I not only get discounted, but need to be actively opposed.
On the contrary, there's absolutely space to improve. But not every change is an improvement.
Also, it's an unpleasant rhetorical trick to attempt to marginalize the OSD as "your definition of open", as though you have an equally valid one.
Constructive criticism and manufacturing confusion don't mix. Constructive criticism needs more clarity and distinction, not equivocation and imprecision.
> But our disagreement is demonstrably narrow: if I struck one numbered item from Parity 6, I take it you might approve!
Not even close; Parity isn't salvageable. By the time you remove enough from it that needs removing, what's left is then just a gratuitously incompatible software license. (As a side note, I can appreciate its approachable style, and if it had come about years ago or if provided a path to compatibility with existing copyleft licenses, that would be a useful property rather than a trap.)
Among other things:
"Contribute", clause 1, requires public publication rather than providing source to people who received a binary.
"Prototypes" clause 3 requires publication of private changes, and infringes freedom zero.
So does "Prototypes" clause 1.
And, of course, "develop, operate, or analyze" completely breaks freedom zero.
Also, from the realm of opinion rather than fatal problems: The link to an anti-copyleft organization should go, the "defense" clause should allow defensive patent usage, and "Protoypes" clause 2 adds a giant loophole ("non-production user testing") that's only mitigated by "Prototypes" clause 1 and 3.
I mentioned personal definitions of open source not to separate your views from OSD of DFSG or What Is Free Software? but to recognize that views of what those highly generalized, nontechnical, post hoc political documents mean in practice varies widely between individuals. There is no single, canonical, workable reading of OSD that follows necessarily from its text. The best candidates for that kind of reading exclude copyleft as we know it, which OSI saw in feedback from very early days. It's not a question of validity in any technical sense, but of mindshare.
If by "anti-copyleft organization" you mean Blue Oak, see https://blueoakcouncil.org/copyleft https://blueoakcouncil.org/company-policy https://blueoakcouncil.org/starter-policy
Nobody here is your enemy. As far as I'm aware, nobody's conscious intentions are anything but pure.
Regarding the Parity license, it used to be called "License Zero Reciprocal" and was submitted to the OSI for approval. When it became clear that that wasn't going to happen (because, as you mention, it clearly violates the OSI definition of Open Source), the author withdrew it[1] and changed the name before it could be formally rejected.
[1] https://lists.opensource.org/pipermail/license-review_lists....
Copyright law regulates public performance of any covered work - whether some activity counts as "redistribution" is ultimately a matter of law, not just licensing. AGPL protects the user by providing explicit language for what's required wrt. the public-performance case. Other copyleft licenses do not deal with this ambiguity.
I still disagree strongly that L0-R fell outside OSI's definition. Do you have a reading of that definition that doesn't exclude existing OSI-approved licenses? A few folks tried to build some, purpose-built to exclude L0-R, but they didn't stand up. People opposed the license for entirely separate reasons, and only tried to talk in definition terms after weeks of trying to steer discussions there.
Your description of AGPL is pretty good, but it better suits OSL than AGPL. AGPL's approach to network copyleft stands largely apart from its approach to distribution-triggered copyleft. Only the definitions of "modify" and "Corresponding Source" get reused in meaningful ways.
Is this actually true? It was my understanding that the term "open-source" was invented by or around esr, one of the founders of OSI.
Being called a "nihilist capitalist" for quitting your day job for working on open source software is certainly a rather ... curious ... experience.
?
The landscape is pretty sad these days. FSF is subverted by corporate interests. OSI is even worth, their entire existence is to serve corporate interests.