Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #160212 > unrolled thread

Strong Copyleft licenses other than the GNU GPL family.

Back to article view | Back to linux.debian.user

Contents

  Strong Copyleft licenses other than the GNU GPL family. Mario Castelán Castro  <marioxcc.MT@yandex.com> - 2015-11-05 00:40 +0100
    Re: Strong Copyleft licenses other than the GNU GPL family. Nicolas George <george@nsup.org> - 2015-11-05 10:30 +0100
      Re: Strong Copyleft licenses other than the GNU GPL family. Renaud (Ron) OLGIATI <renaud@olgiati-in-paraguay.org> - 2015-11-05 11:10 +0100
        Re: Strong Copyleft licenses other than the GNU GPL family. Nicolas George <george@nsup.org> - 2015-11-05 12:00 +0100
      Re: Strong Copyleft licenses other than the GNU GPL family. Mario Castelán Castro <marioxcc.MT@yandex.com> - 2015-11-05 23:40 +0100
        Re: Strong Copyleft licenses other than the GNU GPL family. Joel Rees <joel.rees@gmail.com> - 2015-11-06 20:50 +0100
      Re: Strong Copyleft licenses other than the GNU GPL family. Joel Rees <joel.rees@gmail.com> - 2015-11-06 21:10 +0100
        Re: Strong Copyleft licenses other than the GNU GPL family. Nicolas George <george@nsup.org> - 2015-11-13 16:40 +0100
          Re: Strong Copyleft licenses other than the GNU GPL family. Joel Rees <joel.rees@gmail.com> - 2015-11-14 01:40 +0100

#160212 — Strong Copyleft licenses other than the GNU GPL family.

Hello.

Apart from the GNU GPL GNU LGPL, GNU AGPL, and Affero GPL, are there 
other *strong Copyleft* licenses (note that this entails being a free 
software license) for software (this excludes the CC BY-SA family)?

I have checked some popular free software licenses like the Mozilla 
Public License 2.0, however, this license allows proprietary-licensed 
derived works, and therefore it is not a strong Copyleft license.

All other free software licenses I have checked so far are either 
permissive or have *weak* Copyleft.

By strong Copyleft I mean a free software license that requires 
"derivate works" (as determined by Copyright law) to be free software 
(as in freedom), including works that are derivatives by making use of 
the Copylefted work through an API.

Thanks in advance.

[toc] | [next] | [standalone]

#160217

[Multipart message — attachments visible in raw view] — view raw

Le quartidi 14 brumaire, an CCXXIV, Mario Castelán Castro a écrit :
> By strong Copyleft I mean a free software license that requires "derivate
> works" (as determined by Copyright law) to be free software (as in freedom),
> including works that are derivatives by making use of the Copylefted work
> through an API.

This kind of license, if it exists or if someone invents it, would have two
serious drawbacks. That may explain why you do not find one.

The firs drawback is that it would be incompatible with GPL code and
libraries, and even possibly LGPL. That means libraries made using that
license can not be used from GPL code or with GPL libraries. Basically,
there is logically room for only one widely-adopted copyleft license.

The second drawback is that it would probably have no legal standing.
Copyleft is based on copyright, and copyright controls distribution, nothing
else. In principle, it can not control API use, since there is no
distribution involved. In practice, you can argue that using an API requires
copying tiny bits of it in the calling program: function names, macro
expansion, etc. But this claim is weak: copyright requires originality, and
there is little room for originality in function names; and it is easy to
circumvent. The more restrictive you make your license, the stronger the
incentive to circumvent it.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#160218

On Thu, 5 Nov 2015 10:27:01 +0100
Nicolas George <george@nsup.org> wrote:

> Le quartidi 14 brumaire, an CCXXIV, Mario Castelán Castro a écrit :

Would a kind soul be good enough to explain to me how to get the header date to come out as it does here, in the French Republican calendar ?
 
Cheers,
 
Ron.
-- 
                         Rome wasn't burnt in a day.
                                    
                   -- http://www.olgiati-in-paraguay.org --
 

[toc] | [prev] | [next] | [standalone]

#160220

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 15 brumaire, an CCXXIV, Renaud OLGIATI a écrit :
> Would a kind soul be good enough to explain to me how to get the header
> date to come out as it does here, in the French Republican calendar ?

I use the combination of a specific parser-friendly date format configured
in Mutt with an autocommand script launched by Vim. Probably not easily
usable with your MUA.

Actually, I set this up more than twelve years ago, and I want to remove it
because it looks silly, especially during the sansculottides just before new
year. I have yet to find the tool that would fit my needs exactly: detect
the language of the quoted mail, adapt the attribution language accordingly,
and set the Vim spell check language too.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#160238

El 05/11/15 a las 03:27, Nicolas George escribió:
> Le quartidi 14 brumaire, an CCXXIV, Mario Castelán Castro a écrit :
>> By strong Copyleft I mean a free software license that requires "derivate
>> works" (as determined by Copyright law) to be free software (as in freedom),
>> including works that are derivatives by making use of the Copylefted work
>> through an API.
>
> This kind of license, if it exists or if someone invents it, would have two
> serious drawbacks. That may explain why you do not find one.

Thanks for replying.

I found the IBM public license. _Can somebody else point me to a license 
that is strong Copyleft other than the GNU GPL family?._

You are right regarding API usage itself. What I meant to say is 
*dynamic linking*. I am looking for a strong Copyleft licenses other 
than the GNU GPL, strong enough to apply Copyleft in case of dynamic 
linking (as far as Copyright law allows this provision, which there 
seems to be some dispute about, especially regarding Linux modules).

[toc] | [prev] | [next] | [standalone]

#160249

On Fri, Nov 6, 2015 at 7:37 AM, Mario Castelán Castro
<marioxcc.MT@yandex.com> wrote:
> El 05/11/15 a las 03:27, Nicolas George escribió:
>>
>> Le quartidi 14 brumaire, an CCXXIV, Mario Castelán Castro a écrit :
>>>
>>> By strong Copyleft I mean a free software license that requires "derivate
>>> works" (as determined by Copyright law) to be free software (as in
>>> freedom),
>>> including works that are derivatives by making use of the Copylefted work
>>> through an API.
>>
>>
>> This kind of license, if it exists or if someone invents it, would have
>> two
>> serious drawbacks. That may explain why you do not find one.
>
>
> Thanks for replying.
>
> I found the IBM public license. _Can somebody else point me to a license
> that is strong Copyleft other than the GNU GPL family?._
>
> You are right regarding API usage itself.

He's only sort-of-right, but, then

> What I meant to say is *dynamic
> linking*.

it appears that you at least partially recognize that.

> I am looking for a strong Copyleft licenses other than the GNU
> GPL, strong enough to apply Copyleft in case of dynamic linking (as far as
> Copyright law allows this provision, which there seems to be some dispute
> about, especially regarding Linux modules).
>

Have you read the gnu.org pages on license compatibility? And their
definitions of "free" and their own interpretations of the (GNU) GPL?

(Remember that wikipedia and such are less authoritative on this
subject than the gnu.org pages and the fsf.org pages. And if you need
more authoritative than that, you need a lawyer who understands these
questions. The opensource.org pages (OSI) are not more authoritative,
just a different point of view. And two points of view are still not
really enough, here. Not because RMS is wrong but because it takes all
sorts of people to keep this world functioning.)

And that list of true copyleft licenses on gnu.org, do they still have
it? Is it not useful for you for some reason that I am not seeing yet?

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

#160251

On Thu, Nov 5, 2015 at 6:27 PM, Nicolas George <george@nsup.org> wrote:
> Le quartidi 14 brumaire, an CCXXIV, Mario Castelán Castro a écrit :
>> By strong Copyleft I mean a free software license that requires "derivate
>> works" (as determined by Copyright law) to be free software (as in freedom),
>> including works that are derivatives by making use of the Copylefted work
>> through an API.
>
> This kind of license, if it exists or if someone invents it, would have two
> serious drawbacks. That may explain why you do not find one.
>
> The firs drawback is that it would be incompatible with GPL code and
> libraries, and even possibly LGPL. That means libraries made using that
> license can not be used from GPL code or with GPL libraries. Basically,
> there is logically room for only one widely-adopted copyleft license.

I'm curious as to your reasoning here.

> The second drawback is that it would probably have no legal standing.
> Copyleft is based on copyright, and copyright controls distribution, nothing
> else. In principle, it can not control API use, since there is no
> distribution involved. In practice, you can argue that using an API requires
> copying tiny bits of it in the calling program: function names, macro
> expansion, etc. But this claim is weak: copyright requires originality, and
> there is little room for originality in function names; and it is easy to
> circumvent. The more restrictive you make your license, the stronger the
> incentive to circumvent it.

I'm not really seeing your reasoning here, either.

> Regards,
>
> --
>   Nicolas George

I would disagree (rather strongly) with at least some of what you seem
to be saying, but I'm not really sure what you are intending to say
here.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

#160525

[Multipart message — attachments visible in raw view] — view raw

Le septidi 17 brumaire, an CCXXIV, Joel Rees a écrit :
> > The firs drawback is that it would be incompatible with GPL code and
> > libraries, and even possibly LGPL. That means libraries made using that
> > license can not be used from GPL code or with GPL libraries. Basically,
> > there is logically room for only one widely-adopted copyleft license.
> I'm curious as to your reasoning here.

Copyleft means: if your binary includes bits from my library, then it must
be distributed under the same license.

So, if the binary includes library_A that is under copyleft_license_A and
library_B that is under copyleft_license_B, the requirements can not be met
both.

> > The second drawback is that it would probably have no legal standing.
> > Copyleft is based on copyright, and copyright controls distribution, nothing
> > else. In principle, it can not control API use, since there is no
> > distribution involved. In practice, you can argue that using an API requires
> > copying tiny bits of it in the calling program: function names, macro
> > expansion, etc. But this claim is weak: copyright requires originality, and
> > there is little room for originality in function names; and it is easy to
> > circumvent. The more restrictive you make your license, the stronger the
> > incentive to circumvent it.
> I'm not really seeing your reasoning here, either.

What part of it? That copyrighting API is legally weak? Do you think a judge
will sustain someone's alleged copyright on "create_window"?

That copyrighting API is easy to circumvent? Just wrap the library in a
trivial one, implementing a similar or specialized API with different
function names and structures. Then make a non-working version of the second
API that do not use the copyleft library at all.

That more coercive requirements yields more incentive to circumvent them?
Seems obvious.

> I would disagree (rather strongly) with at least some of what you seem
> to be saying, but I'm not really sure what you are intending to say
> here.

I am saying that looking for that kind of license is a waste of time. It
will not prevent bad guy from using the work, at worse force them to make a
little effort to twist the license. And it will severely annoy people who
insisting on respecting the licenses, like Debian packagers.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#160540

On Sat, Nov 14, 2015 at 12:37 AM, Nicolas George <george@nsup.org> wrote:
> Le septidi 17 brumaire, an CCXXIV, Joel Rees a écrit :
>> > The firs drawback is that it would be incompatible with GPL code and
>> > libraries, and even possibly LGPL. That means libraries made using that
>> > license can not be used from GPL code or with GPL libraries. Basically,
>> > there is logically room for only one widely-adopted copyleft license.
>> I'm curious as to your reasoning here.
>
> Copyleft means: if your binary includes bits from my library, then it must
> be distributed under the same license.

Really? Then perhaps you could explain the reason for this fsf FAQ:

http://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

> So, if the binary includes library_A that is under copyleft_license_A and
> library_B that is under copyleft_license_B, the requirements can not be met
> both.

Well, incompatible strong copyleft licenses are said to exist. For
such licenses, what you say is correct.

But compatible strong copyleft licenses compatible with the GPL are
also said to exist. (Meaning that your explanation is incorrect
relative to combining code from such licenses with code under the
GPL.)

>> > The second drawback is that it would probably have no legal standing.
>> > Copyleft is based on copyright, and copyright controls distribution, nothing
>> > else. In principle, it can not control API use, since there is no
>> > distribution involved. In practice, you can argue that using an API requires
>> > copying tiny bits of it in the calling program: function names, macro
>> > expansion, etc. But this claim is weak: copyright requires originality, and
>> > there is little room for originality in function names; and it is easy to
>> > circumvent. The more restrictive you make your license, the stronger the
>> > incentive to circumvent it.
>> I'm not really seeing your reasoning here, either.
>
> What part of it? That copyrighting API is legally weak? Do you think a judge
> will sustain someone's alleged copyright on "create_window"?

In an ideal world, published APIs were not allowed patent protection
and copyrights on them were not allowed to infer rights over use or
separate implementation of the APIs.

Past tense.

That ideal world no longer exists, unfortunately. The intellectual
property advocates at Oracle, for instance, have demonstrated their
willingness to make assertions over API, and certain courts have
demonstrated their willingness to consider such assertions (and not
turn the lawyers and the companies over to the FBI for racketeering).
So, whether the assertions are valid or not, we are not protected from
some of the financial consequences of breaching such licensing of API.

> That copyrighting API is easy to circumvent? Just wrap the library in a
> trivial one, implementing a similar or specialized API with different
> function names and structures. Then make a non-working version of the second
> API that do not use the copyleft library at all.

In the current courts, such arguments seem to be viewed as logiical
caprice. (How one cannot hold such courts in contempt is beyond me,
but that is not the question we should be asking, if we have much of
anything important invested in anything that could become captured
intellectual property).

> That more coercive requirements yields more incentive to circumvent them?
> Seems obvious.

Unfortunately, engineers are not the ones with the excessive financial
resources to make endless vacuous arguments in courts that seem to
allow such. Making vacuous arguments would not be so bad if they did
not have the power to require you to show up to listen to them, and
also bring a lawyer capable of responding.

>> I would disagree (rather strongly) with at least some of what you seem
>> to be saying, but I'm not really sure what you are intending to say
>> here.
>
> I am saying that looking for that kind of license is a waste of time. It
> will not prevent bad guy from using the work, at worse force them to make a
> little effort to twist the license.

Bad players are having a field day these days.

> And it will severely annoy people who
> insisting on respecting the licenses, like Debian packagers.

Well, that is something of a separate issue.

Deliberately making a new strong copyleft license for no good reason
is a waste of one's own time and may be a waste of other people's
time, as the fsf points out in numerous places in their literature.

The opensource initiative also strongly recommends looking for an
existing license to use instead of creating a new one that then needs
to be analyzed by your own lawyers to see if it really does what you
want, then by lawyers at osi and fsf to see if your claims relative to
opensource-ness and/or copyleft-ness are correct.

And both the fsf and the osi point out that good reasons for a new
license generally aren't good reasons after all. Or, even if there
might be some good reason, it is usually not good enough, compared to
the costs of figuring out whether the license actually achieves your
goals, figuring out what other licenses your new license really is
compatible with, and dealing with the technical fallout of the
incompatibilities that you do end up with.

Clearly, if one wants strong copyleft, one should question one's
reasons for not going with the GPL. And come back a few weeks later to
look at one's answers in the cold light of day.

Do we agree on that point?

But, as near as I could read it, you asserted impossibilities where
counter-examples exist. That was what I was questioning.

> Regards,
>
> --
>   Nicolas George



-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web