Re: Query on "delayed open source" licensing

On 10/25/23 23:01, Roland Turner via License-discuss wrote:
> (replying on list as this seems in scope for license-discuss, although it
> clearly wouldn't be for license-review)
> 
> This is in an interesting question and one that I've been thinking about lately
> (in particular as a potential talk for FOSSASIA 2024) because of the recent rush
> of half-baked "open-source companies" going through the transition to reality.
> 
> Two examples stand out for me:
> 
>   * The informal agreement between RMS and the author of Ghostscript to always
>     make a copyleft version available, and the latter's decision to keep the
>     promise by making his commercial releases available under a copyleft license
>     12 months later.

License or not, this "serial abandonware" model was a fairly common historical
practice, although many of the projects that did this have since failed. I think
I covered it in my 2010 talk "the prototype and the fan club" at Flourish in
Chicago, and even added a section to the busybox FAQ about it way back when:

https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=1_3_stable#n374

Open source development is fundamentally a feedback loop between developers and
users (who overlap with developers, but mostly aren't full-time on this
particular project). Latency spikes damp this feedback loop.

The most valuable bug reports to open source projects are against the current
version, allowing regressions to be caught early while the developers still
remember what they did to break it (and why they made those changes), and the
number of candidate changes between "it used to work" and "it now doesn't work"
is small. If you submit a bug report against an old version, it's entirely
possible it was already fixed upstream, or no longer applies due to other
changes. In order to get the "free support" of open source, reproducing your
issue on a current version is often a price asked by the developers. Support for
old versions is a paid service not provided by the community.

Patches to be merged also need to be against the current version, for similar
reasons. Your code can't go upstream if you don't port it to current.

By only releasing stale source long after the fact, a proprietary development
shop is explicitly preventing community participation in development. Even if
they don't take any external code, the project is still influenced, except a
popular "cyanogenmod" style overlay project can't influence the design and
direction of code that's already been written more than a year ago. All they can
do is fail or reach a breaking point and fork.

Rob

_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.

License-discuss mailing list
[email protected]
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org