[License-discuss] Source code availability after end of life

Fri Aug 17 10:24:45 UTC 2018

Bradley, thanks for sharing your personal experiences in this field. They
were interesting to read, especially the part where dogs eat the requests
for source code!

On Fri, Aug 17, 2018 at 2:35 AM Bradley M. Kuhn <bkuhn at ebb.org> wrote:

> Sorry for reopening a thread from last week; I don't follow this list
> closely and only happened to discover while skimming today that a GPL
> compliance issue was under discussion here.
>
> I do have a few comments on the thread that are hopefully useful:
>
> Scott Peterson wrote on Wednesday,  8 August:
> > There is no reason that a distributor of a product that includes software
> > licensed under the GPL cannot use an upstream supplier's written offer as
> > a part of compliance with the source availability requirement of the
> > GPL. ...
> >
> > That written offer is real; requests sent in response to that written
> > offer are fulfilled. That downstream distributor has not failed to comply
> > with the GPL merely because it did not write its own written offer and
> did
> > not not implement its own separate fulfillment process for receiving
> > requests and sending source code responses.
>
> Scott's analysis is of course correct as to the requirements of GPL, but
> I'm
> glad we're discussing this in detail publicly, as there are some nuances
> worth exploring.  (Transparency and public discourse about these topics
> will
> surely benefit the whole community.)
>
> Most of my comments below aren't about the minimum requirements per the
> license text, but rather discussing about best practices around this issue.
> I generally find that seeking to meet the bare minimum requirements of the
> license has limited utility in copyleft compliance discussions; it's better
> to seek the best practice that will yield compliance practices that are
> beyond reproach.
>
> Thus, as a best practice, I urge all redistributors to avoid the written
> offer entirely (more on that below).  Moreover, certainly in the case of a
> commercial actor, in most real-world scenarios, the written offer from
> upstream is likely to be inadequate in practice even though it might be
> adequate in theory (as Scott pointed out).
>
> In my experience, only white-box repackagers of products ever use the
> binary
> build precisely as upstream provided in a manner that would mean the
> required "scripts used to control compilation and installation of the
> executable" remain absolutely identical for upstream and downstream.  I've
> never seen a scenario in GPL enforcement where the upstream CCS complied,
> because invariably the downstream vendor's engineers made changes and the
> legal staff hadn't realized it.  Most often, this is around the build and
> installation.  Too often, the build scripts requirement is (sadly)
> forgotten, so it's easy for even well-intentioned downstreams to err
> (because they don't read GPLv3§3/GPLv3§6 carefully), and then realize only
> later the source offered by upstream is incorrect source (per "Complete,
> Correspond Source" (CCS) definitions in the various GPL versions).
>
> Furthermore, note that Scott's analysis assumes that the upstream source,
> when shipped, will actually comply with other requirements (e.g., GPLv2§3)
> of the GPL.  In my experience, most upstreams have GPLv3§3/GPLv3§6
> compliance problems.  In other words, if you don't verify yourself
> (regularly) that your upstream's offer, when exercised, puts GPL-compliant
> CCS in the requestor's hands, you'll find out your upstream failed to
> comply
> at the latest possible moment -- when someone tests what is now *your*
> offer
> for source.  You're then left scrambling and have set yourself up to fail.
>
> BTW, as a copyleft drafting matter, the entire "offer for source" idea is
> an annoying necessity.  It assures that full source code provisioning at
> point-of-sale doesn't cost-prohibit commercial incorporation of GPL'd
> software in inexpensive devices.  However, the only advisable time to use
> offer for source is when it's truly financially unviable to distribute
> physical-media source at time of physical distribution.
>
> Relatedly, it's important to note that the companies who nefariously
> violate
> the GPL have used the offer for source for more than a decade as a way to
> cover up their intentional violations (more on that below).  Contrary to
> popular belief, there *are* many bad actor GPL violators who simply publish
> an offer for source with no intention of fulfilling it properly if asked.
> They hope that no one asks during the (usually short) sales lifecycle of
> the
> product, and while the offer is indeed valid for three years after
> distribution (GPLv2) or EOL (GPLv3), it's relatively rare that someone
> requests source on an EOL'd product.  Such companies play the odds and get
> away with violations over and over again.
>
> More reading on this issue can be found in the Comprehensive Copyleft
> Guide.
> This issue is discussed in various sections (search for "offer" in the
> whole
> text of the book available at https://copyleft.org/guide/monolithic/ to
> find
> them all), but the section directly linked via
> https://copyleft.org/guide/comprehensive-gpl-guidech16.html#x21-12700015
> deals with the issue directly.
>
>
> On Bruce's point:
>
> Bruce Perens wrote on Wednesday,  8 August:
> >> It's also possible for a company, including the upstream manufacturer,
> to
> >> formally contract to perform another entity's GPL source code
> >> fulfillment.
>
> This was quite a trend a few years ago, and a few companies in the
> compliance industrial complex even attempted to offer such contracts as a
> fee-for-service business.  I don't get the impression this was successful,
> because contracting out CD/DVD printing fulfillment is a commodity service,
> and if you need any services beyond that, you're basically asking for GPL
> compliance help anyway -- so you might as well train your staff in house
> how
> to comply correctly as that expertise will pay dividends going forward for
> future products.
>
> I thus really don't recommend outsourcing any of your GPL requirements.  I
> do, however, recommend a public-accessible website with all source releases
> for every product.  While this does fail to comply with the offer
> provisions
> for GPLv2-only, it *does* usually mean the number of people who will
> request
> physical media goes down to zero or near-zero, as the only ones who need it
> are those who lack speedy Internet connections.  A sample offer that works
> in this particular way is given in the second Copyleft Guide URL I
> mentioned
> above.
>
> Scott wrote further:
> > If what matters is the name on the offer (not whether the offer is
> > effective), then that would be a GPL that serves the interests of
> > troll-oriented "compliance enforcement", not the interests that the GPL
> > seeks to serve. I do not believe that that is what is intended in the
> GPL.
>
> While I do generally agree with this point, I think it might be overstated
> for these two reasons:
>
> First, I don't think there is *any* serious threat from troll-like
> enforcement in any event; that risk has been unreasonably exaggerated.
>
> Second, and relatedly, the violators who attempt to play games around the
> offer clause behave much worse, such that it easily drowns out any concern
> of bad enforcement behavior.  In my experience, many violators (both the
> nefarious and lazy varieties) have a tendency toward "hide the ball"
> activity around the offer clauses.  This is easier explained by giving a
> few
> examples of why violators have told me they ignored offer requests:
>
>   * "You didn't have the address on the envelope character-for-character as
>     it appeared on the offer page, therefore, we weren't required to honor
>     your request."
>
>   * "You're not our customer."
>
>   * "You can't provide an address in the USA for delivery of your source
> CD,
>      so we aren't required to provide the source to you."
>
>   * "You sent your request via services with tracking, and we only accept
>     source requests with a plain, regular stamped envelope with no tracking
>     or signature required."
>
> The GPL of course doesn't allow for any of these excuses, or the dozens of
> others of the "but the dog ate your source request" variety that I've heard
> from violators over the years.  In most of these cases, compliance was
> achieved in the usual way by following the Principles of Community-Oriented
> GPL Enforcement, and thus I'm not bringing this up to admonish those who
> behaved this way, but rather to point out that for every one of the times I
> (or someone bothered to report a violation) have been told something like
> this when requesting source, I'd suspect there are hundreds of people out
> there are getting specious answers to their source requests -- who just
> give
> up entirely.  That pandemic problem (and the other pandemic problems of
> non-compliance), so much outweigh any threat from one bad-actor-enforcer
> who
> "once-upon-a-time made an argument not supported by the license text", that
> the latter seems risible to me as a concern.  I think we should continue to
> read copyleft licenses with an eye toward assuring its requirements advance
> software freedom, and include any requirements that succeed in that regard,
> even if they are on rare occasions abused.  IMO, the place for worrying
> about what bad-actor-copyright-holders is in meta-documents like the
> Principles of Community-Oriented GPL Enforcement, not the license itself.
> --
>
> Bradley M. Kuhn
>
> Pls. support of the charity where I work, Software Freedom Conservancy:
> https://sfconservancy.org/supporter/
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20180817/2b637b08/attachment-0001.html>