Re: Strong Copyleft licenses other than the GNU GPL family.
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
Reply to: