
De-facto closed source: the case for understandable software - zdw
https://13brane.net/rants/de-facto-closed-source/
======
raverbashing
The more I read about the js ecosystem, the more it seems the inmates are
running the asylum

It's a long time since js needed a good stdlib.

Everybody was using this package but apparently no one but an adversarial
player stepped up to actually maintain it.

(And don't get me started on "let's always get the latest version of the
package")

> You want to download thousands of lines of useful, but random, code from the
> internet, for free, run it in a production web server, or worse, your user’s
> machine, trust it with your paying users’ data and reap that sweet dough. We
> all do. But then you can’t be bothered to check the license, understand the
> software you are running and still want to blame the people who make your
> business a possibility when mistakes happen, while giving them nothing for
> it? This is both incompetence and entitlement.

Not surprising. Not surprising in the least. "Oh wow somebody 0wned the
package I needed". Maybe because js projects have _an order of magnitude more
dependencies_ than a Python/Java/Go, etc project. Maybe because in the extreme
opposite of NIH, people feel the need to import a module for every small thing
they want to do? "Stack overflow programming", "how do I add 2 numbers using
React, is there a module for that!?!?!"

~~~
Drdrdrq
The cynic in me is saying that JS is the new PHP. Ironically, both are very
capable and suitable languages, but the sheer freedom they offer attracts
crowds of wannabe developers who think they are gods because they know how to
shave off 10% of execution time in some small part of their overengineered and
unmaintainable mess. And give talks about it, write blogs and post clever
twits.

However developing robust software is possible in JS, the same way it was
possible in PHP. You just need to take some time to vet dependencies a bit
better and not use every fad when it surfaces. Common sense and experience
help a lot. But it's incredible what can be built with modern toolchains and
how maintainable it can be. Don't let the anti-JS feeling scare you from
trying React / Vue /..., just don't forget that state management, separation
of concerns and similar concepts are still valid.

~~~
saagarjha
> the sheer freedom they offer attracts crowds of wannabe developers who think
> they are gods because they know how to shave off 10% of execution time in
> some small part of their overengineered and unmaintainable mess. And give
> talks about it, write blogs and post clever twits

Honestly, I think JavaScript just has a lot of new developers who have never
been exposed to concepts of software development such as dependency
management, cultivating trust, and how (free and) open source works. I think
the kind of developer you're describing is actually a minority.

~~~
nerdponx
This is my thought as well. "I have creative experience and/or student loans
but I don't know what to do for work so I'll take a Javascript course and
become a web dev."

It's wonderful that programming is becoming a kind of "equalizer" on the job
market. But without supervision from _software engineers_ (i.e. people with
the experience and aptitude to design software properly) you end up with a
mess.

~~~
TAForObvReasons
The myriad of small snippets of JS encapsulated as npm modules is best
compared to the alternative of copy-pasting solutions from websites like stack
overflow. Instead of lots of copies of solutions to common problems, now
everyone shares the same implementation. This obviously has the centralization
weaknesses but also has the centralization strengths.

The fact that there's no panacea is a fact of life. There's a tradeoff, but it
is not reflective of the people in the JS community.

~~~
vbezhenar
In Java world those snippets tend to combine into bigger libraries. Apache
commons and Google guava are the most known ones and their reputation is
established. I don't understand why JS world does not do something similar.
Some essential-utils from AiRbNb or whatever JavaScript analog of Google. And
if there's still need for some tiny function, just implement it and move on! I
can understand that JavaScript favors small download size, but modern tools
should be able to remove unused code, so it shouldn't be an issue either.

------
kstenerud
"FOSS was never about trust in software owners."

Actually, it is. That's why foundations such as Apache, Mozilla, Khronos, etc
exist. Transfers of ownership, abandonment, and bad faith are not new. We need
to trust not only in the software for today, but for tomorrow as well.
Foundations step in because they're able to harness the financial clout to
attract maintainers.

"We must make software simpler."

We must make software INTERFACES simpler. And that means opinionated
solutions, preferably with a HEAVILY opinionated top layer API for the 80% and
a less opinionated lower layer API for the 20%.

This is where "wide open" development systems such as Javascript and Lisp
fail: They offer too much freedom. You need a standard, opinionated library
that provides most of what people need, just for interoperability sake. You
need standard ways of doing the common tasks so that people can harness those
patterns into reusable modules that stand a greater chance of working well
with others.

~~~
skywhopper
Yeah for all the good points in the article the author flubs these two major
takeaways. Trust is required for all human interactions, not just software.
But at scale you have to build the tools to enable trust into the system. And
JavaScript/NPM has a lot more and bigger built-in systemic risks, including a
much greater level of trust required and a lot fewer tools to enable it.

------
572899237947258
As someone with the slightest consciousness for security, this always
terrifies me.

The Gradle version in the Ubuntu repos is too old? Just add a PPA from some
random guy on the internet. The Gradle wrapper also exists, but you'd need to
type "./gradlew" instead, which is apparently enough reason to use the PPA
instead.

Need a Gradle plugin? Oh, yeah, just add Maven Central and JCenter as repos.
No idea who (/if anyone) audits those, but we'll just trust them anyways.

Need a Docker image? Just go to Docker Hub or Quay and download one that looks
good.

Don't quite like Eclipse and the company won't pay for the IntelliJ Ultimate
Edition? Just install the Community Edition, with no idea if that Privacy
Statement actually means they could phish your SSH keys, phone number etc.

Need a way to transfer files? Google Drive is a great way to do that.

Need an operating system? We have either Windows 10 or Windows 10 for you,
which has been shown to transfer encrypted, undisclosed packages to Redmond,
even in the Enterprise Edition.

Office suite? MS Office, for which the same is true.

Need to look up some specific issue with security critical software you use?
Just type it into Google.

I even once saw someone who typed a password into the Chrome URL bar to show
the guy next to them how it's spelled.

With the sheer disregard I frequently encounter for any sensible behaviour,
I've really stopped wondering how hacking, industry espionage etc. work. I'm
already quite content if it's not just all out in the open.

~~~
partycoder
For any electronic device of your choice, search for its manual and look for
this notice:

"This device complies with part 15 of the FCC Rules. Operation is subject to
the following two conditions: (1) This device may not cause harmful
interference, and (2) this device must accept any interference received,
_including interference that may cause undesired operation_."

Everything is backdoored, absolutely everything: your hardware, your firmware,
the compiler used to build your software, your software, libraries used by
your software, your network infrastructure, your crypto, your sources of
entropy, the machines you communicate with, everything.

------
TeMPOraL
Understandability is definitely a nice thing to have, though I believe it's
ultimately limited by essential complexity of the problem domain. Also, it's
not a solution here, because a malicious actor can make the code very easy to
understand in a way in which you gloss over it and not notice subtle bits here
and there that add up to an attack.

Still, this is not the main problem highlighted by this (yet another) NPM
fiasco. I believe there are two and only two core problems that caused this
issue, and that will enable future incidents like this:

Problem 1: some scoundrel violated the commons. The commons have no effective
means of tracking them down and punishing them, so that a) they'll deeply
regret what they've done, and b) other scoundrels will be deterred from
trying. Lack of means of effective policing means various open source
communities will keep having such problems.

Problem 2: people don't check their dependencies. Yes, I can already hear all
startups screaming, "we can't afford it". Well, sucks to be you, but you'd
better hustle and find a way. The licenses of almost all the software you use
disclaim any responsibility for anything whatsoever, so if you expose users to
that software and that software harms the users, it's _your fault_. You
mishandled them. So find a way to vet your software, or buy some insurance
against yet another NPM compromise. Or don't, and accept you're taking a risk.

To be clear, I'm not advocating a general "caveat emptor" attitude to
software. We've build a civilization in part on systems and regulations that
allow us to _not_ vet everything we interact with, and yet be quite confident
in our safety. But FOSS is not there yet (Problem 1). It's built on trust, but
most communities have little means of protecting that trust. As for companies,
I have little sympathy (Problem 2), like I wouldn't have much for any other
company in any other industry that said they can't afford to do their basic
job right.

------
tannhaeuser
I don't know about the feasibility to understand all that's going on on your
computer with the ongoing stuffing of layers over layers (kernel, userspace,
"container", language VM such as node/v8 or JVM, framework, etc.). If
anything, I'd expect younger devs to understand less of it all, since they
don't learn from the ground up (eg from hardware). But there has always been
the option to use interchangable standard components based on POSIX, SQL, etc.
as a remedy to become critically dependent and vulnerable. In fact, node.js
started as just one of many implementations of the CommonJS module loading
mechanism and base API, in addition to being based on one of the most portable
languages of all time.

But I guess no amount of education will make the kind of developers go away
who think 400+ package dependencies for a trivial app is a good thing, or that
you absolutely have to write a proprietary not-quite-JavaScript language
compiled to JavaScript via babel, or that node.js in itself is a goal, rather
than merely an implementation.

~~~
a_bonobo
Not knowing much about node.js, wouldn't the most logical step now to make a
standard node.js library that implements the majority of the functions of
those ~400 packages? Vetting one package is easier than vetting 400. I guess
that's what Rails did in the very beginning, I keep on discovering in-built
magic

~~~
rpeden
Node does have a standard library. It's not massive, but there's a lot more
available out of the box than is available in a browser.

The tricky part is that lots is npm packages end up bundled into an app that
runs in the browser. It's just a guess, but I'd guess that significantly more
npm imports end up running in the browser than in Node. So even giving Node a
standard library as extensive as Ruby's wouldn't help as much as one would
hope.

------
randomsearch
New to web dev. New to node. Looks like a complete mess to me, deserves
criticism, as does much of the web dev ecosystem.

Package maintainer should indeed have found someone to pass it onto (see
Cathedral & the Bazaar). And that doesn’t include the first person he’s never
heard of stepping up.

BUT this applies to all package managers, maintainers, and OSS _at some
level_.

The idea that say a startup has time to audit every line of every dependency
is absurd. Even a big business can’t do that. The idea that you “don’t have to
trust” the authors is untrue, in the current workflow. FOSS relies entirely on
trust.

I’m not convinced FOSS is even a good idea at this point, but with the advent
of widespread cyberwarfare we need to either introduce a sophisticated
accompanying trust model, or exclude FOSS when working commercially.

This is a business opportunity. Audit FOSS and sell your audit guarantees in a
contract. Offer services to audit more recent versions on the proviso that you
can sell that audit elsewhere.

This will have the incidental benefit of encouraging clean software to be
written in languages that minimise audit costs, as those projects will get
used more.

Some commercial arbitration of FOSS now looks inevitable.

~~~
lugg
> Package maintainer should indeed have found someone to pass it onto (see
> Cathedral & the Bazaar). And that doesn’t include the first person he’s
> never heard of stepping up.

WITH NO WARRANTY.

Do you not understand what this part of the licensed mean?

Mainter doesn't have to do shit. That is the point.

You want to start putting arbitrary ethics and morals on these developers? The
"Fuck you. Pay me." talk comes to mind.

FOSS works fine like this and has been for a long time.

We're seeing issues now because of nodes lack of a standard library. Not trust
and certainly not instead issues with free and open source software.

~~~
andrewflnr
Lack of standard library only makes the trust issue manifest with more
hilariously basic libraries, instead of more slowly with the libraries. We've
still seen this in Python, the poster child for batteries-included.

~~~
lugg
I think it's been said elsewhere, this is true but the frequency and severity
is orders of magnitude less with the languages with good standard libraries.

When the entire ecosystem depends on left pad I think you have a problem.

When the entire ecosystem depends on express it is less of an issue because
more eyes are invested in auditing it and changes are more widely reviewed.

You think a nefarious leftpad function would make it's way into express? It
could, but it is way less likely.

Updating the dependency to a newer version of left pad isn't going to raise an
eyebrow. And that is the issue.

------
etaioinshrdlu
Best line in the post:

Software must be made understandable. The essence of FOSS for me can be
reduced to one fundamental computing right: the right to refuse to run, on my
machines, code that I do not have the option to understand. That is it.

~~~
TeMPOraL
To me, those three sentences don't even fit together.

You've always had "the right to refuse to run, on my machines, code that I do
not have the option to understand". Nobody is forcing you to run any random
piece of code you found on-line. You do that of your own accord. And if you
screw this up, and that screwup affects other people, it's your fault. Simple
as that.

~~~
mannykannot
Not only have we always had this right, the rest of the article argues,
correctly, that the _option_ to understand the code you run does not solve the
problem. It's like having the _option_ to study before an exam.

------
ken
The call for a massive reduction in complexity reminds me of the VPRI "STEPS"
project (Alan Kay et al) to build a complete end-user operating system in
under 20,000 lines of code. Sadly, it looks like the project is dead or over,
and the links I've found pointing to it on vpri.org are dead today.

Until there's some external stimulus, I don't think the industry is going to
change. It's a lot cheaper to add new flashy things if you don't care about
complexity (or the consequences of it, like bugs, and security). Getting a
consumer to care about the complexity of the software in their computer or
phone is like asking a Ruby programmer to care about the microcode in their
CPU. It's not that we can't understand the problem but it's not a concern
until it gets so bad it impacts my level of abstraction.

I'd love to see programs start putting little badges on their webpages that
brag about how few lines of code they have, how low their cyclomatic
complexity is, or how short their dependency tree is. I'm terrible at
marketing but surely there's a way to make this sound appealing.

~~~
carapace
The project completed successfully and wrapped up. Final report (2012)
[http://www.vpri.org/pdf/tr2012001_steps.pdf](http://www.vpri.org/pdf/tr2012001_steps.pdf)

Discussion on HN (2016) :
[https://news.ycombinator.com/item?id=11686325](https://news.ycombinator.com/item?id=11686325)

I think Brett Victor is one of the people driving the effort beyond that
project: [http://worrydream.com/](http://worrydream.com/)

------
kqr
> I may be wrong, but in the millions of downloads of event-stream and it’s
> 1.5k dependent packages, there should be at least 5 companies involved
> which, had they spared 1 dev-hour per week each, should be more than enough
> to keep event-stream kosher.

This is a really good observation. If you know some important transitive
dependency your job depends on is missing a maintainer, tell your nearest
supervisor you'll be spending an hour a week taking care of that. Or a similar
amount of time helping a direct dependency get rid of the broken transitive
one, whichever makes more sense.

~~~
dempseye
This might work for the most privileged class of software developers with the
most clout, but I'm pretty sure that most devs don't have the luxury of
informing their supervisor what they'll be working on.

~~~
lugg
You need to find a better employer.

~~~
dempseye
I wasn't talking about myself, but some colleagues I have elsewhere. I pretty
much come and go as I please, define the technical direction of the product
and get paid handsomely for it.

Devs are still treated like children in many companies.

------
discordianfish
Without assigning blame to anyone, a simple-to-follow best practice would be
probably to just never hand over a (personal) project. Make it as deprecated
and let the community fork it. If you feel like it, point to the new,
maintained fork.

~~~
tree_of_item
Absolutely. I don't see why the author brushed off the maintainer's
responsibility so casually.

> lets roll for a bit with the assumption that a small amount of extra care on
> Tarr’s part could have avoided this mess.

Are you kidding? The bare minimum of not just handing a repository under your
name to a random stranger is apparently a hard to fathom concept for this
author.

------
raesene9
Whilst this particular instance focuses on the JS ecosystem and NPM,
realistically the general points apply much more widely.

The number of commercial services and pieces of software that are largely
reliant on huge piles of OSS is significant.

In contrast to that we're not really seeing those companies focus enough on
the security of the OSS that they rely on.

To provide two other well known instances, both Heartbleed and Shellshock sat
as vulnerabilities in their respective OSS software for a large number of
years. The packages were widely used by commercial software vendors, yet none
of them discovered the issues...

------
ummonk
It should be noted that in npm, examining the source of the package tells you
absolutely nothing about whether you should trust the package - the actual
blob that you download need not be generated from the same source.

------
jononor
Support for tree-shaking in Javascript build tools is improving. This means
that unused functions are not included from a dependency when they are not
used. This could be a foundation for a more trusted utility library.

Such a library could be made by crawling NPM stats to find out what kind of
small packages/functions are most used, and select a subset of these. The code
could be lifted from the original packages (with proper licenses and
attribution). The package maintainers could be approached if they are
interested in helping to maintain this new collection package. The thesis
being that such a package can be more efficiently maintained by a group, than
each individual maintainer and package alone.

Once it exists, one can post PRs to common dependants to use the new package.

Could it work?

~~~
qudat
> Support for tree-shaking in Javascript build tools is improving.

I agree tree shaking could help a lot. But every time I have tried to
implement tree shaking properly in a JS codebase, it is not trivial to solve.
If one configuration is not properly setup then the entire library gets
inlined during compilation.

Furthermore, libraries like lodash use a lot of inter dependencies so using
something like `get` could bring in a ton of stuff that is technically used
but totally unnecessary.

------
BigJono
The common consensus is that building JS apps without an endless list of
dependencies is so slow that you're going to get creamed in the marketplace
due to inefficiency. Why should we spend $5m re-inventing the wheel when we
could spend $2m re-purposing a bunch of other people's work?

Whether or not that's true is largely irrelevant, since the decisions are made
based on what people believe, and since the same decision is made every time,
there's not much data for the other side of the comparison. When was the last
time someone deployed an app with less than 10 (total, not direct)
dependencies? Hell, even 100? Some people have probably never built one with
less than 1,000.

------
Wildgoose
This just makes me think a primary design goal when writing software is to
Optimise for Deletion.

Everybody says that they emphasise ongoing maintenance when writing code, but
the best way to take that to extremes is to optimise the ability to remove
(and replace) code en masse.

~~~
Ace17
This looks somewhat similar to good old modularity and decoupling. Does
"optimize for deletion" differ in some way from that?

------
ashleyn
Don't forget horrendous build systems. Ever try to build a Google product? I
wanted to use Skia for my game's GUI - I never got it to build.

~~~
Const-me
I have also evaluated Skia, and came to the same conclusion.

Have been using nanovg instead: somewhat lower level, but at least it builds,
and also it’s quite simple to use. The main downside it doesn’t support
ClearType for text rendering, even when using it with FreeType.

------
codedokode
I don't think that reading through millions lines of code is a sane idea.
Therefore I suggest an alternative to author's opionion:

\- select a Linux distribution one can trust, like Debian

\- throw away your Node.JS and switch to PHP. We have frameworks like Symfony
made by a company that can be trusted and that has proper code review
processes so you don't have to worry that tomorrow there will be a backdoor

Another alternative would be a community code review. Everyone using OSS code
can contribute some time for a review of the project they like the same way
they contribute the code. Reviewing is even easier than writing a code. Then
they sign the lines they have checked. It would also help to find poorly
written, difficult to understand code and find unreliable code that can
contain vulnerabilities.

The companies using OSS code could be interested in this. They would prefer to
use the code checked by other corporations rather than the code that has never
been reviewed. And they probably are already doing the reviews privately so it
wouldn't cost them anything.

------
johnny22
So many people here seem to be missing the point by assigning blame to npm or
node or whatever specifically.

This situation could happen with packages in any language.

~~~
lugg
Could. Yes. But many orders of magnitude less likely.

This is why languages have standard libraries. It prevents the dependency hell
we have with node.

~~~
jononor
Reduces, not prevents.

~~~
lugg
Prevents vs acts to prevent. Sorry, I misspoke.

Fact is. Nobody builds a standard library to reduce dependency hell. They do
it to eliminate it.

The standard library uptake, quality and efficiency is all intertwined sure
and developers can always go shoot themselves in the foot anyway but, wait,
I'm sorry, did you have a point?

~~~
jononor
No standard library contains everything most people need, and sometimes the
stdlib version is not the preferred.

Look for instance at Python. Lot of people use requests instead of urllib for
HTTP client. No-one uses the HTTP server. Until 3.x no support for async IO or
event loops, so we have Twisted/gevent/eventlet, mostly incompatible.

My is only that there are painpoints around dependencies event with a stdlib.

------
malikolivier
I am really rooting for understandable software. I do not consider a software
without appropriate documentation to be free (as in freedom).

Lately I met many companies claiming they make "open source", when their
software is in fact hardly usable as is, and you would anyway be required to
upgrade to "pro" features or "pro" support to get anything useful done with
it.

At this point I consider such piece of code _de facto_ closed source.
Disclosing the sources or part of them in itself does not bring much value and
does not increase the number of careful eyes auditing the code.

I really wonder why they decided to open-source such product to begin with, is
it marketing? Are there other advantages?

~~~
08-15
Open Source is not Free Software. It never was. Open Source is the development
model where you open up your source so more people can see and debug it. In
practice, it could mean you write commercially important software by employing
a thousand monkeys with text editors and then dump the impossible maintenance
task onto the "community".

------
habitue
> FOSS was never about trust in software owners.

I get what the author is saying, but I think these kinds of originalism
arguments are always a bit tedious. Do we really think that the original
utopian intentions of hackers in the 80s are going to provide us with magical
insight into this problem? The context is completely different from anything
they would have imagined.

Open source / free software isn't a gift from heaven that will work out if you
just believe hard enough. The situation described is a new problem, and we
have to think hard about how to solve it

------
bloak
I get annoyed by languages/frameworks that want to download code from
mysterious web sites, bypassing the distribution's package manager. Ruby seems
to do this, though I might be wrong: that I can't easily tell where the code
is coming from is bad in itself. I prefer to know that there's at least a
Debian maintainer between me and upstream.

I definitely would notice if Debian itself got taken over!

Perhaps the rule of thumb should be: if it's not properly _in_ Debian, then
don't use, it unless you have a very good reason for doing so.

~~~
kmarc
Let's not forget how those trustful Debian maintainers packaged openssl
0.9.8...

~~~
Tom4hawk
It was 10 years ago...

For people interested: [https://www.isotoma.com/blog/2008/05/14/debians-
openssl-disa...](https://www.isotoma.com/blog/2008/05/14/debians-openssl-
disaster/)

------
carwyn
Homesteading the Noosphere by Eric Steven Raymond seems relevant in this
discussion. Originally written 20 odd years ago.

"I examine the actual customs that regulate the ownership and control of open-
source software."

[http://www.catb.org/esr/writings/cathedral-
bazaar/homesteadi...](http://www.catb.org/esr/writings/cathedral-
bazaar/homesteading/)

------
jchw
I've been saying this forever and it still feels like an unpopular opinion,
but stuff like this is why I hate micro modules as opposed to frameworks. A
lot easier to trust say, RxJS (with just 1 small runtime dependency) instead
of 40 different tiny modules that may depend on other tiny modules. Actively
developed frameworks seem less prone to this kind of malice.

------
ezoe
This is nothing to do with the free software. It's just that NPM ecosystem and
culture is horrible.

~~~
c-smile
Ah, culture...

There is a law of the transition from quantity to quality by Hegel
([http://www.pnas.org/content/97/23/12926](http://www.pnas.org/content/97/23/12926)).

As soon as number (e.g. of modules in NPM base) reaches some point the overall
quality changes dramatically. It is a step function - from good to bad. From
enthusiastic acceptance to full rejection of NPM and similar code sharing
mechanisms.

~~~
TimJYoung
That is a fantastic read, thank you. It's amazing how many structures and
institutions have evolved from that simple concept.

------
zby
OK - that whole talk about making software more understandable instead of
churning new features - sounds good. But his rejection of reliance on trust
looks like a pipe dream.

What is he proposing in concrete terms? How one should decide that his code is
understandable enough? What to do with the recursiveness of libraries that use
other libs that use libs ...? The only concrete advice he proposes is the two
weeks idea: """ is it possible for a new (but experienced) developer to
understand 80% of the part of the codebase they’ll be responsible for within
their first 2 weeks (80 hours)?

If not, this person is overworked from day 1, """

But is this practical? All code should be understandable in two weeks?

------
codingdave
This is less about open source, and more about how people consume it. If you
take open source as simply one of many available resources, read the code, and
make deliberate decisions whether to use it, fork it, modify it, etc, then
actively engage with its presence in your codebase, you are fine. On the other
hand, if you "npm install <whatever>" as the easy answer to every question,
you will get burned: At best by code bloat, at worst by malicious actors.

------
nerdponx
_But no one has time for that, right?_

This is what really blows my mind. Yes, Facebook is the main force behind
React. But where are the other companies stepping up to maintain chunks of the
JS ecosystem?

If you work at a company using FOSS software, please try to convince your
managers that helping to maintain said software is a good use of (some
fraction of) your time. It's in your own best interest.

------
lifeisstillgood
Interesting - we in theory, get to trust the code cos we can read it.

But in reality we trust the authors. So in theory we could build a dependnacy
chain of signed commits, with a in theory monetary payment going to those whom
we trust

So apart from Linus getting a Xmas bonus, it would directly encourage ...
what?

------
mitchtbaum
Wow, beautiful!

Looking forward to the next chapter on trust by review. (And I don't mean 5
stars on some "app store" you've never used before by reviewers you've never
met.) Big ups.

------
nqzero
part of this issue is that it's difficult for maintainers to capture value for
their work even when they're successful

i've written a "paid use" license that attempts to capture many of the
freedoms of FOSS while allowing a revenue stream if a package is successful.
would love any feedback

[https://github.com/db4j/pupl](https://github.com/db4j/pupl)

~~~
syrrim
The problem is that people want open source software to be like their own
software. That is, it is written like they would have written it, and in such
a way that they can go through the source code and understand it and modify
it, but without them having written it themself. Necessary for this, I think,
is that the software is legally indistinguishable from software they wrote
themself.

Many people license their code under a "public domain license". What's
interesting is that such a license has no requirements of placing a copyright
notice anywhere, and allows someone to freely relicense without modification.
This is precisely as it would be if you had written the software yourself.

Your license recognizes the value of freeware as a marketing tool - the more
people with their hands on the software, the more likely some of them will
stand up and pay for it. But I think the personal ownership aspect is more
foundational.

In advancing that, the license I would write would be one that places the
software under a free license after some fixed date. You might state, for
software released in 2019, that starting in 2024 it will be licensed under the
GNU GPL. Until then, it would be licensed under some proprietary license,
perhaps the one you propose.

This forces people who use the software to pay for it's development, under
whichever terms the proprietary license requires. Simultaneously, it ensures
that those paying for it ultimately own the software, and therefore any
improvements they make to it.

~~~
nqzero
mariadb's Business Source License
([https://mariadb.com/bsl11](https://mariadb.com/bsl11)) is consistent with
what you describe, though without any assurances during the proprietary phase

possible that combining the two as you suggest would be the best of both
worlds. i need to think about the business implications for the author

------
julienfr112
the event-stream story remind me the true/false story of the color logs :
[https://hackernoon.com/im-harvesting-credit-card-numbers-
and...](https://hackernoon.com/im-harvesting-credit-card-numbers-and-
passwords-from-your-site-here-s-how-9a8cb347c5b5)

------
c-smile
The article reminds me posters of USSR time that I saw a lot:

"Soviet developers, make your application simpler and readable!"

"Soviet developers, be responsible, do not pass the code to strangers!"

"Soviet developers, read the code of your dependencies!"

"Soviet developers, do all this with a joy and free of charge!"

Replace "Soviet" by "FOSS" above or vice versa for your taste.

While basic ideas (e.g. Communist Party Manifesto as the Commandments it is
derived from) are perfect the merciless reality is not. Human nature, sigh.

~~~
syrrim
Well, free software _is_ communism, so it's not surprising.

