I always wonder why people bother with providing source under a source available license. It makes outside contributions a lot less likely. Your active community of people working on the code base effectively becomes your employees.<p>There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing. Including free usage and distribution of the work they did. It's not likely to be helpful.<p>My attitude to source available products is the same as to proprietary products. I tend to limit my dependency on those. Companies have short life spans. Many OSS projects I use have a history of surviving the implosion of companies that once actively contributed to them. Developer communities are much more resilient than companies. Source unavailable effectively becomes source unavailable when companies fail. Especially VC funded companies are kind of engineered (by VCs) to fail fast. So, it's just not a great basis for making a long term commitment.<p>If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license. Somebody could take over the project or fork it or even create a new company around it. Some of the original developers would probably show up. A project like that is resilient against that. And projects like that have active contributors outside of the corporate context that provide lots of contributions. Because of the license. You don't get that without a good OSS license. I judge software projects by the quality of their development communities. It needs to have diversity, a good mix of people that know what they are doing, and a broad enough user community that the project is likely to be supported in perpetuity.<p>Shared source provides only the illusion of that. Depending on them is risky. And that risk is rarely offset by quality. Of course people use proprietary software for some things. And that's fine. I'm no different. But most of the stuff I care about is OSS.
I love open source, but I'd welcome less of it and more "source available" projects.<p>I think several large coorporations are pushing the boundaries of what "open source" can actually mean in good faith. Especially several recent big name cases where profit models weren't thought out during start up and then licenses for projects aee suddenly changes.<p>The term has erroded a lot recently, I'd be happy to see less, but more meaningful "open source" out there.
I certainly don't have all the answers here but the entire $300B+ SaaS industry (and a bunch of other stuff that behaves like SaaS) was built in great part on a loophole in the GPL. More precisely, many of the people who licensed their code under GPL were eventually dismayed when they realized you could sell access to whatever you like built on top of that code, over a network, and you wouldn't have to distribute the source. The AGPL was devised to close this loophole.<p>There are really two dynamics at play, one is that there are people who want to give a gift to the world and promote a culture of sharing, in fact they want to REQUIRE you to pay it forward if you use their stuff. That's the ethos behind GPL and AGPL. It has proven to be way more effective than the bean counters expected!<p>The other dynamic is the more conventional profit making and taking which has perceived a loophole and used it to make some extra bucks on the backs of the nice sharing guys.<p>I don't have anything against profits, I like money and I own a business where we choose to keep some code totally closed source because money. But you can't deny that this division exists. And I think this dynamic is what most of the dilemmas in the OSS world really arise from, there is a strain of altruism since the early days of the movement which has been betrayed, for many it feels awful if you've released GPL'ed code and then watched Big Tech promptly pile a bunch of proprietary code on top of it and use the resulting machine to strangle the freedoms of the human race over the Internet. You don't automatically get to squeeze profits from a thing just because it's out there and it's shiny and nice. That may not be why the author built it. It may be a betrayal of their intent if you do.
As a lay person, I still don't get what is AGPL missing that makes vendors "invent" so many new licenses and spawn so much debate? Why not just use AGPL, and if it's insufficient, invest in an AGPLv2 initiative?
The major concern regarding the AGPL is that it only fosters code share when a code change is involved. The license has nothing to do with someone building a competitive service <i>around</i> your project.<p>If a Big Tech company happened to build a cloud service (SaaS) around your project without any code change, and that service is more competitive than the one you provide, there is not much you can do about it with the AGPL.<p>The AGPL is published by the FSF, with mainly community-led projects in mind. The profit and sustainability of a corporation is not their primary concern. (A minor correction: The most recent version is v3; any newer version would be v4, not v2.)
See <a href="https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up#bounty" rel="nofollow">https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up#b...</a><p>MongoDB invested sufficient resources in drafting an update to the AGPL. That license is called the Server Side Public License. Controversy ensued.
MinIO made their source AGPL, but then cloud providers hosted the service "as is" and make money off it, with MinIO team getting zip. That still complies with AGPL but is not monetarily beneficial to the MinIO team.<p>At least that's my understanding. They closed source completely, but a source-available license wouldn't have run into this issue.
It is not possible to create a license that would satisfy the Free Software Foundation's "four freedoms" while also solving the issues many of those vendors have with the AGPL. At the same time, the "source available" mindset doesn't have a steward organization like the FSF or OSI.
Source available isn't a license, it is the lack of a license. It's the legal default state for all art.
I think that people looks at n8n success and say why not use source available?... However, I believe they are wrong to believe that this would work for any project...
Personally I think differentiation between "open source" and "source available" is good.<p>Open source, is, essentially software that I expect to be able to use commercially and tweak if required - but I'm own my own, and I pay for support.<p>Source available means I can basically help debug issues I have...but I <i>expect</i> that a paid licence is required and will have a selection of limitations (number of nodes, etc).
> Personally I think differentiation between "open source" and "source available" is good<p>Maybe, but I think that "source available" isn't detailed enough and can mean many many different things.<p>> Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc).<p>Point in case. For me there is one group, under something like BSL or FSL or SSPL which mostly restricts you from competing with the project's creators (e.g. making your own SaaS out of it), but everything else is fair use, you can use it in prod to make money at any size, etc. And a separate, more restrictive one, which has size, or production restrictions (you can't run the software if you're a commercial entity).<p>Source available sounds like a good description for the second one, because it's just available, little more. But for the first one where you can do whatever you want with one single exception that doesn't impact 99.9999% of potential users, it's not a good and clear enough description.
"Source Available" means that it can become "Source Unavailable" overnight.<p>See the "Our Machinery" fiasco.<p>Yes, Open Source isn't a complete defense against this (especially when there are copyright assignments). However, it sure makes it both a lot harder to pull off and a lot less useful to even try.
What principles and values of the open source movement are protected by staunchly refusing to allow "source available" to call itself open source?<p>To an outsider it looks like counterproductive bickering between people on the same team.
> What principles and values of the open source movement are protected by staunchly refusing to allow "source available" to call itself open source?<p>The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?<p>I know that everyone thinks of Big Tech absorbing your project into their SaaS when they do this, but there are other ways (say AGPL) to combat that. O'SaaSy seems to me to be essentially a "give us your code for free, and you can self host it, but don't dare to charge $$ for it or else!" license.<p>Now you're bringing lawyers into the picture for anyone who's hosting your software on their servers. It's very reasonable for a SaaS company that wants to defend its moat, but it's not Open Source.<p>(Talking of, I'm actually curious if anyone has seen actual self-hosted Fizzy instances in the wild.)
I didn't ask which part of the license violates OSS values, I asked what those principles and values are. I will infer that "anybody can do whatever they want with the code" is the principle you are referring to.<p>I kind of thought that it was more about stuff like sharing and personal development and edification and the ability to see inside and understand things. But let's get really divisive over the money stuff.
It's about unambiguously understanding exactly what my rights are and how I can use that code.<p>In the case of the janky new 37signals license: what <i>exactly</i> counts as "... where the primary value of the service is the functionality of the Software itself"?<p>Who gets to define the "primary value" of the thing I built?
I apologize for having missed the mark with your question.<p>> I will infer that "anybody can do whatever they want with this code, OR ELSE YOU'RE NOT WORTHY" is the principle you are referring to.<p>I feel like there's cynicism in your phrasing, but a perhaps more neutral phrasing would be "Don't pick and choose what specific circumstances your users can use this for".
Or, as GNU puts it,<p>> The freedom to run the program as you wish, for any purpose (freedom 0).<p><a href="https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms" rel="nofollow">https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms</a>
There was of course and I edited it out.<p>Why is it important to give "everything" to the users? They have the source code. Why is it so important that they can use it for whatever they want?
> They have the source code.<p>This can also be true, say, of a dump of leaked Windows source code. Would you say that that's Open Source? Why not? What's different between that and Fizzy? Fizzy's creators will also sue you in certain cases.<p>> Why is it so important that they can use it for whatever they want?<p>It's important only in terms of the ethics of calling yourself open. The OSI (and many other commenters here, and me) are saying that open source should be defined by lack of restrictions on the <i>usage</i>; DHH etc. are saying that it should be defined by lack of restrictions on the <i>access</i>.<p>The reasons why I think usage-based definition rather than access-based definitions are more reasonable are:<p>- Providing access to code is relatively cheap/easy today. This wasn't always true in the past.<p>- Usage has a lot more variables than access. If you start putting restrictions on it, anyone using it has to stop and think about their usage to ensure it's not falling afoul of the restrictions. For example, if I put Fizzy on my server and provide free access to it for anyone on the internet without the 1000-item limit, does that qualify as "directly compet[ing] with the original Licensor by offering it to third parties as a hosted Cloud Service"? I would hope not, but if I want to make sure I have to pay a lawyer hundreds of dollars.
Being able to fork a project when management turns hostile is one of the most effective ways GPL software protects itself from enshittification and corporate sabotage. Source available does nothing to prevent this.
> The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?<p>A bit offtopic but could re-generation of the project with LLM (with for example prompt "rewrite the <repo> changing every line of code") help protecting from being sued? If yes, then the OS licensing is doomed to fail.
If something is open source and follows an OSI approved license I don't have to ask a lawyer to review the license before I integrate with that code.<p>The moment you change a <i>single line</i> of that license I now have to pay extremely close attention to those details again.<p>This isn't a naive idealism thing - there are very solid, boring, selfish reasons for caring about this.
This is a good technical point. But this seems to kind of argue that one of the principles of open source is that businesses should be able to pull it into their proprietary projects to make money without hesitation. Is that accurate? I thought that was kind of more of a bonus.<p>I feel like it's participating in the spirit of open source and should be welcomed, if someone wants to make their code available but just wants to try and restrict anything-goes usage. But I can see the purity argument.
FOSS was founded on The Four Essential Freedoms: <a href="https://en.wikipedia.org/wiki/The_Free_Software_Definition#The_Four_Essential_Freedoms" rel="nofollow">https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...</a> that GPL/LGPL were devised to embody. Shared source licenses don't adhere to freedom 0.
I think it comes to analogies, with open source you have a public park you are free to use. With source available it is public park you are free to look at behind a fence... So not actually public park. Still a fine thing to exist.<p>As user as well. Difference between I can use this for free and I have to pay to use this. Even if I can see parts inside is significant.<p>It might not be real principle, but at least it is real difference.
> bickering between people on the same team.<p>Uh.. are they?<p>I'm somewhat sympathetic to licenses that will be open source in X years, but the open source ethos is that, with proper attribution, we can do whatever with the code, the only restriction being that for some projects a derivative work needs to also be open source (while others don't care even about that)<p>If we were to welcome non-open source projects into a larger community, we should probably begin with licenses that forbid the usage of the software in military and things like that. Which fails to be open source for the same reason: it puts limits in how you can use the code
They’re not at all on the same team. “Open source” is given away for free, to do what you want with it. Source available is not. Fundamentally they have nothing in common other than the fact that you are allowed to read the source code.
Not the same team. Open source isn't really about the license, and it's also not even really about the source; open source is a philosophy centering open <i>development and collaboration</i>. Sharing the source is necessary, but not sufficient. Too often, "source available" means you get to see the source, but you are not invited to participate in development, and certainly you're not going to be participating in collaboration.<p>"Source available" projects want the benefits of being associated with that egalitarian philosophy because it's popular amongst technologists, who are their initial customers. But they don't want to actually <i>practice</i> the philosophy because their core interest is protecting their IP to turn a profit, not open collaboration and development. Outside contributions are considered a liability in many source available projects [1].<p>This is important because source available projects have in the past resulted in a "rug pull", when the project gets enough airspeed, so they start putting more work into the closed source to placate their investors. Once the technologists are not the primary users, the entire source available charade is done. The available source becomes deprecated, features are moved to the closed source branch, and eventually the available source rots.<p>One final point: if we call source available "open source", then what are we going to call open source to differentiate it from source available. Because they're actually different things.<p>[1]: For example, many projects won't even allow outside contributions, but when they do, you'll have to sign some sort of contributor agreement: <a href="https://www.scylladb.com/open-source-nosql-database/contributor-agreement" rel="nofollow">https://www.scylladb.com/open-source-nosql-database/contribu...</a><p>Edit: (this is to the response below me, as I'm rate limited now and I'm going to bed so I'll forget to post this tomorrow)<p>If anyone tried to do this then the project would be forked immediately. An open source project can go closed source, but as an OSS project, everyone should already have everything the need to keep it going despite that, and that all remains open. That's why we love open source.<p>Also, it'd be really hard to pull off if they've accepted a lot of outside contributions -- when you submit code to an open source project, you retain the copyright. This is not a problem as long as the project is licensed under the agreement under which they submitted the commit, which only grants rights to redistribute <i>under that license</i>. At least that's how it works with Apache 2.0 (I believe, IANAL). So to go closed source, they'd need agreements from all of their contributors to do so.<p>Now, it <i>can</i> happen. MongoDB is an example. But as far as I can tell, you'd have a hard time of it if you accepted contributions from people and they.
> Open source isn't really about the license, and it's also not even really about the source; open source is a philosophy centering open development and collaboration.<p>Not really. A project under an open source license which doesn't accept contributions is still open source.<p>It is totally about the license and the source code availability.<p>There are interesting things to say about the various development models, and those common in the open source world, but the open source aspect and the development model aspect should not be mixed.
Haven't open source projects done the rug pull too? Can't they relicense new code going forward?<p>I guess I would have thought of source available as existing under the open source umbrella. I get that there is an important distinction but from an adoption and evangelism standpoint it seems like an unnecessary crusade to push them away.<p>Do those projects have a strong track record of behaving badly? Do you think DHH has those types of intentions? (I don't know much about him really)
> Haven't open source projects done the rug pull too? Can't they relicense new code going forward?<p>They can, if the original license is permissive, or if there was a CLA. They can't for significant contributions under a copyleft license that was not done under a CLA. Something to consider when contributing to a project that uses a CLA or a permissive license.<p>> I get that there is an important distinction but from an adoption and evangelism standpoint it seems like an unnecessary crusade to push them away.<p>Depends on your goals. If source available misses the point anyway, adoption doesn't help, the message risks being blurred, and therefore you should push back.
Some people have internalized the words "open" "source" to mean more than the words, even going so far as to eschew the benefit (which was at the heart of the Stallman problem) because it doesn't fit the desired ethos and license. It's counterproductive, indeed.
I don't know, I kind of have trouble being enthusiastic about a caustic far right activist falling out with some other person over nuances in non-free software licensing.
O'Sassy or whatever is certainly Source available, and not Open Source. DHH can pound sand.<p>I used to think the pedantry was foolish, but I've grown to understand the distinction. It's one thing to criticize the OSI's claim to the term, and I do think they could do a better job at getting out ahead of new licenses and whatnot, but even if you ignore OSI entirely then the distinction is of substantial value.<p>I <i>do</i> think we need more Source Available licenses in the world. Certainly I would greatly appreciate being able to browse the source of the many proprietary software systems I've administered over the years.<p>At the same time it is not worth it if the spirit of Open Source is watered down.
> I do think we need more Source Available licenses in the world. Certainly I would greatly appreciate being able to browse the source of the many proprietary software systems I've administered over the years.<p>Yeah. Releasing a project under a source-available proprietary license and calling it Open Source, or doing a rugpull and changing an established Open Source license to a source-available proprietary license, is the kind of thing that causes the most grief. If you release something under a source-available proprietary license and make no pretenses about it being something else, and the alternative was not releasing it at all, it's a (slight) improvement.
> I do think we need more Source Available licenses in the world. Certainly I would greatly appreciate being able to browse the source of the many proprietary software systems I've administered over the years.<p>I think we need more differentiation and different terms. Because O'Sassy / FSL / whatever that just forbids other companies from selling the same software as a Service is quite different than just the source being available with no rights at all, or with restrictions on who can use it and when (size of company, for profit or not, production, etc).
> DHH's choice of license reacts to a real pressure in open source: many companies make real money from open source software while leaving the hard work of building and maintaining it to others.<p>If you don't want start a business and make real money from your software then denying that to others is antithetical to the concept of open source and free software.<p>That being said; I have no issue with a developer choosing any license they want -- it's their software and therefore it's their right. But calling it "open source" when it specifically forbids certain use-cases is just wrong. DHH wants his cake (pretend it's real OSS) and eat it too (deny usages).
> If you don't want start a business and make real money from your software then denying that to others is antithetical to the concept of open source and free software.<p>What if you do and have done so, yet you're competing with e.g. AWS, GCP, Azure, who can do it for cheaper than you due to scale, and also have a much easier time to sell an extra line item to their existing customers vs you having to go through commercial negotiations and purchase agreements? Cf. Elastic, Redis, etc.
If you have a problem with that then don't make it open source.<p>And if you don't make it open source, don't call it open source.<p>My own personal position is that my commercial software is commercial for me and my open source software is free for everyone to use for any purpose <i>including making money</i> that I will never see. If I cared, I wouldn't make that software open source.
Watching what we charitably call this debate flare up yet again gives me an odd mix of feelings. On the one hand, seeing people I've read and listened to for years heave time, attention, and more typing onto this tire fire evokes deep tragedy. On the other hand, I've been there, casting my own vanities to the bonfire, more than a few times. There's comfort in the familiar heat and glow.<p>I couldn't escape the waste until I was willing to give up the idea of myself as experienced, as an expert. Until I accepted that time served taught me lessons, but didn't bestow authority. Most people coming into this are new. They relearn what's useful and leave the rest behind. That's part of adaptation. I try to see their point of view.<p>If you ask a newer coder what "open source" means, they might say "like MIT?" or even just "like GitHub?" If you look "open" up in a good thesaurus, "available" is there. The Initiative---really, whoever's on the board now or later---will never own or effectively police the term "open source", much less "open source AI". And nobody claiming "open source" for good or ill will ever summon on themself the kind of attention or cachet that marketing bauble once commanded, no matter what their license says.<p>As for fellow oldheads, there's no resolving contradictions between ways we learned to frame these issues, decades ago. Can changes to a license be a solution to the funding problem? Can using freedom terms to buttress a business count as truly open? That bizarre conflict of ontologies won't decide where programming goes in the future, if it ever did. I doubt it will even be won or lost. It will just fade away, like the circumstances that started it.<p>DHH can kick the anthill. The activists can raise their old hue and cry. It's purely elective, demoded dramatics. The real problems of software politics today aren't expressible in either schema. They can even seem tautologically unsolvable. Meanwhile, we've got new aspirational generalities that aren't expressible in the old ways of speaking. "Sustainability", because many doing good aren't doing so well. "Decentralization", because we're all sharecropping on some platform now.<p>Sometimes I think the best I can do for the younger generations facing today is just to never impose petty trivia about "the movement" ever again. Never deign imply I know what they should consider important. If "free" and "open" meant something to me, let their inheritors tell me what they mean now, in practice. Tell me about the world they built and left for them.<p>Maybe I don't have to choose. After all, who reads blogs?
Now it all makes sense, thank you.
> After all, who reads blogs?<p>I used to read yours, anyway!<p>If the literal lawyer who specializes in licenses doesn't have a clear point of view on this, what hope do the rest of us have?
My point of view is clear, but what I see is complex. Things seemed simpler back when I believed what Slashdot told me, before I'd spent twenty years getting involved and looking closer.<p>If you're looking for a seer with a salvation plan---as technology, legal innovation, organizational form---I don't have hope to offer you.<p>Look at the figureheads of free and open, the "philosophers". The ones we remember succeeded, but not on the terms of the lofty gospels they preached. Very few practical systems are "free". Most competitive software is closed, and sharing code across orgs still sucks much of the time. Linus succeeded, but Linus just wanted to code, get respect, and make good money. Glad he did.<p>Thinking we'd seen the end of software history got us here. Now I see more willingness to try new things again. They mostly wither or fail, but so did most early attempts at "free". Mutation, selection, adaptation.
we need more source available, not less. im not the only one sick of the osi thought police. im fine with still calling it open. ya know what else, free as in speech is great. but so is free as in beer.
[dead]
Interesting. The post is about whether a license prohibiting SaaS competitors is "open source" and whether it might work out as a good way to ensure project sustainability. In this context "source available" means that you have the source code but you can't use it to compete with the project owner. [Kinda puts Omarchy in a different light don't you think?]<p>There is another, I think different, form of "source available" that I've seen a bit lately, similarly from corporate/commercial sponsors: the source code is released under an OSI approved license (e.g. BSD, GPL licence) and the owner maintains and develops the code in an ongoing fashion, but there is no way to easily interface with the developers, contribute changes back to the project, nor is there any public facing bug tracker or developer/user community. To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.
> There is another, I think different, form of "source available" that I've seen a bit lately, similarly from corporate/commercial sponsors: the source code is released under an OSI approved license (e.g. BSD, GPL licence) and the owner maintains and develops the code in an ongoing fashion, but there is no way to easily interface with the developers, contribute changes back to the project, nor is there any public facing bug tracker or developer/user community. To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.<p>No, that's very much open source - in fact, it was the way most big name open source projects were developed back in the early days. See the famous "the cathedral and the bazaar" essay. Public bug trackers and widely soliciting contributions to mainline are relatively new phenomena, but you always had the right to fork and maintain and share your own fork, and that's the part that's essential.
How easy do you have to make it to contribute to be considered “open source”. Obviously, no project accepts every single pull request. Where is the line between “open source” and “no open source” in your definition?
Intent. Do you intent to be a genuinely open community and is it set up around fostering that dynamic as a central aspect of development? It's hard to measure intent, but we can do so indirectly by looking at the project structure:<p>- Are there contributor guidelines?<p>- Do contributors have to sign a waiver before they can contribute any code?<p>- Is there a RFC process?<p>- Does the project actually respond meaningfully to that feedback, or does it simply get filed in the special complaints folder for corporate.<p>- Does the project encourage outside contributions in more than a cursory way?<p>- Does the CLA grant the company unilateral relicensing rights?<p>- Are governance documents public?<p>- Can the community vote on decisions?<p>- Does the community have a say in how it's moderated?<p>- Are community members invited to actually join the organization?<p>- Are architectural decisions made in open meetings?<p>- Is there a public ROADMAP and is the community invited to contribute to it or influence it?<p>- Can others build competing distributions without fear of retaliation?<p>- Can the project be forked if there is community disagreement about direction?<p>Those are just some signals off the top of my head. There's no bright line; the presence or absence of a few won't say anything one way or another. But if many of the answers to those questions are leaning toward the negative, then I don't think it can be open source.
Some of my favorite open source software is random stuff that the author just completely abandoned but had the forethought to make open source so that others could still use it, fix bugs, add features, and even fork it.<p>RMS just wanted to be able to fix his printer driver.
Completely disagree. To me, and the OSI, none of those things other than redistribution and forking have anything to do with being open source or not. In fact, you could have a closed source project tick nearly all of those boxes, although that would indeed be very unusual.<p>I'm not sure if there is a term for what you are describing. Perhaps "community driven project".
> To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.<p>I feel like this is a completely different conversation, but this is <i>just</i> as much a misunderstanding of what open source is as DHH's.<p>As long as the code is under BSD or GPL, you are free to take it as-is and do what you want with it. You could run your commercial service using it. You can certainly write patches and apply them to your own servers. You could even email the maintainers with them -- worst case is that they will ignore the emails!<p>Open Source does <i>not</i> guarantee that your contributions will be accepted or merged back to the project -- indeed, if you think about it, that would be absurd. I might want some random thing in the Linux kernel, but the maintainers will always have the final word on whether they want my patches or not.<p>The O'SaaSy license says that (essentially) 37Signals will sue you if you try to host this on your own servers, and try to sell it as a service. That's totally different, and a <i>legal</i> rather than a <i>technical</i> hurdle.
> To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.<p>It’s massively different from source-available in that anyone can fork it for free and start developing it themselves however they want. Just because one fork of the project (the original one) follows a closed development model doesn’t change anything about the code, what you can do with it, and how others can develop it.
> Look, the term "open source" has a specific, shared meaning<p>No, YOU look. The term "open source", being made from two common words with <i>actual</i> specific, shared meanings, unfortunately together create a common-sense meaning that is NOT the "specific, shared" meaning that the Open Source Initiative defines it as. So, we'll spin and spin, stuck in this endless debate. And no amount of beating people over the head (except, maybe if you can find a way to reach through the computer and do it physically) will change that.