While I sympathize with the views here, I have some disagreements.
I think corporations are so often harmful in practice, that we can fall
into just seeing them as institutionally broken or evil all-too-often.
However, I see all sorts of potential for well-meaning large companies
to use something like copyleft-next explicitly to lock in certain
values, have community trust, look for abundance and cooperation with
other companies rather than competition etc. Sure, that may not be the
norm, but I think the potential is real. Businesses aren't necessarily
My favorite quote: "It is easier to avoid temptation than resist it" -
Without being aggressive to *start* with, when a situation arises and
loopholes are noticed, businesses leaders will be *tempted* to take
advantage of them (and usually will indulge). Initially well-intended
actors end up corrupt.
This isn't about branding, this is about literally giving the world
tools to consciously **avoid** temptations so that they need not later
resist them. It's not about what it's called.
If you discriminate about the entities that can use a license, then you
remove this avoid-temptation tool for a set of entities and set up
barriers to cooperation (and there's the whole issue of *temptation*
around writing new licenses that discriminate according to whoever's
political or economic goals, and I want us to avoid *that* temptation as
well as it is full of pitfalls and problems).
On 2020-01-08 7:22 a.m., Giacomo Tesio wrote:
Hi Kuhn, I've read this thread after your blog post, so sorry if
mixing comments about the two and considering even successive mails.
On 06/01/2020, Bradley M. Kuhn <bkuhn(a)ebb.org> wrote:
> I'd like to discuss whether:
> (0) the problem I described is real (I obviously think it is, otherwise I
> wouldn't be posting it :), but I'm open-minded about this)
This is an interesting question.
If I understand your point correctly, you are concerned about
corporate customers fooled to buy a proprietary software (practically
speaking, doesn't matter if through a proprietary license, an
exception, a BSD2+NDA trick or anything else) they don't need in the
first place by corporate open source vendors.
You are concerned about this aggressive practice because it hurts the
"copyleft brand" and ultimately reduce the adoption of copyleft
licenses such us copyleft-next.
Obviously, to seriously state how relevant this concerns are we would
need global statistics and global market analysis that we lack.
However (again, if I understood you properly) this is basically a
business-to-business issue, that indirectly affects users' freedoms:
corporate customers not sharing their improvements slow down the
software evolution from their perspective.
I can imagine that, in some specific contexts, this is a valid concern.
(and I guess you have a few data points that "inspired" you :-D).
Indeed, this is a form of "knowledge lock-in" (as I call it) is very
similar to another form of privatization / vendor lock-in typical in
open source: through the proper mix of permissive license, complexity,
patents, commercial agreements and overwhelming funds, you can have
formally open-source projects that are, in facts, proprietary.
Think for example of Android, Fuchsia or Chromium: while theoretically
everybody could distribute modified versions of such software,
practically speaking they are proprietary software no one could
REALLY, modify and redistribute.
> (1) whether my approach to solve it is on the right track at all, and
I'm afraid that it could be _too_ effective.
Let suppose that your approach works perfectly, is applied widely and
ultimately becomes the norm: no more aggressive use of copyleft from
Sharks being sharks, I guest they won't simply go out of business
crying: they will stop maintaining the open source version and
continue as proprietary developers (maybe with "source available").
You might argue that this is what's happening anyway, and in fact it's
what happening with Android, Chrome and many other OSS from large
BUT your solution won't touch such large corporations: they are using
permissive licenses anyway!
So ultimately, while your approach could work at solving _this_ issue,
I think we can easily foresee two perverse "Cobra effects":
1) to reduce OSS available (as some double
licensed software will become fully proprietary)
2) to strengthen the "knowledge lock-in" of large corporations
(such as GAFAM, for example) that don't need the legal
protection provided by copyleft as they benefit from even
stronger barriers to competitors
> (2) if anyone else has a different approach to address these problems.
Actually the Hacking License provides an alternative: restrict to
humans the grants but include a (conditioned) non-exclusive copyright
assignment (and patent license) upstream on any modified work,
Let suppose that an highly hypothetical Evil corporation that pretends
to "do no evil" start developing an open source software under such
license. Given they automatically get a non exclusive copyright on
derivative works, they could not ask for a separated CA (or it would
sound suspect, and they pretends to do no evil, after all).
But in the moment they violate the conditions, all copyright
assignments terminate TO THEM (not to anybody whose code has been
included in the work).
IOW, inbound restrictions > outbound restrictions.
That's because, with the greater power that all copyright holders gain
(up to the original authors) actually come greater and greater
practical restrictions to their abuse.
Just like your proposal, this approach prevents double licensing, but
it also address other forms of privatization of knowledge such as
SaaSS and the above described Power-play that turns even the most
permissively licensed software into a plain proprietary and (somewhat)
source available project.
PS Sorry for the long reply.
copyleft-next mailing list -- copyleft-next(a)lists.fedorahosted.org
To unsubscribe send an email to copyleft-next-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines