PG: Arc Likely To Be Open-Sourced This Winter
news.ycombinator.com
news.ycombinator.com
ArcAde - Retro Games
ArcAne - Obfsktd Programs
ArcHer - Dating Website
ArcHetype - PDF Generation Tool
ArcHegonium - Porn website for hardcore mosses & ferns freaks
ArcHipallium - Image recognition framework
ArcHosaur - 'Enterprise' apps
ArcHlute - Anywhere.fm competitor
Thanks: http://InstantWordSearch.com/Choosing a license to fight imagined evils seems like the short route to a DRM'd license.
Incidentally, the last thing the FSF is worried about is popularity, yet look at how popular GCC, Emacs, bash, and other GPL'd software is.
Licensing your software with a very liberal license may help make your software more popular with some large companies who are in a position to take advantage of it (and I suspect timing is important here as well), but I'm not so sure it makes your software popular with the developer community.
One thing that's important for languages like Tcl is that they can be embedded within other projects, and for that reason a liberal license was very important. Of course, it's certainly not the only thing you need. The GPL is probably ok for "finished product" sorts of things that you don't need to link against to utilize it.
they seem like ostensibly the same thing.
GPLv2 requires modified public distributions to also be under GPLv2, so you could both see the fix/change and use it (in the sense that you won't be infringing on copyright).
GPLv3 adds patent protection, so someone adding a fix/change that they have also patented explicitly grants a license for that patent.
I think GPLv3 is the most comprehensive way to keep fixes/changes of others available for reuse.
http://www.apache.org/licenses/LICENSE-2.0
OTOH, it's a big, long license, and perhaps the BSD license would be simpler, which is always an advantage.
I prefer GPL over BSD strictly for the reason that if someone makes a modified version of Arc publicly available, then we all get to see (and maybe use) the modifications.
The license should be Affero GPL.
From what I've seen, projects that go GPL tend to be more community-focused, and seem to more readily gather a contributor community around them. I think contributors tend to like the idea of their contribution being free in perpetuity.
MIT-licensed projects, OTOH, tend to be mostly worked-on by their creator (again, FWICT). That is, there are fewer individuals willing to contribute code to a project which could simply be scooped up and put into some company's closed-source product. I get the impression that MIT-licensed projects are always looking to be popular, and feel entitled to be so, since users can basically do whatever they want with the code.
A lot of careful thought by lawyers, the community, and the FSF has gone into the most current GPL. I'd suggest that it's worth considering.
Being Arc a language, I think you would like to remain the head of its development, so maybe the Artistic License [3][4]would be right. Like Perl does.
It's far more complicated than the simple ones, but it would make easier to differentiate between the Vanilla Arc and the Straciatella Arc.
For the GPL[5], I think it is better suited for programs than for languages.
[0] http://www.opensource.org/licenses/category
[1] http://www.opensource.org/licenses/bsd-license.php
[2] http://www.opensource.org/licenses/mit-license.php
[3] http://www.opensource.org/licenses/artistic-license.php
[4] http://www.opensource.org/licenses/artistic-license-2.0.php
"Do What The Fuck You Want To Public License"
It's actually not a joke: http://sam.zoy.org/wtfpl/
Some ideas I've got floating around are to use it for scripting (instead of, say, LUA or XSLT) and for config files (instead of XML) in existing apps. Also, lisp seems fantastically placed for HTML generation, so if I embed it in an IIS or Apache site, then great!
So, if Arc is available for download at UTC 5:48am on March 20, pg will have met his goal. :)
I'm realist, so I predict: this spring (to be clear: there's only one in 2008).
When there's a big thread like that I'd like to check the new comments but I can't be bothered to read again the 64 comments I read earlier to find the 8 new ones.
I guess this announcement puts an end to my plan to read everything PG has written about Arc and then write my own implementation.
Last year was Common Lisp. I was planning on doing Python this year. Then recently Scala has been looking very interesting, with the functional/static thing with not bad performance and access to the whole Java stack (I program Java at my job).
Now Arc might be a possibility. At this rate, it will be December and I'll still be trying to decide.
I think you're right. I already found a task for Python to do, spent a couple weeks (off and on) refining it, and at the end I seemed to have used all of the prominent features of Python somewhere in that script. At the end of that, I had this vague feeling that I now "knew" Python and wasn't sure what was left to learn.
So, you are confirming my vague feeling and I can now move on to Scala and decide whether or not to switch to Arc once it emerges. :)
Python can definitely fit in your head, as far as the language. Reading lots of code is a good way to learn the idioms.
But, regardless of the very sound reasons for it to be the way it is, it's a very intimidating codebase, and a really good case study in the "reinvent everything" mindset. (It's quite powerful, and I've worked with several of the guys who built it, as I did contract work for Zope Corp for a few years, and I have the utmost respect for their talent and intellect. They're some of the smartest developers I've ever met. But it's not quite like anything else I've ever seen when it comes to having a learning cliff, even with some pre-existing Python knowledge.)
I'm told a great place to read good code, both Python and C, is to read the code that makes Python.
This is true of any language to some degree, although some are worse than others, and if the code was purposefully written in some non-traditional way it can be even harder.
send(to, from, count)
register short *to, *from;
register count;
{
register n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}Thanks for the link!
However, I did experience a certain amount of burnout on this - I haven't written anything nearly as extensive since (eg, no more than 1000 lines of Lisp).