[haiku-development] Re: INPUT / VOTE : --include-gpl-addons
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 20 Aug 2009 18:37:41 +0200
On 2009-08-20 at 00:34:08 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
> 2009/8/19 Ingo Weinhold <ingo_weinhold@xxxxxx>:
[...]
> > The reason that e.g. a GPLed file system was possible for the BeOS kernel
> > is that the GPL has an explicit exception for "major operation system
> > components". The situation for media codecs is somewhat tricky. No idea
> > whether the exception applies there too. Possibly not.
>
> Section 3c reads:
>
> """The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable. However, as a
> special exception, the source code distributed need not include
> anything that is normally distributed (in either source or binary
> form) with the major components (compiler, kernel, and so on) of the
> operating system on which the executable runs, unless that component
> itself accompanies the executable."""
>
> This is a section about what the requirements are of distributing the
> source code with a binary. In this case the exception you refer to
> does not actually refer to an exception on what can be GPL and what
> not, but merely on what you need to distribute.
I stumbled over that too, particularly wondering how that plays together with
2 b) -- if the combined work still has to be covered by the terms of the GPL,
this would mean you could still only link against GPL-compatible libraries
and would just be freed from also distributing the source for OS components.
This is apparently not what is meant, though. The respective FSF GPL FAQ is
pretty explicit in that this clause in the license implies an exception to
the copyleft:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
Reading the license text I find this interpretation a bit weird, but I'm
neither a lawyer, nor would I doubt that the FSF, the authors of the license,
know what it is supposed to mean. Particularly since they do have lawyers.
> Luckily we don't have
> to distribute the compiler and the operating system with the source
> when we distribute a binary of a GPL program.
>
> Your example of a GPL filesystem actually has the same theoretical
> issues like any other add-on.
I still believe the "major operation system component" exception applies to
file systems in such a way, that there are no restrictions applying to the
kernel they link against.
> > The MIT license is said to be GPL-compatible. AFAICT that mainly means
> > that
> > it is OK with 2. b) of the GPL v2, i.e. it allows a work combined from MIT
> > licensed and GPLed work to be distributed under the GPL. What that means
> > in
> > the case of our media codecs -- no idea.
>
> The MIT license is compatible because it is less restrictive than the
> GPL, effectively meaning that if you distribute MIT code with GPL
> code, you can relicense the MIT portion to GPL to confirm to the
> requirements.
>
> This effectively means that you are doubly licensing the source files
> at that point.
Yeah, I guess that's what it amounts to.
> The issue at hand is that it is not clear what happens to add-ons,
> which are binaries that interact with a program. There are two ways to
> tackle this:
>
> 1. The add-on (program) is loaded like a library (as such, it is
> linked). This would mean that when the add-on is GPL (and it is
> loaded), the loader should be GPL as well (as by section 2b of the
> GPL).
> 2. The add-on is a dedicated unit specifically for one task. When
> terminal utilities are piped together (thus interoperating), the GPL
> is not viral, so it does not matter if one is GPL and one is not.
>
> That's the issue at hand, and there is no legal answer to it yet.
> There was a decision (a while back) to separate GPL add-ons from the
> distribution, in order to not get into trouble if this was ever
> decided in court.
The FSF FAQs draw the line pretty clearly, cf.
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins
and the following two. The gist is, a program has to run the GPL code in a
separate process in order not to be affected by the GPL.
> So I think the best way is to ask the authors of the GPL modules if
> they can grant us a formal exemption by allowing us to use their
> module as an add-on.
Yes, I guess we have to do that for the media codecs.
On 2009-08-20 at 09:35:26 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Niels Reedijk <niels.reedijk@xxxxxxxxx> wrote:
> > """b) You must cause any work that you distribute or publish, that in
> > whole or in part contains or is derived from the Program or any part
> > thereof, to be licensed as a whole at no charge to all third parties
> > under the terms of this License."""
> >
> > The 'viral' aspect of the GPL is in this statement. It circumvents
> > the
> > discussion you are having by claiming that any program that uses
> > GPL'd
> > code, must be completely GPL.
>
> The problem here is that "uses" is not really defined. In any case, the
> component using (not in GPL terms, just English) a GPL add-on is
> neither part of that add-on (or vice versa), nor is it a derivative.
With that interpretation you could just put GPL code you want to use into an
add-on and thus circumvent the GPL.
> > Now the theoretical issue is whether add-ons are like modules
> > (read:libraries) or whether they are independent apps that
> > communicate
> > with another independent app. (read on)
>
> AFAICT that's from the FAQ, but not mentioned in the license, and as
> such is just an opinion (IMO :-)).
> In any case, the following is what needs to be checked (last paragraph
> before section 3):
>
> "In addition, mere aggregation of another work not based on the
> Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License."
>
> The question is, if that can be translated to add-ons, too.
> Practically, the means of communication is indeed just a technicality
> (even if the FAQ hints in another direction, that's still not part of
> the license).
While that is certainly true, I would follow the intention of the license --
i.e. go with the FSF's interpretation -- rather than use potentially existing
loopholes in the license text.
> If we would write an add-on that is using the ffmpeg executable, the
> end result would be the same, but then the "mere aggregation" would
> definitely be fulfilled (and you could also consider shell applications
> as add-ons to the shell - they just communicate with each other as
> mentioned in the FAQ).
The FAQs I linked to above make exactly that distinction. And no, the end
result would not be quite the same, at least not in terms of
efficiency/performance.
> In the end, add-ons are not actually taken into account by the license,
> and we do not know how it would be judged in a trial.
> Therefore, I think, if I get a "better don't do this" from the FSF, I
> think we should follow Urias' suggestion, and ask the project in
> question.
Unless the FAQs are misleading, which I don't think they are, that's exactly
what we should do.
CU, Ingo
Other related posts:
