diff options
| author | Linus Torvalds <torvalds@home.transmeta.com> | 2003-03-21 10:58:28 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-07 20:59:34 -0700 |
| commit | a8971acb6cbfa8cfa6f5105340fcdee13c649590 (patch) | |
| tree | 3011554bbfa156146b6b86c91754a771c5e0c9ae /FAQ | |
| parent | f1d060b1cf8e9c46f7390c54d8eee9d4b51c028c (diff) | |
| download | sparse-dev-a8971acb6cbfa8cfa6f5105340fcdee13c649590.tar.gz | |
Add copyright statements and file comments. Add a FAQ, README, and
placeholder LICENSE file.
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 68 |
1 files changed, 68 insertions, 0 deletions
@@ -0,0 +1,68 @@ + FAQ - Why sparse? + +Q. Why not just use gcc? + +A. Gcc is big, complex, and the gcc maintainers are not interested in + other uses of the gcc front-end. In fact, gcc has explicitly + resisted splitting up the front and back ends and having some common + intermediate language because or religious license issues - you can + have multiple front ends and back ends, but they all have to be part + of gcc and licensed under the GPL. + + This all (in my opinion) makes gcc development harder than it should + be, and makes the end result very ungainly. With "sparse", the + front-end is very explicitly separated into its own independent + project, and is totally independent from the users. I don't want to + know what you do in the back-end, because I don't think I _should_ + know or care. + + +Q. Why not GPL? + +A. See the previous question: I personally think that the front end + must be a totally separate project from the back end: any other + approach just leads to insanity. However, at the same time clearly + we cannot write intermediate files etc crud (since then the back end + would have to re-parse the whole thing and would have to have its + own front end and just do a lot of things that do not make any sense + from a technical standpoint). + + I like the GPL, but as rms says, "Linus is just an engineer". I + refuse to use a license if that license causes bad engineering + decisions. I want the front-end to be considered a separate + project, yet the GPL considers the required linking to make the + combined thing a derived work. Which is against the whole point + of 'sparse'. + + I'm not interested in code generation. I'm not interested in what + other people do with their back-ends. I _am_ interested in making a + good front-end, and "good" means that people find it usable. And + they shouldn't be scared away by politics or licenses. If they want + to make their back-end be BSD/MIT licensed, that's great. And if + they want to have a proprietary back-end, that's ok by me too. It's + their loss, not mine. + + At the same time, I'm a big believer in "quid pro quo". I wrote the + front-end, and if you make improvements to the semantic parsing part + (as opposed to just using the resulting parse tree), you'd better + cough up. The front-end is intended to be an open-source project in + its own right, and if you improve the front end, you must give those + improvements back. That's your "quid" to my "quo". + + +Q. So what _is_ the license? + +A. I don't know yet. I originally thought it would be LGPL, but I'm + possibly going for a license that is _not_ subsumable by the GPL. + In other words, I don't want to see a GPL'd project suck in the + LGPL'd front-end, and then make changes to the front end under the + GPL (this is something that the LGPL expressly allows, and see the + previous question for why I think it's the _only_ thing that I will + not allow). + + So I'm currently considering just taking the LGPL and removing the + GPL subsumption clause, and calling it the LLPL ("Lesser Linus + Public License" or something). In the meantime, you have no rights + at all, except to send me useful suggestions about a license that + still requires people who work on the front-end to work as open + source, while allowing arbitrary back-ends. |