btw, anyone interested in something like this? I have an extensive codebase after trying to build a business around p2p vpn/filesync software. The business didn't go too well (various reasons) but the code is very high quality and still lying around collecting digital dust. We had (we think we had :-)) the best NAT traversal algorithms at that time. Multiplatform - Linux, Win, Mac. Written mostly in very readable old school die hard ANSI C :-)
In the wake of the recent NSA-related news I thought that this stuff may find a new use. If you have an idea and would like to devote some time and effort - you're welcome (I guess my contact info is visible in the profile).
I have no issues opensourcing it, it contains no close licensed and/or GPL-poisoned code. Everything we borrowed was BSD-type licensed. I just want to have some product to opensource instead of just dumping it on the Github and then waiting 4 billion years for life to conceive itself there :-)
Sorry for shameless plug.
Update for "Github ++" commenters: I'm all in to put it on Github (BitBucket is more natural in my case, because it's a Hg repo). But: the architecture was quite well thought out and internal APIs are quite clear, but they're not documented. We didn't have immediate open source plans. You wont be able to figure out how to use it, especially if you're going to use our "lower" layer - NAT traversal and friends. You need to know how it works to build a more universal API on top of it. Trust me, I know what I'm talking about - I did a few experiments with this code about a year ago and I spent a _lot_ of time figuring out how we did this and that. And it was _our_ code, we wrote it and discussed it daily for two years.
Hey, the shameless plug would have been a lot better with a link to a Github repo. I'd advise you to put it up on Github and keep advertising it, good NAT traversal algorithms are probably worth something for open source projects.
wow, I didn't follow this field for a while. Seems to be a great thing, but it's not an alternative, it's a higher layer. Telehash may provide naming, addressing, etc, while the stack I'm talking about basically provides UDP connectivity between parties.
For a otherwise very interesting and up-vote worthy comment, I really don't know what to do with comments that also include derogatory terms.
The project sound interesting, the comment is very much relevant in today's post-NSA world. So should I downvote, upvote, or not vote at all? If the comment had used a neutral word, rather than a derogatory term, it would not be a question about it.
I'd admit a wrongdoing if you can explain how to poison a project with BSD. For me (not an expert in OSS licenses in any way) it sounds like "the victim was poisoned with glass of pure water".
You can vote whatever you feel like, but I'm not selling my opinion for a vote on HN. My opinion is what it is and I can change it if you either provide sufficient argument or threaten my life, health, family or some other factor of my life, more important than my opinion on OSS licensing :-)
I can provide argument why I think GPL is what I think it is, but I seriously doubt this thread is the right place for it.
Users of BSD software still need to follow the BSD license. This mean for 4 clause BSD that you must including the line "This product includes software developed by the <organization>." in All advertising materials. If you are using the Revised BSD License, you still need to include the BSD license in any documentation or "other materials" that is shipped.
So if you like to be in full control over your advertisement, and your documentation, bsd do indeed "poison" the project. It clearly adds restrictions. I would however not use such derogatory term when describing the BSD. Is it really that hard to avoid using derogatory terms and simply use language without it?
I wrote specifically "BSD-type" not BSD. We didn't use BSD license itself, as far as I can tell and the project contains surprisingly small amount of _any_ third party code.
I do not consider "poisonous license" a derogatory term. English is not my native language, may be this is why.
That's fair. I consider calling anything, be that GPL, BSD, or open source as poisonous as to be on the side of derogatory term, similar to the cancer comparison made by Steve Ballmer. I can see however if that’s not always the case for others.
Just as a side note, I found an half year old HN article which talked about the BSD requirements, with suggest that one might want to use ISC license in some cases: https://news.ycombinator.com/item?id=5798431
Not that your project is code for embedded software (or is it? C code tend to be quite fast and have small memory footprint), but it might be an interesting read.
We designed and coded it with embedded in mind. We both have extensive embedded experience and it was a no brainer with all that hype about "internet of things". Our stack is naturally born IPv6 and as such is a natural match for "things", so not thinking about embedding would have been clearly a mistake.
>So if you like to be in full control over your advertisement, and your documentation, bsd do indeed "poison" the project.
The real trouble with the advertising clause is that it breaks compatibility with several other common licenses. Some of the BSD advocates actually like this because it causes trouble for people who use GPL code (the usual holy war justifications), but the net result is still that you have two otherwise-useful pieces of code that become mutually incompatible for political reasons.
I'd be very interested to check it out if it lands on GitHub. I don't think I'd be much of a contributor up front, I'm still getting my head around all the acronyms tossed around VPN networking, but I have a hobby project for which I've been researching how to build something like this.
Look, I was born, raised and spent most of my life in the country government of which considered themselves the one and only source of what is good and what is bad for 70 years. Actively punishing people for disobedience for "greater good". This great experiment came at the price of just a few tens of millions dead people, besides other things. And it didn't end well - country, being one of the superpowers of the world, basically disappeared overnight.
Since then, when I hear "greater good" I feel an urge to kill (only half joking here). And "requiring the source code" sounds pretty much like "greater good" for me. If I'm releasing the code, then I'm releasing it. If I think that some asshole, who invented the best smartphone on the planet, will use it for his own profit and if I feel pain thinking so, I'm not going to release it.
Releasing source code and attaching a piece of political agenda to is is not a coding activity, it's a specific kind of political activity - a political propaganda. "When I hear the word propaganda I'm reaching for the gun".
hehe, well, if you make it available with bsd3/mit, if someone really wants they can gpl it, so anyone arguing that it must be gpl from the get go should just commit to forking it :)
(you know you're doing well when folks want to fork you!)
In the wake of the recent NSA-related news I thought that this stuff may find a new use. If you have an idea and would like to devote some time and effort - you're welcome (I guess my contact info is visible in the profile).
I have no issues opensourcing it, it contains no close licensed and/or GPL-poisoned code. Everything we borrowed was BSD-type licensed. I just want to have some product to opensource instead of just dumping it on the Github and then waiting 4 billion years for life to conceive itself there :-)
Sorry for shameless plug.
Update for "Github ++" commenters: I'm all in to put it on Github (BitBucket is more natural in my case, because it's a Hg repo). But: the architecture was quite well thought out and internal APIs are quite clear, but they're not documented. We didn't have immediate open source plans. You wont be able to figure out how to use it, especially if you're going to use our "lower" layer - NAT traversal and friends. You need to know how it works to build a more universal API on top of it. Trust me, I know what I'm talking about - I did a few experiments with this code about a year ago and I spent a _lot_ of time figuring out how we did this and that. And it was _our_ code, we wrote it and discussed it daily for two years.