Re: [Nectar-devel] Licensing of the base distribution...
Status: Alpha
Brought to you by:
skander
|
From: Royce A. <124...@cs...> - 2005-04-26 12:53:18
|
I don't see not including MySQL support Nectar as a huge problem as I plan to implement some better database system in the future anyways (native to nectar =D). POstGreSQL is fine anyways, if a little slow...But we have record caching (and soon query caching) so that's not a huge issue for small sites/serving needs. On another note - being the rebellious bugger that I am, I'm rewriting the query and record system to be what I call better - expect updates/approval requests sometime soon... --ROyce > Extract from previous emails not posted to the list: > > -------------------------------------------------------------- > > The other topic is choosing the right license for the base > distribution of Nectar. Fundamental to this is a business concept > behind Nectar, which even if we don't want to make any money from > the project, we should have some form of business plan to at least > promote the use of the system. > > I would like these things to be in that license: > > 1. using an open source model > 2. allowing proprietary code to link with Nectar > 3. somehow make money from commercial, for-profit users, ie > e-commerce or paid hosting. > > The problem is that the Open Source Definition > (http://opensource.org/docs/definition.php) states in Article 6: > > 6. No Discrimination Against Fields of Endeavor > > The license must not restrict anyone from making use of the program > in a specific field of endeavor. For example, it may not restrict > the program from being used in a business, or from being used for > genetic research. > > /*Rationale:* The major intention of this clause is to prohibit > license traps that prevent open source from being used > commercially. > We want commercial users to join our community, not feel excluded > from it./ > > so goal #1 and #3 are in conflict. > > One option would be to keep all the clustering code totally > proprietary, or even code that allows for multiple projects (though > that would be *very* difficult). The problem here is of course that > since we're using an open source model, we can't prevent anyone from > writing a clone of our clustering software. > > So that doesn't really work either... > > What we could consider is a not-so-open license which would only > restrict commercial users (which really isn't very different from > what MySQL and Trolltech are doing, they're just using a different > approach!). > > The final option is to adopt a license policy similar to MySQL / > Trolltech. Release Nectar in GPL, and make anyone that wants to > release proprietary code that uses Nectar pay us... This is a really > bad option for us I believe, because it would drive away a massive > amount of potential users, and the competition is rough... > > My initial "dream" was to build a not-for-profit organization > (association) that would, with it's income, pay developpers and > project managers. Why not a corporation? cause I don't like the > tyrannical structure of corps... in an association, the body of > members (including package developpers paying a membership fee) > would vote on key positions in the association and on important > decisions. Package developpers and any other financial contributors > would essential become similar to the share holders, who would get > their value not in return from investment, but in a better end > product. In a corporate world, it would be the founders / owners / > investors who would collect the profit, which then would be > financial and not necessarily a better product. > > So, yeah... I'm trying to keep away from the evil corporate world. > But because of Article 6 in the OS definition, the 'soft' business > plan crumbles, and we'd have to use a non OSS license, making us > evil anyway... :( > > But not all is lost... > > Let's stop thinking about software as a product, but rather as a > service. Nectar specifically, is much more of a service than a > product. > > So where do we make the cash? > > Hosting. :) > > We could go fully LGPL (as long as MySQL isn't gonna be a pain) and > focus a business model on a server hosting business. We'd focus on > tuning the servers just right and we'd provide support to project / > package developpers. If another hosting company wants to start > hosting Nectar projects as well, they can take the source code and > try, but they wouldn't have the system expertise that we would, nor > many tools that we would keep inhouse... > > This hosting concept doesn't lend itself too well to a > non-profit-organization, but it's quite possible a hybrid could be > found, or even just a partnership (ie, a corporation would provide > hosting and subcontract tech support to the non-profit org, which > would actually for a "repeatable process" (ARGGGHH get SE out of my > head)). These contracts would then provide the funding for > development efforts within the org... > > -------------------------------------------------------------- > > > > Now here's the problem... I just received an email from MySQL licensing > / sales department: > >>> I'm leaning for LGPL because I want to allow others >>> to develop and run proprietary code on this platform, >>> which would mean that their code would link to the >>> LGPL base code. Their software would then run on >>> a shared server cluster, running potentially hundreds >>> of different proprietary software bits from different developpers. >>> >>> So, in short... Proprietary code links to my LGPL code >>> which links to GPL MySQL... What happens to MySQL's >>> licensing policy? >> >> > > From > http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL > ======= > If a library is released under the GPL (not the LGPL), does that mean that > any program which uses it has to be under the GPL? > > Yes, because the program as it is actually run includes the library. > ======= > > => So your "LGPL" would need to be GPL'ed, thus > forcing your proprietary code to be GPL'ed as well. > > >>> If that means a commercial license is required, who needs >>> to buy it? Each developper of each proprietary bit of code or >>> just me, the developer of the base distribution? >> >> > > In that case you should purchase right to distribute > the commercial MySQL client libraries with your > programs. And this requirement would rely on > your shoulder, as you are the person, in whose > interests it is to ensure, you are GPL compliant. > > Good additional reading is available at > http://www.fsf.org/licensing/licenses/lgpl-java.html > > >>> Furthermore, a single server may run a large number of projects, >>> but not all will use MySQL (other data adapters may be available). >>> Consider one developper has written proprietary code that indirectly >>> links to MySQL code, but doesn't use it... Does he also need a >>> license?!? >>> >>> Or is this all a moot point because LGPL code isn't allowed to link >>> to GPL code? >> >> > > If you want to make sure, you can create your own > drivers in LGPL, you must get commercial MySQL > Client libraries to "cut" the link to the GPL server > or purchase commercial MySQL Server to be run > beneath the system (and the licenses are really > cheap: 250 Euro/server for MySQL Classic and > 500 Euro/server for MySQL Pro). > > > > In short, this means that Nectar can't include the MySQL Connector J > driver (necessary to access a MySQL server) in the distribution unless > Nectar is itself GPL. Nectar will still have MySQL support (or more > generally, SQL support), but will ship without the MySQL driver. It will > be up to the end user, if they want to use MySQL, to buy a Commercial > server license from MySQL. > > In order to use MySQL freely, Nectar would have to be GPL, which in turn > would prevent anyone from developping proprietary code for Nectar > entirely (even if they bought the MySQL license then, Nectar would still > be GPL). > > So MySQL is one problem and can be easily circumvented, simply by > shipping Nectar with a Postgresql driver instead of MySQL, which comes > under the BSD license, which isn't 'viral' like GPL. The > MysqlDataAdapter implementation will remain in the base distribution, > because it doesn't link statically to any MySQL code, it only links at > runtime if the driver .jar file is available. > > The MySQL driver is currently the only "offender" in Nectar, the only > piece of software that Nectar uses that is GPL. > > > Now... Nectar heavily relies on a lot of Apache Foundation projects, > especially Jakarta Commons and Struts. Some parts of Nectar are actually > modified source code from a variety of different Struts releases. All > this code is under the Apache License, which makes no restriction to > being linked with proprietary code, but the license doesn't allow people > to take code, modify it and release it under another license. > > In essence, this would mean that if Nectar would be released in LGPL, > some parts of it would have to come under the Apache License, which is > just really confusing and messy... Since there is no real reason I can > find why the LGPL is any better than the Apache License, we may as well > use the Apache License for the whole of the base distribution. > > Soooo... that's that... If there are no complaints or unless someone has > suggestions, the next release of Nectar (not coming anytime soon just > yet) will be under the Apache License, version 2.0, and will not include > MySQL support directly! (http://www.apache.org/licenses/LICENSE-2.0) > > Then there's the matter of finding a good license for the sample code, > which should be an open source license that actually allows anyone to > take the code and use under any other license, proprietary or not, but > that'll be in another mail :) > > -kai > > > > > > !DSPAM:426e2c2a157331858919272! > |