Hello all,
please let me introduce myself first. My name is Jan Wildeboer, I am member of the core team of a GPL'ed shopping cart solution, written in PHP, called osCommerce (www.oscommerce.com).
We just celebrated the second birthday of our project, we have the feeling we are quite successfull and we managed to build a community that supports our project.
Because we try to produce a global solution, we introduced a modules-structure for shipping and payment routines. We provide sample code and some global modules. Shipping and payment sometimes is very country-specific, so there are some country-specify mailing-lists/support sites that offer modules for these specific countries.
The way we understand the GNU General Public License all modules programmed to be used in our system must be published under the terms of the GPL. Our opinion is mainly based on this GPL-FAQ entry:
http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins
This is due to the fact that shipping/payment modules use objects generated by our project (the cart object, customer address etc.). So we are quite sure that the second part of this FAQ-entry is valid in this context, so all modules written for our project MUST be published under the terms of the GPL or a GPL-compatible license.
Now we have one company that doesn't want to do this. They are selling modules under a closed-source license and they don't seem to be willing to accept our arguments.
I will provide more details if a serious discussion can be possible on this mailing list. From what I've seen in the last few days (The HURD vs. Schilling) I must wait for reactions :-)
Jan Wildeboer
Hi Jan,
to answer the question raised in the subject:
Whenever you believe you may be facing a GPL violation, get in touch with the FSFs. The easiest way to get in touch with the FSF Europe is probably by sending mail to team@fsfeurope.org.
First we will figure out whether something is really a violation, then we will try to figure out whether it can be solved peacefully and only if this fails will we resort to other means like making such cases public or taking legal steps.
Our goal is to make people comply to the GPL, not to put them all out of business. Sometimes GPL violations will be genuine mistakes and if we come down on them hard without ever giving them a chance to solve the problem first, this will not encourage people and companies to support Free Software.
Making such cases public prematurely, will put a lot of pressure on the violator, making a peaceful solution much more unlikely.
Also it will create a lot of noise about potential GPL violations that will create uncertainty and also make sure people miss the truly important information. Shouting "Wolf" all the time has never been a very good idea.
And whatever you do: never take legal actions based on the GPL without involving the FSFs beforehand and keeping them involved as a third party!
Most lawyers and judges do not know a lot about software and they usually know much less about Free Software.
The FSFs know the strengths of the GPL better than anyone else and have a lot of experience dealing with such cases. Taking legal steps without involving the FSFs means taking a gamble on the future of Free Software.
It may come out fine, but if it doesn't, you'll be the one who created the precendence case against Free Software!
Coming back to your case, Jan, I recommend you write a summary of the situation to team@fsfeurope.org or to me directly and let us know what's going on. Then we can see what should be done.
Regards, Georg Greve
Jan Wildeboer jan.wildeboer@gmx.de wrote:
The way we understand the GNU General Public License all modules programmed to be used in our system must be published under the terms of the GPL. Our opinion is mainly based on this GPL-FAQ entry: http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins
This is due to the fact that shipping/payment modules use objects generated by our project (the cart object, customer address etc.). So we are quite sure that the second part of this FAQ-entry is valid in this context, so all modules written for our project MUST be published under the terms of the GPL or a GPL-compatible license.
I believe this to be the case, but I'm unable to find any documentation on how plug-ins integrate with your software. (I am asked to give you my details before being allowed to read the FAQ!) Are they really linked in, or could they be counted as separate programs? Can someone more familiar with PHP confirm that this use of objects is similar to that in C++ or other more common languages, please?
Also, you ought to follow the instructions of how to apply the GPL to your software more closely. Most of your files seem not to have any copyright information, for example. Are they covered by the GPL or another "Open Source" licence? This may be part of the reason for the third party company's confusion.
I believe this to be the case, but I'm unable to find any documentation on how plug-ins integrate with your software. (I am asked to give you my details before being allowed to read the FAQ!) Are they really linked in,
or
could they be counted as separate programs?
The way we use modules is by using include() statements that include the modules in the calling page thus forming a single source page that the PHP interpreter interpretes.
Modules work with objects generated by the main application, they use functions from various project-wide include files. They use database query wrapper functions etc.
Also, you ought to follow the instructions of how to apply the GPL to your software more closely. Most of your files seem not to have any copyright information, for example. Are they covered by the GPL or another "Open Source" licence?
I don't know which files you are looking at, I am talking about the development versions that uses this in (almost) all source files:
/* $Id: banner.php,v 1.9 2001/12/14 12:55:49 hpdl Exp $
osCommerce, Open Source E-Commerce Solutions http://www.oscommerce.com
Copyright (c) 2001 osCommerce
Released under the GNU General Public License */
Is that sufficient?
The third party thinks that their modules (which I believe are based on our sample modules, but they won't show us the sources) can be published under any license they like. They even used our mailing lists to advertise their modules.
Jan Wildeboer
Jan Wildeboer jan.wildeboer@gmx.de wrote:
The way we use modules is by using include() statements that include the modules in the calling page thus forming a single source page that the PHP interpreter interpretes.
Modules work with objects generated by the main application, they use functions from various project-wide include files. They use database query wrapper functions etc.
Right. So, they are not "linked" as such and are distributed seperately as extensions to your distribution? (If they are distributing a combined ready-to-run package, this is moot and they must obey GPL.) I don't know what previous thoughts are on PHP'd software. In the FAQ, Perl is mentioned and using GPL'd modules means that you must be GPL'd. Java is mentioned and subclassing is a derivative work. I guess that *because* they use your functions and data structures, they are derived works to all intents and purposes. So they should be GPL'd.
But they don't call your scripts, do they? They just expect you to include() them and your functions to be available. Consider this: Would #include'ing a GPL'd file require your work to be GPL'd? Probably. But if you are #include'd by a GPL'd program, what happens there? I don't know, but I think it makes your software Free Software using non-free "libraries". http://www.gnu.org/licenses/gpl-faq.html#WritingFSWithNFLibs It seems that the combined system may not be distributed unless you grant a specific exception. I'm guessing that you won't.
Do they have to modify your files to run their software??
I don't know which files you are looking at, I am talking about the development versions that uses this in (almost) all source files:
Yes, that's better. Maybe I snagged the stable version by mistake.
The third party thinks that their modules (which I believe are based on our sample modules, but they won't show us the sources) can be published under any license they like. They even used our mailing lists to advertise their modules.
Can't you analyse their binaries? Maybe not, if their licence is nasty.
If they are abusing your mailing lists, you should set their messages to be held for moderation. If they evade the moderation, you should file an abuse report with their provider.
I am not a lawyer. I'm just trying to understand.
Right. So, they are not "linked" as such and are distributed seperately
as
extensions to your distribution?
Yes. Though these files are of no use outside our application. They can't work standalone, they rely on being included.
(If they are distributing a combined ready-to-run package, this is moot and they must obey GPL.) I don't know what previous thoughts are on PHP'd software. In the FAQ, Perl is
mentioned
and using GPL'd modules means that you must be GPL'd. Java is mentioned
and
subclassing is a derivative work. I guess that *because* they use your functions and data structures, they are derived works to all intents and purposes. So they should be GPL'd.
That's our understanding. Good to know we're not alone :-)
But they don't call your scripts, do they?
They do. For example a payment module is included in the checkout process, processes the data it gets from the main application (cart/customer info, module parameteres stored in the database), initiates a redirect to either the success or non-sucess page etc.
They just expect you to include() them and your functions to be available. Consider this: Would #include'ing a GPL'd file require your work to be GPL'd? Probably. But
if
you are #include'd by a GPL'd program, what happens there? I don't know, but I think it makes your software Free Software using non-free
"libraries".
That's the other way round. This comes in effect when we utilite libraries that were written not specifically for this purpose (e.g. calling curl in some checkout modules as they require SSL-connections, something PHP lacks). These modules are clearly programmed as modules for osCommerce without any functionality beyond osCommerce, so I guess they are plug-ins and no libraries.
Do they have to modify your files to run their software??
I don't know. They won't allow us to see their sources or an installed version.
Can't you analyse their binaries? Maybe not, if their licence is nasty.
They probably don't use binaries, as PHP normally is interpreted and not compiled. I asked several times if they are willing to send us their sources but they ignore these questions.
If they are abusing your mailing lists, you should set their messages to
be
held for moderation. If they evade the moderation, you should file an
abuse
report with their provider.
The funny thing is that after I showed them relevant GPL-FAQ entries they suddenly posted a message stating that after an internal meeting they had decided to not offer the modules but only the installation service. Yet they never did that. The license question was never answered nor did they change anything on their webserver.
Jan Wildeboer
Jan Wildeboer jan.wildeboer@gmx.de schrieb/wrote:
The FAQ unfortunatly has a legal opinion that is probably not compatible with most copyright laws, especially German Urheberrecht:
If a plugin is not based on code of yours but rather uses an interface to "communicate" with it - be it fork/exec, function calls or other methods - it is not a work dereived from yours, so your copyright simply does not apply.
Even an include() statement does not make the plug-in in the form it is _distributed_ in a dereived work.
Further, it might be a violation of antitrust laws if GNU software becomes more prominent.
It is probably not a very good idea to test this aspect of the GPL in court.
Claus (No I'm not yet a lawyer but a law student specialising in IP law)
=?ISO-8859-1?Q?Claus_F=E4rber?= list-fsf-eu-discussion@faerber.muc.de wrote:
Even an include() statement does not make the plug-in in the form it is _distributed_ in a dereived work.
Hrm. The program cannot function independently and modifies the original at run-time. Sounds derived to me, but is it?
Of course, if it is based on a GPL'd sample, all this is moot.
It is probably not a very good idea to test this aspect of the GPL in court.
It is never a good idea to go to court, but sometimes one has to.
An alternative strategy in this case is to implement something similar to the "licence taint" that is now in Linux module loading and inform your customers in many-feet-high lettering that they just abandoned all hope of support. With PHP, maybe you could do this by reporting an md5sum of installed modules in any crash output? Just thinking aloud, really.
Claus (No I'm not yet a lawyer but a law student specialising in IP law)
Got any colleagues in the UK? ;-)
MJ Ray markj@cloaked.freeserve.co.uk schrieb/wrote:
=?ISO-8859-1?Q?Claus_F=E4rber?= list-fsf-eu-discussion@faerber.muc.de wrote:
Even an include() statement does not make the plug-in in the form it is _distributed_ in a dereived work.
Hrm. The program cannot function independently and modifies the original at run-time.
Does it? Or does it just _use_ it?
What matters is wheter you are doing something that requires the permission of the author. In EU member states, this is making any copy, even temporary copies.
Although you might be distributing code that cannot function independently, you are not copying the original code, so you don't need the permission of its author.
Please also note that the EU Copyright Directive for Computer Programmes also includes a statement that even allows reverse- engineering to make other software interoperable. So a licence clause that disallows (proprietary) interoperable software should be void in most member states.
Claus
Although you might be distributing code that cannot function independently, you are not copying the original code, so you don't need the permission of its author.
Something we cannot examine without the sources. To make sure the code is independent we need to compare their module with our code and sample sources.
Please also note that the EU Copyright Directive for Computer Programmes also includes a statement that even allows reverse- engineering to make other software interoperable. So a licence clause that disallows (proprietary) interoperable software should be void in most member states.
Interoperability is no problem for GPL'ed software, as you always get the sources. The other way round is the problem - distributing closed source products based on GPL'ed sources.
Jan Wildeboer
Jan Wildeboer jan.wildeboer@gmx.de wrote:
Although you might be distributing code that cannot function independently, you are not copying the original code, so you don't need the permission of its author.
Something we cannot examine without the sources. To make sure the code is independent we need to compare their module with our code and sample sources.
Sadly, in most legal systems that I know, you will have to prove the case with the available facts, unless you get a friendly judge who will compel them to show the code.
I don't like the OAGPL posted elsewhere in this thread. It seems to have problems. Why is the GPL perceived as inadequate for web-based software?
On Thu, 2002-03-21 at 00:36, MJ Ray wrote:
I don't like the OAGPL posted elsewhere in this thread. It seems to have problems. Why is the GPL perceived as inadequate for web-based software?
The GNU GPL requires access to the program and the sources. Through a webapp, you never actually use the program, but feed data into the webserver which will run the program and then send you back the results.
So... the user is "using" a GPL program, but has no way to get it's sources.
Hugs, Rui
http://www.affero.org/oagpl.html http://www.be.linux.org/pipermail/asbl-libre/2002-March/000138.html
The affero general public licence is trying to extend this to the ASP world. This is an excellent idea to extent Freedom in other specific area where the GNU general public license version 2 is not well suited.
We think that the Affero GPL is a small step to the next GPL version 3.
So we are waiting to change from GPLv2 to GPLv3... ;-)
alx
On 21 Mar 2002, Rui Miguel Silva Seabra wrote:
On Thu, 2002-03-21 at 00:36, MJ Ray wrote:
I don't like the OAGPL posted elsewhere in this thread. It seems to have problems. Why is the GPL perceived as inadequate for web-based software?
The GNU GPL requires access to the program and the sources. Through a webapp, you never actually use the program, but feed data into the webserver which will run the program and then send you back the results.
So... the user is "using" a GPL program, but has no way to get it's sources.
Hugs, Rui
Alexandre Dulaunoy adulau-conos@conostix.com wrote:
The affero general public licence is trying to extend this to the ASP world. This is an excellent idea to extent Freedom in other specific area where the GNU general public license version 2 is not well suited.
The new clause is badly written, though. Examples:
1/ Why specify a particular protocol? Protocols are not forever and why should my email or gopher application offer its source by HTTP?
2/ Why only specify that they are allowed to "request transmission"? There doesn't seem to be anything stopping me returning a "Not Found" or "Forbidden" error response, yet still being compliant with this licence. It would probably be better to say that they may obtain source, not merely request it.
3/ How can you decide what the program "intended"? They are not animate. (Ok, this is a nitpick making up the numbers... two errors in one sentence is still not good ;-) ).
Yes, we know. We have made some comment, but the idea is a good step ;-)
Here it is the email sent to fsf and affero :
<email> Dear Sir,
http://www.affero.org/oagpl.html
The licence is very interesting and seems to fill some gap of the GPLv2 regarding the ASP/MSS world. We have the same issue with one of our projects IPFC (released under GPLv2). Some ASP (in Managed Security Service) are using IPFC without giving back the modified version because they don't directly distribute the software to the customer. So for us the affero is a big step for the maybe GPLv3.
But there is some issue regarding the clear definition of what is an ASP, what is a customer (client, user)... We have read the license and with some comment regarding the point 2(d).
There is a point about the use of "user" as name. In our case, we have some specific external application (for example, syslog server that are pushing information into our infrastructure). These applications could be considered as user. Is there maybe another generic term to describe this case ?
Another point is regarding the availability of the modified source code. We think that the HTTP distribution is not possible in all case and limits the possibility of redistribution (not so good for Free Software ;-). For example, an "evil" ASP could have a special button that permit download of the modified source code. But you must be a customer of that "evil" ASP... So, classical distribution (open web server (not asp interface), ftp server, cdrom...) is maybe better.
This is minor comment. We think that the affero public license is going into the right direction.
We found that is a great idea to extent the GPLv2 to protect Freedom in some other area.
</email>
So don't hesitate to send comment directly to affero and FSF.
alx
On Thu, 21 Mar 2002, MJ Ray wrote:
Alexandre Dulaunoy adulau-conos@conostix.com wrote:
The affero general public licence is trying to extend this to the ASP world. This is an excellent idea to extent Freedom in other specific area where the GNU general public license version 2 is not well suited.
The new clause is badly written, though. Examples:
1/ Why specify a particular protocol? Protocols are not forever and why should my email or gopher application offer its source by HTTP?
2/ Why only specify that they are allowed to "request transmission"? There doesn't seem to be anything stopping me returning a "Not Found" or "Forbidden" error response, yet still being compliant with this licence. It would probably be better to say that they may obtain source, not merely request it.
3/ How can you decide what the program "intended"? They are not animate. (Ok, this is a nitpick making up the numbers... two errors in one sentence is still not good ;-) ).
Alexandre Dulaunoy adulau-conos@conostix.com wrote:
So don't hesitate to send comment directly to affero and FSF.
I've sent it to Affero. Hopefully FSF are reading this list (as are the FSFE people designing our locally usable licence, I hope). Let's see what responses we get?
The GNU GPL requires access to the program and the sources. Through a webapp, you never actually use the program, but feed data into the webserver which will run the program and then send you back the results.
So... the user is "using" a GPL program, but has no way to get it's sources.
Hugs, Rui
In the case of a server-side solution (like PHP scripts) the end user does not actually run the program. All he gets is a quite static HTML document (well not so static if it as Javascript, applets or other client side runnable content). In fact your are not provided with a program but with a service. So your not the user of the program.
IMHO the actual user of the program is the owner/webmaster of the server who did intall and configure the program. For example my ISP is free.fr and I'm writing this using the IMP webmail interface (which is free software as far as I know) it provides me. Can I say that I'm an user of IMP? I don't think so. I'm an user of the free.fr web services, whatever it uses to provide it (even if I like to know that they use free software).
Well, now if the pages does contain some Java applet content wich are actually runned client side on my computer, I'm puzzled. Am I directly using foo.class so I can say I'm a user of this program or am I just an user of a browser (Mozilla in this case) which provides me the features of foo.class? Can a GPL'd browser run non free applets?
The problem is that the difference between what is a program and what is a (dynamic) document is not really clear for me.
Guillaume Ponce http://www.guillaumeponce.org/
(even if I like to know that they use free software).
IMP is free software.
http://www.horde.org/imp/about/
HTH
Jan Wildeboer
On Wed, 2002-03-20 at 13:46, Claus Färber wrote:
MJ Ray markj@cloaked.freeserve.co.uk schrieb/wrote:
=?ISO-8859-1?Q?Claus_F=E4rber?= list-fsf-eu-discussion@faerber.muc.de wrote:
Even an include() statement does not make the plug-in in the form it is _distributed_ in a dereived work.
Hrm. The program cannot function independently and modifies the original at run-time.
Does it? Or does it just _use_ it?
There is no difference. It can modify the behaviour because it is linking with it.
What matters is wheter you are doing something that requires the permission of the author. In EU member states, this is making any copy, even temporary copies.
With GPL'ed software you have the permission of the author if you respect the conditions the software is released under.
I do suggest changing that web software's license from GPL to OAGPL.
AFFERO GENERAL PUBLIC LICENSE http://www.affero.org/oagpl.html
This license is an attempt at solving issues with web apps.
Although you might be distributing code that cannot function independently, you are not copying the original code, so you don't need the permission of its author.
Please also note that the EU Copyright Directive for Computer Programmes also includes a statement that even allows reverse- engineering to make other software interoperable. So a licence clause that disallows (proprietary) interoperable software should be void in most member states.
This is not interoperability. Communicating with a remote machine (C2S ou P2P) involves interoperability. Linking with some software is including at runtime that code in the program, so it is a derived work.
Hugs, rui
On Wed, Mar 20, 2002 at 03:55:08PM +0000, Rui Miguel Silva Seabra wrote:
I do suggest changing that web software's license from GPL to OAGPL.
AFFERO GENERAL PUBLIC LICENSE http://www.affero.org/oagpl.html
This license is an attempt at solving issues with web apps.
The section added (2.d) is still limited by what is and what isn't the Program and if the modules are derivated work.
IANAL, but I doubt that OAGPL is valid. It isn't even coherent, that same section goes against "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does."
Regards, Luciano Rocha
Hi,
On 20 Mar 2002, Claus Färber kindly wrote:
--snip--
Although you might be distributing code that cannot function independently, you are not copying the original code, so you don't need the permission of its author.
Please also note that the EU Copyright Directive for Computer Programmes also includes a statement that even allows reverse- engineering to make other software interoperable. So a licence clause that disallows (proprietary) interoperable software should be void in most member states.
Why the hell would anybody want to reverse-engineere a programm when you can have the source under GPL?
So, your analogy is incorrect: What you are reffering to is a legal measure designed for cases in which you buy software and can not use it the way you need, because the Licensor refuses to give you the source. This is the purpose of the law (in German: Schutzzweck der Norm, since you want to become a lawyer, you should study this). *Nothing* more.
Georg Jakob jack@unix.sbg.ac.at schrieb/wrote:
Why the hell would anybody want to reverse-engineere a programm when you can have the source under GPL?
You completly missed the point: The statement only shows that it is the intention of the legislator to allow creation of interoperable software regardless of copyright restrictions.
So, depending on national law (in Germany ?307 II 1. BGB) this might render a clause that only allows interoperable software under certain conditions (such as being GPL) void.
Otherwise, this would lead to strange situations: You would always be allowed to decompile the programme to find out the information neccessary to write interoperable programmes (as it can't excluded by contract) but you could not write interoperable programmes because of other licensing restrictions.
So, your analogy is incorrect: What you are reffering to is a legal measure designed for cases in which you buy software and can not use it the way you need, because the Licensor refuses to give you the source.
No, that's plain wrong. The Directive 91/250/EEC clearly says:
| Whereas an objective of this exception is to make it possible to | connect all components of a computer system, including those of | different manufacturers, so that they can work together;
(where it is clear from later paragraphs that components refers to both hard and software.)
Claus
On Fri, 2002-03-22 at 07:44, Claus Färber wrote:
No, that's plain wrong. The Directive 91/250/EEC clearly says: | Whereas an objective of this exception is to make it possible to | connect all components of a computer system, including those of | different manufacturers, so that they can work together; (where it is clear from later paragraphs that components refers to both hard and software.)
Why can't different manufacturers work together? How come a change from ASF's httpd to GPL'ed would fall under antitrust law?
Let's keep in mind a few things: a) manufacturers can continue to develop their own versions of apache httpd based under a lower version that has the ASL b) manufacturers of proprietary stuff are those who are having a more restrictive license. The change is benefitial to competition, just not to their licensing model. c) they are not excluded from developing with apache, they choose to exclude themselves by not willing to comply with a license that would break their monopoly on the proprietary extension.
A change of apache httpd to GPL would not hinder competition in favour of ASF but enlarge competition. To comply with the new license, the proprietary extension maker would have to open the extension to competitors. He can simple take an older version of apache httpd and develop on it.
Cheers, rui
Hi,
On 22 Mar 2002, Claus Färber kindly wrote:
Georg Jakob jack@unix.sbg.ac.at schrieb/wrote:
Why the hell would anybody want to reverse-engineere a programm when you can have the source under GPL?
You completly missed the point: The statement only shows that it is the intention of the legislator to allow creation of interoperable software regardless of copyright restrictions.
I thougt it was clear that nobody would want to reverse engineer apache. I got your point - you wanted to make clear the intention of the legislator using an example that can't be directly applied to apache. On the other hand, I just wanted to point out that maybe your example was to far away to be applied to apache (or other Free Software, especially GPLed) at all.
So, depending on national law (in Germany ?307 II 1. BGB) this might render a clause that only allows interoperable software under certain conditions (such as being GPL) void.
In general I agree with you. Apart from "such as being GPL". But please read on.
Otherwise, this would lead to strange situations: You would always be allowed to decompile the programme to find out the information neccessary to write interoperable programmes (as it can't excluded by contract) but you could not write interoperable programmes because of other licensing restrictions.
Good point. Please see my other response for details on that.
So, your analogy is incorrect: What you are reffering to is a legal measure designed for cases in which you buy software and can not use it the way you need, because the Licensor refuses to give you the source.
No, that's plain wrong. The Directive 91/250/EEC clearly says:
| Whereas an objective of this exception is to make it possible to | connect all components of a computer system, including those of | different manufacturers, so that they can work together;
| [...] provided that the following conditions are met:
| (a) these acts are performed by the licensee or by another person having ^^^^^^^^ ^^^^^^ | a right to use a copy of a program, or on their behalf by a person ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | authorized to do so;
OK, this means that you have to have a license for the binary to be privileged by the directive, i.e. you have to have a valid contract with the licensor. Notice that nothing is said about licensing conditions - those are left to negotiation between licensor and licensee.
| (b) the information necessary to achieve interoperability has not | previously been readily available to the persons referred to in | subparagraph (a)
For GPLed Software, the source is available per definitionem.
The problem is *readily*. Do the sources have to be available without any limiting conditions? No, that would be ridicoulus. They have to be available under the same conditions as the binary. And the GPL is one of the few licenses that does exactly that.
(where it is clear from later paragraphs that components refers to both hard and software.)
Yes. License compatibility is *not* an issue of the directive. Neither is the fairness of a license.
So we are back to the purpose of the law, this is not only about what the law itself says, but what can be derived from it's content and context as the true intention of the legislator.
And the cases I mentioned - where the manufacturer=vendor refuses to give you the source - are what the legilator had in mind. The directive simply wasn't designed for Free Software.