All of those are plausible options. Another option is Allura, which is in the Apache incubator stage. SourceForge is its sponsor and is switching all projects to Allura.
More info: http://sourceforge.net/p/allura/wiki/Allura%20Wiki/
I suggest using the Internet. I hear it's popular. What's more, over time the number of people who get news through TV will probably decrease.
But to be honest, depending on changing the law is silly. You can collaborate today, just add a license statement. Then work to change the law, arguing that the presence of all these licenses is evidence that the law's default is wrong. That way you get what you want today, and you create evidence for tomorrow.
You miss the point. It's true that copyright and license are not the same thing. But under almost every country's laws, works like software are automatically copyrighted by the creator or employer (with a few exceptions, e.g., US government employees as part of their official duties). And you cannot use copyrighted software unless (1) you're the copyright holder, or (2) you have permission from the copyright holder. A license (from the copyright holder) grants that permission.
If you don't have a license, then the lawyers and judges get to decide whether or not you had permission. And you probably won't like what they decide, because the DEFAULT is "no permission".
You can complain about a "permission-based culture". But this is law, not just amorphous culture. If you want to share, then grab an OSS license, put it in the LICENSE file, and you're done. If you want to do just about anything, the MIT is a perfect license for it; it's short, and it provides some protection from lawsuits.
Yes, it's criminal. From the Webster's Ninth New Collegiate Dictionary:
criminal
n
1 : one who has committed a crime.
crime
n
1: The act or the commission of an act that is forbidden or the omission of a duty that is commanded by a public law and that makes the offender liable to punishment by that law.
Great points, but a minor correction: He hasn't open sourced anything. To release something as open source, it has be released so others can LEGALLY read, use, modify, and distribute it. That's typically done by a license.
Okay, so you are knowingly breaking the law. You are risking getting sued for everything you own and more. You're putting yourself, your family, your company, and your customers at risk.
No, I do not just copy, paste, compile, test, deliver, done.
If it's small then fair use applies, so no problem there, but if it's larger it'd better have a license, or I'm not using it.
Why are you bringing up the WTFPL? That's a license. If you want to use that license, copy that into the LICENSE file and "git add LICENSE". Problem solved. The problem is software that does not have a license.
You can give away whatever you want. But posting it to GitHub without a license is not giving it away, it's creating legal trap for anyone who might use it.
Part of the problem is that younger people think they're immortal. Imagine this: You write software for 4 years, posted on GitHub, with no license. Then you die in some car accident. Your estate then sues everyone who uses the software, because they have no right to use the software. They could just rewrite the software, but they're still liable for all that unauthorized use.
Look, it's clear that a lot of developers (especially younger ones) are completely ignorant about the law. But ignorance of the law is no excuse. This is how the law works, and at this point, many of these developers can no longer claim ignorance anyway. Under the law, you can give stuff away... but you have to SAY that you are giving it away.
If you don't like how the law works, then work to change it. What you want USED to be the law of the land (before 1976). But don't create new dangers for innocent third parties, that's grossly unfair to them.
What about the WTFPL? My complaint is about software without a license. The WTFPL is a license, and it makes it clear what you can do.
The problem isn't the WTFPL, it's the software without any license at all.
If GitHub made your personal interpretation a requirement for using its site at no charge, that might work.
But GitHub's terms don't really make sense for what people are trying to do on it. GitHub only allows you to "view" and "fork".
Are users allowed to run the code? The answer appears to be "no". That's because under most countries' law, including the US, by default users have NO rights unless they are granted somehow. Heck, as far, as I can tell, users aren't even allowed to modify it, because you can make a fork without modifying it, and only "forks" are allowed. Now we have to dance on what a "fork" means, and the LAWYERS, not the programmers get to decide.
If you want to release software, and collaborate, great! Posting stuff without a license is not a release, it's a legal minefield.
If don't include a license, the LAWYERS decide what is allowed... not the programmers. You probably won't like what the lawyers decide.
Software without a license is like a poison for everyone else. There's typically no legal risk to a developer in releasing their software, since it's likely he has the copyright. But it creates a legal minefield for anyone else who uses or modifies the software, either directly or by using software that stupidly embeds such things. At any time the developer, or his employer, could sue, and there's nothing the user could do.
Ignoring lawyers does not simplify your life. Sure, it'll simplify your life today, but only by creating potential disasters in the future. You need to think about other people, and whole lifetimes, not just think about yourself today.
If you think that copyright should only apply to software if it's marked, then work to get the law changed. It used to be that way before 1976. But it's not 1976. I suspect that the law won't get changed, really. But intentionally creating dangers for other people is a terrible, nasty thing to do.
Presuming that you bring your own laptop, ideally with good battery life (and a spare battery)...
When you want internet connectivity, try out libraries. In the US they're quiet and usually have free Wi-fi. I don't know how common that is in libraries around the world.
As far as development goes, yank down the relevant documentation (wget works great), and use a distributed CM system like git. Git, in particular, works really nicely for disconnected environments; you can work away and then sync up later. Then go to some beautiful locale like a park. You may find that you don't need to be "always on" to get things done.
For more $$, cell phones work for Internet connectivity, but depending on where you are that can get pricey.
Careful, I emphasized *Scheme* and not *Common Lisp*. All Schemes are *required* to be properly tail recursive, per spec, which combined with garbage collection completely deals with the pure-functional-style memory pressures properly.
It's true that nobody in practice writes large (Common) Lisp projects in functional style, but Common Lisp doesn't guarantee proper tail recursion (and implementations don't typically provide it), so that should be unsurprising that you can't really scale that up in Common Lisp.
This is an excellent idea!! It's further explained in THE DICTATOR'S PRACTICAL INTERNET GUIDE TO POWER RETENTION (aka "Dictator's guide to the Internet") section 3.1, "Suppressing anonymity (who)":
"There are two things that are simply not compatible with the regime you run: anonymizing tools and data-encrypting tools. With anonymizing tools, you can perhaps control and monitor internet activity, but you cannot tie this activity to a certain individual. Anonymity thus makes accountability evaporate. With data-encrypting tools, you cannot even see or make sense of the data which travels in the internet cables you control, as it is mangled specifically to avoid being recognizable. The proliferation of online political dissidence in non-democratic states is usually dependent on the availability of tools to anonymize and encrypt data. If you cannot effectively dismantle the use of these tools, it's often a matter of (short) time before political opposition organizes against you."
Actually, the braces are implemented in the reader. In Common Lisp terminology, they can be implemented as a "reader macro", but this is a completely different step than the Lisp "macros" usually refer to. This means that you can use {...} with data or code, and you can even use them as inputs to macros (in the usual sense). Thus, you can combine Scheme's "define-syntax" with {...} without problems. The SRFI-105 spec has some examples you might want to look at.
The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces. If you try to use them inconsistently (tab on one line, where space was used on the previous line), then it reports an error.
Notice that this is COMPLETELY DIFFERENT from Makefiles. The problem with Makefiles is that there are cases where you can't tell where an error is, and so it quietly does the wrong thing. Requiring that you MUST be consistent means that you can use either spaces or tabs... but the next line that's indented better be consistent with its parent.
Scheme is normally considered a functional programming language. The 1989 paper "Conception, Evolution, and Application of Functional Programming Languages" by Paul Hudak defines functional programming languages as languages "in which computation is carried out entirely through the evaluation of expressions" (as opposed to setting mutable states, like variables, or allowing routines with side-effects). That paper specifically identifies Lisps (including Scheme) as languages that can be used as functional programming languages, as well as ML and Haskell.
Like ML, Scheme provides mechanisms that let you "escape" outside the functional programming paradigm, but "well-written code" normally doesn't do that.
"Programmers that use Lisp or Scheme for a while end up using plain prefix."
Sure, for those few programmers who keep using (Common) Lisp or Scheme. But almost all developers say, "what, no infix?", and ignore or stop using Lisps. And those who stick around find that it's hard to use infix in most Lisps today because there's no standard mechanism for using it. We're working to fix that, while keeping Lisp homoiconic and general.
The percieved inconvenience of prefix notation is due to not being used to it.
Prefix and infix have exactly the same capabilities, notationally. But of COURSE people are used to infix. Are you saying that schools will stop teaching and using infix in school? That math books will stop using it? I do not think so, and that means that while infix and prefix have the same capabilities, failing to support the standard (infix) has been a long-standing problem in Lisps. All developers show up with 15+ years of experience with infix, and 0 with strict prefix. Even if YOU like prefix, all future developers will have a 15-year head start in reading infix. So saying, "everyone will do it this non-standard way" doesn't really make sense, and more importantly, is provably false. Lisp has has had 50 years to convince people to only use prefix and failed to convince most developers; time to do something different.
After a while you realize that prefix notation is a lot more readable and less error-prone than infix.
I disagree. They are the same in terms of capability. And when people spend 15+ years being trained in one notation, all other notations are less readable and will remain so for many years. I've been writing prefix code for 30 years, and it isn't magically more readable. Indeed, what I find is that many people are unwilling to use a language that cannot handle infix.
The *notation* is more flexible. That said, if you want to use the notation a particular way, then feel free. I normally use two-space indentation in sweet-expressions.
However, to get a notation accepted for wide use, the notation has to accept the different ways that people work.
Python accepts either spaces or tabs, specifically because you can't get agreement on one or the other. The same argument applies here, too.
There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.
Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations.
In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c).
We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ for more info, and in particular, please join the mailing list!!
Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions", as developed by the Readable Lisp S-expressions Project. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.
Yes, this is similar to the assert mechanism of C, Python, etc., but because it's built into the language, it can do some extras. Often these are optimized out, because the compiler can determine that they're always met. You can also define a "Type_Invariant" once, and then the invariant is checked every time the value can be changed from the point of view of a user (e.g., after initialization, conversion, or return of a value of that type). A type_invariant is like inserting C "assert" calls in every call that might return it, but only having to say it once.
Historically, Ada was developed by the Department of Defense (DoD), and the DoD tried to make it the one and only universal language . An NRC report on Ada talks about this. Fundamentally, trying to make one language do everything was a bad idea, and predictably failed; there is still no one language that can be all things to all people, even many years later.
Ada isn't a complex language by today's standards, but it has a lot of "pickiness" that means you have to obey more rules. Is that a good thing? Well, you first have to understand what it was designed for - and then decide if that design is what you want.
Ada focuses on software that needs high reliability and yet absolutely no compromise of performance. If reliability isn't really all that important to you, or you can give up a lot of performance, then Ada's trade-offs may not work for you. For reliability, it has a strong typing system, and you have to use generics (etc.) instead of just saying "shut up and trust me" a la C. For performance, it doesn't mandate automatic garbage collection (as compared to Java or Python). Ada shines when you're writing programs that will could un-intentionally kill people if the program is wrong or takes too long. Think airplane flight controls, train systems, medical systems, that sort of thing. A lot of Slashdot readers have never tried to write software that could accidentally kill people, and thus can't understand why you might want a "picky" language like Ada. If your response to "it has a bug" is just "install this patch" maybe another language would be fine. But when mistakes can kill, having a language that helps prevent them can be literally a lifesaver.
Slashdot Mirror
You might look at "The NIST Definition of Cloud Computing": http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf - it's one-and-a-half pages once you skip the boilerplate.
All of those are plausible options. Another option is Allura, which is in the Apache incubator stage. SourceForge is its sponsor and is switching all projects to Allura. More info: http://sourceforge.net/p/allura/wiki/Allura%20Wiki/
I suggest using the Internet. I hear it's popular. What's more, over time the number of people who get news through TV will probably decrease.
But to be honest, depending on changing the law is silly. You can collaborate today, just add a license statement. Then work to change the law, arguing that the presence of all these licenses is evidence that the law's default is wrong. That way you get what you want today, and you create evidence for tomorrow.
You miss the point. It's true that copyright and license are not the same thing. But under almost every country's laws, works like software are automatically copyrighted by the creator or employer (with a few exceptions, e.g., US government employees as part of their official duties). And you cannot use copyrighted software unless (1) you're the copyright holder, or (2) you have permission from the copyright holder. A license (from the copyright holder) grants that permission.
If you don't have a license, then the lawyers and judges get to decide whether or not you had permission. And you probably won't like what they decide, because the DEFAULT is "no permission".
You can complain about a "permission-based culture". But this is law, not just amorphous culture. If you want to share, then grab an OSS license, put it in the LICENSE file, and you're done. If you want to do just about anything, the MIT is a perfect license for it; it's short, and it provides some protection from lawsuits.
Yes, it's criminal. From the Webster's Ninth New Collegiate Dictionary:
criminal
n
1 : one who has committed a crime.
crime
n
1: The act or the commission of an act that is forbidden or the omission of a duty that is commanded by a public law and that makes the offender liable to punishment by that law.
That's a real license, it's just not a good one. It doesn't include the usual "no warranty" statement that protects you and your co-developers.
Great points, but a minor correction: He hasn't open sourced anything. To release something as open source, it has be released so others can LEGALLY read, use, modify, and distribute it. That's typically done by a license.
Okay, so you are knowingly breaking the law. You are risking getting sued for everything you own and more. You're putting yourself, your family, your company, and your customers at risk.
No, I do not just copy, paste, compile, test, deliver, done. If it's small then fair use applies, so no problem there, but if it's larger it'd better have a license, or I'm not using it.
Why are you bringing up the WTFPL? That's a license. If you want to use that license, copy that into the LICENSE file and "git add LICENSE". Problem solved. The problem is software that does not have a license.
You can give away whatever you want. But posting it to GitHub without a license is not giving it away, it's creating legal trap for anyone who might use it.
Part of the problem is that younger people think they're immortal. Imagine this: You write software for 4 years, posted on GitHub, with no license. Then you die in some car accident. Your estate then sues everyone who uses the software, because they have no right to use the software. They could just rewrite the software, but they're still liable for all that unauthorized use.
Look, it's clear that a lot of developers (especially younger ones) are completely ignorant about the law. But ignorance of the law is no excuse. This is how the law works, and at this point, many of these developers can no longer claim ignorance anyway. Under the law, you can give stuff away... but you have to SAY that you are giving it away.
If you don't like how the law works, then work to change it. What you want USED to be the law of the land (before 1976). But don't create new dangers for innocent third parties, that's grossly unfair to them.
What about the WTFPL? My complaint is about software without a license. The WTFPL is a license, and it makes it clear what you can do. The problem isn't the WTFPL, it's the software without any license at all.
If GitHub made your personal interpretation a requirement for using its site at no charge, that might work. But GitHub's terms don't really make sense for what people are trying to do on it. GitHub only allows you to "view" and "fork".
Are users allowed to run the code? The answer appears to be "no". That's because under most countries' law, including the US, by default users have NO rights unless they are granted somehow. Heck, as far, as I can tell, users aren't even allowed to modify it, because you can make a fork without modifying it, and only "forks" are allowed. Now we have to dance on what a "fork" means, and the LAWYERS, not the programmers get to decide.
If you want to release software, and collaborate, great! Posting stuff without a license is not a release, it's a legal minefield.
If don't include a license, the LAWYERS decide what is allowed... not the programmers. You probably won't like what the lawyers decide.
Software without a license is like a poison for everyone else. There's typically no legal risk to a developer in releasing their software, since it's likely he has the copyright. But it creates a legal minefield for anyone else who uses or modifies the software, either directly or by using software that stupidly embeds such things. At any time the developer, or his employer, could sue, and there's nothing the user could do.
Ignoring lawyers does not simplify your life. Sure, it'll simplify your life today, but only by creating potential disasters in the future. You need to think about other people, and whole lifetimes, not just think about yourself today.
If you think that copyright should only apply to software if it's marked, then work to get the law changed. It used to be that way before 1976. But it's not 1976. I suspect that the law won't get changed, really. But intentionally creating dangers for other people is a terrible, nasty thing to do.
Presuming that you bring your own laptop, ideally with good battery life (and a spare battery)... When you want internet connectivity, try out libraries. In the US they're quiet and usually have free Wi-fi. I don't know how common that is in libraries around the world. As far as development goes, yank down the relevant documentation (wget works great), and use a distributed CM system like git. Git, in particular, works really nicely for disconnected environments; you can work away and then sync up later. Then go to some beautiful locale like a park. You may find that you don't need to be "always on" to get things done. For more $$, cell phones work for Internet connectivity, but depending on where you are that can get pricey.
Careful, I emphasized *Scheme* and not *Common Lisp*. All Schemes are *required* to be properly tail recursive, per spec, which combined with garbage collection completely deals with the pure-functional-style memory pressures properly. It's true that nobody in practice writes large (Common) Lisp projects in functional style, but Common Lisp doesn't guarantee proper tail recursion (and implementations don't typically provide it), so that should be unsurprising that you can't really scale that up in Common Lisp.
This is an excellent idea!! It's further explained in THE DICTATOR'S PRACTICAL INTERNET GUIDE TO POWER RETENTION (aka "Dictator's guide to the Internet") section 3.1, "Suppressing anonymity (who)": "There are two things that are simply not compatible with the regime you run: anonymizing tools and data-encrypting tools. With anonymizing tools, you can perhaps control and monitor internet activity, but you cannot tie this activity to a certain individual. Anonymity thus makes accountability evaporate. With data-encrypting tools, you cannot even see or make sense of the data which travels in the internet cables you control, as it is mangled specifically to avoid being recognizable. The proliferation of online political dissidence in non-democratic states is usually dependent on the availability of tools to anonymize and encrypt data. If you cannot effectively dismantle the use of these tools, it's often a matter of (short) time before political opposition organizes against you."
Actually, the braces are implemented in the reader. In Common Lisp terminology, they can be implemented as a "reader macro", but this is a completely different step than the Lisp "macros" usually refer to. This means that you can use {...} with data or code, and you can even use them as inputs to macros (in the usual sense). Thus, you can combine Scheme's "define-syntax" with {...} without problems. The SRFI-105 spec has some examples you might want to look at.
Actually, it turns out there's no problem.
The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces. If you try to use them inconsistently (tab on one line, where space was used on the previous line), then it reports an error.
Notice that this is COMPLETELY DIFFERENT from Makefiles. The problem with Makefiles is that there are cases where you can't tell where an error is, and so it quietly does the wrong thing. Requiring that you MUST be consistent means that you can use either spaces or tabs... but the next line that's indented better be consistent with its parent.
Scheme is normally considered a functional programming language. The 1989 paper "Conception, Evolution, and Application of Functional Programming Languages" by Paul Hudak defines functional programming languages as languages "in which computation is carried out entirely through the evaluation of expressions" (as opposed to setting mutable states, like variables, or allowing routines with side-effects). That paper specifically identifies Lisps (including Scheme) as languages that can be used as functional programming languages, as well as ML and Haskell. Like ML, Scheme provides mechanisms that let you "escape" outside the functional programming paradigm, but "well-written code" normally doesn't do that.
Sure, for those few programmers who keep using (Common) Lisp or Scheme. But almost all developers say, "what, no infix?", and ignore or stop using Lisps. And those who stick around find that it's hard to use infix in most Lisps today because there's no standard mechanism for using it. We're working to fix that, while keeping Lisp homoiconic and general.
Prefix and infix have exactly the same capabilities, notationally. But of COURSE people are used to infix. Are you saying that schools will stop teaching and using infix in school? That math books will stop using it? I do not think so, and that means that while infix and prefix have the same capabilities, failing to support the standard (infix) has been a long-standing problem in Lisps. All developers show up with 15+ years of experience with infix, and 0 with strict prefix. Even if YOU like prefix, all future developers will have a 15-year head start in reading infix. So saying, "everyone will do it this non-standard way" doesn't really make sense, and more importantly, is provably false. Lisp has has had 50 years to convince people to only use prefix and failed to convince most developers; time to do something different.
I disagree. They are the same in terms of capability. And when people spend 15+ years being trained in one notation, all other notations are less readable and will remain so for many years. I've been writing prefix code for 30 years, and it isn't magically more readable. Indeed, what I find is that many people are unwilling to use a language that cannot handle infix.
The *notation* is more flexible. That said, if you want to use the notation a particular way, then feel free. I normally use two-space indentation in sweet-expressions. However, to get a notation accepted for wide use, the notation has to accept the different ways that people work. Python accepts either spaces or tabs, specifically because you can't get agreement on one or the other. The same argument applies here, too.
There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.
Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations. In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c). We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ for more info, and in particular, please join the mailing list!!
Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions", as developed by the Readable Lisp S-expressions Project. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.
You can see more about Ada 2012 here; the rationale is probably the best place to start.
Yes, this is similar to the assert mechanism of C, Python, etc., but because it's built into the language, it can do some extras. Often these are optimized out, because the compiler can determine that they're always met. You can also define a "Type_Invariant" once, and then the invariant is checked every time the value can be changed from the point of view of a user (e.g., after initialization, conversion, or return of a value of that type). A type_invariant is like inserting C "assert" calls in every call that might return it, but only having to say it once.
Yes, people are using Ada, in fact, it's been making a quiet comeback. Ada is the #16 most popular language according to the TIOBE programming language survey of November and December 2012, an increase from #19 in November 2011. Keller reports that by 2000 Ada use had decreased and then increased again. It's not huge compared to C or Java, of course; its use is focused in certain domains. In certain communities, such as aviation software, it continues to be a popular language and has been credited with helping to produce high-quality software within time and budget.
Historically, Ada was developed by the Department of Defense (DoD), and the DoD tried to make it the one and only universal language . An NRC report on Ada talks about this. Fundamentally, trying to make one language do everything was a bad idea, and predictably failed; there is still no one language that can be all things to all people, even many years later.
Ada isn't a complex language by today's standards, but it has a lot of "pickiness" that means you have to obey more rules. Is that a good thing? Well, you first have to understand what it was designed for - and then decide if that design is what you want.
Ada focuses on software that needs high reliability and yet absolutely no compromise of performance. If reliability isn't really all that important to you, or you can give up a lot of performance, then Ada's trade-offs may not work for you. For reliability, it has a strong typing system, and you have to use generics (etc.) instead of just saying "shut up and trust me" a la C. For performance, it doesn't mandate automatic garbage collection (as compared to Java or Python). Ada shines when you're writing programs that will could un-intentionally kill people if the program is wrong or takes too long. Think airplane flight controls, train systems, medical systems, that sort of thing. A lot of Slashdot readers have never tried to write software that could accidentally kill people, and thus can't understand why you might want a "picky" language like Ada. If your response to "it has a bug" is just "install this patch" maybe another language would be fine. But when mistakes can kill, having a language that helps prevent them can be literally a lifesaver.