Dmitry Kulagin | 12 Dec 16:34 2012
Picon

containers license issue

Hi Cafe,


I am faced with unpleasant problem. The lawyer of my company checked sources of containers package and found out that it refers to some GPL-library. 

Here is quote:
"The algorithm is derived from Jorg Arndt's FXT library" 
in file Data/IntMap/Base.hs

The problem is that FXT library is GPL and thus containers package can not be considered as BSD3. And it means that it can not be used in my case (closed source software).

Is this logic actually correct and containers should be considered as GPL?

The package is widely used by other packages and the only way I see right now is to fix sources to reimplement this functionality, which is not good option.

Thank you!


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vo Minh Thu | 12 Dec 16:47 2012
Picon

Re: containers license issue

2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
> Hi Cafe,
>
> I am faced with unpleasant problem. The lawyer of my company checked sources
> of containers package and found out that it refers to some GPL-library.
>
> Here is quote:
> "The algorithm is derived from Jorg Arndt's FXT library"
> in file Data/IntMap/Base.hs
>
> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.

GPL covers code, not algorithms.

Beside, you can use GPL in closed-source code. GPL forces you to make
the source available when you distribute the software, but if you
don't distribute the software, there is nothing wrong to use GPL and
not make your code available.

HTH, IANAL,
Thu
David Thomas | 12 Dec 17:00 2012
Picon

Re: containers license issue

Right. If either of the following hold, you should be able to carry on as you were (but double check with your lawyer):

1) The algorithm is borrowed but the code was not copied.  In this case, copyright doesn't cover it, and the GPL is inapplicable.  (Patents could conceivably be an issue, but no more so than if it was BSD code).

2) If you are not going to be distributing the code - either it is used for internal tools or in the backend of a networked service (which the GPL does not treat as distribution, as distinct from the AGPL).

If a sizable chunk of actual code was copied, then the containers package would have to be GPL, and if you are using the library and distribute programs built with it then those programs must be GPL as well.



On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
> Hi Cafe,
>
> I am faced with unpleasant problem. The lawyer of my company checked sources
> of containers package and found out that it refers to some GPL-library.
>
> Here is quote:
> "The algorithm is derived from Jorg Arndt's FXT library"
> in file Data/IntMap/Base.hs
>
> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.

GPL covers code, not algorithms.

Beside, you can use GPL in closed-source code. GPL forces you to make
the source available when you distribute the software, but if you
don't distribute the software, there is nothing wrong to use GPL and
not make your code available.

HTH, IANAL,
Thu

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Clark Gaebel | 12 Dec 17:19 2012
Picon
Picon

Re: containers license issue

I think this is a potential problem, but, obviously, IANAL. [1]

According to the GPL:

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

and

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

and of course

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).


I believe that this counts as "propagation" of the original work, since it would be considered "infringement under applicable copyright law". Now, the wording in the GPL is a bit confusing on this point. I'm not sure if propagation requires that the BSD3 that containers is licensed under must remain in force, or the GPL on which the which is derived must remain in force. Does anyone else have better luck interpreting this?

  - Clark

[1] Aside: Can we stop saying IANAL? Let's just all assume that, until proven otherwise, no one here is a lawyer.
[2] Required Reading: http://www.gnu.org/licenses/gpl.html


On Wed, Dec 12, 2012 at 11:00 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
>
> Right. If either of the following hold, you should be able to carry on as you were (but double check with your lawyer):
>
> 1) The algorithm is borrowed but the code was not copied.  In this case, copyright doesn't cover it, and the GPL is inapplicable.  (Patents could conceivably be an issue, but no more so than if it was BSD code).
>
> 2) If you are not going to be distributing the code - either it is used for internal tools or in the backend of a networked service (which the GPL does not treat as distribution, as distinct from the AGPL).
>
> If a sizable chunk of actual code was copied, then the containers package would have to be GPL, and if you are using the library and distribute programs built with it then those programs must be GPL as well.
>
>
>
> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
>>
>> 2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
>> > Hi Cafe,
>> >
>> > I am faced with unpleasant problem. The lawyer of my company checked sources
>> > of containers package and found out that it refers to some GPL-library.
>> >
>> > Here is quote:
>> > "The algorithm is derived from Jorg Arndt's FXT library"
>> > in file Data/IntMap/Base.hs
>> >
>> > The problem is that FXT library is GPL and thus containers package can not
>> > be considered as BSD3. And it means that it can not be used in my case
>> > (closed source software).
>> >
>> > Is this logic actually correct and containers should be considered as GPL?
>> >
>> > The package is widely used by other packages and the only way I see right
>> > now is to fix sources to reimplement this functionality, which is not good
>> > option.
>>
>> GPL covers code, not algorithms.
>>
>> Beside, you can use GPL in closed-source code. GPL forces you to make
>> the source available when you distribute the software, but if you
>> don't distribute the software, there is nothing wrong to use GPL and
>> not make your code available.
>>
>> HTH, IANAL,
>> Thu
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vo Minh Thu | 12 Dec 17:27 2012
Picon

Re: containers license issue

I'm not sure what your point is.

Re-implementing an algorithm is not a copyright infringement (nor is a
propagation of the original work). Algorithms are not covered by
copyright.

2012/12/12 Clark Gaebel <cgaebel <at> uwaterloo.ca>:
> I think this is a potential problem, but, obviously, IANAL. [1]
>
> According to the GPL:
>
> To “propagate” a work means to do anything with it that, without permission,
> would make you directly or secondarily liable for infringement under
> applicable copyright law, except executing it on a computer or modifying a
> private copy. Propagation includes copying, distribution (with or without
> modification), making available to the public, and in some countries other
> activities as well.
>
> and
>
> You may make, run and propagate covered works that you do not convey,
> without conditions so long as your license otherwise remains in force.
>
> and of course
>
> You may not propagate or modify a covered work except as expressly provided
> under this License. Any attempt otherwise to propagate or modify it is void,
> and will automatically terminate your rights under this License (including
> any patent licenses granted under the third paragraph of section 11).
>
>
> I believe that this counts as "propagation" of the original work, since it
> would be considered "infringement under applicable copyright law". Now, the
> wording in the GPL is a bit confusing on this point. I'm not sure if
> propagation requires that the BSD3 that containers is licensed under must
> remain in force, or the GPL on which the which is derived must remain in
> force. Does anyone else have better luck interpreting this?
>
>   - Clark
>
> [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
> proven otherwise, no one here is a lawyer.
> [2] Required Reading: http://www.gnu.org/licenses/gpl.html
>
>
> On Wed, Dec 12, 2012 at 11:00 AM, David Thomas <davidleothomas <at> gmail.com>
> wrote:
>>
>> Right. If either of the following hold, you should be able to carry on as
>> you were (but double check with your lawyer):
>>
>> 1) The algorithm is borrowed but the code was not copied.  In this case,
>> copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
>> conceivably be an issue, but no more so than if it was BSD code).
>>
>> 2) If you are not going to be distributing the code - either it is used
>> for internal tools or in the backend of a networked service (which the GPL
>> does not treat as distribution, as distinct from the AGPL).
>>
>> If a sizable chunk of actual code was copied, then the containers package
>> would have to be GPL, and if you are using the library and distribute
>> programs built with it then those programs must be GPL as well.
>>
>>
>>
>> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
>>>
>>> 2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
>>> > Hi Cafe,
>>> >
>>> > I am faced with unpleasant problem. The lawyer of my company checked
>>> > sources
>>> > of containers package and found out that it refers to some GPL-library.
>>> >
>>> > Here is quote:
>>> > "The algorithm is derived from Jorg Arndt's FXT library"
>>> > in file Data/IntMap/Base.hs
>>> >
>>> > The problem is that FXT library is GPL and thus containers package can
>>> > not
>>> > be considered as BSD3. And it means that it can not be used in my case
>>> > (closed source software).
>>> >
>>> > Is this logic actually correct and containers should be considered as
>>> > GPL?
>>> >
>>> > The package is widely used by other packages and the only way I see
>>> > right
>>> > now is to fix sources to reimplement this functionality, which is not
>>> > good
>>> > option.
>>>
>>> GPL covers code, not algorithms.
>>>
>>> Beside, you can use GPL in closed-source code. GPL forces you to make
>>> the source available when you distribute the software, but if you
>>> don't distribute the software, there is nothing wrong to use GPL and
>>> not make your code available.
>>>
>>> HTH, IANAL,
>>> Thu
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
Clark Gaebel | 12 Dec 17:29 2012
Picon
Picon

Re: containers license issue

It's not an algorithm. The source code of containers is derived from the source code of another library.

  - Clark


On Wed, Dec 12, 2012 at 11:27 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
I'm not sure what your point is.

Re-implementing an algorithm is not a copyright infringement (nor is a
propagation of the original work). Algorithms are not covered by
copyright.

2012/12/12 Clark Gaebel <cgaebel <at> uwaterloo.ca>:
> I think this is a potential problem, but, obviously, IANAL. [1]
>
> According to the GPL:
>
> To “propagate” a work means to do anything with it that, without permission,
> would make you directly or secondarily liable for infringement under
> applicable copyright law, except executing it on a computer or modifying a
> private copy. Propagation includes copying, distribution (with or without
> modification), making available to the public, and in some countries other
> activities as well.
>
> and
>
> You may make, run and propagate covered works that you do not convey,
> without conditions so long as your license otherwise remains in force.
>
> and of course
>
> You may not propagate or modify a covered work except as expressly provided
> under this License. Any attempt otherwise to propagate or modify it is void,
> and will automatically terminate your rights under this License (including
> any patent licenses granted under the third paragraph of section 11).
>
>
> I believe that this counts as "propagation" of the original work, since it
> would be considered "infringement under applicable copyright law". Now, the
> wording in the GPL is a bit confusing on this point. I'm not sure if
> propagation requires that the BSD3 that containers is licensed under must
> remain in force, or the GPL on which the which is derived must remain in
> force. Does anyone else have better luck interpreting this?
>
>   - Clark
>
> [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
> proven otherwise, no one here is a lawyer.
> [2] Required Reading: http://www.gnu.org/licenses/gpl.html
>
>
> On Wed, Dec 12, 2012 at 11:00 AM, David Thomas <davidleothomas <at> gmail.com>
> wrote:
>>
>> Right. If either of the following hold, you should be able to carry on as
>> you were (but double check with your lawyer):
>>
>> 1) The algorithm is borrowed but the code was not copied.  In this case,
>> copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
>> conceivably be an issue, but no more so than if it was BSD code).
>>
>> 2) If you are not going to be distributing the code - either it is used
>> for internal tools or in the backend of a networked service (which the GPL
>> does not treat as distribution, as distinct from the AGPL).
>>
>> If a sizable chunk of actual code was copied, then the containers package
>> would have to be GPL, and if you are using the library and distribute
>> programs built with it then those programs must be GPL as well.
>>
>>
>>
>> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
>>>
>>> 2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
>>> > Hi Cafe,
>>> >
>>> > I am faced with unpleasant problem. The lawyer of my company checked
>>> > sources
>>> > of containers package and found out that it refers to some GPL-library.
>>> >
>>> > Here is quote:
>>> > "The algorithm is derived from Jorg Arndt's FXT library"
>>> > in file Data/IntMap/Base.hs
>>> >
>>> > The problem is that FXT library is GPL and thus containers package can
>>> > not
>>> > be considered as BSD3. And it means that it can not be used in my case
>>> > (closed source software).
>>> >
>>> > Is this logic actually correct and containers should be considered as
>>> > GPL?
>>> >
>>> > The package is widely used by other packages and the only way I see
>>> > right
>>> > now is to fix sources to reimplement this functionality, which is not
>>> > good
>>> > option.
>>>
>>> GPL covers code, not algorithms.
>>>
>>> Beside, you can use GPL in closed-source code. GPL forces you to make
>>> the source available when you distribute the software, but if you
>>> don't distribute the software, there is nothing wrong to use GPL and
>>> not make your code available.
>>>
>>> HTH, IANAL,
>>> Thu
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 12 Dec 17:33 2012
Picon

Re: containers license issue

Ah, that's more than we'd been told.  If that is the case, then containers is in violation of the GPL (unless they got permission to copy that code, separately), and either must obtain such permission, be relicensed,  remove/replace that code.



On Wed, Dec 12, 2012 at 8:29 AM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
It's not an algorithm. The source code of containers is derived from the source code of another library.

  - Clark


On Wed, Dec 12, 2012 at 11:27 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
I'm not sure what your point is.

Re-implementing an algorithm is not a copyright infringement (nor is a
propagation of the original work). Algorithms are not covered by
copyright.

2012/12/12 Clark Gaebel <cgaebel <at> uwaterloo.ca>:
> I think this is a potential problem, but, obviously, IANAL. [1]
>
> According to the GPL:
>
> To “propagate” a work means to do anything with it that, without permission,
> would make you directly or secondarily liable for infringement under
> applicable copyright law, except executing it on a computer or modifying a
> private copy. Propagation includes copying, distribution (with or without
> modification), making available to the public, and in some countries other
> activities as well.
>
> and
>
> You may make, run and propagate covered works that you do not convey,
> without conditions so long as your license otherwise remains in force.
>
> and of course
>
> You may not propagate or modify a covered work except as expressly provided
> under this License. Any attempt otherwise to propagate or modify it is void,
> and will automatically terminate your rights under this License (including
> any patent licenses granted under the third paragraph of section 11).
>
>
> I believe that this counts as "propagation" of the original work, since it
> would be considered "infringement under applicable copyright law". Now, the
> wording in the GPL is a bit confusing on this point. I'm not sure if
> propagation requires that the BSD3 that containers is licensed under must
> remain in force, or the GPL on which the which is derived must remain in
> force. Does anyone else have better luck interpreting this?
>
>   - Clark
>
> [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
> proven otherwise, no one here is a lawyer.
> [2] Required Reading: http://www.gnu.org/licenses/gpl.html
>
>
> On Wed, Dec 12, 2012 at 11:00 AM, David Thomas <davidleothomas <at> gmail.com>
> wrote:
>>
>> Right. If either of the following hold, you should be able to carry on as
>> you were (but double check with your lawyer):
>>
>> 1) The algorithm is borrowed but the code was not copied.  In this case,
>> copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
>> conceivably be an issue, but no more so than if it was BSD code).
>>
>> 2) If you are not going to be distributing the code - either it is used
>> for internal tools or in the backend of a networked service (which the GPL
>> does not treat as distribution, as distinct from the AGPL).
>>
>> If a sizable chunk of actual code was copied, then the containers package
>> would have to be GPL, and if you are using the library and distribute
>> programs built with it then those programs must be GPL as well.
>>
>>
>>
>> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu <noteed <at> gmail.com> wrote:
>>>
>>> 2012/12/12 Dmitry Kulagin <dmitry.kulagin <at> gmail.com>:
>>> > Hi Cafe,
>>> >
>>> > I am faced with unpleasant problem. The lawyer of my company checked
>>> > sources
>>> > of containers package and found out that it refers to some GPL-library.
>>> >
>>> > Here is quote:
>>> > "The algorithm is derived from Jorg Arndt's FXT library"
>>> > in file Data/IntMap/Base.hs
>>> >
>>> > The problem is that FXT library is GPL and thus containers package can
>>> > not
>>> > be considered as BSD3. And it means that it can not be used in my case
>>> > (closed source software).
>>> >
>>> > Is this logic actually correct and containers should be considered as
>>> > GPL?
>>> >
>>> > The package is widely used by other packages and the only way I see
>>> > right
>>> > now is to fix sources to reimplement this functionality, which is not
>>> > good
>>> > option.
>>>
>>> GPL covers code, not algorithms.
>>>
>>> Beside, you can use GPL in closed-source code. GPL forces you to make
>>> the source available when you distribute the software, but if you
>>> don't distribute the software, there is nothing wrong to use GPL and
>>> not make your code available.
>>>
>>> HTH, IANAL,
>>> Thu
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Larsson | 12 Dec 17:37 2012
Picon

Re: containers license issue

2012/12/12 David Thomas <davidleothomas <at> gmail.com>:
> Ah, that's more than we'd been told.  If that is the case, then containers
> is in violation of the GPL (unless they got permission to copy that code,
> separately), and either must obtain such permission, be relicensed,
> remove/replace that code.

I think it's just a confusion of language, the "derived" algorithm
clashes uncomfortably with the lawyerly "derived work". They are not
used in the same sense.

Niklas
Clark Gaebel | 12 Dec 17:47 2012
Picon
Picon

Re: containers license issue

Just for reference:

In Data/IntMap/Base.hs

highestBitMask :: Nat -> Nat
highestBitMask x0
  = case (x0 .|. shiftRL x0 1) of
     x1 -> case (x1 .|. shiftRL x1 2) of
      x2 -> case (x2 .|. shiftRL x2 4) of
       x3 -> case (x3 .|. shiftRL x3 8) of
        x4 -> case (x4 .|. shiftRL x4 16) of
#if !(defined(__GLASGOW_HASKELL__) && WORD_SIZE_IN_BITS==32)
         x5 -> case (x5 .|. shiftRL x5 32) of   -- for 64 bit platforms
#endif
          x6 -> (x6 `xor` (shiftRL x6 1))

In FXT bithigh.h:

static inline ulong highest_one(ulong x)
// Return word where only the highest bit in x is set.
// Return 0 if no bit is set.
{
#if defined  BITS_USE_ASM
    if ( 0==x )  return 0;
    x = asm_bsr(x);
    return  1UL<<x;
#else
    x = highest_one_01edge(x);
    return  x ^ (x>>1);
#endif  // BITS_USE_ASM
}

And in FXT bits/bithigh-edge.h:

static inline ulong highest_one_01edge(ulong x)
// Return word where all bits from (including) the
//   highest set bit to bit 0 are set.
// Return 0 if no bit is set.
//
// Feed the result into bit_count() to get
//   the index of the highest bit set.
{
#if defined  BITS_USE_ASM

    if ( 0==x )  return 0;
    x = asm_bsr(x);
    return  (2UL<<x) - 1;

#else  // BITS_USE_ASM

    x |= x>>1;
    x |= x>>2;
    x |= x>>4;
    x |= x>>8;
    x |= x>>16;
#if  BITS_PER_LONG >= 64
    x |= x>>32;
#endif
    return  x;
#endif  // BITS_USE_ASM
}

=====

However... I think the easy solution for this is to just find this in http://graphics.stanford.edu/~seander/bithacks.html, and cite it instead. I looked briefly and couldn't find it, but I'm almost sure it's in there.

  - Clark


On Wed, Dec 12, 2012 at 11:37 AM, Niklas Larsson <metaniklas <at> gmail.com> wrote:
2012/12/12 David Thomas <davidleothomas <at> gmail.com>:
> Ah, that's more than we'd been told.  If that is the case, then containers
> is in violation of the GPL (unless they got permission to copy that code,
> separately), and either must obtain such permission, be relicensed,
> remove/replace that code.

I think it's just a confusion of language, the "derived" algorithm
clashes uncomfortably with the lawyerly "derived work". They are not
used in the same sense.

Niklas

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mike Meyer | 13 Dec 10:05 2012
Face

Re: containers license issue

On Wed, 12 Dec 2012 17:27:03 +0100
Vo Minh Thu <noteed <at> gmail.com> wrote:

> I'm not sure what your point is.
> 
> Re-implementing an algorithm is not a copyright infringement (nor is a
> propagation of the original work). Algorithms are not covered by
> copyright.

While algorithms aren't covered by copyright, *code* is. A translation
of a copyrighted work into another language is considered a derived
work of the original. If not, then simply translating a source program
into some computer's binary language would release it from copyright,
and it could be freely distributed. That would pretty much kill the
GPL.

Once someone has read an algorithm in some programming language, it
opens the question of whether they are copying the algorithm or the
code if they produce a copy of the algorithm. The generally accepted
solution is the one taken here - a clean-room re-implementation by
people who haven't read the code (ok, sort of taken here).

It might be small enough to get by on a "fair use" clause. The "prior
art" and "obvious" exceptions stated on this thread are for patents,
and don't apply to copyright.

But that's all irrelevant. The reason company lawyers object to having
GPL'ed code in the company code base is that it opens them up to the
possibility of a lawsuit. That the original author said it was derived
from GPL'ed code was sufficient to cause at least one lawyer to
believe that a case existed.

	<mike
--

-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Niklas Larsson | 12 Dec 17:30 2012
Picon

Re: containers license issue

> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.
>

There is no copied code from FXT (which can be said with certainty as
FXT is a C library), hence the there can be copyright issue.

Niklas
Niklas Larsson | 12 Dec 17:33 2012
Picon

Re: containers license issue

2012/12/12 Niklas Larsson <metaniklas <at> gmail.com>:
>> The problem is that FXT library is GPL and thus containers package can not
>> be considered as BSD3. And it means that it can not be used in my case
>> (closed source software).
>>
>> Is this logic actually correct and containers should be considered as GPL?
>>
>> The package is widely used by other packages and the only way I see right
>> now is to fix sources to reimplement this functionality, which is not good
>> option.
>>
>
> There is no copied code from FXT (which can be said with certainty as
> FXT is a C library), hence the there can be copyright issue.
>
> Niklas

Gah, I should proofread! NO copyright issue, of course.
Mike Meyer | 12 Dec 18:23 2012

Re: containers license issue

Niklas Larsson <metaniklas <at> gmail.com> wrote:
>2012/12/12 Niklas Larsson <metaniklas <at> gmail.com>:
>>
>> There is no copied code from FXT (which can be said with certainty as
>> FXT is a C library), hence the there can be copyright issue.
>Gah, I should proofread! NO copyright issue, of course.

Um, no. Copyright *includes* translations. A translated copy of a work is based on the original and
requires copyright permissions. This makes it a modified work according to the definitions in the GPL.

You're all thinking about this as if logic and the law had something in common. The relevant question isn't 
whether or not the GPL applies, but whether or not a case can be made that the GPL should apply. Clearly, that
case can be made, so if you include the containers code without treating it as GPL'ed, you risk winding up in
court. I suspect that's what the lawyer is really trying to avoid, as it would mean they'd actually have to work.
--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
Clark Gaebel | 12 Dec 19:40 2012
Picon
Picon

Re: containers license issue

I just did a quick derivation from http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get the highest bit mask, and did not reference FXT nor the containers implementation. Here is my code:

highestBitMask :: Word64 -> Word64
highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
                        x3 = x2 .|. x2 `shiftR` 2
                        x4 = x3 .|. x3 `shiftR` 4
                        x5 = x4 .|. x4 `shiftR` 8
                        x6 = x5 .|. x5 `shiftR` 16
                        x7 = x6 .|. x6 `shiftR` 32
                     in x7 `xor` (x7 `shiftR` 1)

This code is hereby released into the public domain. Problem solved.

  - Clark


On Wed, Dec 12, 2012 at 12:23 PM, Mike Meyer <mwm <at> mired.org> wrote:
Niklas Larsson <metaniklas <at> gmail.com> wrote:
>2012/12/12 Niklas Larsson <metaniklas <at> gmail.com>:
>>
>> There is no copied code from FXT (which can be said with certainty as
>> FXT is a C library), hence the there can be copyright issue.
>Gah, I should proofread! NO copyright issue, of course.

Um, no. Copyright *includes* translations. A translated copy of a work is based on the original and requires copyright permissions. This makes it a modified work according to the definitions in the GPL.

You're all thinking about this as if logic and the law had something in common. The relevant question isn't  whether or not the GPL applies, but whether or not a case can be made that the GPL should apply. Clearly, that case can be made, so if you include the containers code without treating it as GPL'ed, you risk winding up in court. I suspect that's what the lawyer is really trying to avoid, as it would mean they'd actually have to work.
--
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johan Tibell | 12 Dec 19:54 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
> I just did a quick derivation from
> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
> the highest bit mask, and did not reference FXT nor the containers
> implementation. Here is my code:
>
> highestBitMask :: Word64 -> Word64
> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>                         x3 = x2 .|. x2 `shiftR` 2
>                         x4 = x3 .|. x3 `shiftR` 4
>                         x5 = x4 .|. x4 `shiftR` 8
>                         x6 = x5 .|. x5 `shiftR` 16
>                         x7 = x6 .|. x6 `shiftR` 32
>                      in x7 `xor` (x7 `shiftR` 1)
>
> This code is hereby released into the public domain. Problem solved.

I will integrate this into containers later today.
Vo Minh Thu | 12 Dec 21:06 2012
Picon

Re: containers license issue

2012/12/12 Johan Tibell <johan.tibell <at> gmail.com>:
> On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
>> the highest bit mask, and did not reference FXT nor the containers
>> implementation. Here is my code:
>>
>> highestBitMask :: Word64 -> Word64
>> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>>                         x3 = x2 .|. x2 `shiftR` 2
>>                         x4 = x3 .|. x3 `shiftR` 4
>>                         x5 = x4 .|. x4 `shiftR` 8
>>                         x6 = x5 .|. x5 `shiftR` 16
>>                         x7 = x6 .|. x6 `shiftR` 32
>>                      in x7 `xor` (x7 `shiftR` 1)
>>
>> This code is hereby released into the public domain. Problem solved.
>
> I will integrate this into containers later today.

Note that I think the current implementation use a series of case
expression instead of a let binding, possibly to force the evaluation.
Clark Gaebel | 12 Dec 21:09 2012
Picon
Picon

Re: containers license issue

Possibly. I tend to trust GHC's strictness analyzer until proven otherwise, though. Feel free to optimize as necessary.

  - Clark


On Wed, Dec 12, 2012 at 3:06 PM, Vo Minh Thu <noteed <at> gmail.com> wrote:
2012/12/12 Johan Tibell <johan.tibell <at> gmail.com>:
> On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
>> the highest bit mask, and did not reference FXT nor the containers
>> implementation. Here is my code:
>>
>> highestBitMask :: Word64 -> Word64
>> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>>                         x3 = x2 .|. x2 `shiftR` 2
>>                         x4 = x3 .|. x3 `shiftR` 4
>>                         x5 = x4 .|. x4 `shiftR` 8
>>                         x6 = x5 .|. x5 `shiftR` 16
>>                         x7 = x6 .|. x6 `shiftR` 32
>>                      in x7 `xor` (x7 `shiftR` 1)
>>
>> This code is hereby released into the public domain. Problem solved.
>
> I will integrate this into containers later today.

Note that I think the current implementation use a series of case
expression instead of a let binding, possibly to force the evaluation.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johan Tibell | 12 Dec 23:11 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 12:09 PM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
> Possibly. I tend to trust GHC's strictness analyzer until proven otherwise,
> though. Feel free to optimize as necessary.

The GHC strictness analyzer will have no troubles with this. Since the
return type is Word64, there's no place for thunks to hide as Word64
is defined as:

    data Word64 = W64# Word#  -- on 64-bit archs

or some such. Since Word# is unlifted it cannot be a pointer (to a thunk).
Dmitry Kulagin | 12 Dec 21:18 2012
Picon

Re: containers license issue

Clark, Johan, thank you! That looks like perfect solution to the problem.

12.12.2012, в 22:56, Johan Tibell <johan.tibell <at> gmail.com> написал(а):

> On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel <cgaebel <at> uwaterloo.ca> wrote:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
>> the highest bit mask, and did not reference FXT nor the containers
>> implementation. Here is my code:
>>
>> highestBitMask :: Word64 -> Word64
>> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>>                        x3 = x2 .|. x2 `shiftR` 2
>>                        x4 = x3 .|. x3 `shiftR` 4
>>                        x5 = x4 .|. x4 `shiftR` 8
>>                        x6 = x5 .|. x5 `shiftR` 16
>>                        x7 = x6 .|. x6 `shiftR` 32
>>                     in x7 `xor` (x7 `shiftR` 1)
>>
>> This code is hereby released into the public domain. Problem solved.
>
> I will integrate this into containers later today.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johan Tibell | 13 Dec 02:15 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
<dmitry.kulagin <at> gmail.com> wrote:
> Clark, Johan, thank you! That looks like perfect solution to the problem.

Clean-room reimplementation merged and released as 0.5.2.0.
Felipe Almeida Lessa | 13 Dec 02:24 2012
Picon

Re: containers license issue

Crisis averted!

=)

On Wed, Dec 12, 2012 at 11:15 PM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
> <dmitry.kulagin <at> gmail.com> wrote:
>> Clark, Johan, thank you! That looks like perfect solution to the problem.
>
> Clean-room reimplementation merged and released as 0.5.2.0.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

--

-- 
Felipe.
Michael Orlitzky | 13 Dec 02:38 2012

Re: containers license issue

On 12/12/2012 08:15 PM, Johan Tibell wrote:
> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
> <dmitry.kulagin <at> gmail.com> wrote:
>> Clark, Johan, thank you! That looks like perfect solution to the problem.
> 
> Clean-room reimplementation merged and released as 0.5.2.0.
> 

Not even a little bit clean-room: he posted the source code that he was
going to reimplement like two hours earlier, and had obviously read it.

Did anyone consider just asking the original author if he cares?
Johan Tibell | 13 Dec 02:53 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 5:38 PM, Michael Orlitzky <michael <at> orlitzky.com> wrote:
> On 12/12/2012 08:15 PM, Johan Tibell wrote:
>> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
>> <dmitry.kulagin <at> gmail.com> wrote:
>>> Clark, Johan, thank you! That looks like perfect solution to the problem.
>>
>> Clean-room reimplementation merged and released as 0.5.2.0.
>>
>
> Not even a little bit clean-room: he posted the source code that he was
> going to reimplement like two hours earlier, and had obviously read it.

Clean-room was clearly a bit over enthusiastic. He said he didn't use
the other code as a reference but instead the bithacks reference,
which is public domain. I'm comfortable enough with this. I wasn't
particularly worried about the prior implementation either, as it
don't think (as a non-lawyer) that it will hold up as copyrightable in
court due to its trivial nature and the presence of prior art (this is
a standard bit-twiddling algorithm).
Clark Gaebel | 13 Dec 04:45 2012
Picon
Picon

Re: containers license issue

This is a silly issue.

I'd be willing to testify in court that that implementation was clean. If such an issue were to ever come up, shoot me an email and I'll be there. Until then, you're going to have to take my word for it. And honestly, we do that with every bit of code we use every day. Do we really have anything except the author's word that he hasn't copied some GPL code?

And, if it ever does come up and a real clean-room implementation (with someone who's never seen FXT nor this thread) needs to be done, let me know about that, too. I know lots of kids who'd jump at the chance for a practice interview question.

I'll even do that now if Johan wants, but I doubt it's that useful. There are bigger fish in the sea, and you're chasing a minnow.

Regards,
  - Clark


On Wed, Dec 12, 2012 at 8:53 PM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
On Wed, Dec 12, 2012 at 5:38 PM, Michael Orlitzky <michael <at> orlitzky.com> wrote:
> On 12/12/2012 08:15 PM, Johan Tibell wrote:
>> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
>> <dmitry.kulagin <at> gmail.com> wrote:
>>> Clark, Johan, thank you! That looks like perfect solution to the problem.
>>
>> Clean-room reimplementation merged and released as 0.5.2.0.
>>
>
> Not even a little bit clean-room: he posted the source code that he was
> going to reimplement like two hours earlier, and had obviously read it.

Clean-room was clearly a bit over enthusiastic. He said he didn't use
the other code as a reference but instead the bithacks reference,
which is public domain. I'm comfortable enough with this. I wasn't
particularly worried about the prior implementation either, as it
don't think (as a non-lawyer) that it will hold up as copyrightable in
court due to its trivial nature and the presence of prior art (this is
a standard bit-twiddling algorithm).

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Clint Adams | 13 Dec 04:57 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 10:45:48PM -0500, Clark Gaebel wrote:
> This is a silly issue.

It certainly seems to be.  If it were serious, I'd like to think
that people would be attempting to get actual legal advice
instead of spouting anti-copyleft FUD.
Chris Smith | 13 Dec 08:11 2012
Picon

Re: containers license issue

"Clint Adams" <clint <at> debian.org> wrote:
>
> On Wed, Dec 12, 2012 at 10:45:48PM -0500, Clark Gaebel wrote:
> > This is a silly issue.
>
> It certainly seems to be.  If it were serious, I'd like to think
> that people would be attempting to get actual legal advice
> instead of spouting anti-copyleft FUD.

Well, actual legal advice comes from actual lawyers, who often want actual money.

I'm interested in what you saw as "anti-copyleft FUD" though.  That the code might be subject to the GPL and that caused problems?  That's the only thing that did come from a lawyer.  And it's really the only negative thing I saw about the GPL in this thread.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Clint Adams | 13 Dec 18:34 2012
Picon

Re: containers license issue

On Wed, Dec 12, 2012 at 11:11:28PM -0800, Chris Smith wrote:
> Well, actual legal advice comes from actual lawyers, who often want actual
> money.

That's true.  However, haskell.org's fiscal sponsor receives pro bono
legal services.

> I'm interested in what you saw as "anti-copyleft FUD" though.  That the
> code might be subject to the GPL and that caused problems?  That's the only
> thing that did come from a lawyer.  And it's really the only negative thing
> I saw about the GPL in this thread.

I may have been conflating threads, though the response to what I assume
was just a lawyer asking a question seems excessive too.
Christopher Howard | 13 Dec 19:45 2012

Re: containers license issue

On 12/13/2012 08:34 AM, Clint Adams wrote:
> On Wed, Dec 12, 2012 at 11:11:28PM -0800, Chris Smith wrote:
> 
> That's true.  However, haskell.org's fiscal sponsor receives pro bono
> legal services.
> 
> 
> I may have been conflating threads, though the response to what I assume
> was just a lawyer asking a question seems excessive too.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

Just thought I'd mention: It is possible for anyone involved in a FOSS
project to get pro bono legal advice from the SFLC, from actual lawyers
who are highly familiar with the legal aspects of FOSS licenses:

https://www.softwarefreedom.org

quote:
--------
If you are involved in a Free, Libre and Open Source Software (FLOSS)
project in need of legal advice, please email help <at> softwarefreedom.org.
When seeking legal advice, please use only this address to contact us
(unless you are already a client).
--------

I'm not sure if they are willing to help those who are trying to /avoid/
making a free software product, but they would likely be willing to
answer any generic questions about applicability of the GPLs, derived
works, etc.

--

-- 
frigidcode.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Clark Gaebel | 13 Dec 20:17 2012
Picon
Picon

Re: containers license issue

I didn't even know that site existed. Let's add them to the thread!

softwarefreedom.org, what are your opinions on what was discussed in this thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-December/105193.html

Is there anything that we, as a community, should know about? Should we proceed differently?

Thanks,
  - Clark

(you might need to sign up to haskell-cafe to post. maybe use a different account?)

On Thu, Dec 13, 2012 at 1:45 PM, Christopher Howard <christopher.howard <at> frigidcode.com> wrote:
On 12/13/2012 08:34 AM, Clint Adams wrote:
> On Wed, Dec 12, 2012 at 11:11:28PM -0800, Chris Smith wrote:
>
> That's true.  However, haskell.org's fiscal sponsor receives pro bono
> legal services.
>
>
> I may have been conflating threads, though the response to what I assume
> was just a lawyer asking a question seems excessive too.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Just thought I'd mention: It is possible for anyone involved in a FOSS
project to get pro bono legal advice from the SFLC, from actual lawyers
who are highly familiar with the legal aspects of FOSS licenses:

https://www.softwarefreedom.org

quote:
--------
If you are involved in a Free, Libre and Open Source Software (FLOSS)
project in need of legal advice, please email help <at> softwarefreedom.org.
When seeking legal advice, please use only this address to contact us
(unless you are already a client).
--------

I'm not sure if they are willing to help those who are trying to /avoid/
making a free software product, but they would likely be willing to
answer any generic questions about applicability of the GPLs, derived
works, etc.

--
frigidcode.com


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Richard O'Keefe | 14 Dec 03:54 2012
Picon

Re: containers license issue


On 14/12/2012, at 7:45 AM, Christopher Howard wrote:
> Just thought I'd mention: It is possible for anyone involved in a FOSS
> project to get pro bono legal advice from the SFLC, from actual lawyers
> who are highly familiar with the legal aspects of FOSS licenses:
> 
> https://www.softwarefreedom.org

Intimately familiar with New Zealand law, are they?
Christopher Howard | 14 Dec 04:44 2012

Re: containers license issue

On 12/13/2012 05:54 PM, Richard O'Keefe wrote:
> 
> On 14/12/2012, at 7:45 AM, Christopher Howard wrote:
> 
> Intimately familiar with New Zealand law, are they?
> 

I couldn't say anything about that, specifically. However, SFLC has an
international outreach. From 2011 SFLC news:

quote:
--------
We are proud to announce a new position at the Software Freedom Law
Center: Director of International Programs. Over the past few years SFLC
has become an increasingly International organization, working with the
European Commission, launching SFLC India, and consulting with
governments around the world on issues of free software licensing,
policy, and use. Mishi Choudhary, counsel at SFLC and head of SFLC
India, has always been at the heart of this work so it is only fitting
that she is stepping up to fill the new position. Congratulations to Ms.
Choudhary and we all look forward to a stronger international presence
ahead.
-----

--

-- 
frigidcode.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ketil Malde | 15 Dec 14:04 2012

Re: containers license issue


Clark Gaebel <cgaebel <at> uwaterloo.ca> writes:

> I just did a quick derivation from
> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 

A copyrighted work, you say?

> to get the highest bit mask, and did not reference FXT nor the containers
> implementation. Here is my code:

If copyright follows reimplementations of algorithms from other programs
(because they are considered "translations" of that program), then
surely it must also follow reimplementation from copyrighted
documentation?

I think this is wrong, copyright does not cover algorithms, and reverse
engineering is not literary translation.  The implications of anything
else would be draconian, simply documenting a program would be a breach
of its copyright, for instance, and Tanenbaum would hold the copyright
to Linux.  But in a court of law, anything is possible.

-k
Ketil Malde | 15 Dec 14:18 2012

Re: containers license issue


Ketil Malde <ketil <at> malde.org> writes:

>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 

> A copyrighted work, you say?

Whoops, public domain, according to itself.  Of course, there's no way
to tell if the author read similar copyrighted programs, but maybe
you'll get off easier from claimin the infringement was not wilful?

(BTW, the concept Public Domain isn't recognized in some jurisdictions)

-k
Mike Meyer | 15 Dec 17:29 2012

Re: containers license issue

Ketil Malde <ketil <at> malde.org> wrote:
>Clark Gaebel <cgaebel <at> uwaterloo.ca> writes:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 
>A copyrighted work, you say?

The work is copyrighted, the snippets are placed in the placed in the public domain. This is old hat - you can
copyright a collection of non-copyrightable objects.
>I think this is wrong, copyright does not cover algorithms, and reverse
>engineering is not literary translation.

As it's commonly understood, reverse engineering doesn't involve looking at the code. That's why it's
called "reverse engineering" instead of "copying." If  you never had access to the code, you couldn't have
copied it. Of course, you can't produce a literary translation of it, either.

>The implications of anything else would be draconian

Calling the current state of copyright law in the US draconian might be going a little far. But only a little.

>simply documenting a program would be a breach of its copyright

Documenting code has run into copyright issue before. That's why *both* volumes of the Lion's book were
pulled from publication. Documenting codes behavior as a black box or how you use it isn't a problem. If you
say "function F finds the highest one it in it's argument" or  "call f(x) to find the highest one bit in x" and I
then write a function f that behaves that way, there can't have been a copyright violation, because I never
saw the source to f. If you *give* me that source, and I translate the code to another language, then I've
created a derived work, which means copyright law applies. If you give me the source to f, and I write a
function that does the same thing - then I may or may not have copied it. This means I *could* wind up in court
over the thing, which is exactly the poss
 ibility that the lawyer is trying to avoid.

>Tanenbaum would hold the copyright to Linux.

Only if Tanenbaum documented the internal behavior of Linux before it was written.

--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
Niklas Larsson | 15 Dec 17:49 2012
Picon

Re: containers license issue

2012/12/15 Mike Meyer <mwm <at> mired.org>:
> Only if Tanenbaum documented the internal behavior of Linux before it was written.

Tannenbaum wrote Minix, the operating system that Linus used (and
hacked on) before he did Linux. Minix contained lots of features that
was reimplemented in Linux.

Same thing with Stallman, do you think he never saw the Unix sources?

Niklas
Mike Meyer | 15 Dec 18:42 2012

Re: containers license issue

Niklas Larsson <metaniklas <at> gmail.com> wrote:
>2012/12/15 Mike Meyer <mwm <at> mired.org>:
>> Only if Tanenbaum documented the internal behavior of Linux before it
>was written.
>Tannenbaum wrote Minix, the operating system that Linus used (and
>hacked on) before he did Linux. Minix contained lots of features that
>was reimplemented in Linux.

Ah, Minix isn't documentation.  And it has a radically different architecture than either Linux or Unix
(which it copied features from). That makes a successful lawsuit unlikely should Tanenbaum pursue one -
but you can't say for certain until after a court rules on it.  Which is the bottom line in such cases: if the
copyright holder doesn't care, it'll never go to court, so there isn't an infringement. 

>Same thing with Stallman, do you think he never saw the Unix sources? 

Did he ever write anything that was copied from Unix? The Hurd used a completely different architecture
than Unix.  Emacs predated Unix.  By the time he got around to writing a c compiler, there were more from
people other than AT&T than from AT&T. And gcc drew more from the lisp community than from the Unix
compilers. 
--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
Ketil Malde | 17 Dec 09:38 2012

Re: containers license issue


Mike Meyer <mwm <at> mired.org> writes:

> Niklas Larsson <metaniklas <at> gmail.com> wrote:
>>2012/12/15 Mike Meyer <mwm <at> mired.org>:
>>> Only if Tanenbaum documented the internal behavior of Linux before
>>> it was written.

>>Tannenbaum wrote Minix, the operating system that Linus used (and
>>hacked on) before he did Linux. Minix contained lots of features that
>>was reimplemented in Linux.

> Ah, Minix isn't documentation.  And it has a radically different
> architecture

The point is that Linux read the source code to Minix before
implementing similar things - quite likely using the same algorithms,
for instance.  So if containers is a "translation" of FXT, then surely
Linux is a "translation" of Minix.

> That makes a successful lawsuit unlikely 

The point of the point is that neither of these are translations of
literary works, there is no precedence for considering them as such, and
that reading somebody's work (whether literary or source code) before
writing one's own does not imply that the 'somebody' will hold any
rights to the subsequent work.

"Translations" in software is what compilers do, not reimplementing
specific algorithms.

> it'll never go to court, so there isn't an infringement.  

Wot?

-k
Chris Smith | 17 Dec 11:00 2012
Picon

Re: containers license issue

"Ketil Malde" <ketil <at> malde.org> wrote:
> The point of the point is that neither of these are translations of
> literary works, there is no precedence for considering them as such, and
> that reading somebody's work (whether literary or source code) before
> writing one's own does not imply that the 'somebody' will hold any
> rights to the subsequent work.

So IANAL, but I do have an amateur interest in copyright law.  The debate over the word "translation" is completely irrelevant.  The important point is whether it is a "derived work".  That phrase certainly includes more than mere translation.  For example, it includes writing fiction that's set in the same fantasy universe or HHS the same characters as another author's works.  It also includes making videos with someone else's music playing in the background. If you create a derived work, then the author of the original definitely has rights to it, regardless of whether it is a mere translation.  That's also why the word "derived" in a comment was particularly Dacey to the legal staff and probably caused them to overreact in this case.

The defense in the case of software is to say that the part that was copied was not a work of authorship in the sense that, say, a fiction character is.  This is generally not a hard case to win, since courts see computer software as dominated by its practical function.  But if you copied something that was clearly a matter of expression and not related to the function of the software, you could very well be creating a derived work over which the original author could assert control.

That said, I agree that in this particular case it's very unlikely that the original author could have won an infringement case.  I just balked a little at the statements about translation, which was really just an example.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mike Meyer | 17 Dec 16:30 2012

Re: containers license issue

Ketil Malde <ketil <at> malde.org> wrote:
>Mike Meyer <mwm <at> mired.org> writes:
>> Niklas Larsson <metaniklas <at> gmail.com> wrote:
>>>2012/12/15 Mike Meyer <mwm <at> mired.org>:
>>>> Only if Tanenbaum documented the internal behavior of Linux before
>>>> it was written.
>>>Tannenbaum wrote Minix, the operating system that Linus used (and
>>>hacked on) before he did Linux. Minix contained lots of features that
>>>was reimplemented in Linux.
>> Ah, Minix isn't documentation.  And it has a radically different
>> architecture
>The point is that Linux read the source code to Minix before
>implementing similar things - quite likely using the same algorithms,
>for instance.  So if containers is a "translation" of FXT, then surely
>Linux is a "translation" of Minix.

Since they are both C, the concept of "translation"  doesn't enter into that case at all.

I never said that containers was a translation of FXT. I said that translations are considered to be derived
work requiring permission to copy. This is deeply embedded in copyright law, and the GPL *depends* on it
working for software. Otherwise, a distribution of GPL' d software translated to another language (say
as asm from the compiler, or a linkable object, or even an executable) wouldn't be a derivative work and
could be distributed without having to obey the license.

The point is that containers being in haskell isn't a defense against copyright violation. It doesn't mean
that it *is* a translation, merely that it might be. That the author of containers said it was "derived"
from FXT opens the possibility that his version is actually GPL'ed, so using it opens up the possibility of
a lawsuit. It may not stand up in court, but the lawyer objecting is trying to avoid just that possibility.

>> That makes a successful lawsuit unlikely 
>The point of the point is that neither of these are translations of
>literary works, there is no precedence for considering them as such,

Actually, there *is* a precedent for considering them such. The clean-room implementations of the IBM PC
bios were done because a judge ruled that translating from asm to binary was an infringing copy.

If you have a precedent that translating from one programming language to another is *not* the creation of a
derived work, I'd be interested in hearing about it. Without such a precedent, then a case can be made that
such a translation is a derived work (and you're the only person I've ever heard claim otherwise) which
opens up the possibility of a lawsuit, which is what the problem is.

>and
>that reading somebody's work (whether literary or source code) before
>writing one's own does not imply that the 'somebody' will hold any
>rights to the subsequent work.

This is correct. Reading a copyrighted work does not prove that some subsequent creation is a copy of that
work.  It does, however, make it *possible* that such a work is a copy and needs the appropriate permissions.

>"Translations" in software is what compilers do, not reimplementing
>specific algorithms.

"Translation" in a copyright case is a term of law, and has *nothing* to do with the behavior of compilers
(other than the precedent that what a compiler does is considered a translation for copyright purposes).

Reimplementing an algorithm may or may not be a copyright violation. Depends on whether or not the
reimplementation involved creation of a work derived (in the legal sense) from the original. Access to
the original is required for that to happen. The two being in the same language is *not* required for that to
happen. Access to the original and working in the same language is *not* sufficient for that to happen.

>> it'll never go to court, so there isn't an infringement.  

Tannenbaum isn't going to sue Linus. So either he doesn't believe there is an infringement (I suspect this
is likely, as he has had access the source and would probably have at least said something if he thought
there was an infringement) or doesn't care enough to go to court. Until a judge tells Linus he's
infringing, he isn't.
--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
Amit Levy | 19 Dec 19:06 2012

Re: containers license issue


On Dec 17, 2012, at 10:30 AM, Mike Meyer <mwm <at> mired.org> wrote:

> Ketil Malde <ketil <at> malde.org> wrote:
>> Mike Meyer <mwm <at> mired.org> writes:
>>> Niklas Larsson <metaniklas <at> gmail.com> wrote:
>>>> 2012/12/15 Mike Meyer <mwm <at> mired.org>:
>>>>> Only if Tanenbaum documented the internal behavior of Linux before
>>>>> it was written.
>>>> Tannenbaum wrote Minix, the operating system that Linus used (and
>>>> hacked on) before he did Linux. Minix contained lots of features that
>>>> was reimplemented in Linux.
>>> Ah, Minix isn't documentation.  And it has a radically different
>>> architecture
>> The point is that Linux read the source code to Minix before
>> implementing similar things - quite likely using the same algorithms,
>> for instance.  So if containers is a "translation" of FXT, then surely
>> Linux is a "translation" of Minix.
> 
> Since they are both C, the concept of "translation"  doesn't enter into that case at all.
> 
> I never said that containers was a translation of FXT. I said that translations are considered to be
derived work requiring permission to copy. This is deeply embedded in copyright law, and the GPL
*depends* on it working for software. Otherwise, a distribution of GPL' d software translated to another
language (say as asm from the compiler, or a linkable object, or even an executable) wouldn't be a
derivative work and could be distributed without having to obey the license.
> 
> The point is that containers being in haskell isn't a defense against copyright violation. It doesn't
mean that it *is* a translation, merely that it might be. That the author of containers said it was
"derived" from FXT opens the possibility that his version is actually GPL'ed, so using it opens up the
possibility of a lawsuit. It may not stand up in court, but the lawyer objecting is trying to avoid just that possibility.
> 
>>> That makes a successful lawsuit unlikely 
>> The point of the point is that neither of these are translations of
>> literary works, there is no precedence for considering them as such,
> 
> Actually, there *is* a precedent for considering them such. The clean-room implementations of the IBM PC
bios were done because a judge ruled that translating from asm to binary was an infringing copy.
> 
> If you have a precedent that translating from one programming language to another is *not* the creation of
a derived work, I'd be interested in hearing about it. Without such a precedent, then a case can be made that
such a translation is a derived work (and you're the only person I've ever heard claim otherwise) which
opens up the possibility of a lawsuit, which is what the problem is.
> 
>> and
>> that reading somebody's work (whether literary or source code) before
>> writing one's own does not imply that the 'somebody' will hold any
>> rights to the subsequent work.
> 
> This is correct. Reading a copyrighted work does not prove that some subsequent creation is a copy of that
work.  It does, however, make it *possible* that such a work is a copy and needs the appropriate permissions.
> 
>> "Translations" in software is what compilers do, not reimplementing
>> specific algorithms.
> 
> "Translation" in a copyright case is a term of law, and has *nothing* to do with the behavior of compilers
(other than the precedent that what a compiler does is considered a translation for copyright purposes).
> 
> Reimplementing an algorithm may or may not be a copyright violation. Depends on whether or not the
reimplementation involved creation of a work derived (in the legal sense) from the original. Access to
the original is required for that to happen. The two being in the same language is *not* required for that to
happen. Access to the original and working in the same language is *not* sufficient for that to happen.
> 
>>> it'll never go to court, so there isn't an infringement.  
> 
> Tannenbaum isn't going to sue Linus. So either he doesn't believe there is an infringement (I suspect this
is likely, as he has had access the source and would probably have at least said something if he thought
there was an infringement) or doesn't care enough to go to court. Until a judge tells Linus he's
infringing, he isn't.

This is quite a digression from the topic of the thread, but it turns out Tennenbaum has actually stated
publicly that he does not consider Linux to be copied from Minix at all:

(from http://www.cs.vu.nl/~ast/brown/)

"MINIX had clearly had a huge influence on Linux in many ways, from the layout of the file system to the names
in the source tree, but I didn't think Linus had used any of my code. Linus also used MINIX as his development
platform initially, but there was nothing wrong with that. He asked if I objected to that and I said no, I
didn't, people were free to use it as they wished for noncommercial purposes. Later MINIX was released
under the Berkeley license, which freed it up for all purposes."

> -- 
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Attachment (smime.p7s): application/pkcs7-signature, 5836 bytes
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ketil Malde | 17 Dec 09:52 2012

Re: containers license issue


Mike Meyer <mwm <at> mired.org> writes:

> As it's commonly understood, reverse engineering doesn't involve
> looking at the code. 

I guess I should make it clear that I don't use it in the strict sense -
I would call that "clean-room reverse engineering".  (I'm not sure which
is the most "commonly understood" meaning, I think Wikipedia supports
both interpretations)

> That's why it's called "reverse engineering" instead of "copying." 

I mean the process of reimplementing specific functionality from another
system, with or without knowledge of implementation details.  I would
use "copying" to mean verbatim cut-and-pasting, which is something else.

In particular when copyright is concerned, I believe that verbatim
copying in many cases will require a license to the original work, but
merly examining the original work to make use of algorithms, tricks, and
structures from it will not.

I suspect there's nothing magical about source code, if I extract a
component (algorithm or data structure, say) from a program and use it
in my own program, I'm not convinced it matters if I extract it from
object code, source code, or documentation - they're all copyrighted
works, and could be interpreted as translations of the same work.  I
could be wrong about that, though.

-k
Mike Meyer | 17 Dec 17:57 2012

Re: containers license issue

On 12/17/12, Ketil Malde <ketil <at> malde.org> wrote:
>  I would use "copying" to mean verbatim cut-and-pasting, which is something else.

I feel I should point out that, while that's currently a common
definition of "copying", it's not the legal definition. Copyright law
predates the ability to mechanically create copies of a work. The
closest you could come was the printing press, which started with what
was at the time a handmade mirror image of the work you were going to
print copies of.

Back then, the only way to create a copy of a printed page (or
anything else that wasn't created with the express purpose of being
duplicated) was to read the original, and transcribe it into a copy.
There was no "cut-n-paste" or "copy command" - just reading and
creating another copy by hand. Changes made along the way that
depended on the original - adding illustrations or illuminations,
setting it to music, re-arranging it into a script for a play, or
translating it to another language - were all considered derived
works, and hence infringing.

IANAL, but I've been studying copyright law since before the US signed
the Berne treaty. Generally, copyright law in the US has been getting
stricter, not more permissive - largely because the only people who
cared were the large copyright holders. In general, new media brought
under the purview of copyright is treated as strictly as the law can
be interpreted.

In the US, most radio stations pay a license fee in order to play
music. Bars and restaurants (and even the Girl Scouts!) are required
to pay a license fee for public performances if they play live or
recorded music. If you buy media capable of recording music or video,
part of the cost is used to compensate the copyright holders of the
presumably infringing copies you're going to make onto them. If I took
a picture of my living room, I'd technically be in violation of a slew
of copyrights (images of the statuary on the mantelpiece, paintings
hanging on the wall, etc.) but chances are that nobody would care
unless I included images from a FOX television show.

Personally, I think this is silly, but it's the law.
Mike Meyer | 17 Dec 16:45 2012

Re: containers license issue

Ketil Malde <ketil <at> malde.org> wrote:
>In particular when copyright is concerned, I believe that verbatim
>copying in many cases will require a license to the original work, but
>merly examining the original work to make use of algorithms, tricks,
>and
>structures from it will not.

If you don't actually copy any of the text in the latter case, that would be correct. But there's an
incredible amount of grey between those two extremes of black and white, and it's possible that you've
unintentionally recreated significant bits of the original.

The Oracle/Google lawsuit was all about those shades of grey - some of the API's in Dalvik were implemented
by people who had read the Java sources. Oracle claimed as much as possible was derivative, Google that
none of it was. The judge ruled that some uses were infringing and some uses were not. This was a technically
literate judge - he ruled that one of the cases was non-infringing because he could trivially implement
the function in Java himself.

The lawyer who pointed out the possible infringement here isn't really worried about losing such a lawsuit
- there are lots of ways to deal with that short of actually releasing any sources they consider
proprietary. They want to avoid the lawsuit *at all*, as that will almost certainly be more expensive than
losing it. At least, that's what I hear from clients who ask me not to include GPL'ed software.

   <mike
--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
Clark Gaebel | 17 Dec 19:47 2012
Picon
Picon

Re: containers license issue

So I heard back from softwarefreedom.org, and they're looking for a representative from haskell.org to talk to them, as they want to avoid conflict-of-interests with other clients.

Does anyone with any "official status" want to talk to real lawyers about this issue, then let the list know of anything interesting that was said? Let me know.

  - Clark


On Mon, Dec 17, 2012 at 10:45 AM, Mike Meyer <mwm <at> mired.org> wrote:
Ketil Malde <ketil <at> malde.org> wrote:
>In particular when copyright is concerned, I believe that verbatim
>copying in many cases will require a license to the original work, but
>merly examining the original work to make use of algorithms, tricks,
>and
>structures from it will not.

If you don't actually copy any of the text in the latter case, that would be correct. But there's an incredible amount of grey between those two extremes of black and white, and it's possible that you've unintentionally recreated significant bits of the original.

The Oracle/Google lawsuit was all about those shades of grey - some of the API's in Dalvik were implemented by people who had read the Java sources. Oracle claimed as much as possible was derivative, Google that none of it was. The judge ruled that some uses were infringing and some uses were not. This was a technically literate judge - he ruled that one of the cases was non-infringing because he could trivially implement the function in Java himself.

The lawyer who pointed out the possible infringement here isn't really worried about losing such a lawsuit - there are lots of ways to deal with that short of actually releasing any sources they consider proprietary. They want to avoid the lawsuit *at all*, as that will almost certainly be more expensive than losing it. At least, that's what I hear from clients who ask me not to include GPL'ed software.

   <mike
--
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michael Orlitzky | 18 Dec 01:27 2012

Re: containers license issue

On 12/17/2012 01:47 PM, Clark Gaebel wrote:
> 
> Does anyone ... want to talk to real lawyers ...

No.

This is absurd. If anyone cares, email the original author and explain
the situation. Ask if he's cool with the reimplemented version. Chances
are he'll say "yeah," and we've just solved the problem like adults.
David Thomas | 12 Dec 17:42 2012
Picon

Re: containers license issue

This may be overconfident - how does copyright law deal with translations in literature?  Still, it certainly makes infringement less likely, and the earlier explicit statement that code was copied likely the result of confusion.

On Dec 12, 2012 8:33 AM, "Niklas Larsson" <metaniklas <at> gmail.com> wrote:
> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.
>

There is no copied code from FXT (which can be said with certainty as
FXT is a C library), hence the there can be copyright issue.

Niklas

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane