Regarding a license that allows distribution only if the program has been changed, the FSF has covered this topic. I do not have the link to it and I will look it up when I have time. However I will provide the crux of the argument here.
Yes the FSF has covered this topic. But it has yet to be addressed in a court. What the FSF interprets as compatible with the GPL is really not all that much different than what Joomla interprets as a derivative. That interpretation will have to be made and adopted by a court before the burden of proof is made in a license violation suit. Is it a solution? we don't know yet for the same reasons we don't know if Product A is actually a derivative or seperate work. The only ones who can say with any certainty have not spoken to the point yet. (Judges and courts)
As for your example of A to B to C=A....
C would still be in violation of A's license and it does not matter that he started off with B as opposed to the original A. You see just as the GPL states that any modifications must be noted clearly in the code and copyrights of work you did not modify must remain, so too would this new RGPL (restricted GPL) license have such an article. This would stop someone from creating Version A/C again because they would see clearly that they are only removing past modifications to another work. They could however change the modifications to parts of A and parts of the modified sections of B and create C. That would comply with the original license.
So if the license is written correctly there would be no chance of someone recreating A by modifying B. the modification stipulation would automatically require you to add something and note it or change something (note the change and add your name to the copyright of what you changed). If you did not then you would be in violation of that license should you ever distribute your version. Use as in GPL would be unrestricted.
Think of the GPL license with the word copy and verbaitm removed from every article.
FSF would be hard pressed to say that such a license harms their license. IT merely harms the ability to distribute a GPL product with that RGPL product. FSF would argue that it restricts verbatim distribution but they would then have to prove to a court why that is important and how that restriction on a seperate work would impact the rights to distribute the original GPL product verbatim. I don't think they could make that case easily to a US court. Maybe they could be successful in other countries, but in the US you have to show that you are being harmed in some manner before you can win. Since the extentions would give all the rights (except one) that the GPL does FSF would have to make a very strong case for verbatim distribution. And they have yet to ever make that case to anyone that I know of.
Thier answer is ideological not legal. Courts don't care much for ideology only law.
As to the point of how much modification is needed to comply, well how much modification is needed to a GPL program before you can say it is a different project? GPL actually says NONE so My license could be as little as one line of code which is far more fair than none! In any case a court would decide based on the same terms they would for any copyright work. It's not defined in the law and would be determined on a case by case basis. The point of this is to ensure that any modifications would mean that the stability of the original code has changed. This gives the original author some exclusivity to his stability of version. And while it may start off only seperated by a single line of code the original author can continue to add to his version and the modifier will have to either pay for that new version or code it himself. to avoid this the license would have to include a clause to rename (in the same way a fork is done) to distinguish the two products. The orginal Author will also have exclusivity to the reputation and marketing of his version. This is almost as important to their sales as the actual code is!
So when you combine all three, GPL + LGPL + Proprietary into one whole program, you arrive at a program that is not distributable under the terms of the GNU GPL.
It is distributable...just not as a single distribution. All three must be distributed seperatly and in the case of JoomlaGPL/API LGPL a dual license.
Where I think the confusion comes from is it is being considered that all 3 parts are combined together. But they really are not. GPL A is combined with LGPL B as a single combination then Proprietary C is combined with LGPL B seperatly. the GNU C Library is a very good example of this. Any program no matter if it is GPL or Prorietary can use the GNU C Libraries (LGPL) The fact that two seperate programs both use those libraries and can communicate through that library does not mean all three become one program. In that case what is actually happening is that the library creates data that both can use. the functions of GPL A are not being called to by Proprietary C instead the Data created by a call to LGPL B is being sent to GPL A via a call to LGPL B.
User clicks
GPL - Call to LGPL, call function Component?+parameter and wait for data from JDisplay...
LGPL - Run Prop A?+Parameter
Prop A - Do custum work using any functions in LGPL if needed.
Prop A - Call to LGPL, Make data and send to function JDisplay in LGPL
LGPL - create the data output via JDisplay
GPL - Get data from JDisplay ann proceed.
The proprietary program could only be derivative of the LGPL library not that GPL core since it doesn't link or use any functions of the GPL work
the Core itself would have a lot of it's functionality inside the LGPL API. In a sense it would be derivative too!
But both are really not derivative in the sense the GPL puts that term. They would be more along the lines of a programming language (Like PHP) in the fact that the API would define new language constructs that any other program could use.
The only issue I see with the LGPL method is does Joomla/OSM really wish to put all of their magic into a file that anyone could create a competing (and Proprietary) CMS with? I can't answer that and I suspect there may be some disagreement on this topic among the Devs. But I do NOT want to put words into their mouth. Jinx said it was a possibility and no one has really come out against that statement so maybe I'm wrong or maybe it just hasn't been addressed as a group yet.
Yet, when they are combined, they form a new whole program. So this whole program would be prevented from distribution under the terms of the proprietary license, and the GPL
My contention is this. What is so important about being able to distrubute a PACKAGE of programs and why is it important that they follow the not restrictive GPL as opposed to some other license? If I wanted to create a package of Windows and several other applications (some Free Some proprietary) I should not be forced to distribute for Free all the proprietary stuff simply because I have one free program in the package. that is license hijacking and I do not believe that would hold up in any couirt of law. As an agregator I am allowed to distribute a GPL program for cost. In a sense I CAN distribute Proprietary programs at cost as well. I can buy a license for a client and give them that license and add a charge for my cost. Provided no one is harmed in that transaction. that practice does not stop or harm the availablity of the free project at all. So why must the whole package be distributed under the terms of that one license when there are many licenses included in that package? This is the real reason why GPL has such a contentious interpretation. I believe it DOES overstep it's bounds. In my package model I am giving a verbatim distribution of the GPL product so why should it now extend itself to other licenses in the package? This is why the LGPL method solves the derivation issue and once that is solved the license issue can largely go away. This concept is fine if you modify the actual GPL code and attempt tp proprietize the result but it should not apply to any program that is actually not derivative and installed, only those modified directly into the code.
So at what point then is one a derivative and another not? There is a great difficulty in adjudicating this, because should one be declared not a derivative, another developer might be convinced that her program is no different than the other program so declared. Ultimately I am convinced that the whole program is a derivative of both the GPL licensed program, and the proprietary licensed program. If a proprietary program contains no instructions, no extra libraries, no method of interfacing to the GPL program then I see no issue. It is left to the user to accomplish on their own.
As has been stated time and again. J1.0X extentions are considered derivative of Joomla AND Mambo. Joomla 1.0X itself is essentially derivative at this point. If I release a mambo extention I could not be fairly accused of making a program derivative of Joomla. Lets use your original A-B-C=A...
there is CMS A
I write Extention C for CMS A
someone takes and forks CMS A and makes CMS B
How can I be sued for making a derivative of a program I made before the program I supposedly derived from existed?
I derive from CMS A and face 10 lawsuits from CMS B,D,E,F G,H etc?
all of which were made after I wrote my code?
This is why I say derivation is not the whole issue here. Most GPL code is derived from other GPL code. Part of why the GPL selection of programs is so full.
So this whole it is derived and therefore must be GPL is not a slam dunk or really signifcant item in the license violation.
the part that is really significant is the last bit in the GPL about incorporating GPL into proprietary work. Incorporating talks to physical use inside the code either as a copy and paste operation or linkage to function. the LGPL will solve that part of the controversy because the GPL specifically states it does.
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
If there is any problem with that method it would be in regards to the fact that not all functions needed were actually placed under the LGPL library and some extention might still need to call to that function to get work done. If the LGPL is not all inclusive of all functions a 3rd party program needs then it will fail. But if the job is done correctly and all of the functions an extention needs are placed in LGPL then the LGPL will solve just about every problem we have with restrictive licensing.
Some GPL ideologists (not accusing anyone of this mind you) would hate to see this happen. they want free software and I certainly don't blame them for wanting that since it has gotten us this far with Joomla. But if we truly want to allow proprietary works to be used in conjunction with Joomla then some sacrifices will have to be made. I personally would hate to see some great new technology owned by say IBM be denied to Joomla users because the people who want free software feel if you let one proprietary technology to be used all technology will become proprietary. I hardly feel this is the case!
Look at the extentions directory and you can clearly see less than 20% of the projects in there are Commercial and maybe 10% of those are actually proprietary. Of that 10% maybe a handful are actually worth using or do something that hasn't be done just as well under GPL.
But while their numbers may be small their functionality opens Joomla use up to many people it would not be a viable option for if we restricted those technologies from being used.
I think you know my views well enough Aoithor to know Is support the current strict interpretations of GPL. and even much of the ideology that interpretation is meant to foster. But the ideology is not as important as the growth and versatility of Joomla and fairness towards sharing a free idea on your own terms as opposed to FSF's terms. This is why I suggested the new license as one method. It would create a new way to share FREE IDEAS without all the drunken fights caused by all the Free beer that is created trying to share those ideas. FSF and GPL says it is all about Free Ideas not Free Beer, but the license does a hell of a lot more to create Free Beer than it does to promote free ideas!
It is all this free beer that ruins all the Commercial GPL busines models. There would be no issue using a Commercial GPL business model if the Free Beer was not involved.
This is not an issue that Joomla can address. Must be done by the FSF or the courts. Court won't see it till it is challenged and so far I have not seen anyone use a lcense that could be used to make that challenge. I am merly suggesting someone does. As far as Joomla today is concerned it is GPL as it always has been and the risks P3PDs face today is no greater than the risk they faced a year ago when they released a Proprietary product for J1.0X.
So they really don't have any reason to whine. That said Joomla/OSM could hold the key to solving their problems via a LGPLing of the API. Do they want to? If I read Jinx's statement correctly, they are open to that. Can't do it for 1.5 but then again asking them to would be like asking them to do it for 1.0X too. too late in the day to do that right now. Instead of focusing on how many ways and solutions could fail we should look more towards how many solutions there are that could succeed. LGPL can succeed. Sure it can fail but not because it can't succeed only because we didn't do enough to make it work.
We need to stop trying to poke holes into potential solutions and dismiss them. Poking holes is fine provided the reason for the poking is to test the stability and to reenforce the weakness that allows the hole to be created.
If we want a positive solution we must work and trouble shoot with a positive attitude so that when negatives are found they can positively be solved!
