Policy on BUILD_PATENTED

[Sam Kuper]

On Tue, Aug 11, 2020 at 01:30:08AM +0100, Mauro Mozzarelli wrote:
> Citizens of the European Union are major contributors to OpenWrt and
> other Open Source projects, The European Union, after several years of
> debate. listened to its citizens, not corporations, and has put into
> law that freedom from software patents that allows us all to
> contribute to the community without fear of litigation nor constraints
> imposed from monopolistic organizations.
> 
> The EU and its citizens are too important stakeholders. EU law, and EU
> citizens' will must too be respected.

Mauro, I may be wrong, but I don't think anyone in this thread trying to
deny the rights or freedoms of EU citizens, nor expressing disagreement
with EU law on software patents.

Rather, I think they are trying to point out that OpenWRT must also
accommodate developers and users who live in jurisdictions that, sadly,
do not grant them the same rights and freedoms as the EU does.  I hope
that one day more jurisdictions will take a European approach to
software patents; but in the meantime, it would be tragic if a person in
e.g. the USA were to inadvertently get into serious legal trouble simply
by developing or using OpenWRT.

So, the question is how to avoid that sort of tragedy.  Ideally, the
answer would still uphold user and developer rights to the maximum
extent that each jurisdiction will permit.

I see only two broad approaches available to avoiding the tragedy:


1.  "Lowest common denominator".

    Any software that might place a developer or user in legal jeopardy,
    wherever they are in the world, should be excluded from distribution
    in OpenWRT.
    
    (I personally dislike this approach, because although it would avoid
    the tragedy mentioned above, it fails to uphold user and developer
    rights to the maximum extent that each jurisdiction will permit.)


2.  "Selector switches".

    OpenWRT should contain a mechanism to allow the user/developer to
    choose whether or not to enable (and ideally, whether or not to even
    *receive*) patent-encumbered code.

    (I personally think this is the better approach.)

    I can see two ways to implement the "selector switches" approach:

    2a. Compile-time switch.  (This seems to be the current approach.)

    2b. Separate package repositories.  (This seems to be your proposed
        approach.)


As I mentioned in a separate message in this thread, I suppport your
proposal of (IIUC) a separate repo for patent-encumbered software, i.e.
2b above.  I think that is better than a compile-time switch (2a above)
for several reasons:

-   Usability.  For instance, if a user downloads a binary of OpenWRT,
    then the installation/setup interface for that binary could ask the
    user whether or not to enable repositories other than the default
    (and perhaps explain to them the implications of this).  This would
    not be easy to achieve with a compile time option.

-   Codebase hygiene.

    If the primary OpenWRT Git repo or package repo contains
    patent-encumbered code (which I think might be the case at the
    moment?), then this could put in jeopardy those OpenWRT developers
    who live in jurisdictions that uphold software patents, even if
    those developers never enable the relevant compile-time option.
    (I.e.  because they would still be receiving/distributing
    patent-encumbered code, which might count as an infringement.)
    
    But if patent-encumbered code is kept cleanly separate from the
    primary OpenWRT Git repo and package repo, then any developer or
    user who wishes to completely avoid patent-encumbered code can
    easily do so; and likewise, any developer or user who wishes to
    install or hack on patent-encumbered code can equally easily do so.


For maximum safety and choice for users and developers, I propose
that OpenWRT adopts the following variant of approach 2b:

============================================================
Package repository name     | Enabled  | Non-free | Patented
                            | by       | software | software
                            | default? | allowed? | allowed?
============================+==========+==========+=========
main                        | Yes      | No       | No
----------------------------+----------+----------+---------
non-free*                   | No       | Yes      | No
----------------------------+----------+----------+---------
patent-encumbered           | No**     | No       | Yes
----------------------------+----------+----------+---------
non-free-patent-encumbered* | No       | Yes      | Yes
============================================================

* By "non-free" here, I mean software that is non-free (i.e. does not
uphold the Four Freedoms) for reasons *other* than patent encumbrance.
Closed-source binary BLOBs, for example.

** I suppose it would be possible in principle, in future, to distribute
"-eu" builds that have the patent-encumbered repository enabled by
default, alongside regular builds that do not.  Whether the OpenWRT
developers think that is worth the effort is another matter, given that
users would easily be able to enable the patent-encumbered package
repository.  I don't have a strong view on this.


Best wishes, and a big thank-you to everyone who develops/maintains
OpenWRT.  Likewise thank you to everyone who campaigns in favour of
libre software and against software patents.  I think we are all pretty
much on the same side here in principle, we just need to agree on an
implementation :)


Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.