Hacker News new | past | comments | ask | show | jobs | submit login
Choosing a License for GoatCounter (arp242.net)
50 points by mplanchard 57 days ago | hide | past | web | favorite | 70 comments



The EUPL has network protection, but it can be circumvented pretty easily. That’s because the EUPL also has a clause which lets you convert EUPL code to any of a long list of “Compatible Licenses”, including GPLv2, GPLv3, and many others. So you can just convert to a license without network protection and use the software under those terms.

(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.)


> some companies avoid AGPL due to its extremely “viral” nature

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.


The problem is that it will also affect code that's only tangibly related to the AGPL'd code. See e.g. the Google page: https://opensource.google/docs/using/agpl-policy

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).


I'm familiar with Google's AGPL policy. Google doesn't have a policy against paying for an alternative license, though; the bottom of the page you linked to says "In some cases, we may have alternative licenses available for AGPL licensed code.". Offering your code under a copyleft license and selling an alternative license is a long-standing successful business model.

>> 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 .)


This kind of post always makes me happy and sad.

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.


Already stumbled on the first paragraph:

> 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 and MIT are functionally equivalent, which really means there are no differences.

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.

[1] https://www.rosenlaw.com/oslbook.htm


Yeah, functionally they're identical but the ISC is slightly shorter and slightly more readable.


Perhaps that is simply length/readability?


There are very few real copyleft licenses in the age of SaaS. Basically just Parity [1] and API Copyleft [2] licenses. The rest allow corporations to build proprietary services on top of such software without releasing any of that proprietary code.

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.

[1] https://paritylicense.com/

[2] https://apicopyleft.com/


I'm not an expert on licenses, but from my own understanding of AGPL, I'm not sure why Parity and/or API Copyleft would give better protection against SaaS corporations. Would you be able to explain why AGPL is not as good as the two licenses you named?


How do you understand AGPL?


Do the (A)GPL or the EUPL really require the publication of hacks for private use? I thought that was always linked to redistribution of the software, not use.

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


AGPL says roughly "you have to give the source code to anyone who accesses the software over a network". In other words, it's basically trying to say that software-as-a-service counts as "redistribution" for the purpose of the license.

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....


> In other words, it's basically trying to say that software-as-a-service counts as "redistribution" for the purpose of the license.

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 never withdrew L0-R and OSI never rejected it. But that implies a formality to the process that was never there.

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.


> 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”.

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.)


Different people have different meanings for "open". Right now there seems to be something of a crisis of terminology, where "open source" originally just meant "the source is available". The the OSI stepped in and gave it a specific definition with the OSD, but some people still continue to use it in the original "source is available"-way, whereas others use it only to mean OSD-compatible or OSI-approved.

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.


The central thesis of your comment, which also mirrors an oblique side remark from the article, is a total fabrication.

OSI did not commandeer the phrase "open source". OSI coined "open source".


But the English language already had definitions for "open" and "source".

English-speakers combining those two to produce the intuitive way ("you can see the source code") gives us our present situation.


Regardless of how valid anyone sees your "but", it's not the extent of claim made in the comment I replied to.

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!


"Open" was a high-froth marketing term in computing long before OSI came around. "Open source" itself was and is commonly used in intelligence.

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.


This sounds like a retort to OSI's "open source", but it isn't. It contradicts nothing and does much less to support the "other" side than it seems to.

How many times are the goalposts going to move in this conversation?

> Christine Patterson

Peterson.


Thanks for the typo correction.

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.


> This sounds like a retort to OSI's "open source", but it isn't.


That's not an argument, it's a naked conclusion about an argument.

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.


Here's a breakdown of this particular bait-and-switch:

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.


Usage examples of "Open Source" from 1993 and 1996:

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.


Not exactly, it was used before that as well, I don't have time to find references for this right now as it's Dec 31st and I'm going out in a bit, but will update the article with them later.

"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).


The quip "human memory is not very good" is the most accurate part of this comment.


People also misuse the term "public domain" to refer to a wide variety of things that mostly amount to "I found it somewhere and I want to use it". That doesn't make it correct.

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.


When a large number of people use a word to mean something, that's what the word means. My definition of "public domain" doesn't trump their definition, just because I'm a lawyer or a programmer or somehow more specific. Neither does James Boyle's or Larry Lessig's.

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.


No, you should ignore OSI crap. They interpret "open" as open to be closed and abused by corporations, not remaining open for end users.


> No, you should ignore OSI crap. They interpret "open" as open to be closed and abused by corporations, not remaining open for end users.

This is incorrect. OSI's approved licenses include copyleft licenses, which do not permit releasing closed-source versions.


A requirement to "Contribute software you develop, operate, or analyze with this software" is incredibly extensive - imagine if, e.g. gcc or valgrind were licensed with this clause! You would be well advised not to ignore what OSI has to say; they're there to protect users and developers, not just corporate entities.


But it's good to have the option, no? Always depends what you try to license, and in some cases I think it's good to have a very strong copyleft license available. gcc might not be it, other software might.

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.


We don't need more non-FOSS licenses in the world. I'd like to see more use of copyleft as well, but the whole point of copyleft is to keep software FOSS. If the license isn't FOSS to begin with, that defeats the purpose.


See, thats where we disagree. And thats perfectly fine, but i do honestly think we need at least one more copyleft license, one that actually works. FOSS ist just a bunch if words, which, apparently mean different things to you than they do to me. Maybe you are going to say that my interpretation is invalid, and i should be accepting the status quo. But well, that just doesn't make any sense to me...

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.


There are two critical reasons I think it's important to stick to the letter of the OSD and DFSG:

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.)


Defaults can be important, but the game to win isn't software licensing. That's just a play in bigger games like end-user rights and developer autonomy and dominating a market niche. Means, not the end. Unless it's really all about righteous cred strictly within the software industry itself, for self-edification or advancement.

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.


> the game to win isn't software licensing. That's just a play in bigger games like end-user rights and developer autonomy and dominating a market niche. Means, not the end.

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. ;)


Whether in activism or negotiation, oversimplifying complex problems, then taking absolute positions and refusing to compromise, doesn't work. The only upshot of black-and-white positioning is a reputation for being uncompromising. RMS is and will always occupy that space. And as an activist he'll go down as largely unsuccessful on his own terms, beyond the threshold of popularizing his own ideas among his own kind within his own industry.

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.


Taking nuanced positions does not require accepting yours. Compromises do not require moving towards your positions. People who disagree with you are not automatically absolutists just because they have different principles.


You're completely correct!

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.


Parity pretends nothing and hides nothing. Unlike scores of OSI approved terms, its rules are plain for all to read and understand. Hackers can quote the terms in HN posts and grok them without taking anyone else's word for it.

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.


> Parity pretends nothing and hides nothing.

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.


I am intimately familiar with license minutiae and history. I wrote Parity (with lots of hackers!) and License Zero.

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 well aware of who you are and that you wrote the non-FOSS license in question, which is part of why it seemed worth the time to respond to address the misinformation. I don't have any expectation of convincing you, only of making sure nobody else mistakes your work for contributions to FOSS. When I said that Parity is "more dangerous if you're not deeply familiar with license minutiae and history", I wasn't suggesting you were unfamiliar, but rather, that you've built a trap for others.

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 obviously think highly of my own licenses. But I also think "open source" should embrace CAL, SSPL, and 996, which I had no hand in. I think it's safe to say CAL wouldn't have gone anywhere with the OSI to which I proposed L0-R. But I no longer really care whether OSI approves terms or not. I don't care if it approves Blue Oak or not.

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.


I think that you should select a license which is both FSF and OSI approved. Alternatively, publish the source code as public domain.


I had the same understanding as you regarding hacks for private use and was also confused there. My understanding of the [A]GPL is that you can modify software and even use it internally at a company without the distribution restrictions kicking in. I’m far from an expert on the topic though.


For private use, certainly not. In case of distribution, yes. The EUPL consider as distribution "providing on-line access to essential functionalities of a software". This is tha case of SaaS.


The GPL indeed only triggers on redistribution. The AGPL's extra clauses over the GPL only trigger on modification of the software (not use) and only require source redistribution to users of the service.


I was expecting the BSL would be chosen, as that seems to be gaining a bit more popularity lately (mariadb, sentry, cockroachdb, etc). I wasn't very familiar with the EUPL. Interesting reading more about it.


The thing with the BSL is that it's not OSI approved, and never will be as it doesn't fit the OSD, which was one of my requirements (for pragmatical reasons, not ideological ones). I should perhaps include it in the comparison.


Makes sense. Thanks for the reply!


> the term was around for a long time before the OSI was started

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.


ESR didn't invent it (nor does he claim to) just popularized it. The credit goes to Christine Peterson[1].

[1]https://en.m.wikipedia.org/wiki/Christine_Peterson


Thanks for that source. She claims to have come up with the term on Feb. 3rd, 1998 and the OSI was formed the same year. That suggests the term wasn't used long before the OSI.


"Open" was a marketing buzzword in computing long before that. Christine has written that she ran "open source" by a friend in marketing at the time and they told her it was vague and played out.


There are earlier usages of "Open Source"; see my other comment: https://news.ycombinator.com/item?id=21928290


When researching the entire thing several weeks ago I came across references from the earlier 90s and I think even late 80s. I don't have the references at the moment, but I'll find them again and add it when I've got some more time.


the AGPL is clearly the best free software license nowadays. It could supersede the plain GPL, as it inherits the same spirit in the cloud context.


I agree, I re-licensed my own GPL projects to AGPL recently.


I always feel weird when reading long explanations about why someone chooses a copyleft free software license for nihilistic capitalist reasons (I don't care about the four freedoms, and I want money).


I work on this full-time; it's my only source of income. I don't think it's especially capitalist or nihilist to shield yourself from potential abuse by actual nihilist capitalist who will stop at nothing to make a buck. Not doing so would be naïve.

Being called a "nihilist capitalist" for quitting your day job for working on open source software is certainly a rather ... curious ... experience.


But that's not what this is? He very clearly states that he just wants other people who profit from it to contribute their changes back. That seems to be his main requirement, all others are just there to make it easier to understand for people what they are allowed to do (concise, not overly restrictive, easy to read). How is that nihilistic and capitalistic?


"nihilistic capitalist" = "I want to support myself full-time with this"

?


The author of this piece really came across as a nihilistic capitalist to you? Honestly?


What about WTFPL?




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: