Feedback on potential Joomla! Framework LGPL license change

[AmyStephen]

Michael, Andrew, Don, George, and myself have all explained over and over and over that as contributors, we ('we = a collective set of developers who have contributed code') signed the Joomla! Contributor Agreement granting OSM authority to use our code contributions with any of the licenses defined in the agreement.

The link to the Joomla! Contributor Agreement has been provided multiple times and is provided again http://developer.joomla.org/9-site/7-jo ... duals.html for all to see what licenses OSM is authorised to use.

This information was provided in response to a question "Why not MIT?"

The answer is because OSM is not authorised to use that license.

[AmyStephen]

Why was this LGPL even created for ? LGPL is only here to undermine free software

Hi Arktor -

There is a one situation in which the FSF recommends using the LGPL and acknowledges using the GPL presents a clear disadvantage.

From the FSF:

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

Source: https://www.gnu.org/philosophy/why-not-lgpl.html

Given the stage of PHP framework availability, there are many other frameworks available that provide access to basic website services, like database or filesystem access.

The FSF recognizes that in situations where software is a commodity (meaning -- it fulfills standard and basic functionality, common) enforcing the GPL is a disservice to the project. In those situations, the FSF recommends using the LGPL.

Hope that helps.

[Webdongle]

@Amy
Thank you for clarifying that you were speaking of developers authorising the use of their code in any of the licences listed in the JCA ... and not about developers authorising the OSM to change from GPL to any of those licences.

[AmyStephen]

I'll be completely honest.

If either of these things happen:

1. OSM approves the LGPL relicensing but forces the Joomla Framework to stop using the Joomla Trademark.

2. OSM disapproves the LGPL relicensing, allows the Joomla Framework to continue using the Joomla Trademark, and the PLT then only accepts LGPL code.

I wash my hands of all of it.

It's "All Together, As A Whole." Everyone needs to grow up.

[dilbert4life]

@Amy
Thank you for clarifying that you were speaking of developers authorising the use of their code in any of the licences listed in the JCA ... and not about developers authorising the OSM to change from GPL to any of those licences.

You may not agree, but those items are exactly the same. Approving of the licenses in the JCA by signing is the developer authorizing OSM to change from GPL to any of those licenses.

[NivF007]

+1 LGPL for the Joomla! Framework

If you’ve somehow managed to follow this monster of a topic, you’ll see that I have switched from a staunch GPL position to being supportive of, and embracing, a potential switch to LGPL for the Joomla! Framework.

For those still struggling with either understanding the issues, the difference between the Joomla! Framework and Joomla! CMS and the implications of licenses, I hope that you will find the following analysis to be helpful in arriving to a decision.

The simplest possible definitions

First let me begin with the simplest possible definitions I can use to describe what we are talking about.

Joomla! Framework v. the Joomla! CMS

Think of building a car.

Joomla! Framework: The ‘nuts and bolts’ used to build the car.

Joomla! CMS: The car.

The distinction here is that the CMS is end-product (the application). The Framework itself is not an ‘end-product’ but can be used to build much more than just ‘cars’ (many different applications).

The licensing discussion is with respect to the Framework.

Licenses Simplified

GPL: if you use my code in yours, you must distribute your code as I do for mine.

LGPL: if you modify my code, you must distribute your modifications.

MIT: do what you want with my code except pretend that the code is yours.

Why is OSM being asked by the Framework Team to switch from GPL to LGPL?

The underlying reason, which I've come to understand, is to attract more developers for the Framework.

GPL has in ‘infectious’ quality to it. Again, this is an over-simplification, but if you use GPL code in your code, then your code must become GPL too.

This prevents many people from using GPL, not just those who want to produce ‘closed-source’ software, but also open-source developers who don’t want to place (or for other reasons cannot place) such impositions on their code-base.

In this context, the “open-source by force for all your code” effect of GPL excludes potential contributors.

The effect of a switch to LGPL is that by removing the “for all your code” part of the conditional use, and switching to a “open-source by force for my code only” will remove the barriers that are keeping developers from participating.

The feeling you are selling your soul

Perhaps why this has been such a difficult decision is that licensing is also, for many (myself included), tied to a socio-political ideology known as the 4 Software Freedoms, an ideology evangelized by Richard Stallman, many, many years ago. (see http://www.rastinmehr.com/2009/03/01/th ... -stallman/) - in fact for me personally, it was this ideology that led to my involvement in open-source to begin with.

According to him, a program is free software if you the user have the 4 essential freedoms

1. Freedom to run the program as you wish.

2. Freedom to study the source code of the program and then change it so the program does what you wish.

3. Freedom to help your neighbour. That’s the freedom to redistribute the exact copies of the software when you wish.

4. Freedom to contribute to your community. That’s the freedom to distribute copies or modified versions when you wish.

If the program gets you all these 4 essential freedoms, then it is free software.

Under GPL, anybody who uses Joomla! code gets these advantages, in turn, when they distribute it, they are required, under the license to pass the those 4 freedoms on, not just for the Joomla! software they received, but for any derivative work they distribute. This is why extensions in the JED must be GPL.

For myself, and I believe for many in the community, Joomla! has always represented this ideology.

I therefore sympathize with those who feel we are ‘selling our souls’ by not insisting on GPL – I had that strong sentiment – not so much for rational reasons – but the GPL movement is certainly one I’ve embraced and come to identify with (in fact I left good job in a propriety company because I felt I belonged in an environment which embraced open-source - and I strongly identified with the GPL).


When the GPL ideology becomes counter-productive

There is an excellent article, Does GPL hurt free software? by Martin Sustrik. (see http://250bpm.com/blog:7) For brevity, I won’t repeat it here, but I’ve found this to be the single best write up for the negative impact that GPL can have.

I would encourage anybody who still has misgivings about GPL to read it – and see if your opinion changes.

The Github effect

The GPL ideology was born long before Github began to play such a major role in software development. If it is the attraction of developers we seek, in today’s world, Github is the ‘forum’ on which that involvement occurs.

The projects that thrive on Github are the ones with the most permissive licenses (i.e. the ‘no strings attached’ MIT license). Think of jQuery for example utilizing MIT – although the 4 freedoms are not enforced – the is a robust community, active development – and in the end, it is easy to see how everybody has benefited far more from the ‘no strings’ attached approach.

More permissive licenses on Github have translated into more software, and better software - for everybody.

Why not MIT?

It seems then, that MIT would be the way to go to foster the most involvement on Github. Regrettably, because there have already been numerous contributors who signed the Joomla! Contributor Agreement (JCA), a contract which contemplates LGPL but not MIT – it becomes a very complex matter to switch to MIT to the point where an MIT license is not considered feasible. It's not impossible - it's just considered by many that a switch to MIT would be overly complex to really consider - regardless of it's merits.

So is LGPL the way to go?

I think so. At least for the Framework. After careful consideration, and especially after reading Martin Sustrik’s article above and considering the limitations of the JCA – LGPL seems to be the right fit.

How should OSM vote?

Right now, those who support an adoption of LGPL (such as myself) are in the minority. I believe that OSM should vote in accordance with the Joomla!’s Community’s wishes (i.e. the majority).

I’ve been keeping an ‘unofficial tally’ at http://forum.joomla.org/viewtopic.php?f=704&t=837342 and you are welcome to have your vote recorded there - just visit the link above and PM me.

Ultimately, I believe OSM should do a formal poll – the tally I’ve put together should not be considered 'official' by any means or anything more than a ‘temporary thermometer.’

[dilbert4life]

Very good explanation Niv. More than a little unexpected, but welcome and very good.

[jodofin]

jodofin -

It has nothing to do something "going wrong", it's more related to what's happening in the industry. Framework code is becoming a commodity.

From my "Joomla Framework Licensing Discussion Notes" section named in the first line.
https://docs.google.com/document/d/1GyT ... r2m7b7ttwf

There is a one situation in which the FSF recommends using the LGPL and acknowledges using the GPL presents a clear disadvantage.

From the FSF:

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

Source: https://www.gnu.org/philosophy/why-not-lgpl.html

So, the question is “Are there alternatives to the Joomla Framework available to proprietary software?”

Clearly there are. Dozens of them. Arguably many are even of higher quality than the Joomla Framework....

Even the FSF recognize that in situations where software is a commodity enforcing the GPL is a disservice to the project. In those situations, the FSF recommends using the LGPL

.

Thanks for this.

The FSF's position seems maddening the more I look at it. It seems they recognise that LGPL is seriously flawed, but have no meaningful strategy to prevent its widespread adoption.

My views right now are GPLv3 is better than GPLv2
I think I would like all Joomla opened up to GPLv3 if there are currently restrictions, whilst keeping GPLv2 too.

LPGL is worse than more permissive licences, at least in terms of what supporters of a move to LPGL are trying to achieve. It appears that developers are really more keen on MIT etc, but this is not feasible for Joomla.

So it seems we are really discussing moving to Joomla Framework LGPL, whilst there are better frameworks with 'sexier' licences, out there.

Tough proposition to market.

Secondly - a move that may cause strife. The move will satisfy some developers but will it achieve any real goals? Where are the certainties.

I think we can all agree that Joomla is strong on the Open Source ethos, this should really be a source of strength not weakness.

Joomla CMS is also very popular - millions of users, many of whom are skilled, or even very skilled - this is a potential strength as users of Open Source software can be encouraged to become contributers.

Joomla has an active community of developers whose interests are closely matched to those of the users. This should also be a source of strength for Joomla.

Joomla is already very large, the focus should be on quality.

There are proprietary CMS's out there that cost a thousand or more. This speaks to quality, performance, reliability, excellent marketing - all the things closed source products need to focus on and which they do well or fail.

Our aim should be to unstintingly focus on competing with these guys, matching them here, beating them there.

Not giving away what we've worked on in the hope that we get crumbs in return.

Lets have an end to all this open source naivety! Do we really have a clue how silly we look to the outside world?

[BenTasker]

I’ve been keeping an ‘unofficial tally’ at http://forum.joomla.org/viewtopic.php?f=704&t=837342 and you are welcome to have your vote recorded there - just visit the link above and PM me.

Erm, Niv, small point. You say you've changed your mind, but don't appear to have updated your spreadsheet

[NivF007]

Secondly - a move that may cause strife. The move will satisfy some developers but will it achieve any real goals? Where are the certainties.

Agreed. I think the focus needs to be on how we engage more developers - the proposed license change to LGPL, while it may remove obstacles, needs to be accompanied with a concerted and focused effort to engage top talent.

Lets have an end to all this open source naivety! Do we really have a clue how silly we look to the outside world?

As opposed to people who dress up in shirts and ties and sit in rush hour traffic everyday? In my view, the world is very full of 'silly people' (myself included) - let's face it - we are all silly - let's stop taking ourselves so seriously.

JQuery is MIT, as are many other robust projects which give software away for free. Depending on your perspective, the whole lot of us are just plain silly.

[NivF007]

I’ve been keeping an ‘unofficial tally’ at http://forum.joomla.org/viewtopic.php?f=704&t=837342 and you are welcome to have your vote recorded there - just visit the link above and PM me.

Erm, Niv, small point. You say you've changed your mind, but don't appear to have updated your spreadsheet

I just updated the vote/tally as of 12:30pm EST.

[AmyStephen]

@Amy
Thank you for clarifying that you were speaking of developers authorising the use of their code in any of the licences listed in the JCA ... and not about developers authorising the OSM to change from GPL to any of those licences.

Your welcome. For future reference, when I say something, that's what I mean. You should be advised, I am wrong more often than I like. That's why I share links and I verify what I say before I say it. I am not afraid to admit when I'm wrong because I want people to know my goal is to share valid, pertinent information.

I've been known to change my mind. I try to say if something is just an opinion. But, I will give you a straight answer or I'll tell you it's none of your business. You don't need to worry that I am hiding my meaning or trying to trick you -- I'm pretty blunt.

That, you can count on even if there are too many times I could be more careful with my wording.

Thank you for your appreciation of my response.

@Niv - +1

[Webdongle]

...
You may not agree, but those items are exactly the same. Approving of the licenses in the JCA by signing is the developer authorizing OSM to change from GPL to any of those licenses.

The wording is quite explicit in that it refers to the type of licence that the code can be placed under ... and lists acceptable licences. That is specific to which licences their code is used in. It does not refer to changing the licence that is in force.

It specifies what licences are acceptable ... but does not specify under what circumstances change would be acceptable. There is a difference between accepting possibilities and authorising a change to one of those possibilities.

[NivF007]

...
You may not agree, but those items are exactly the same. Approving of the licenses in the JCA by signing is the developer authorizing OSM to change from GPL to any of those licenses.

The wording is quite explicit in that it refers to the type of licence that the code can be placed under ... and lists acceptable licences. That is specific to which licences their code is used in. It does not refer to changing the licence that is in force.

It specifies what licences are acceptable ... but does not specify under what circumstances change would be acceptable. There is a difference between accepting possibilities and authorising a change to one of those possibilities.

To quote the exact wording from the JCA (http://developer.joomla.org/9-site/7-jo ... duals.html)

2. ...OSM will only make the Contribution available under on or more of the following licenses..

3. b. In addition, you grant OSM a license to the Contribution under the terms of any, several and all of the Acceptable licenses;

3. d. ...each party can do all things in relation to the Contribution as if each party were the sole owners (subject to the limitations in Section 2)

I read these clauses to give OSM full-rights to switch to LGPL without requiring any further authorization - further, they do not a need a justifiable cause.

Now that said, a) this a unilaterally negotiated contract (either you accept it or your contribution is not accepted); therefore b) although it represents a legal agreement (and consent in the legal sense), it does not necessarily represent either of those in the 'non-legal' sense.

So OSM is legally entitled to do as it wishes (under the terms of the contract) - but nonetheless, if the majority of contributors were against the switch to LGPL by OSM - and OSM disregarded that and switched anyways, it would certainly erode the trust of contributors.

It's a delicate issue - which is why I've been advocating that any such a switch should be done with a majority consensus of contributors and the community - in that respect, whatever fall out may occur, there will be safety for all of us with respect to have having obtained a support of the majority.

N

[NivF007]

I have to add - why I also have strongly advocated that the decision ought to be postponed until it can be done by OSM Directors elected by the community.

[Webdongle]

...
The simplest possible definitions

First let me begin with the simplest possible definitions I can use to describe what we are talking about.

Joomla! Framework v. the Joomla! CMS

Think of building a car.

Joomla! Framework: The ‘nuts and bolts’ used to build the car.

Joomla! CMS: The car.

The distinction here is that the CMS is end-product (the application). ...

Perhaps more like:

Joomla! Framework: The engine and chassis the car is built on

Joomla! CMS: The bodywork.

Joomla! Full package: the car

Engineers build the engine and chassis ... knowledgeable enthusiasts build the bodywork and less knowledgeable enthusiasts test drive the car. All the enthusiasts give their time freely because they are under the impression that the car and everything used to build it will be freely available for everyone to use.

Then the engineers announce that they are going to allow others to use the engine in a different type of car that can not be used by everyone. The engineers say "We built the engine so we get to say who uses it". The volunteers who spent hours test driving, reporting faults and generally made sure the engine worked correctly say "Now (after we have given our time freely to make sure your engine works) you want to shaft us by changing the rules and allow your engine to be used for a car that is not available for everyone."

[NivF007]

...
The simplest possible definitions

First let me begin with the simplest possible definitions I can use to describe what we are talking about.

Joomla! Framework v. the Joomla! CMS

Think of building a car.

Joomla! Framework: The ‘nuts and bolts’ used to build the car.

Joomla! CMS: The car.

The distinction here is that the CMS is end-product (the application). ...

Perhaps more like:

Joomla! Framework: The engine and chassis the car is built on

Joomla! CMS: The bodywork.

Joomla! Full package: the car

Engineers build the engine and chassis ... knowledgeable enthusiasts build the bodywork and less knowledgeable enthusiasts test drive the car. All the enthusiasts give their time freely because they are under the impression that the car and everything used to build it will be freely available for everyone to use.

Then the engineers announce that they are going to allow others to use the engine in a different type of car that can not be used by everyone. The engineers say "We built the engine so we get to say who uses it". The volunteers who spent hours test driving, reporting faults and generally made sure the engine worked correctly say "Now (after we have given our time freely to make sure your engine works) you want to shaft us by changing the rules and allow your engine to be used for a car that is not available for everyone."

I don't see anything wrong with this analogy. My guess is that it will happen.

It's become apparent to me that we are spending 98% of our time and resources attempting to resolve what amounts to 2% of the problem.

Let me explain further:

Ultimately the goal is to attract more talented developers. Without that, the Joomla! Framework, that it will be anything worthwhile, is but a mere 'pipe dream.' The license is irrelevant in that scenario.

So the question we should be asking is, "How do we engage top developers?"

The answer to that has at least 2 parts:

1) these days Github is where the action is at and the projects with the most permissive licences are the ones that have gained the most traction;

2) we need a funnel to get top developers motivated and involved (hence we really should be focusing on academic community engagement).

If we can do 1) and 2) above (and 2 should, IMHO, be where our real efforts are) then in the end, we will achieve better free software for everybody.

If we simply focus on the license change - then my view is the same as yours - counter-productive.

What I labelled as the 'Github effect' in my write-up - I've come to view as the real engine for open-source development these days - and the more permissive the license, the better chance of more robust engagement on Github (hence my argument and decision to support LGPL).

That said - what are some of the casualties?

Some consider FoF/RAD (I'm stealing from our JUGT FB page here) as much more important to the success of the Joomla! CMS (and it's hard to argue) - but the lead developer on that who might not embrace LGPL and leaves because of it - well, let's just say given that person's leadership and contributions, we just might suffer greatly for making that transition (let's not mince words - we are going to hurt bad as project if that happens) - something I don't think too many people on this thread can truly appreciate the implications of. I have no doubts that we are all better off with that specific contributor remaining.

What would prevent us being in such a predicament? Making sure we reach out and attract top talent, ensure that they are engaged - the project benefits and we do not suffer as a project from the ideological views of any one (or group) of developers when their views are inconsistent with what the community wants.

Right now the Joomla! Community is a huge asset - we need to leverage that to attract more developers.

In other words, this whole debate is a 'Kansas City Shuffle' (Lucky Number Sleven reference) - everyone is looking 'left' when we should be looking right.

[Webdongle]

To quote the exact wording from the JCA (http://developer.joomla.org/9-site/7-jo ... duals.html)

2. ...OSM will only make the Contribution available under on or more of the following licenses..

Agrees the type of licence that the contribution will be "available under" ... it is not an instruction to change the licence

To quote the exact wording from the JCA (http://developer.joomla.org/9-site/7-jo ... duals.html)

3. b. In addition, you grant OSM a license to the Contribution under the terms of any, several and all of the Acceptable licenses;

Authorises the OSM to use the Contribution under the licences that have been agreed as acceptable. Again that is not an instruction to change the licence type

To quote the exact wording from the JCA (http://developer.joomla.org/9-site/7-jo ... duals.html)

3. d. ...each party can do all things in relation to the Contribution as if each party were the sole owners (subject to the limitations in Section 2)

The OSM or the Contributor can use the Contribution in the same way.

I read these clauses to give OSM full-rights to switch to LGPL without requiring any further authorization - further, they do not a need a justifiable cause.

Giving the " OSM full-rights to switch to LGPL" is not the same as instructing them to change the licence. There is a difference between accepting possibilities and authorising a change to one of those possibilities.

[jodofin]

As opposed to people who dress up in shirts and ties and sit in rush hour traffic everyday? In my view, the world is very full of 'silly people' (myself included) - let's face it - we are all silly - let's stop taking ourselves so seriously.

You get a t-shirt with "Silly and Proud" I will too. Wear it always and if we ever meet will know instantly we are Brothers.

The kind of silliness I speak to is Mozilla Foundation cozing up with Google. Getting funding by making Google the default search engine in Firefox. Making Google their single largest cash source. Not grasping how much Google is gaining from this arrangement. Google releasing Chrome. Firefox's days of glory are over. Chrome is now by far the largest browser. It's open source - largely - yes. But still Mozilla has lost out.

Its a silliness that amounts to poor strategy. The same can be said for FSF and LGPL. The difference is FSF can acknowledge LGPL should not be used - iow it was a mistake. Mozilla foundation simply says "Google is a key partner and our relationship is solid." They can't say anything other. They are too dependent to say, "we are getting screwed and boy do we know it! Boy did we mess up!" I think that is what they are privately thinking.

I have no idea how much of Chrome if any is built on Firefox. But let it be none. The only way for Firefox to compete is to compete on quality. This was always the case. If Mozilla had an excellent strategy they could still have forced Chrome to become a niche player.

When the GPL ideology becomes counter-productive

There is an excellent article, Does GPL hurt free software? by Martin Sustrik. (see http://250bpm.com/blog:7) For brevity, I won’t repeat it here, but I’ve found this to be the single best write up for the negative impact that GPL can have.

I would encourage anybody who still has misgivings about GPL to read it – and see if your opinion changes.

Good food for thought. In some cases closed source proprietary products are best and in other cases open source. I can't really make a case for hybrids.

There are special cases.

When it comes to CMSs open source has a MASSIVE advantage - no one wants to be 'locked in' not if you are building a huge website, unless perhaps we are talking of a household name with an excellent track record - say Google or Microsoft. And they are pretty much giving away the product maybe with better support.

Open source has an easy victory in CMSs. The problem is that the victory is easy and complancency can set it. Joomla and Drupal are popular not because they are excellent but because they are open source and got into the race early. There's plenty of room for a Google or Microsoft to jump in and make things 'exciting'. Competition is good. I don't mind. But Joomla should be concerned!

When it comes to Operating Systems Windows beats Linux. The world loves Windows. Its cheap, Microsoft marketing is excellent, support is good and Microsoft got into the game early.

I think the arguments in the article range from too narrow to basically wrong.

[masterchief]

Jenny, this was quite simply "masterchief" being "mastercheesy" and talking out of both sides of his mouth in order to appear to have retracted his threat of exodus (i.e. if OSM does not permit LGPL) when in fact he did not - please don't take him seriously on this - I've already confronted him on the matter.

Yes, and I gave your confrontation the due attention it deserved Jenny's point is correct in so much as how new code is added (see below). What's not moot is that OSM does indeed have to approve changing the license of code that has already been released. That's what this process is about.

Somebody offered $500 when he claimed he would abandon Joomla! and sell his sites - I wouldn't hold my breath on that either.

Really! I missed that. That much for thousands of hours of work! I'm truly honoured. Not that it's any of your business but I am winding up my consulting entity July 1 (for tax reasons). And I would consider any reasonable offer for my domains on merit (merit is how we operate in this project too).

Bottom line, it's quite apparent that OSM determines which licenses software will be released under, subject to the conditions of the JCA (which permits a switch to LGPL).

Actually let me change to my MasterSerious helmet. Darn, this thing never feels quite right - and the colour - really? Ok, what you are missing is the fact that the PLT has complete authority over development matters. For instance, the board did not decide to add jQuery or Bootstrap (MIT) or PHP-UTF8 (LGPL), the PLT ultimately approved that. Were you to add a new module to the CMS that relied on a new library that was LGPL, the PLT would assess that pull request, and because the license is compatible with the GPL then proceed to judge the code on merit.

Likewise, with the Framework, if someone submits a new package under the LGPL, the PLT is within its rights to accept it because it IS an acceptable license listed under the JCA. I, one who is authorised to merge code into the Framework, don't need to send each pull request to the board of OSM for approval. We already have an LGPL package in the Framework and because the Framework is now modular, not monolithic like the Platform was, and licensing on a per-package basis is now possible and perfectly reasonable. No developer would think twice about this fact but I can see its still causing you some angst. I hope that explains a little more about how this project actually operates.

Oh, and like Don, drawing out the summary of the arguments that we and others have already made was useful. Thanks. However, you might want to add that the PLT is authorised to merge code that is licensed according to the JCA, or licenses that are compatible with those licenses. I hope my explanation has cleared up that confusion for you.

[masterchief]

Licenses Simplified

GPL: if you use my code in yours, you must distribute your code as I do for mine.

LGPL: if you modify my code, you must distribute your modifications.

I don't think that's quite clear. Maybe:

GPL: if you use or modify my code in yours, you must distribute ALL your code as I do for mine.

LGPL: if you use or modify my code in yours, you must distribute my source code, including modifications, but have the option of not distributing yours.

That's a little more accurate but unfortunately not as succinct. Note that "modification" implies "derivation" as well and that would have to be spelled out in a detailed FAQ. Niv, I suggest in the event of a positive response from OSM, you craft that into a JCM article but have the PLT review if for final accuracy.

[tj.baker]

I just say No to LGPL....

[Webdongle]

... the PLT has complete authority over development matters. For instance, the board did not decide to add jQuery or Bootstrap (MIT) or PHP-UTF8 (LGPL), the PLT ultimately approved that. Were you to add a new module to the CMS that relied on a new library that was LGPL, the PLT would assess that pull request, and because the license is compatible with the GPL then proceed to judge the code on merit.

Likewise, with the Framework, if someone submits a new package under the LGPL, the PLT is within its rights to accept it because it IS an acceptable license listed under the JCA. I, one who is authorised to merge code into the Framework, don't need to send each pull request to the board of OSM for approval. ....

But it is the OSM that decide what licence Joomla(cms and framework) uses ... yes ? Therefore signing the JCA accepts that the Contributed code can be used within Joomla and that is completely separate to authorising a change to the licence Joomla (cms and framework) uses.

[masterchief]

But it is the OSM that decide what licence Joomla(cms and framework) uses ... yes ? Therefore signing the JCA accepts that the Contributed code can be used within Joomla and that is completely separate to authorising a change to the licence Joomla (cms and framework) uses.

That is correct. OSM is the only one that can authorise a "change" to "submitted" code. However, the PLT authorises the "addition" of "new" code in accordance with JCA (set by OSM) and "license compatibility" rules. Is that more clear?

[Webdongle]

But it is the OSM that decide what licence Joomla(cms and framework) uses ... yes ? Therefore signing the JCA accepts that the Contributed code can be used within Joomla and that is completely separate to authorising a change to the licence Joomla (cms and framework) uses.

That is correct. OSM is the only one that can authorise a "change" to "submitted" code. However, the PLT authorises the "addition" of "new" code in accordance with JCA (set by OSM) and "license compatibility" rules. Is that more clear?

Thank you for clearing that up Andrew.

[AmyStephen]

Likewise, with the Framework, if someone submits a new package under the LGPL, the PLT is within its rights to accept it because it IS an acceptable license listed under the JCA. I, one who is authorised to merge code into the Framework, don't need to send each pull request to the board of OSM for approval. We already have an LGPL package in the Framework and because the Framework is now modular, not monolithic like the Platform was, and licensing on a per-package basis is now possible and perfectly reasonable. No developer would think twice about this fact but I can see its still causing you some angst. I hope that explains a little more about how this project actually operates.

Oh, and like Don, drawing out the summary of the arguments that we and others have already made was useful. Thanks. However, you might want to add that the PLT is authorised to merge code that is licensed according to the JCA, or licenses that are compatible with those licenses. I hope my explanation has cleared up that confusion for you.

That helped a lot. Thanks for this explanation. Makes sense.

[Jenny]

Thank you Andrew for confirming that OSM really has no control over this situation at all anyways and the community has no say as to whether they prefer GPL or LGPL, so that in effect the conversation really is moot.

[masterchief]

Thank you Andrew for confirming that OSM really has no control over this situation at all anyways and the community has no say as to whether they prefer GPL or LGPL, so that in effect the conversation really is moot.

That's an interesting "literal" way of taking what I said, but in reality it's not as black and white and it's not really what I said.

OSM has control over relicensing the existing code that has been submitted to the Joomla project by contributors under the JCA.

OSM has not made any statement about whether they prefer GPL or LGPL, just that they have approved a JCA that includes both.

OSM has decided that the Joomla CMS is released under the GPL. OSM has not explicitly decided that the Joomla Framework is to be released as GPL, but as many of the packages are derived from CMS code, it is, by derivation, GPL.

New code can be submitted to the CMS, Framework, Issue Tracker or additional extensions under the terms of the JCA and license compatibility rules (citing the example that jQuery/Mootools and Bootstrap are MIT, not explicitly mentioned in the JCA, but compatible with the licenses mentioned in the JCA).

The conversation about relicensing any existing Joomla source code, CMS, Framework, Issue Tracker or additional extensions (such as the JED Store) is not moot.

In short, no, you are mistaken.

[Jenny]

I am not mistaken, I believe. You have repeatedly stated that as a committer you will commit new code as only as LGPL and replace or rewrite existing code and commit it as LGPL - that makes this whole conversation moot in regards to the license, as you have made it clear exactly what you intend to do.

The only remaining issue is: if it will be allowed to use the name/brand of Joomla! while doing what you have clearly stated you are going to do. The use of the trademark/name/brand is the only thing that OSM actually does have control over in regards to the Framework.

[AmyStephen]

I was initially confused/concerned at some of these comments, too. But, I understand the point to be if phpMailer, for example, came and wanted to contribute their work for the Joomla Framework to maintain, knowing it's under the LGPL, that new contribution could be received under that license. If that's the point, then, yes, that's always been how I understood.

In the case where the project has been releasing code under one license, changing to another requires OSM's consent. That makes sense, too, and it's why OSM is involved (they get to decide) and have requested input.

To add, bringing the point up like was done created unnecessary concern. There was probably no reason to mention it. It has nothing to do with the relicensing and it had a sense of feeling (for lack of a better word) threatening. (Tho, I'm not saying that was the intention.) Timing was off, IMO.