Comments on another thread got me thinking about the future of Xoops.

There is speculation that XOOPS 3 will be LGPL not GPL. This on the surface seems to quash all of the "how can modules be developed for money and publicly distributed, and yet development costs be defrayed?" questions.

However, I have some concerns in this regard. The Free Software Foundation states:
Quote:

I do not think that XOOPS is a "special circumstance".

What would the impact of a LGPL license be? Developers could create modules and sell them as closed source applications. You may think this sounds fair, what is the problem? The recipeints would have no legal right to extend the modules and contribute back the code! That is a huge downside.

How many times has a module been extended by others to make it better? And the whole community benefits. Take away that garunteed right to improve and redistribute, and people will have to reinvent the wheel every time. Community development will surely slow.

I am a perfect example of why LGPL is a BAD IDEA. I am a business man. My motivation in business is to make money. I do not love Xoops. It is not my family. XOOPS is a tool I use to solve problems for my clients. I get paid to use and improve it when needed. Right now I am incented to release my code for several reasons.

1> I can not sell it and make money for a sustainable time. This is because once I sell it, it is now public domain and freely redistributable.

2> I want others to help maintain and improve it.

3> I want to give back to the community.

When you change to a LGPL license, reason number 1 goes out the window. And even though reasons 2 and 3 are still there, my business sense tells me to make money from the sale of the module. Community responsibility is not enough. Enforceability is required. Thus the need for the GPL.

As a side point. Could someone please explain to me how, with out a complete rewrite with no XOOPS 2 code, XOOPS 3 can be released as LGPL. Dosen't the fact that it is GPL require that all derivitive works be GPL(or less restrictive) as well? Or is their provisions for this that I am unaware of?

JMass

The licensing discussion has been hibernating for quite a while and never really took off.

One of the main advantages of releasing XOOPS as LGPL is (if I recall correctly) that we will be able to use other LGPL code in it - but I may be wrong there.

Regarding whether XOOPS 3 can even be released with a more restrictive license, I would think that it could as the idea of XOOPS 3 is that it should be much different from XOOPS 2 - however, Skalpa has been able to implement a lot in XOOPS 2.1, which was not expected to be even possible without a complete rewrite, so XOOPS 3 is still very much in the planning stage.

I don't know if it matters at all that the XOOPS Organisation in general is the "owner" of XOOPS - I haven't studied that part of the GPL.

Any way, it is not something imminent - but do let us get a discussion going, also for those, who do not know about the differences between GPL and LGPL.

Hmmm...I wouldn't be very keen on seeing XOOPS head in a direction that would encourage privatisation of parts of it.

I don't look at XOOPS as a collection of modules, I tend to think of it as a system. There is no one module that made me use XOOPS - it was the fact that there was so much functionality available. I'm sure that giving devs the option to lock up their work (should they choose) with fees and licenses would deliver them some benefits (good !) but wouldn't it weaken the system / community process as a whole ?

Just two random and entirely flame-free cents.

Are there any other LGPL CMS out there ? Surely this sort of thing has come up before.

The LGPL is intended for libraries and other "utility level" code, not an application like XOOPS.

-------------

Quote from the LGPL:

This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

....the Lesser license provides advantages in certain special circumstances.

For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.

In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software.

--------------

I can think of no reason to use the LGPL with XOOPS. It makes no sense. XOOPS is not code that can be embedded into another application. We're not talking about a protocol implementation like OpenLDAP or OpenSSL here.

Since XOOPS is GPL code, to release it under another license would require rewriting it from zero, wouldn't it?

--Julian

Just to be absolutely clear on this fact: The XOOPS core is free of charge and will continue to be free of charge.

The LGPL suggestion was brought up because of an immediate advantage. This advantage was NOT that module developers would be able to charge for their modules and restrict their use.

The discussion is available on Xoops SourceForge forums

Edit: reading the discussion again, the core of it is that with a LGPL core, it is possible to use other LGPL code in modules - something which is not possible with a GPL system.

i've seen other groups change the license of their code from GPL, i think it's possible since they 'own' the code, but they can't affect the older GPL licensed code, just their newer releases, from what i gather.


anywho, i personally think XOOPS should change to a license that encourages both contribution back to the system (open-source environment with active contributors) AND the ability to release a closed-source module, for sale.

programmers need an outlet to earn money sometimes, and when they've already coded a module, then why should you expect them to instead sell their 'services' instead of marketing their already existing work?


i don't think that all modules should be closed-source (or closed licensed), but the option should definitely be there. there are often good applications that can be developed by a company or team, on a faster timetable and of higher quality, than some open source products, and i'm willing to pay the $5 or 10 or 15 fee (or more) if i want that product (usually if there's no comparative free module or product, regarding the feature set & quality, is when i'll buy it)

OK, let me make this clear: the discussion on the XOOPS future licensing is purely to get an overview of the options we have. We're going to research this more deeper soon, and put the options before you all.

The main reason for looking at the LGPL is (as Mith stated correctly) to make it possible to integrate XOOPS with non-GPL (corporate backoffice) applications and whatnot. This would greatly increase the implementability (is that a word?) of the system. As Mith also stated correctly (damn, he's good, isn't he?), the XOOPS core and official modules will ALWAYS be free and open!

Herko

just to clarify my end as well, i'm speaking for 3rd party modules


btw herko, there's a pm for ya at dev.xoops from awhile back, and also i have a thread open at sourceforge that i'd like you to look at as well (related to the same topic)

[ot]bd_csmc: I've been away for a few days, I'll get back to you on that tomorrow or the day after [/ot]

Herko

Quote:

It is my understanding that the copyright holder (Xoops.org) withholds the right to release XOOPS under other licenses. I could be wrong though.

This leads me to another question, would a dual licensing model (like MySQL, MAMBO or EZPublish) be another option? Essentially there would be two licenses available for Xoops, the free GPL license, or a commercial license giving the right to rebrand and sell versions of XOOPS and develop modules under a commercial license. The only thing I'm not sure of is if a module is developed under the commercial license, can it be used under the GPL version without taking on the GPL license itself? I've tried searching the web for an answer but haven't found anything yet to that exact question.

Could you restrict module use to only commercial versions? Thereby allowing people to develop modules for either the GPL version (open) or the commercial version (closed)?

Another question is how improvements submitted work. If an improvement is made to the GPL version, can it be included into the commercial version or does the improvement need to take on the GPL license??? Not really sure how mambo and eZpublish work this since I'd assume their software is essentially commercial and then grants a GPL cversion afterwords, since you couldn't do it the other way around... could you?

Gah, I've been reading licensing sites for hours now and I'm more confused then when I started. lol

I definitely think a dual license could be a possible solution that satisfies both sides, the GPL for free use, and the commercial for those wishing to do more with Xoops. The only thing I'm not sure of is how this would work with XOOPS since Xoops.org isn't really a company, while the site owns the copyright, no one person owns the site, or do they? Would Kazu?


References and discussions of interest:

Here's a great write from Mike Olsen at Sleepycat (Berkeley DB), a company currently using the dual license. Has some great reasons why a corporation would not use an Opensource product, but would if it were duel licensed.
http://www.linuxworld.com/story/33893_p.htm

FAQ on MySQL's Dual License
http://www.mysql.com/company/legal/licensing/faq.html

Interesting discussion concerning eZpublishings dual license
http://ez.no/community/forum/general/license_issues/re_gnu_gpl_license_finally_answers

Duel licensing as a marketing approach
http://management.itmanagersjournal.com/management/04/06/24/2057239.shtml