Thank you very much for providing another example.
Ecwid can operate 'independently' of Joomla! - it's viable software with or without Joomla!
Now that said:
The 'independence' rule for extensions bridging to non GPL extensions has been clarified by a JED Manager as intended only to apply to GPL extensions which bridge non-GPL extensions so as to prevent, as I understand it, a 'bait and switch' scenario in which a JED software consumer purchases a GPL extension, only to be later switched to a 'non-GPL' extension.
Of course, all of these policies mean nothing if what was not to protect the '4 freedoms' - access to source-code being a pre-requisite.
I have used the word 'Mischief' specifically as it is a well-known paradigm at law for interpreting rules.
The main aim of the rule is to determine the "mischief and defect" that the statute in question has set out to remedy, and what ruling would effectively implement this remedy.
So in other words, we look at the rules, and instead of a 'strict literal' interpretation, we interpret those rules in a way which enforces what those rules were intended to prevent against (i.e. protecting JED Software Consumers from being 'bait and switched' to non-GPL solutions).
So we have these policies in place that say
1) Your extension, if listed on the JED must be GPL (i.e. the software-consumer has access to source code and the freedom to do what they will (study, improve, resell etc.));
2) If your extension bridges to a non-GPL extension, it has to be one that can operate 'independently' of Joomla!
In looking at Ecwid, I see that it is passes these tests. Ecwid would still be Ecwid and be viable without Joomla! - it is 'independent' of Joomla!
Conversely, in looking at Watchful.li, what is this application without Joomla!?
It has no purpose or function. It does not meet these tests.
Therefore, we have in Watchful.li an extension which is 'wholly' dependent on Joomla! - but not all the source-code required to make it operate is available to the software consumer.
For these reasons, it is effectively a 'closed-source' proprietary application listed on the JED.
It is an interesting comparison
- but because of Mr. Baylor's clarification of the history of the rule, we know that the preventing the 'mischief' of 'SaaS loophole' solutions were never considered when drafting the rules.
However, we still essentially have the 'mischief' occurring (i.e. no access to source code) when the JED is used as gateway for a proprietary SaaS solution.
With the respect to the closed-source proprietary portion of the extension, the software consumer cannot
- study the software;
- improve the software;
- share the software; nor
- be free for unlimited use of their software.
As a result, the software consumer becomes bound to the vendor, per domain licensing fees and cannot modify the software.
The freedoms which the Joomla! project seeks to protected are effectively subverted.
Now this isn't just about high-level ideology - the impact to the Joomla! Project is very real, and we can point to a 'real-life' scenario which has recently taken place.
If you look at the following thread, I'd respectfully draw your attention to Mr. Dionysopoulos' (founder of Akeeba) post, which I encourage folks to read.
Here we have one of Joomla!'s brightest and best contributing to the core - as I understand from Mr. Dionysopoulos' documentation, business models and comments, he is a true-blood, through-and-through GPL solution provider. Everything you get from Akeeba honours the 4 Freedoms - you get access to the source code - exactly inline with the Joomla! projects' vision
Nicholas' software can be improved upon by others, re-incorporated into other solutions, studied and redistributed, etc. - and we see this in action to the benefit of the project in numerous ways
Even the extension in question, Watchful.li relies on Akeeba as part of it's solution.
And further, only the services which the extension developer could not reasonably be expected to provide (e.g. the software that runs the Amazon S3 servers is not under the control of Akeeba it runs independently of Joomla!) - is a 'reasonable exception' as it would not be reasonable to expect Akeeba to do the impossible - that is to provide source code over which the extension developer could not possibly have any control.
In this context, IMHO, those extension developers who use the 'SaaS loophole' can be given a 'pass' without to much debate simply on the basis that they have no alternative, and by barring their solutions we, as a project, have nothing to gain.
However, with Watchful.li, we have a wonderful extension (very useful and a great idea) and the case is very different.
The proprietor could
provide the 'source-code' to the project or any of his software consumers, but never offers to
in thread listed above, opting instead to set up their own servers and strip any reference to their 'free trials' etc.
This might sound generous. The project gets 'software for free,' but this is not the same as 'free software' as the software consumer never gets access to the source code
- a prerequisite for the 4 freedoms.
In the specific instance referenced, we see a real-life scenario in which as a project, we are barred from using a derivative work of Joomla! that would otherwise be available to be re-incorporated back into the project, modified and improved upon - and continue to improve the code base for everybody's benefit.
The gain in this case a 'personal gain' of the extension provider - a competitive advantage. It can be argued that project benefits because of more available solutions - but the 'true gain' to the project - the one in which the code-base is expanded - is subverted in the process.
This is what the author of 'The GPL Has No (Networked) Future
' (see http://www.linux-mag.com/id/3017/
) means by
Bryan Richard wrote:...if you’re looking to leverage Free Software without completely fulfilling the requirements of the license, a better method would be to exploit the software as a service (SaaS) loophole, which the latest draft of the GPL3 just legalized.
The fact that this is the accepted modus operandi
for a Director of OSM is significant.
What it means is that the people charged with protecting the 4 Freedoms (this is part of the stated vision of the Joomla! Project (i.e. this is the duty of OSM Directors)) see the use of the 'SaaS Loophole' as 'acceptable.'
They are free to do so - and there are very good arguments as to why the 'SaaS Loophole' can and should be permitted.
I would further note that nobody on this thread has objected to Watchful.li from being listed on the JED, or has requested that the 'SaaS Loophole' be closed, so let's wish Watchful.li and Dr. Drover the best of luck.
While many of us would much prefer that the software freedoms be honoured (I am on of those), as long as we agree that these rules apply equally to everybody and the project accepts the 'SaaS Loophole' as fair-game - I am willing to as well, if for no other reasons than
a) I have numerous proprietary extensions through a business associate that can be leveraged for profit under this model;
b) After many hundreds of thousands of dollars of personal investment, my business associate does not wish to make their source code available; and
c) If this is the 'accepted modus operandi
' of the Joomla! Project, then I would be foolish not to take advantage of it as others are.
I think that I've done my best, however, to have a frank discussion about these issues - so that if there are any objections, those have had opportunity to come to light.