GPLv2 for cifs-utils existing?

GPLv2 for cifs-utils existing?

[brennersimon-KvP5wT2u2U0]

Hello there,

I'm wondering whether the cifs-utils are available licenced under the GPLv2? I only found it under GPLv3. Maybe there are specific circumstances under which the licence is changeable?

Thanks,

-Simon Brenner.

Re: GPLv2 for cifs-utils existing?

[Jeff Layton]

On Thu, 1 Sep 2011 15:08:54 +0200 (CEST)
brennersimon-KvP5wT2u2U0@public.gmane.org wrote:

> Hello there,
> 
> I'm wondering whether the cifs-utils are available licenced under the GPLv2? I only found it under GPLv3. Maybe there are specific circumstances under which the licence is changeable?
> 
> Thanks,
> 
> -Simon Brenner.

No. It's GPLv3 and up.

We do occasionally dual-license some of the patches to make it
easier to backport to older versions of the same tools in samba. The
cifs-utils package itself has always been GPLv3 however.

Can you clarify why you'd like to see it as GPLv2?

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

Re: GPLv2 for cifs-utils existing?

[simo]

On Mon, 2011-09-05 at 18:10 +0200, sean finney wrote:
> > > > If every user has to be able to rebuild his own firmware files
> then
> > > > the manufacturer would be forced to open all code.
> > > 
> > > I would say so.
> > 
> > And you'd be TOTALLY wrong, unless the firware is a single program
> where
> > everything is linked together. If, as it almost certainly is, it is
> just
> > some sort of squashfs or similar that is unpacked at boot by the
> kernel,
> > then you have mere aggregation.
> 
> That's kind of what I was getting at above.  Please reconsider the
> context of that answer, that as a given, the user needs to be able to
> disassemble/reassemble the firmware and it was in question whether
> that
> was even possible.  if you can't reliably take the image apart and put
> it back together, what's the difference between that and an ELF file
> with a really large .rodata section?

Ok this would be a case of combining all the code in a single
executable, which makes a big difference. Unfortunately you are still
totally wrong wrt the question made.

Nobody can force you to disclose code, if the firmware is not found
compliant then the first option is to simply stop distributing the code
completely. Of course if you want to keep distributing the code then you
have to come in compliance, either by removing and replacing the GPLed
portions (v2 or v3 makes no difference wrt linking executables) or by
compatibly licensing your own code and distributing its source under the
terms of the GPL.

I find it hard to think that something including the linux kernel (which
is the only reason to use cifs-utils) is transformed into a single
executable all linked together. But I guess everything is possible.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: GPLv2 for cifs-utils existing?

[sean finney]

Hi,

On Mon, Sep 05, 2011 at 03:50:30PM +0200, brennersimon-KvP5wT2u2U0@public.gmane.org wrote:
> > > The entire point of the GPL is that an end user who
> > > receives GPL'd software should be able to take it apart, modify it,
> > > put it back together, and run the result.
> > 
> > Yes, but only what is part of the GPLed program.
> 
> Does that mean a separation of GPL programs and proprietary programs would provide a clean solution? Perhaps one GPL firmware image and one proprietary firmware image?

If you put the kernel, busybox, and other GPL'd stuff on one image, and
had some kind of "add-on" image, I don't think there'd be much question about
it, as long as you could still adhere to the GPL with the former.  But as
simo pointed out, depending on the technicalities of how you are 
generating/packing your firmware files it might not be necessary either.

But once again IANAL, and if you're making an actual thing that you plan on
selling to someone, it's probably prudent to talk to someone who is :)

> > > I read about 'tivoization' and I guess that's the thing I'm actually
> > > referring to, isn't it? And as far as I read that's a point which was
> > > enforced especially with GPLv3.
> > 
> > Are you signing the firmware in a way that is checked at boot and won't
> > allow the boot to proceed if the signatures do not check ?
> > 
> > If so then there is a difference between GPLv2 and GPLv3 but has nothing
> > to do with aggregation, nor with release the source code of other
> > unrelated components.
> 
> Interesting part. Let's say yes, how differ v2 and v3 if I signed my firmware so that none other than my own firmware was bootable?

In that case I think you'd be violating only the spirit of v2 (i.e. techincally
in compliance, but not exactly making end-users who care about the GPL
happy).  But with v3 you would probably have GPL compliance issues since
that was one of the express concerns it attempts to address -- unless
you also provided a way for the end users to create their own signed firmwares,
in which case it'd be a non-issue.


	sean

Re: GPLv2 for cifs-utils existing?

[sean finney]

Hi,

On Mon, Sep 05, 2011 at 08:39:01AM -0400, simo wrote:
> On Mon, 2011-09-05 at 11:26 +0200, sean finney wrote:
> > Hi,
> > 
> > On Sat, Sep 03, 2011 at 09:39:17AM +0200, Simon Brenner wrote:
> > > So how is it when, say, a router manufacturer has its own
> > > (proprietary + closed) file format for the firmware files. Within
> > > the firmware he uses several GPL projects (v2 or v3) as well as some
> > > own closed projects which he doesn't want to be seen by everyone.
> > 
> > Again IANAL, this is my own interpretation (and apologies to the list
> > regulars if my de-lurking is causing annoyance, if so just msg me
> > privately and I'll shut up).
> > 
> > > Would the manufacturer then have to provide all source code, even
> > > its own which he originally wanted to keep private?
> > 
> > I would say yes, because the resulting firmware file is not a mere
> > aggregation but rather a derived work containing the GPL'd components.  I
> > believe at least one major retail brand of consumer network products
> > has been successfully taken to court along these lines.
> 
> This is probably just BS.
> 
> How is a firmware file different from a tar file or a .iso image ?
> 
> Please let's stop making things up.

With all due respect I am not.  If the firmware image could be construed
as some form of media (filesystem image, file archive, etc), then yes,
there is some room for argument -- I mentioned this point in my first
response, even, but the response from the OP seemed to hint that this
was not the case.  If it is not some readily accessible form of media/fs,
for which tools and/or documentation are not freely available to
pack/unpack the image, I think your argument becomes much less tangible.

> Not murky at all.
> The distributor has to provide the tools necessary to build and change
> the program. It does not need to provide source code form unrelated apps
> ion the same firmware just their binaries at most. If the firmware can
> be simply unpacked and repacked they probably do not need to provide
> anything more than GPL components sources and build scripts and
> instructions on how to unpack/replace/repack the firmware image.

Your argument has merit iff the firmware can be considered a form
of media to contain a "mere aggregation".  Otherwise, I don't see how
to consider the firmware as anything other than a single executable with
a lot of embedded data.  We may agree to disagree here, and it wouldn't
be the first time this argument has been had...

> > Generally it *doesn't* apply to any build tools and system libraries
> > that you'd normally find on the OS used to build the work, or could
> > find freely available.  But it's a very blurry line, and one that
> > I'd just as soon avoid...
> 
> You certainly do not need to provide compiler and libraires used by the
> compiler, but makefiles or similar scripts needed for build should be
> provided.

What I was getting at with the "Murky" comment above was that in some cases
building firmware is more than just running source code through a standard
compiler chain + archiving tools.  Depending on the context/platform it
might be necessary to use proprietary (licensed and expensive) tools to
generate either intermediate and/or final output in the process, or even
the entire compiler chain might be proprietary.  Sometimes even the output
format itself is proprietary and laden with IP/NDA's etc.  And that's
where stuff gets a bit sketchy with regards to the toolchain requirements,
at least IMHO.

> > > If every user has to be able to rebuild his own firmware files then
> > > the manufacturer would be forced to open all code.
> > 
> > I would say so.
> 
> And you'd be TOTALLY wrong, unless the firware is a single program where
> everything is linked together. If, as it almost certainly is, it is just
> some sort of squashfs or similar that is unpacked at boot by the kernel,
> then you have mere aggregation.

That's kind of what I was getting at above.  Please reconsider the
context of that answer, that as a given, the user needs to be able to
disassemble/reassemble the firmware and it was in question whether that
was even possible.  if you can't reliably take the image apart and put
it back together, what's the difference between that and an ELF file
with a really large .rodata section?

> >   If the firmware is the
> > product you are giving them, and it contains GPL software inside it,
> > then I think it does apply to the whole.
> 
> No, it depends on what the firwamre is. A distribution ISO file doesn't
> cause all the software to become magically GPLed.

Agreed there.  But a distribution ISO file comes in a well recognized and
standardized media format for which numerous tools and documentation exist.
The above was said under a different premise -- if the user could creatively
use dd/squashfs-tools and a cross-compiler to reproduce a firmware image,
then obviously there's much more strength to the "mere aggregate" argument.

On Mon, Sep 05, 2011 at 08:42:24AM -0400, simo wrote:
> On Mon, 2011-09-05 at 12:27 +0200, brennersimon-KvP5wT2u2U0@public.gmane.org wrote:
> > > > Would the manufacturer then have to provide all source code, even
> > > > its own which he originally wanted to keep private?
> > > 
> > > I would say yes, because the resulting firmware file is not a mere
> > > aggregation but rather a derived work containing the GPL'd components.
> > 
> > Does that apply to GPLv3 software as well as GPLv2 software within the firmware?
> 
> If it were true yes, it would apply equally, GPLv3 is a copyleft license
> just like GPLv2 and the 2 are *obviously* very close.

And JFTR I agree with just about everything in the subsequent mail (including
that it's probably a good idea to chat with a GPL-savvy lawyer).



	sean

Re: GPLv2 for cifs-utils existing?

[brennersimon-KvP5wT2u2U0]

> > The entire point of the GPL is that an end user who
> > receives GPL'd software should be able to take it apart, modify it,
> > put it back together, and run the result.
> 
> Yes, but only what is part of the GPLed program.

Does that mean a separation of GPL programs and proprietary programs would provide a clean solution? Perhaps one GPL firmware image and one proprietary firmware image?

> > I read about 'tivoization' and I guess that's the thing I'm actually
> > referring to, isn't it? And as far as I read that's a point which was
> > enforced especially with GPLv3.
> 
> Are you signing the firmware in a way that is checked at boot and won't
> allow the boot to proceed if the signatures do not check ?
> 
> If so then there is a difference between GPLv2 and GPLv3 but has nothing
> to do with aggregation, nor with release the source code of other
> unrelated components.

Interesting part. Let's say yes, how differ v2 and v3 if I signed my firmware so that none other than my own firmware was bootable?

-Simon.

Re: GPLv2 for cifs-utils existing?

[simo]

On Mon, 2011-09-05 at 12:27 +0200, brennersimon-KvP5wT2u2U0@public.gmane.org wrote:
> > > Would the manufacturer then have to provide all source code, even
> > > its own which he originally wanted to keep private?
> > 
> > I would say yes, because the resulting firmware file is not a mere
> > aggregation but rather a derived work containing the GPL'd components.
> 
> Does that apply to GPLv3 software as well as GPLv2 software within the firmware?

If it were true yes, it would apply equally, GPLv3 is a copyleft license
just like GPLv2 and the 2 are *obviously* very close.

> > > If every user has to be able to rebuild his own firmware files then
> > > the manufacturer would be forced to open all code.
> > 
> > I would say so.  The entire point of the GPL is that an end user who
> > receives GPL'd software should be able to take it apart, modify it,
> > put it back together, and run the result.  If the firmware is the
> > product you are giving them, and it contains GPL software inside it,
> > then I think it does apply to the whole.
> 
> Here again the question if this applies for v3 as well as v2 licenced software?

Of course. (But I think the whole premise is false, so consult a lawyer
or an otherwise expert in licensing matters that understand the
technicalities about how your firmware is built).

> I read about 'tivoization' and I guess that's the thing I'm actually
> referring to, isn't it? And as far as I read that's a point which was
> enforced especially with GPLv3.

Are you signing the firmware in a way that is checked at boot and won't
allow the boot to proceed if the signatures do not check ?

If so then there is a difference between GPLv2 and GPLv3 but has nothing
to do with aggregation, nor with release the source code of other
unrelated components.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: GPLv2 for cifs-utils existing?

[simo]

On Mon, 2011-09-05 at 11:26 +0200, sean finney wrote:
> Hi,
> 
> On Sat, Sep 03, 2011 at 09:39:17AM +0200, Simon Brenner wrote:
> > So how is it when, say, a router manufacturer has its own
> > (proprietary + closed) file format for the firmware files. Within
> > the firmware he uses several GPL projects (v2 or v3) as well as some
> > own closed projects which he doesn't want to be seen by everyone.
> 
> Again IANAL, this is my own interpretation (and apologies to the list
> regulars if my de-lurking is causing annoyance, if so just msg me
> privately and I'll shut up).
> 
> > Would the manufacturer then have to provide all source code, even
> > its own which he originally wanted to keep private?
> 
> I would say yes, because the resulting firmware file is not a mere
> aggregation but rather a derived work containing the GPL'd components.  I
> believe at least one major retail brand of consumer network products
> has been successfully taken to court along these lines.

This is probably just BS.

How is a firmware file different from a tar file or a .iso image ?

Please let's stop making things up.

> > How about the toolchain he used to compile all the stuff?
> 
> This gets into really murky waters...  see the definition of
> "Corresponding Source" and what it entails.  If you have custom
> proprietary build tools used to generate the image, there's a pretty
> strong argument that they are included in the derived work and thus
> subject to its terms.

Not murky at all.
The distributor has to provide the tools necessary to build and change
the program. It does not need to provide source code form unrelated apps
ion the same firmware just their binaries at most. If the firmware can
be simply unpacked and repacked they probably do not need to provide
anything more than GPL components sources and build scripts and
instructions on how to unpack/replace/repack the firmware image.

> Generally it *doesn't* apply to any build tools and system libraries
> that you'd normally find on the OS used to build the work, or could
> find freely available.  But it's a very blurry line, and one that
> I'd just as soon avoid...

You certainly do not need to provide compiler and libraires used by the
compiler, but makefiles or similar scripts needed for build should be
provided.

> > If every user has to be able to rebuild his own firmware files then
> > the manufacturer would be forced to open all code.
> 
> I would say so.

And you'd be TOTALLY wrong, unless the firware is a single program where
everything is linked together. If, as it almost certainly is, it is just
some sort of squashfs or similar that is unpacked at boot by the kernel,
then you have mere aggregation.

> The entire point of the GPL is that an end user who
> receives GPL'd software should be able to take it apart, modify it,
> put it back together, and run the result.

Yes, but only what is part of the GPLed program.

>   If the firmware is the
> product you are giving them, and it contains GPL software inside it,
> then I think it does apply to the whole.

No, it depends on what the firwamre is. A distribution ISO file doesn't
cause all the software to become magically GPLed.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: GPLv2 for cifs-utils existing?

[brennersimon-KvP5wT2u2U0]

> > Would the manufacturer then have to provide all source code, even
> > its own which he originally wanted to keep private?
> 
> I would say yes, because the resulting firmware file is not a mere
> aggregation but rather a derived work containing the GPL'd components.

Does that apply to GPLv3 software as well as GPLv2 software within the firmware?

> > If every user has to be able to rebuild his own firmware files then
> > the manufacturer would be forced to open all code.
> 
> I would say so.  The entire point of the GPL is that an end user who
> receives GPL'd software should be able to take it apart, modify it,
> put it back together, and run the result.  If the firmware is the
> product you are giving them, and it contains GPL software inside it,
> then I think it does apply to the whole.

Here again the question if this applies for v3 as well as v2 licenced software?

I read about 'tivoization' and I guess that's the thing I'm actually referring to, isn't it? And as far as I read that's a point which was enforced especially with GPLv3.

-Simon.

Re: GPLv2 for cifs-utils existing?

[sean finney]

Hi,

On Sat, Sep 03, 2011 at 09:39:17AM +0200, Simon Brenner wrote:
> So how is it when, say, a router manufacturer has its own
> (proprietary + closed) file format for the firmware files. Within
> the firmware he uses several GPL projects (v2 or v3) as well as some
> own closed projects which he doesn't want to be seen by everyone.

Again IANAL, this is my own interpretation (and apologies to the list
regulars if my de-lurking is causing annoyance, if so just msg me
privately and I'll shut up).

> Would the manufacturer then have to provide all source code, even
> its own which he originally wanted to keep private?

I would say yes, because the resulting firmware file is not a mere
aggregation but rather a derived work containing the GPL'd components.  I
believe at least one major retail brand of consumer network products
has been successfully taken to court along these lines.

> How about the toolchain he used to compile all the stuff?

This gets into really murky waters...  see the definition of
"Corresponding Source" and what it entails.  If you have custom
proprietary build tools used to generate the image, there's a pretty
strong argument that they are included in the derived work and thus
subject to its terms.

Generally it *doesn't* apply to any build tools and system libraries
that you'd normally find on the OS used to build the work, or could
find freely available.  But it's a very blurry line, and one that
I'd just as soon avoid...

> If every user has to be able to rebuild his own firmware files then
> the manufacturer would be forced to open all code.

I would say so.  The entire point of the GPL is that an end user who
receives GPL'd software should be able to take it apart, modify it,
put it back together, and run the result.  If the firmware is the
product you are giving them, and it contains GPL software inside it,
then I think it does apply to the whole.


	sean

Re: GPLv2 for cifs-utils existing?

[Simon Brenner]

Thanks for all your answers so far!

> That's to say that if you are distributing a single installable
> firmware file for your router, and it contains GPL'd software, you would
> arguably need to provide source for the entire work generating the
> firmware file.  And this isn't specific to v3 of the GPL either, AFAIK,
> it's kind of the point of the license to begin with.

So how is it when, say, a router manufacturer has its own (proprietary + 
closed) file format for the firmware files. Within the firmware he uses 
several GPL projects (v2 or v3) as well as some own closed projects 
which he doesn't want to be seen by everyone.

Would the manufacturer then have to provide all source code, even its 
own which he originally wanted to keep private?
How about the toolchain he used to compile all the stuff?
If every user has to be able to rebuild his own firmware files then the 
manufacturer would be forced to open all code.

Can you clarify that for me?

Thanks!

-Simon.

Re: GPLv2 for cifs-utils existing?

[simo]

On Fri, 2011-09-02 at 06:40 -0400, Jeff Layton wrote:
> On Fri, 2 Sep 2011 08:45:35 +0200 (CEST)
> brennersimon-KvP5wT2u2U0@public.gmane.org wrote:
> 
> > > Can you clarify why you'd like to see it as GPLv2?
> > 
> > At the moment, I'm just trying to learn and understand more about
> the GPLv3. So for several Linux programs I've been seeing what licence
> they've got. I've heard that GPLv3 is quite virulent. That could
> prevent a manufacturer (say of routers, receivers or similar things)
> from using cifs-utils if he didn't want to be all of his code opened.

Almost everything you said up to here is a mixture of FUD,
misconceptions and outright lies (you are no doubt a victim of such
lies, not saying you lied).

>  Is that right?

No

First of all GPLv3 is no more "virulent" than GPLv2, that it is to say
it is not at all. A license cannot spread to other code unless the
copyright holder wants to apply it to his code.

The license, like any other, states some requirements about source code
and when and how and to whom it needs to be distributed, and when the
code can be linked to other code. Esp. with cifs-util code, that is not
a library and therefore arguably not linked together with other code
there is really no more than mere aggregation going on.

I strongly suggest you talk to a (knowledgeable) lawyer about what are
your obligations applied to your specific case if you have this kind of
doubts. If you do not know lawyers that well versed in free software
licenses, write me in private and I'll give you names.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: GPLv2 for cifs-utils existing?

[sean finney]

On Fri, Sep 02, 2011 at 06:40:23AM -0400, Jeff Layton wrote:
> That's nonsense. It's certainly fine to ship GPLv3 software alongside
> closed source code. You'll need to provide source for the GPL'ed parts
> of course, but providing a set of self-contained GPLv3 programs
> shouldn't force a vendor to open anything else.

I will echo Jeff's "you should talk to a lawyer about this", and IANAL,
but to share some of my own experiences on the matter from having to
deal with this myself:

A lot of how the GPL applies to your own software depends on how you
distribute the binary form, and whether this combined non-GPL+GPL
product would be viewed as a "derivative work" or a "mere aggregation".

That's to say that if you are distributing a single installable
firmware file for your router, and it contains GPL'd software, you would
arguably need to provide source for the entire work generating the
firmware file.  And this isn't specific to v3 of the GPL either, AFAIK,
it's kind of the point of the license to begin with.  

Similarly, an application that links against a GPL'd work is generally
considered to be a derived work (since the resulting application contains
portions of the GPL'd work), and thus the GPL would apply to the whole.
I'm not sure the linking issue has been tried in court but I do think that
the previous issue has been successfully argued.

If on the other hand you have something a bit more modular, where the GPL'd
component (or conversely the proprietary component) was not included in
the firmware binary but was added/removed through some additional medium
(i.e. packages from a cd-rom or download site), then you'd have a pretty
strong argument for the "mere aggregation" status.  Possibly also if you
could show that the resulting firmware image was more like a medium for
distribution (i.e. tarball or disk image) rather than software, but that's
a really slippery slope and I don't know how well received that would be.


	sean

Re: GPLv2 for cifs-utils existing?

[Jeff Layton]

On Fri, 2 Sep 2011 08:45:35 +0200 (CEST)
brennersimon-KvP5wT2u2U0@public.gmane.org wrote:

> > Can you clarify why you'd like to see it as GPLv2?
> 
> At the moment, I'm just trying to learn and understand more about the GPLv3. So for several Linux programs I've been seeing what licence they've got. I've heard that GPLv3 is quite virulent. That could prevent a manufacturer (say of routers, receivers or similar things) from using cifs-utils if he didn't want to be all of his code opened. Is that right?

(re-cc'ing linux-cifs and Jeremy who is better versed in this sort of
thing than I am)

That's nonsense. It's certainly fine to ship GPLv3 software alongside
closed source code. You'll need to provide source for the GPL'ed parts
of course, but providing a set of self-contained GPLv3 programs
shouldn't force a vendor to open anything else.

The problems that you describe typically come in with linking GPL
libraries against closed source code, which is a bit more murky. That
shouldn't be a problem with cifs-utils as it doesn't ship any libraries.

That said, I'm not a lawyer and you may want to consult yours before
doing anything.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>