Re: [Nectar-devel] Licensing of the base distribution...

[Royce A. <124...@cs...>]

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!
>