> "Fair Source" is abundantly less clear. It implies some sense of "fairness" which can mean drastically different things to people.
Fair source has a very clear definition:
Fair Source is an alternative to closed source, allowing you to safely
share access to your core products. Fair Source Software (FSS):
- is publicly available to read;
- allows use, modification, and redistribution with minimal
restrictions to protect the producer’s business model; and
- undergoes delayed Open Source publication (DOSP).
The key here is delayed open source publication and limited restrictions up to that point.
> allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model
That part is not something that a lot of folks running "source-available" want. It may have nothing to do with competition.
I license most of my stuff as MIT. It allows folks to reuse the source in any way they want (few people do, which is fine by me). Just don't come crying to me, if you mess things up.
I can easily envision authors of open-source projects being hit, if their stuff gets caught up in things like breaches, malware, or scamming. In many cases (in the US), the suits may not have merit, but they are still a major distraction. Just the suit can be crippling, and many suits can't be anti-SLAPPed.
There's a few reasons that I like to open my source:
- It allows folks to ensure that my stuff doesn't violate anyone else's IP;
- I would like to hear if I have made any big mistakes. Sometimes, someone may see that I'm doing something in a boneheaded way, and offer a correction (sometimes, in a nasty way, but I still appreciate the help).
- If there are problems with things like App Store reviews, or SDK bugs, the ability to point to the entire project, is helpful.
- I am sincerely interested in "giving back," and genuinely hope that folks (even if they are a bit "rough around the edges"), can learn from it.
On another note, I suspect that the use of "zealots" throughout the post, may be to encourage passionate response. Many folks like all the clicks that outrage brings.
Just because some people decide to define a term doesn't mean that the words making up that term aren't confusing and misleading. Defining "fair source" without regard to common understandings of what's "fair" is guaranteed to leave a good chunk of the world disliking your terminology.
It seems that it doesn’t so much “have a very clear definition” as a small faction are attempting to create a definition.
What is clear about “with minimal restrictions to protect the producer’s business model”? Don’t business models change over time? Doesn’t this suggest that if I were to stake my venture on such a “fair” element of software, it would be fine unless I turned out to succeed, in which case the producer could rightfully box me out (or, more likely, extort a ransom)?
Which, I suppose, is a roundabout way of saying: “fair” to whom? Such an “author-first source-available” license may well prevent the specific unfairness of AWS-style snarfage, but would seem to open the door to different kinds of unfairness years down the line.
Until I read your definition I assumed what the parent comment mentioned i.e. there's some inherent fairness in the project/code, which made little sense.
> It sounds like ICANN has tried to get rid of it but had too much opposition.
Not my recollection. As far as I know ICANN said they will retire it, a handful of companies in Russia complained and ICANN said that if they want to retain it they need to get the ISO 3166 Maintenance Agency to create an exceptional reservation. Today it has an exceptional reservation so .su won't be retired.
As for how that reservation was created and what the process is I don't know.
> It's absolutely possible that someone will asking for an exceptional reservation for IO at ISO and it can be kept alive forever.
I agree it's possible, I disagree with OP that it's a foregone conclusion.
At this point if I were the owner of a .io domain I would treat that as the unlikely best case scenario and start looking at what domain I'd fall back to if ICANN sticks to their rules.
.uk only exists because UKERNA was already using it (or, rather, UK.) for JANET's own X500-ish system that pre-dates the standardisation of DNS.
At one point, it was intended that moving the UK's internet resources to .gb would be the final stage of the transition from the internal JANET system.
By the time I first heard about that in the early 90s, that had already gained legendary "that'll never happen" status - and, sure enough, the transition was declared complete when the last UK.AC.SITE <-> ac.uk mail gateways were retired circa 1996.
Right, but confusingly, GB is the ISO 2 code for the United Kingdom, even though the United Kingdom is much bigger than Great Britain, where the GB abbreviation comes from.
I mean, the TLD .pizza exists, so could .io move to the same mechanism that allows those to exist? Or is it something like 2-3 character TLDs are reserved for country codes?
Breaking with ISO 3166-1 comes with the risk that a new ISO-standardized country cannot claim its TLD.
So in order to reclaim the TLD as generic, startups dont just have to persuade ICANN, they have to make the case to ISO that IO is a significant enough code that it should be an "exceptional reservation" like UK, UN, EU, and SU.
.pizza is a gTLD (generic top level domain) rather than a ccTLD (country code top level domain). ICANN rules say that gTLDs have to have three characters or more. So you can have .xyz but not .xo
> In this case, though, would .io stay with the UK or come under Mauritian control? It’s not clear.
Before the retirement of .yu, Slovenia wanted to hold on to it, but it was not the successor state of Yugoslavia so they had to relinquish control and pass it to Serbia. So going by that logic, it would not stay in the UK (for long).
Mauritius could decide to incorporate it as "Mauritius Indian Ocean Territory", hence maintaining the CC. I expect .io owners will likely suggest something like that, while showing them how much money they could get from a 10-15% deal similar to what Tuvalu has for .tv. Nobody likes to burn money.
That is not possible. However it's possible that "not much" will happen, but the .io domain would have to move to the control of another country with the current rules in place. For historic precedent on this you can look at the .yu domain which was forcefully transferred to Serbia (more precisely FR Yugoslavia) when Slovenia did not want to give it up.
I don't think it's very likely that it will be retired given the state of .su.
I still feel that it was a big mistake in retrospective that we ended up with serde style macros all over the place instead of getting introspection early on. The end result is ungodly amounts of quite convoluted code that in parts is not even compatible with each other. It also greatly restricts what you can do, because you cannot be conditional on the thing you're generating for.
I'm not sure if the C++ solution proposed is the right abstraction, but I feel very confident in saying that Rust's is not the gold standard that one should strive for.
Really makes me appreciate Java/kotlin's annotation processors. They are much cleaner/clearer APIs for writing compile time generated software and the entire ecosystem has benefited from them.
I, uh, cannot in good conscience call Java's annotation processing APIs "clean" or "clear"; the way they interact with the multi-round processing model, and in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time.
Despite their definite flaws, though, I have to agree: compile-time code generation via annotation processing is something I think we should do more of (and invest more time into better tools for it).
> in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time.
I'm not exactly sure how you can really make this particular problem better when working with compile time code generation. But what I'd say WRT cleaner and clearer, Java and Kotlin both expose much higher level type information than is available in rust's proc macros. That's mostly what I meant by cleaner and clearer. Without needing to pull in weirdo not-quite-third-party libraries, you can reflect on and generate for all sort of different type information.
It seems to me that something like this should be possible with rust given its early transformation into high level bytecode. But I could see why the rust devs have pushed back on doing that as it'd really lock in features they might not want to lock in.
Correct, it's gplv2 or later.
v2/v3 GPL compatibility is also sort of an abstract thing - it gets talked about a lot (IE do the terms have to actually conflict as applied to a given situation or only conflict in theory) , but you also can't file a lawsuit with a claim of "GPL incompatibility". You'd have to file a claim for breach of contract or infringement (or both).
This matters because if, for example, your main incompatibility is around the patent pieces (that's one of them), and there are no patents anywhere involved, you may have a hard time convincing a judge that there is really a breach of contract.
I do not believe it is legally "GPL v2 or later" at all. The original b2 license was GPL v2. There was no or later version option in the original b2 license. Given that WordPress is a derivative work, it has to keep the same or compatible license. Which "GPL v2 or later" is not.
Note how the original license is GPL v2 at [0], then the "or later" header is added much later at [1] seemingly out of nowhere.
Not that multiversion support was one of the goals that I had when I built rye. It's also something I want to see if it's possible with uv. Multiversion support is entirely orthogonal with how you are installing packages.
> It removes incentives for maintainers to adhere to sane versioning standards like semver
Semvers does not matter in this way. The issue with having a singular resolution — semver or not — is that you can only move your entire dependency tree at once. If you have a very core library then you are locked in unless you can move the entire ecosystem up which is incredibly hard.
Fair source has a very clear definition:
The key here is delayed open source publication and limited restrictions up to that point.reply