[License-discuss] [License-review] Evolving the License Review process for OSI

Rick Moen rick at linuxmafia.com
Tue Jun 4 22:14:31 UTC 2019


Quoting Luis Villa (luis at lu.is):

> People who have asked questions of the list have certainly been told that,
> both explicitly and by implication ("well, it isn't written down anywhere
> else, so...") Usually politely, but polite terrible news is still terrible
> news.

That's regrettable and it would certainly be better to be able to point
to a summary in some suitable non-mailing-list ticket.  As with the SVLUG 
example, there is a tendency to rely on an existing tool for unsuitable
uses, if that's what is on hand, and I imagine people get lazy and don't
want to spend time getting and providing the right per-message
Pipermail archive URL.

Well, at least this was not an OSI statement or (I gather) from an OSI
Board member, which was the impression I got from your initial footnote.

> https://github.com/OpenSourceOrg/ has existed, and been relied on, for some
> time. And that's purely proprietary.

Although past regrettable decisions are, in my opinion, best not used to
justify future ones, I have the pleasure today of bringing good news:  

The proprietary GitHub service and the theoretically open source &
self-hostable but extremely ponderous and overengineered GitLab codebase
have, for some years, had excellent, modestly scoped, open source
alternative codebases, fully suitable for self-hosting and devoid of bloat.  
In particular, _Gitea_ is excellent and increasingly in use by Linux
distributions for their own code repositories, in managing their software
development teams.  (If you want an example:  Devuan Project.  There are
others.)

https://gitea.io/

So, today's the day OSI can start migrating that repo off proprietary
software, and onto something less horribly overfeatured than is
Microsoft's GitHub service, to boot, on any OSI static IP.
(Administrative burden, you say?  But this isn't corporate bloatware, so
please check the Gitea docs, and you'll see there's rather little.)


> More generally, SaaS is a massive channel for open source these days, and
> the org has very limited organizational bandwidth. It would seem odd to
> insist on both avoiding one of (the?) predominant open source distribution
> model, and imposing overhead on the org.

Is is not the least bit odd to model the suitability of open source to
be in control of one's computing infrastructure -- the way businesses
control business risk by deploying autonomous open source -- by doing so.  
(Example:  A year from now, Civilized Discourse Construction Kit, Inc.
advises that it's shutting down its free hosting.  Is OSI able and 
prepared to migrate everything?  To where?  Uh-oh.  Yes, theoretically 
the Discourse Web-forum software is open source hence migratable, but 
in practice it's about as vendor-locked-in as is GitLab data.)

On the other hand, it's entirely impossible to compete with the zero
administrative overhead of outsourcing to third-party hosted software,
so if that's the criterion OSI wants to apply, then outsourcing will
automatically win, every time.

-- 
Cheers,
Rick Moen             "History is a nightmare from which I am trying to awake."
rick at linuxmafia.com                               -- Stephen Dedalus, _Ulysses_
McQ! (4x80)



More information about the License-discuss mailing list