[License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

Rick Moen rick at linuxmafia.com
Thu Mar 8 20:51:17 UTC 2012


[Moving from license-review, where this no longer seems topical, to
license-discuss.]

Quoting Tzeng, Nigel H. (Nigel.Tzeng at jhuapl.edu):

> On 3/7/12 8:41 PM, "Russ Nelson" <nelson at crynwr.com> wrote:
> >(I think we're ALL agreed that patents which are not freely licensed
> >-- at least for open source software -- are not compatible with open
> >source software, right?)
> 
> No. I say no is because I see explicit trademark and patent rights
> exclusion from other open commons licenses for data, etc and even code
> when you count CC0.

Pardon my interjecting, but I think you may have misread Russ's point.
I _believe_ he was saying that, if a codebase is encumbered by patents
not available royalty-free (e.g., only under 'RAND' terms), then the
software in question ends up being effectively proprietary in
jurisdictions where the patent is enforceable, irrespective of the
software's licence -- as long as the software continues to implement the
patented method, anyway:  Derivatives that no longer do that would be 
open source if the licensing and other relevant facts permit.

That is, I _believe_ Russ was reminding us all of a fact sometimes
forgotten, that suitable licensing is a necessary but not sufficient
requirement for open source, and always has been:  E.g., if someone
releases a binary codebase and claim it's BSD, you might reasonably
believe it's open source -- but then you might notice that the source
has for whatever reason never appeared or is no longer findable.  Ergo,
effectively proprietary, despite licensing.  A week later, someone finds
a matching source tarball:  You now reasonably believe it's open source
again.  A week more, and someone finds an encumbering patent for your
jurisdiction that isn't available royalty-free:  effectively proprietary
again.

Trademark encumbrance, by contrast, is a red herring, as it never blocks
any usage or direction of development, and only affects branding
details.  (See:  Iceweasel, CentOS, Sawfish window manager.)


I bowed out of upthread discussion in part because it was difficult to
bring clarity to it, in the face of (pardon my wording) a great deal of
interpersonal noise and advocacy posturing.  E.g., the notion that
anyone who thinks new licences ought to address patent issues in some
way is logically obliged to try to revoke BSD licence's OSI Certified
status (or formally deprecate the licence) is absurd, and we could have
done without those and similar time-wasting polemics.

At the beginning of the CC0 evaluation, I opined:  (1)  It's obviously
OSD-compliant.  (2) It would be helpful if CC would drop the patent waiver
from section 4a, leaving open the possibility if not likelihood of
implicit patent grants and defences based on estoppel -- and OSI should
ask CC to please consider doing so.  (3) Irrespective of CC0's merits as
a fallback permissive licence, the document's fundamental reason for
existing is foolhardy: the delusional belief that creative works can be
safely magicked into the public domain despite a worldwide copyright
regime, and the equally delusional belief that it's even desirable to
try (and thereby, among other problems, have no protection against
warranty claims).

I think -- hope -- that we all agree, despite recent noisy polemics,
most of us agree that it's useful for newly crafted licences to permit
at least implicit patent defences if not explicit patent rights, and
that modern licences that address such matters are, all other things
being equal, a better idea than ones that don't -- but that saying that
is miles away from saying BSD should be formally deprecated.  (As Larry
points out, there are nuances among degrees and types of explicit patent
grants.)

-- 
Rick Moen            "Take note; the semicolon is never to be used correctly."
rick at linuxmafia.com                                         -- FakeAPStylebook
McQ!  (4x80)



More information about the License-discuss mailing list