Author here. The draft is currently in ISE review (there was not enough interest at IETF or IRTF).
If you want to engage or need more info gnunet-developers@gnunet.org is a good place to start and ask questions.
A lot of work has been going in over the last years to separate the protocol properly from the underlying stack (gnunet).
We are currently also working on a spec for our DHT (which is a required basis for GNS).
One of the reasons we specified GNS first is because of the order of fundings we receive(d).
Thanks for working on GNS. It's genuinely the most exciting tech project i've heard about in the past few years and i'm sure many people would like to try it out or get involved given proper communications channel.
A few questions:
- are you people open to the idea of an IRC/XMPP chan or a weblog/gemlog? following from afar (without being on the ML) looks like there's not a lot of activity, although i can see with my bare eyes the draft spec has evolved a lot
- how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with?
- are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations
- why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me
> - are you people open to the idea of an IRC/XMPP chan or a weblog/gemlog? following from afar (without being on the ML) looks like there's not a lot of activity, although i can see with my bare eyes the draft spec has evolved a lot
Yes, the only reason why there are no posts on the ML and very little posts on the GNUnet news archive is that I do this in my spare time.
Now, the draft is mostly(TM) finished. So I do not see a reason for blogging anymore.
> how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with?
That is a good question. GNUnet is still figuring out the transport layer. Until that is in a state that we are satisfied with, we will conduct performance tests.
That being said, looking at other DHT proposals out there we think that R5N (and especially the improvements we have planned) are far superior. It still has strong roots in Kademlia though.
> are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations
> - why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me
As this was confusing, it is removed from the draft. I think you can still find it on some slides when you look for it. In general, what is currently explained in the draft should be correct and there is no need to think about this too hard ;)
I think so. There seems to be an understandable conflation of the technical means of name resolution (the draft) and the governance issues related to zones and names. Governance of zones (but especially root zone governance) is out of scope of the draft. But it is of major importance for any real world use.
> - how can we support GNS and help make it a reality?
My usual response would be: Install GNUnet and run a zone.
But, we are currently in the process of fixing some major bugs in GNUnet and it is just not yet ready. As you correctly assessed, we are a very small team at the moment.
Abuse through name confusion is possible, of course.
I do not think this can be solved while at the same time supporting i18n.
The real question is: What is the attack vector and how can it be mitigated.
A GNS deployment and the selection of root zones should eventually converge towards a trusted namespace (for each individual user).
There is not really any incentive having a TLD zone in your configuration that would allow such odd labels as there is not much use beyond fraud in using them.
The governance policies ("rules") of the zone are expected to "trickle down" the delegation chains or alternatively damage reputation of the parent zone.
I wish them luck. As being one of a handful of people who have designed a scalable naming system that made it into production I can tell you that there are a lot of dragons there. A good start would be to look at the work done by the IETF on DNSSEC.
That said, as systems problems go, it is a really juicy one and brings a lot of understanding to all those who undertake it!
Handshake will suffer all the same problems as other cryptocurrency-based systems: centralized control in the hands of whoever is the most ruthless at acquiring currency.
Handshake is even worse because it claims to assert control over top-level domains. Most other systems just claim one top-level domain (e.g. .bit) and assert control over that one.
I thought handshake was pretty cool when they handed out millions of dollars to free-software project (although that was a little fishy). But i think this video presentation does a fair job of explaining the problems (or imo non-problems) they try to solve with Handshake (auctions for names) and the actual problem GNS tries to solve (crypto-secure resolution without enumeration/amplification).
Handshake is focused on fixing something that isn't broken to introduce auctions instead of first-come-first-served in the DNS world. I personally don't see any interest in that, but i also don't see much wrong, except of course my clever names are going to be outbid by people with more money :'(.
They handed out DNS-auction-tokens, which are free but have some silly value because of the current crypto bubble.
Algorithmic auctions for names simply don't work. There are bots trying to register basically every conceivable name for the lowest possible fee. Once sold, the name is permanently taken, unless the bot owner decides not to renew it every 2 years. That's why they don't work.
It's the same problem that most cryptocurrencies face: by the time you want something, it's almost guaranteed that someone else already took it. Real-life capitalism also suffers this problem with regards to land.
Wait, they didn't hand out real money?! Was it even possible for the projects to convert those tokens to real money?!
> That's why they don't work.
Strongly agree!
> Real-life capitalism also suffers this problem with regards to land
The two problems are related but different: land property titles are not auction-based. They're far more expensive than a domain name (and that's a problem that land can even be sold), but it's still a first-come-first-served system. If you had auctions for land, you can be sure only the richest people would own land at all (which is already the case to some extent, but the situation would arguably be worse).
Yes, you can trade the tokens with people who are willing to pay money for the tokens. Same as any cryptocurrency-tokens.
The problem with land titles is very similar to the problems with domain auctions. The problem is unchecked first-come-first-served. Whoever happened to put a fence around that bit of land 300 years ago got to own it. Now 300 years later, we don't get the same privilege because all land in existence was already fenced around. Instead we have to beg someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who fenced it off back at the beginning. And it is the same with most cryptocurrencies, and it will be the same with Handshake names.
More like: Whose henchmen ran off the farmers working that land at the beginning, or alternatively declared it their own and started demanding taxes at swordpoint from those farmers.
Thanks for the explanation, i understand your point better. To be clear, i'm also strongly opposed to private property, i just didn't understand that's the point you were trying to make.
the entire session, which is a roundtable on on the future of DNS is 1h+. the section on GNS specifically is only about 20 minutes (at the very start) and the section on handshake is an additional 20 minutes.
i agree though, i prefer to be able to rapidly seek and skim for interesting things, rather than commit time to videos when i'm not sure if it's something i want to invest time in.
I searched around the GNS site quite a bit and couldn't find an answer. It is pretty well understood today that the main obstacle to decentralized naming is Zooko's Trilemma, much as it was well understood pre-2009 that the main obstacle to decentralized cryptocurrencies was the double-spend problem.
I'm a bit surprised that "here's how we solve Zooko's Trilemma" isn't front-and center on the GNS website.
> If this is decentralized, what is its solution to Zooko's Trilemma?
I was going to say: Gnunet pet names aren't globally unique, therefore Gnunet gives up on having the human-meaningful addresses be globally unique. However, from your link it appears that there is no requirement in Zooko's Triangle for those human-meaningful addresses to be globally unique. So it doesn't actually give up anything:
1. Pet names are human meaningful (though not globally unique). Check.
2. Public keys are secure (and in the typical cases globally unique, btw). Check.
3. Gnunet zones are decentralized. Check.
There you go. Triangle drawn.
AFAICT Gnunet punts the names down to the user in a similar way to how Convergence punted CA choice down to the user. In both cases the user chooses which entity or entities to trust, being more or less strict in what to do if those entities disagree based on some predetermined criteria.
In reality, however, I remember that Google balked at adopting Convergence because it seemed likely that most would have eventually just standardized on delegating their own choice of "decentralized" CA to Google. Then you'd end up with an ostensible decentralized set of authorities where that set is simply { Google } for the vast majority of users.
I don't see any mechanism in Gnunet that would avoid a similar fate. Especially given that the examples given in the current docs are so goddamned confusing and convoluted that a tempting workaround would be "Step 1. Just set Google as your thingy." I offer into evidence exhibit one: Gmail.
> it appears that there is no requirement in Zooko's Triangle for those human-meaningful addresses to be globally unique
If they aren't globally unique they aren't really names anymore.
If I send you a link involving news.ycombinator.com, and you think that news.ycombinator.com is really furrypr0n.com, I would say that we are not using the same naming system.
Google public dns is different than Gmail. It isn't the source of the data, for one thing. It's just a cache. The cost of switching to someone else's cache is approximately zero. And it's not very difficult to set up your own nameserver that actually queries the root nameservers.
The resolution mechanism is decentralized. Zones are published and resolved through a peer-to-peer mechanism with the goal of preventing censorship and allow for query/response privacy.
Is the namespace decentralized? That depends on how you use it.
If you use GNS with an ICANN provided root zone configuration (this is an example, there is no such thing atm), then your names will have the same meaning as for other people using this configuratin.
If you build your root zone from scratch, you will have modified the namespace in such a way that names are no longer unique.
If you go full petname system (ie. names are basically treated as your personal address book), the names are no longer unique.
Think about DNS:
If you are sufficiently technically literate, you can run your own root servers and use them. Is DNS at odds with Zookos triange? I would argue: Yes, depending on how you use it. It is just very common to use it with unique global names.
I have experimented with GNS. While DNS is designed to be a tree/hierarchy of zones, GNS appears to be a web of zones with no real notion of a root zone. ICANN-provided zones will at best be just a bootstrap zone - not a root zone. Globally unique names don't seem to be a goal at all.
The issue is going to be how to communicate a domain name that resolves identically between sender and receiver. Some sort of relative domain naming will have to be implemented. Perhaps sub domains may have to be resolved against the zone used to access the original information. Or, the address may also specifies the zone pkey against which names have to be resolved. If this could be resolved, the Zooko's triangle may finally be completed, without the need for globally unique names.
This system pushes the "not human friendly" parts into the initial setup of a trusted root zone. This also establishes chain of trust security. The fact this can be used to create nationally and corporately controlled root namespaces that ship with machines seems like a survival trait even if I don't personally like it.
After that initial non-human friendly+secure part, the ideal result is that it is secure+human friendly. The reality is that this is just as vulnerable to eventual implicit centralization like DNS has been. That just means things need to be hijacked by regulatory capture instead of hacking.
The “human-meaningful” point seems like a pretty moot point to the end-user in a browser. See also: the current trust the general browser user places in a lock symbol somewhere on screen.
GNS does not "square" Zooko's Triangle. It relies on petnames as said above, so names are purely local, like /etc/hosts. The global identifier used by each Zone is an opaque identifier, like IPFS hashes, that is not human memorable.
before diving into a deep and complicated rfc, is there a short document somewhere that describes at a high level the various threat models and mitigations that the system proposes? i had a look on the website and the closest thing i could find were some videos of talks, which i don't have time to invest in...
went back and watched the video. actually only 20m and totally worth it.
i'm left with a few big questions:
1) how can you have query privacy and zone privacy in the same system? seems like query privacy would open the system up to dictionary attacks at least; with a possibility that depending on how the dht is implemented, perhaps even high performance locally distributed dictionary attacks could be executed?
2) the issues of economics and property rights (as well as invested parties in the economy of name sales and registration) seem like they could collide with the technical goals with something like this gaining traction, has there been any thought given as how these political/economic concerns could be addressed?
To 1)
Yes, IF you know the zone key (which is a public key). You can perform a dictionary attack for common label values. This is discussed in the security considerations
To 2)
This is a governance issue. Theoretically, you could deploy GNS with an ICANN root zone. BUT, the system is designed to give users the freedom to override defaults if necessary (see the root zone section in the draft).
GNS clients will likely ship with a default zone configuration.
If you operate a zone and are a considered trustworthy third party, nobody can prevent you from taking coin for adding delegations to your zone or offering a platform on which you can trade the labels.
I really like the idea of a pinning service for domains that uses provider lists, where you can subscribe to ICANN and root name servers but then override or add your own domains and TLDs.
When reading about GNS for the first time, that was really the killer feature for me. How many times have i failed to resolve domains that were either censored, seized or simply forgotten to renew?! With GNS, as long as the public key lives in my zone i'd be very confident i can resolve thepiratebay.org or wikileaks.org no matter what some government has to say about it.
It's different because it's not subject to IP spoofing, and does not require to run specific infra to setup a zone. Your zones live in the DHT not on a nameserver of yours, so even your less-technical friends given the right software UX could publish their favorite domain names in their zones for them to be forever resolvable, or as shortcuts.
Like maybe there's this super cool blog about guitars my friend akhmad follows but i can't remember the URL right now and of course Google is giving me the worst SEO-induced results. But i know my friend akhmad published it as "guitar" in his zone because he also forgets the name every now and then, so now i can just go to "guitar.akhmad" in my browser (assuming i already have akhmad in my hyper-hyper local root).
Yes this does have some consequences for some things such as TLS validation, but if you want we could get into the details of why that's OK (TLDR: CAs are only good because DNS is bad security for key distribution, DANE over GNS would be arguably more secure).
The HN comments are of course great, but what is the best way to follow the ongoing discussion of this proposal, it's merits/drawbacks and barriers to adoption? Is the working group's mailing list used for this purpose, or does feedback come from the public forum, i.e. This comments section, blog posts, etc.?
To be honest: I would prefer our mailing list for discussions (see top post).
Our email addresses are also in the draft.
A lot of discussions happen via the IETF Datatracker infrastructure and internal email discussions/meetings.
We have a monthly gnunet jour fixe and we do post news entries (https://www.gnunet.org)
We dropped our IRC channel when the freenode apocalypse happened.
FYI- I have seen DJ Bernstein mention this project in the past on a mailing list. It appeared he had looked at it. I am guessing the developer Christian Grotholff is a djb fan.
We did receive feedback on the concept in general and draft in particular.
We reworked the crypto significantly from the initial draft, both the key blinding as well as the symmetric encryption.
Notably, the crypto is now more agile (you can add new zone types if applicably cryptographic primitives emerge that allow for this particular key bliding)
But joking aside, it's good to have a censor-resistant resolution protocol. This is a more radical idea than the EU's recent proposal to have parallel name servers that obey Europe's GDPR rules.
Still, a lot of power is given to those that control the cables and satellites, and of course the electricity that powers the Internet's hardware. The commercialisation of the Internet has led to more centralization since the 2000s.
A true state of freedom and safety from repression, censorship and dictatorships can perhaps be only achieved with more ad-hoc mesh networks.
> A true state of freedom and safety from repression, censorship and dictatorships can perhaps be only achieved with more ad-hoc mesh networks.
I've recently started playing with mesh networks. Yggdrasil is excellent. They haven't solved naming, they're focused on mesh routing with e2e encryption. There's a public network. It's very experimental. But it works and its just so cool!
Also worth mentioning is Nebula (made by the Slack devs). Nebula is great for building private mesh networks.
Its a very exciting space right now! I'm hopeful; an open internet is possible.
TLDR: It's a regular domain name. It looks like a domain name. There is no specific extension for GNS.
GNS is intended to replace DNS (in a backwards-compatible way) at the ICANN level so if it was ever adopted facebook.com would resolve (by following public key PKEY records, not IP/DNS NS records) using GNS.
In addition, a neat feature of GNS is the hyper-hyper local root. So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice. But can this not be achieved with DNS already, you may wonder? Two differences:
1) resolution is by public key, so you don't need to keep a mapping of all your friends' nameserver IPs
2) it's intended as a recursive mechanism where you can advertise your favorite domains on your own zone, so for example if i publish The Pirate Bay's public key in my zone in a tpb record, hypothetical tpb.tofu.net will still resolve properly
All in all, GNS is so far the only credible alternative to DNS i've read about, if only because both the protocol and the zonefile syntax are backwards-compatible with DNS.
So what are some reasons that it won't gain popularity? Are the prevailing registries/registrars opposed to it? Would there be any authority that could mediate disputes over who "owns" a name? Does it address the problem of name-squatting/hijacking?
> So what are some reasons that it won't gain popularity?
The main reason would be lack of interest. It's developed by a handful of people who are undertaking one of the biggest tasks in the history of the Internet with very little resources.
Remember how much energy it took to switch everyone to IPv6? Right it still hasn't happened 20 years later: that's exactly the kind of change GNS is about, and that's why it's designed to be backwards-compatible with DNS so we don't end up in the same situation.
I'm open to the idea that the provided implementation could be bad (haven't read the code), and i believe there may be valid criticisms of some parts of the protocol. I just haven't read anything of the sort so far. In both cases, that could hinder adoption, but both could be fixed before GNS is standardized, which is why the authors have been pushing early drafts to the IETF (to gather feedback).
> Are the prevailing registries/registrars opposed to it?
In regards to the ICANN, registries and registrars i'm not aware of any opposition. GNS changes nothing significant to their politics/economics: it would require some time/resources to deploy but arguably nothing terrifying. Registr* specifically are probably entirely unaware of this effort and couldn't care less, especially since GNS is designed in a backwards-compatible manner where people can continue to use regular DNS and it will "just work".
> Would there be any authority that could mediate disputes over who "owns" a name?
This is registry policy and has nothing to do with the protocol. Every registry has a different policy on this matter, which may also be impacted by local regulations.
> Does it address the problem of name-squatting/hijacking?
Hijacking is made harder by GNS because we use public-key cryptography from the start to delegate zones to a third-party, not location (IP/domain). It's like DNSSEC but better because you don't have to mess with your zone to advertise the key (the key *is* your zone identifier in the DHT).
As for name-squatting, this is again entirely unrelated to GNS as it has to do with ICANN/registry policies. GNS is about better technical foundations for DNS in the 21st century, it's *not* about changing the politics of the ICANN root (although it's arguably an empowering technology for alternative roots to emerge).
Hope i answered your questions. (there may be some details i got wrong as i'm not involved with GNS project)
> GNS is about better technical foundations for DNS in the 21st century, it's not about changing the politics of the ICANN root _(although it's arguably an empowering technology for alternative roots to emerge)_.
For a such long answer, you could just mention this at beginning and stop there. This is a reason it will never become a standard. There is no possibility that a central authority will endorse a tool that will potentially make them obsolete or create a competitor to them.
i said "arguably" because it's definitely not a key property of the system. GNS is designed to make it easier to add entries to your local/personal root, which *could* be used by alt roots. but hey like other commenters said people/orgs can already do that in their resolver so it's not exactly a game changer.
> The same address resolving to the same website for everyone is a useful property of the current system.
That's already only guaranteed under the public root, which GNS intends to preserve: the situation would not change in this regard. I can already map "hn" to a well known HN IP address in my /etc/hosts: the only hurdles would come from my web browser sending the "hn" Host header (easily fixed) and trying to validate the remote TLS certificate for "hn" (less easily fixed). In this regard, GNS would be different in that i could delegate "HN" to a public key and not be bound to the IP suddenly changing under my feet.
On a higher level, i would argue the difference is GNS by design empowers users to archive/publish records because they don't need to operate infrastructure for that. If you already have a domain name and are familiar with DNS, publishing records is not that hard: GNS would make it far easier because since the records live in the DHT you only need client UX to publish a zone, no need to configure a name server or to point your client configuration to a specific name server API.
Can't you do the exact same thing in DNS right now? If your configured DNS server returns a valid result you wouldn't check other DNS servers for other valid results.
This is a desirable property for many companies that filter employee internet access from their internal network right on the DNS level.
It is a fair point, because it doesn't need to be the year of the Linux Desktop for those tools to be installed on and used daily on the vast majority of computers right now, dwarfing the number of ALL desktops, thereby being extremely popular.
Personally I don't mind GNU working on it, but I do mind GNU being part of the name,because GNU equates to FSF and that comes with a lot of political and idealogical baggage.
Imagine for a moment this was a Microsoft project, and was called MSDNS. Would the name matter? I would argue that it does.
Granted that basically no non-techie has ever heard of GNU (or the FSF) - despite the insistence on calling it GNU/Linux - I don't think it'll be a deal breaker, but I think it's uncool to put a "company" name/trademark in a global standard protocol name.
So for me it's not the creators, but rather the name itself that warns a down vote.
I personally have strong ambivalent about rms, but GNU projects are not necessarily under the umbrella of a single person/organization. Following the FSF coup by its board at last LibrePlanet and the surrounding controversies, the GNU Assembly was setup: https://gnu.tools/
I value the GNU project's ethical framework and feel like that's worth fighting for/with, although i personally am strongly opposed to the current internal politics of the FSF which are definitely not aligned with the base/masses of the libre-software movement.
> A name in GNS is a domain name as defined in [RFC8499] as an ordered list of labels. The labels in a name are separated using the character "." (dot). Names, like labels, are encoded in UTF-8.
It's possible to be smarter than that. I believe Chrome doesn't drop down to punycode if it sees the string is entirely within a single language so that there is no possibility of look-alike characters. It might even be checking explicitly for the presence of look-alike character pairs, since they're known ahead of time.
Just look at 田中太郎. Four completely independent glyphs, equal widths, no modifiers, in left-to-right order. It is a very good way to write things. The only issue is the fourth one seem to barely have enough pixels.
On the other hand what is the alternative? The current blockchain/dlt hype is built on top of technology that severely impacts its security promise (https://btc-hijack.ethz.ch/).
The reason why gnunet appears to be "redo-everything" is because that is exactly what is necessary if you take the issues seriously and think them through.
The reason why it takes so long is also because we are a small team and the goal does not provide instant gratification while at the same time being very hard to achieve.
It is a lot of systems programming and engineering. It is a lot more fun to reinvent the wheel in the newest shiny technology.
I was wondering which names are currently available. Apparently there is a first-come, first serve domain ending in ".pin" but the server is down. "Bad gateway."
So it seems like more of a software project than a running service at this point?
It's supposedly a decentralized naming system, so running a node/client yourself should be enough to get started, otherwise I don't see how they can call it decentralized. But I'm not finding any links to any source code from this specification, which is to be expected, but my searches are not helping me either.
Start [here](https://www.gnunet.org/en/index.html). The release notes for 0.15.0 talk about about the "First-come-first-served GNUnet top-level domain ".pin" zone key."
Nice try but no different then any of the other attempts to unseat ICANN. This has absolutely no chance of working unless incumbents get their cut or you find some reason to have this, that is so compelling that average people will take it upon themselves to install and use it.
There is endless free porn with regular DNS so you can't use that. Pirate music and video has been done to death, don't think you can use that to roll out your own DNS. If facebook wanted to have their own DNS and rolled out their software with their clients then they could probably pull it off. China will do it at some point but only for their citizens in their territories.
Nice try but it appears you didn't even read the draft RFC or any of the related resources. GNS is not trying to unseat ICANN it's trying to modernize the technical infrastructure. The GNS project does stand for user rights by advocating for a hyper-hyper local root but that's irrelevant to ICANN/registry governance as i explained in other comments on this thread.
Alas, users delegate this authority. They do not change defaults and let network admins decide where computers should point and what software will be used. The admins all point their computers to ICANN roots and ICANN roots are sometimes hardcoded into DNS software that admins insist on using.
Yet it is absoutely true, all it takes is changing some settings so that computers point elsewhere. ICANN derives its "authority" from voluntary behaviour of network admins.
And then what? You want to put up a website that only resolves from said alternative DNS server, so you… tell everyone who may want to visit your site that they have to first setup a different DNS server?
Most people don’t know how to do that, so they are stuck with whatever Verizon, Comcast, Spectrum, AT&T, etc. offer despite there being better solutions from Cloudflare, Google, and OpenDNS.
"People" means common folk, with their Edge, Chrome, Android Chrome and iOS Safari. There is the web that 'just works' and the web where you need to open up the back of the unit and start swapping wires.
I didn't downvote, but let me give context for the downvotes: GNS is not a special-use TLD (like .onion/.i2p is) and it should not be something you have to setup as a user, either because your distro will set it up for you, or because your ISP will use it on their infra transparently to you (GNS is backwards-compatible with DNS protocol). It's that kind of project that either everybody will use, or nobody will.
It's a serious research project (with usability studies and all) intending to replace the DNS in its entirety, solving whole classes of problems related to enumeration, amplification attacks, query privacy... If you don't trust me you should probably check out the ICANN presentation video about GNS, it's really short and instructive. Not that ICANN is advocating for GNS, but ICANN regularly holds "future identifiers" sessions during which projects can present their R&D.
That could be, and probably has been, said about every startup.
I don't know about the parent, but it has been a big trend- it's said how many people have bought into powerlessness. It's got to be killing innovation.
The only mention of X.509 on the page is a sentence saying that the protocol does not use X.509. Certainly reading it in full I did not see any usage of X.509. So I'm not sure what you're trying to say.
Not to mention, X.509 is not centralized to begin with.
Can we please stop naming things with the GNU/G* prefix? Hasn't RMS been cancelled several times already? And this proposal looks to be BSD centric rather than GPL centric anyway.
happy hacking