Fergal, *Warning* - Wall of text ahead! If you think OSS works perfectly fine the way it is today feel free to press delete now...
I've been holding back commenting on this thread to see where it would go. It is nice to see everyone's take on the need for (or not) a solution to the lack of an OSS "business model." From what I can tell, there really isn't a business model in OSS at all. Almost by definition, the "market" for OSS is a failed market. What other industry/market exists where the price of goods is $0? Freedom issues aside, when you give away the fruits of your hard labor you are doing just that, giving it away and that in no way constitutes a sale. The Free Rider problem is alive and well, that is just human nature. I would love to live in a world where this isn't true and I actively work towards a future when we can all just work on whatever scratches our itch, but so far we are not there yet. Of course, ancillary to the lack of a price/valuation for the code itself, companies still make money by various other means given the environment created by the OSS they give away. I doubt that Clojure or any other OSS project has ever made any significant cash flow just giving away code. Conferences, books, consulting services, freemium, value added Closed Source/Dual License products and all the rest make up the difference (hopefully!) Sometimes just the marketing visibility generated by giving away code is enough to cover the costs of producing it. In that way, OSS can be accounted for as a marketing "give away" from which other revenue and "goodwill" will flow. This is obvious stuff we all know. To be perfectly honest, I am not a fan of the GPL or any other viral license. I do not believe "code needs to be free". Code is code, an inanimate artifact of human labor. Everyone is free to give theirs away - I think this is admirable and altruistic behavior that we need more of. I'm very grateful that Rich and all the rest of the Clojure developers, contributors, library authors, etc. are giving their time, effort and focus to make this community what it is, awesome! A very big shout out to all of you. Clearly there is a spectrum of software that runs the gamut from operating systems, languages, databases, tools and other "utility" code, up through more targeted platforms such as SAS, CRM, SalesForce type systems. Another example class of software might target an industry such as Construction Project Management systems or even custom software written in-house or by a consultancy for a specific customer (that could, in theory, be refactored and sold to another customer), software written for a specific piece of hardware (my day job) and finally software written by the NSA, which has no market value whatsoever. As the utility for a wider audience decreases so too does the potential market, which in turn affects how licensing terms are chosen for any given project. Each of these classes of software seems to have different requirements for licensing terms. Typically, OSS projects tend to fall under the "utility" class and has the widest audience, almost by necessity/definition, and seems to do best with very lenient license terms. All of these classes of software overlap to some degree in their needs for things like developer mind share or the availability of engineers to work on a project, technology or code base. Layered on top of the pragmatic concerns listed above are the larger moral (e.g. freedom) and societal (IP/patents, OccupyStartups?) factors that influence the choice of licensing terms for a code base. Clearly the GPL and other Open Source licenses are very opinionated in their terms. In reviewing your license terms, I don't know what class of software your license is intended to target. Your approach may have a fatal flaw in that the time it takes to bootstrap is highly variable and having a fixed deadline might fit some projects/markets but not others. In my thirty years of working in the Silicon Valley for many different startups we were almost always too early into the market. This left us running out of money and scrambling to find other sources of revenue (pivoting in modern parlance) and inevitably shuttering the business or being bought out for very small fractions of the potential value. We built a Tivo-like system before there was a Tivo, we did ads and coupons on gas pumps, ATMs and grocery checkout terminals long before there was Groupon, we built teleradiology systems before telemedicine became a thing, etc. etc. I once filed a trademark application that described/covered the features provided by GitHub, LinkedIn, Atlassian, Asana, Slack, AngelList and Kickstarter -- predating all of them by ten years or more. If only I had help getting going in those early days... sigh. Another problem I see is this, why would I work hard to bootstrap a project, to prove it has economic viability only to have someone else come along, fork my code base and compete with me? It seems that the time-bomb terms will filter out certain classes of software from using the license. At the risk of being redundant, I will once again mention the Co-op Source License. This license has been under development for a number of years now and attempts to solve the Free Rider problem in OSS. As with your license, the basic premise is to strike a balance between OSS licensing terms and traditional closed source licenses. It does this by having the code owned by all the members of the cooperative (often an LLC for the purpose of fitting into existing legal frameworks.) Members of the cooperative share the code as well as the rights and responsibilities that come along with building a commercially viable project. Projects are organized in a democratic fashion w.r.t. general goals, direction, large decisions, etc. but are run day-to-day like many OSS projects are by a core group of maintainers with the "lead" role being rotated on a release by release basis. Individual projects are expected to be "federated" into a larger whole (a not-for-profit corporation) so that the result looks a lot like the Valve corporation is organized - a very flat organization with lots of autonomy for individual projects and members with a common support structure that helps with common services for the members/projects. This organization would provide funding mechanisms (via membership fees, direct investment and/or crowdfunding) as well as legal, marketing, sales and other services for the member projects, either directly or contracted to outside firms. By incorporating the seven cooperative principles into our software license and membership agreements, we enjoy the benefits of being a cooperative: cooperatives are one of the most stable forms of enterprise, often surviving two, four or even ten times longer a typical commercial enterprise. It is interesting that someone brought up the subject of Credit Unions vs Big Banks. Guess what, Credit Unions are cooperatives! I see this approach providing an alternative to large tech companies like Oracle, Google, Facebook and or VC backed startups. Cooperatives distribute a majority of profits back to the members in accordance with their contributions. Utilizing direct democracy allows each member to have the same power over the direction of the project(s) and the community as a whole. I suppose our visions are divergent in many respects but I do wholly support your goal of finding a viable commercial alternative to the typical OSS license. The Co-op Source License is not viral but it is inclusive, fair, transparent and pragmatic. And of course, source code is *always* included. :-) I have been thinking and working on these topics for an embarrassingly long time. Most of that time has been waiting for the limitations of commercializing OSS to become apparent over the OSS hubris of the last decade or so. I think developers are finally realizing that using an alternative licensing scheme is both a valuable, sustainable and worthwhile endeavour. Again, sorry for the wall of text... some things just take a bit of explaining. Take care. Alan P.S. I too am an old-school C++ dev :-) On Friday, June 5, 2015 at 3:17:43 AM UTC-7, Fergal Byrne wrote: > > > An old-school C++ dev and I have started an initiative to combine the best > of Open Source with a limited commercial license. It's not a new idea - > MySQL creator Monty Widenius thought of something less viral in 2013 [1]. > > The Time-Bombed Open License [2] is the commercial side of a dual-licensed > project, best paired with something strongly viral like GPL. Essentially, > the project owner has 2 (up to 4) years to commercialise their product and > then must go fully Open Source. The license is viral, so any commercial > licensees must also use the TBOL and eventually open up their derived > products. > > One major idea is to foster a culture of disruption of exploitative > industries. If you can develop software to disrupt in your local market, > your innovation can be used similarly by others elsewhere, and each new > startup can improve on your work while earning their keep. Eventually, all > derived products become Open Source and are free to all. > > We'd appreciate any comments, feedback and assistance from the wonderful > Clojure community - we're up on twitter at @OccupyStartups. > > Regards, > > Fergal Byrne > > p.s. I wonder if this might be a solution to the clamour for Datomic to be > Open Sourced (cough)? > > [1] > http://monty-says.blogspot.ie/2013/06/business-source-software-license-with.html > [2] http://occupystartups.me > > -- > > Fergal Byrne, Brenter IT > > http://inbits.com - Better Living through Thoughtful Technology > http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne > > Founder of Clortex: HTM in Clojure - > https://github.com/nupic-community/clortex > > Author, Real Machine Intelligence with Clortex and NuPIC > Read for free or buy the book at https://leanpub.com/realsmartmachines > > e:fergalby...@gmail.com <javascript:> t:+353 83 4214179 > Join the quest for Machine Intelligence at http://numenta.org > Formerly of Adnet edi...@adnet.ie <javascript:> http://www.adnet.ie > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.