So, the current draft says this:
If I distribute a Covered Work under a Proprietary License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3. "Proprietary License" means a license which (i) is not royalty-free, (ii) does not permit distribution, (iii) does not permit preparation of derivative works, (iv) limits the number of licensed users or copies, and/or (iv) contains field-of-use restrictions.
I've often called this one of the most interesting, novel, and ingenious features that Fontana has promulgated in copyleft-next. Admittedly, as some of you probably recall from various ancient HBR cures, I lobbied Fontana pretty hard 5-7 years ago for a solution to proprietary relicensing, so I suppose he felt pressure to come up with something. I am glad my persistent complaining brought a great copyleft clause into existence. ;)
Anyway, I have been studying this clause lately and I think it has a bug. Here's the loophole scenario I can think of:
* Proprietary Relicensing Vendor ("Vendor") sets up a usual proprietary relicensing "prep system" (i.e., CLAs giving them full powers to relicense etc), and makes their outbound license copyleft-next.
* Optional, but "helpful" to Vendor's cause: Vendor also takes technological measures in the software that make it difficult to get to a full CCS situation (i.e., the stuff is hard to build, or whatever).
* Vendor finds Downstream in violation of copyleft-next, and Downstream cannot comply within 30 days, either because Vendor "set them up", or just mundane confusion about copyleft compliance.
And, here's the key part:
* Vendor offers Downstream not a *Proprietary* License, but a permissive FOSS license for a fee (say, 2-Clause-BSD).
* Optional: Vendor demands an NDA about the whole situation and negotiation.
The user base is effectively "divided and conquered", since at that point the Downstream has a business relationship with Vendor and (possibly) also can't afford to violate the NDA by telling anyone. Without the NDA, of course, Downstream would have the right to distribute under the 2-Clause-BSD -- but why would they? They just paid a lot of money to get that, and they just give it to their competition? There are few business who would care about software freedom enough to do that.
I think *maybe* this problem (if real) could be remedied with a deflation of proprietary relicensing clause that reads something more like this:
If I distribute a Covered Work under any license (except pursuant to 6(a-c)) other than this License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3.
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)
(1) whether my approach to solve it is on the right track at all, and
(2) if anyone else has a different approach to address these problems.
My specific concerns regarding (1) is that I have this sinking feeling that some of the "escape hatches" away from pure copyleft (i.e., "only under this License and nothing else") that 6(a-c) currently provide might *also* be used for some form of proprietary relicensing tomfoolery as well. I am also not clear whether (a) my clause still functions coherently if you yank the "except pursuant to 6(a-c)", and/or (b) whether the mere existence of 6(a-c) means there will always be some way for tomfoolery no matter how we chose to deflate proprietary relicensing.
[ BTW, in researching and thinking about what became this email (and a blog post I'll be putting up soon generally about proprietary relicensing), I realized "nullification of copyleft" is a problematic phrase for this license feature, so as you see I've been calling it "deflation of proprietary relicensing" -- sort of imagining copyleft as a balloon that gets deflated if upstream tries to proprietary relicense. I'm getting used to the term, but if others have better ideas, let's discuss that too. License adoption is obviously also about marketing, so we need good phrases to get attention for coypleft-next. Minor HBR Cure related to this: I talked with Fontana last week on IRC about what terminology might work better and we couldn't really come up with anything that I thought was compelling. I came up with "deflation" as a word choice a few days later on my own. ]
Ok, enough of a core-dump. I've obviously been thinking about this on my own for a number of weeks so I now really would love to read what all of you think.
Welcome (back) bkuhn! I think we may have an overdue HBR (Hindering Backchannels Rule) cure from last April but I am no longer sure.
On Sun, Jan 5, 2020 at 8:34 PM Bradley M. Kuhn bkuhn@ebb.org wrote:
So, the current draft says this:
If I distribute a Covered Work under a Proprietary License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3. "Proprietary License" means a license which (i) is not royalty-free, (ii) does not permit distribution, (iii) does not permit preparation of derivative works, (iv) limits the number of licensed users or copies, and/or (iv) contains field-of-use restrictions.
I've often called this one of the most interesting, novel, and ingenious features that Fontana has promulgated in copyleft-next. Admittedly, as some of you probably recall from various ancient HBR cures, I lobbied Fontana pretty hard 5-7 years ago for a solution to proprietary relicensing,
Actually this was something we used to discuss in public long before inception of copyleft-next, at least as far as I can remember.
so I suppose he felt pressure to come up with something. I am glad my persistent complaining brought a great copyleft clause into existence. ;)
It's definitely true that you are the original inspiration of the clause.
Anyway, I have been studying this clause lately and I think it has a bug. Here's the loophole scenario I can think of:
Proprietary Relicensing Vendor ("Vendor") sets up a usual proprietary relicensing "prep system" (i.e., CLAs giving them full powers to relicense etc), and makes their outbound license copyleft-next.
Optional, but "helpful" to Vendor's cause: Vendor also takes technological measures in the software that make it difficult to get to a full CCS situation (i.e., the stuff is hard to build, or whatever).
Vendor finds Downstream in violation of copyleft-next, and Downstream cannot comply within 30 days, either because Vendor "set them up", or just mundane confusion about copyleft compliance.
And, here's the key part:
Vendor offers Downstream not a *Proprietary* License, but a permissive FOSS license for a fee (say, 2-Clause-BSD).
Optional: Vendor demands an NDA about the whole situation and negotiation.
The user base is effectively "divided and conquered", since at that point the Downstream has a business relationship with Vendor and (possibly) also can't afford to violate the NDA by telling anyone. Without the NDA, of course, Downstream would have the right to distribute under the 2-Clause-BSD -- but why would they? They just paid a lot of money to get that, and they just give it to their competition? There are few business who would care about software freedom enough to do that.
I'm somewhat confused about this hypothetical. Is it the NDA that is keeping the violating vendor from continuing to vend software that contains copyleft-next'd code? I guess you're assuming that the violation is some sort of interesting "derivative work" kind of violation, of the sort that is relatively atypical of GNU GPL violations? Otherwise they wouldn't care about giving anything to their competition, unless (as is admittedly true of some companies in the GPL setting) they mistakenly see some sort of proprietary value in their modifications?
I think *maybe* this problem (if real) could be remedied with a deflation of proprietary relicensing clause that reads something more like this:
If I distribute a Covered Work under any license (except pursuant to 6(a-c))
(More specifically, "except pursuant to 6(a)" [stuff under compatible licenses], right?)
other than this License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3.
Hmm, this is more like what we had in the most recent release (0.3.1):
"If I offer to license, for a fee, a Covered Work under terms other than a license that is OSI-Approved or FSF-Free as of the release date of this License or a numbered version of copyleft-next released by the Copyleft-Next Project, then the license I grant You under section 1 is no longer subject to the conditions in sections 3 through 5."
Maybe we should go back to that? At the moment I can't remember why this was changed. Though it may still have the tomfoolery problem you're pointing to.
My specific concerns regarding (1) is that I have this sinking feeling that some of the "escape hatches" away from pure copyleft (i.e., "only under this License and nothing else") that 6(a-c) currently provide might *also* be used for some form of proprietary relicensing tomfoolery as well. I am also not clear whether (a) my clause still functions coherently if you yank the "except pursuant to 6(a-c)", and/or (b) whether the mere existence of 6(a-c) means there will always be some way for tomfoolery no matter how we chose to deflate proprietary relicensing.
[ BTW, in researching and thinking about what became this email (and a blog post I'll be putting up soon generally about proprietary relicensing), I realized "nullification of copyleft" is a problematic phrase for this license feature, so as you see I've been calling it "deflation of proprietary relicensing" -- sort of imagining copyleft as a balloon that gets deflated if upstream tries to proprietary relicense. I'm getting used to the term, but if others have better ideas, let's discuss that too. License adoption is obviously also about marketing, so we need good phrases to get attention for coypleft-next. Minor HBR Cure related to this: I talked with Fontana last week on IRC about what terminology might work better and we couldn't really come up with anything that I thought was compelling. I came up with "deflation" as a word choice a few days later on my own. ]
I'm not wedded to "nullification" (though I'm not sure I like "deflation", but I can't think of anything better). BTW, prior to copyleft-next 0.2.0 the ancestral section was called "Effect of Proprietary Relicensing".
Richard
First, the NDA thing was not really necessary and I almost left it out my example (and should have). FWIW, the reason I put it in there was to communicate the idea that there might be some reason the Downstream was forbidden from mentioning the deal itself, and thus the public wouldn't know they had new permissions under copyleft-next.
But let's leave my NDA out of it -- it muddies the example. Let's focus on this being the reason the Downstream never distributes:
Downstream would have the right to distribute under the 2-Clause-BSD -- but why would they? They just paid a lot of money to get that, and they just give it to their competition? There are few business who would care about software freedom enough to do that.
I brought *that* up because I was expecting you to say: "Oh, if Vendor sells Downstream a 2-Clause-BSD, then Downstream can just post it on the Internet, and everyone else effectively *has* the same license anyway." Let's just assume that won't happen for the reasons I stated above (or other ones):
I think *maybe* this problem (if real) could be remedied with a deflation of proprietary relicensing clause that reads something more like this:
If I distribute a Covered Work under any license (except pursuant to 6(a-c))
(More specifically, "except pursuant to 6(a)" [stuff under compatible licenses], right?)
Yeah, more focused on 6(a) but also not sure if 6(b-c) have impact on or interaction bug with my proposed rewrite of this clause. Do they?
"If I offer to license, for a fee, a Covered Work under terms other than a license that is OSI-Approved or FSF-Free as of the release date of this License or a numbered version of copyleft-next released by the Copyleft-Next Project, then the license I grant You under section 1 is no longer subject to the conditions in sections 3 through 5."
Maybe we should go back to that? At the moment I can't remember why this was changed. Though it may still have the tomfoolery problem you're pointing to.
Actually, that old version is "even worse" in this regard, because it explicitly *permits* Vendor to sell 2-Clause-BSD versions of the software to Downstreams.
We can't forbid them from doing this outright, because in the examples we're worried about, they're the sole copyright holder. What I'm trying to do is:
(a) make sure that the Vendor is *highly disincentivezed* from selling non-copylefted licenses to the software,
(b) all copyleft requirements deflate on all copyrights Vendor holds on any Covered Works, everywhere, at the very moment any non-copyleft license is sold.
(c) That the public has a way to find out if (a) and/or (b) have happened.
I think the current draft does much better at these jobs than any other version, but I still think there is the "non-copyleft FOSS license loophole" in both versions.
If it weren't for 6(a), BTW, I would probably just write it this way:
If I distribute a Covered Work under any license other than this License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3.
Basically, this clause itself must be a copyleft clause (sorry for the recursion), in that it must apply to all Covered Works *and* confine the behavior (namely, the permanent relaxation of all *other* copyleft requirements for every Covered Work controlled by given "I" (in the problematic case, the sole licensor). We also have to be sure, BTW, that it doesn't relax copyleft for any other "I"s (i.e., copyright holders who may have made Covered Works by combining/adding their own copyrighted material downstream).
I *think* this 'just works' but I'm wondering if there are bugs? I also really wanna explore how 6(a) interacts. (I assume 6(a) is there to get some GPLv3/AGPLv3 compatibility? I'm not completely sure 6(a) works right anyway, so maybe that's why I'm all worried about how 6(a) will interact with this section.)
I'm not wedded to "nullification" (though I'm not sure I like "deflation", but I can't think of anything better). BTW, prior to copyleft-next 0.2.0 the ancestral section was called "Effect of Proprietary Relicensing".
After I posted my email yesterday, I thought of a new section name for this section: "Copyleft Equality Clause". And, we could still call the *outcome* the clause causes as "deflating proprietary relicensing".
-- Bradley M. Kuhn - he/him
Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Mon, Jan 6, 2020 at 6:00 PM Bradley M. Kuhn bkuhn@ebb.org wrote:
But let's leave my NDA out of it -- it muddies the example. Let's focus on this being the reason the Downstream never distributes:
Downstream would have the right to distribute under the 2-Clause-BSD -- but why would they? They just paid a lot of money to get that, and they just give it to their competition? There are few business who would care about software freedom enough to do that.
I brought *that* up because I was expecting you to say: "Oh, if Vendor sells Downstream a 2-Clause-BSD, then Downstream can just post it on the Internet, and everyone else effectively *has* the same license anyway." Let's just assume that won't happen for the reasons I stated above (or other ones):
I think *maybe* this problem (if real) could be remedied with a deflation of proprietary relicensing clause that reads something more like this:
If I distribute a Covered Work under any license (except pursuant to 6(a-c))
(More specifically, "except pursuant to 6(a)" [stuff under compatible licenses], right?)
Yeah, more focused on 6(a) but also not sure if 6(b-c) have impact on or interaction bug with my proposed rewrite of this clause. Do they?
I'm not seeing how 6(b) or 6(c) have an impact.
"If I offer to license, for a fee, a Covered Work under terms other than a license that is OSI-Approved or FSF-Free as of the release date of this License or a numbered version of copyleft-next released by the Copyleft-Next Project, then the license I grant You under section 1 is no longer subject to the conditions in sections 3 through 5."
Maybe we should go back to that? At the moment I can't remember why this was changed. Though it may still have the tomfoolery problem you're pointing to.
Actually, that old version is "even worse" in this regard, because it explicitly *permits* Vendor to sell 2-Clause-BSD versions of the software to Downstreams.
Yeah, that isn't what was meant by "by a fee" but the language is confusing.
We can't forbid them from doing this outright, because in the examples we're worried about, they're the sole copyright holder. What I'm trying to do is:
(a) make sure that the Vendor is *highly disincentivezed* from selling non-copylefted licenses to the software,
(b) all copyleft requirements deflate on all copyrights Vendor holds on any Covered Works, everywhere, at the very moment any non-copyleft license is sold.
(c) That the public has a way to find out if (a) and/or (b) have happened.
I think the current draft does much better at these jobs than any other version, but I still think there is the "non-copyleft FOSS license loophole" in both versions.
If it weren't for 6(a), BTW, I would probably just write it this way:
If I distribute a Covered Work under any license other than this License, then the licenses I grant You under section 1 are no longer subject to the conditions in sections 2 and 3.
Basically, this clause itself must be a copyleft clause (sorry for the recursion), in that it must apply to all Covered Works *and* confine the behavior (namely, the permanent relaxation of all *other* copyleft requirements for every Covered Work controlled by given "I" (in the problematic case, the sole licensor). We also have to be sure, BTW, that it doesn't relax copyleft for any other "I"s (i.e., copyright holders who may have made Covered Works by combining/adding their own copyrighted material downstream).
I *think* this 'just works' but I'm wondering if there are bugs? I also really wanna explore how 6(a) interacts. (I assume 6(a) is there to get some GPLv3/AGPLv3 compatibility? I'm not completely sure 6(a) works right anyway, so maybe that's why I'm all worried about how 6(a) will interact with this section.)
I'm not convinced this is a realistic enough problem to be worth worrying about. Maybe I need to think about it some more or have an off-list discussion with you (obviously which will then be timely Hindering Backchannels Rule cured).
By "this" I think I mean "offering a more permissive free software license in return for money, with no other strings attached". That's essentially the scenario, right? When has that ever been done though? (I am aware of something arguably analogous to this but only involving the GPL.) If I was the would-be copyleft inequality vendor I wouldn't try something so reckless (from a business standpoint). The vendor is banking on the customer being unlikely to exercise their BSD rights because of, essentially, something akin to sunk costs?
I don't know if you and I are the only ones still reading this list (which I'm afraid has been mostly dormant given the mostly dormant nature of copyleft-next during the past few years) but if anyone else is reading I'd love to know their comments. :)
Richard
On Tue, Jan 7, 2020 at 1:54 PM Richard Fontana fontana@sharpeleven.org wrote:
I don't know if you and I are the only ones still reading this list
You're not!
(which I'm afraid has been mostly dormant given the mostly dormant nature of copyleft-next during the past few years) but if anyone else is reading I'd love to know their comments. :)
I lack the sophistication to grok the discussion on this particular topic, so I'll refrain from adding anything other than a reassurance that someone is still paying attention. :-)
On 2020-01-07 10:54 a.m., Richard Fontana wrote:
By "this" I think I mean "offering a more permissive free software license in return for money, with no other strings attached". That's essentially the scenario, right? When has that ever been done though? (I am aware of something arguably analogous to this but only involving the GPL.) If I was the would-be copyleft inequality vendor I wouldn't try something so reckless (from a business standpoint). The vendor is banking on the customer being unlikely to exercise their BSD rights because of, essentially, something akin to sunk costs?
I read this exchange and I think I followed it all, even Bradley's initial points with NDA mention.
I can't predict or read the minds of the business owners, but the premise seems worth worrying about to me.
A BSD license with an NDA around the sale of it would mean:
- the business *could* publish under BSD and share with the world - but they'd be barred from answering the question, "how did you get this under BSD??" - and that awkwardness could have various lawyers saying that the business should limit activities that would prompt such questions (including providing any public BSD derivative projects)
The NDA scenario from the original licensor's view could be about hiding their undermining of copyleft and discouraging the BSD licensee from publishing derivatives.
Anyway, separate from the NDA, a business with a BSD license that they never share has comparable advantage as having a proprietary license to make derivatives. They have an incentive to not share under BSD in order to have exclusive ability to make proprietary derivatives while competitors are stuck with copyleft.
--- Aaron Wolf Snowdrift.coop
Richard Fontana wrote:
By "this" I think I mean "offering a more permissive free software license in return for money, with no other strings attached". That's essentially the scenario, right? When has that ever been done though? (I am aware of something arguably analogous to this but only involving the GPL.)
As am I, and we're probably thinking of the same company.
I think that proprietary relicensors would use this in practice if they could. Heck, they could simply give the software under LGPL and it would still defeat the strong copyleft of copyleft-next for a proprietary relicensing effect.
I really think many customers aren't as savvy as you're thinking, because in the anecdata I've been able to collect (since business negotiations are private, unlike coyleft-next discussion ;), many customers who bought licenses from the most aggressive proprietary reliensors generally didn't even need them for the activities they wanted to do. They may often not even *realize* they're getting the code itself under 2-Clause BSD, even if the contract says so, just as customers of AGPL and/or GPL relicensors didn't realize they were already in compliance if they they did what they were planning.
If I was the would-be copyleft inequality vendor I wouldn't try something so reckless (from a business standpoint).
Not as your primary business, but possible as a side hustle. If the side hustle went well, it might become the main business, just like happened with MySQL, etc.
The vendor is banking on the customer being unlikely to exercise their BSD rights because of, essentially, something akin to sunk costs?
Yes, but also remember they could drop the party as a customer if they *did* redistribute the BSD version.
I guess the other argument for my change is it does make the license shorter. :) Why do we really need to define proprietary license? Just make it "any license except this license" and exclude 6(c) .. why not?
Also, I think Aaron Wolf makes some good points, although at least one of them was a point I was trying to make, but better stated, so that's not surprising that I like those comments. :)
And Richard, happy to discuss in person: HBR disclosures are fun to write. :) -- Bradley M. Kuhn - he/him
Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Tue, Jan 07, 2020 at 01:54:31PM -0500, Richard Fontana wrote:
On Mon, Jan 6, 2020 at 6:00 PM Bradley M. Kuhn bkuhn@ebb.org wrote:
I don't know if you and I are the only ones still reading this list (which I'm afraid has been mostly dormant given the mostly dormant nature of copyleft-next during the past few years) but if anyone else is reading I'd love to know their comments. :)
I'm still out here and following along as best I can. I am no longer working for Uncle Sam so some restrictions on me are off.
While I'm trying to get ready for a Table Top Exercise after the West Freeway Church of Christ incident I'm looking at Bradley's scenario and finding it simply difficult to believe. Are there precedents or similar scenarios that lead to such behavior being exhibited? I need a better baseline to judge against.
Stephen Michael Kellat
Hi Kuhn, I've read this thread after your blog post, so sorry if I'm mixing comments about the two and considering even successive mails.
On 06/01/2020, Bradley M. Kuhn bkuhn@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 corporations.
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 corporations.
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, recursively.
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.
Giacomo PS Sorry for the long reply.
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 all sharks.
My favorite quote: "It is easier to avoid temptation than resist it" - Dan Ariely
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).
- Aaron
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 I'm mixing comments about the two and considering even successive mails.
On 06/01/2020, Bradley M. Kuhn bkuhn@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 corporations.
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 corporations.
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":
- to reduce OSS available (as some double licensed software will become fully proprietary)
- 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, recursively.
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.
Giacomo PS Sorry for the long reply. _______________________________________________ copyleft-next mailing list -- copyleft-next@lists.fedorahosted.org To unsubscribe send an email to copyleft-next-leave@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 List Archives: https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahoste...
On 08/01/2020, Aaron Wolf wolftune@riseup.net wrote:
Businesses aren't necessarily all sharks.
While I sympathize with your optimism I'm afraid that exceptions are irrelevant.
Corporation are organization made of humans but operating on different dimensions than humans: as they grow, each person progressively becomes as relevant as a single cell to your whole body. We can define them "evil" only if we judge them by human standards (which is pointless) and from a human perspective. They simply adapt to the (legal/political/economical) environment.
(also, I was following Kuhn depiction of aggressive copyleft's violation seekers that build a business model out of their customers' lawyers' fears :-D).
My favorite quote: "It is easier to avoid temptation than resist it" - Dan Ariely
Not bad, but it's not a matter of temptation: it's survival of the fittest into an highly competitive system designed to maximize wealth concentration.
Surely, it's a matter of "Communion": how can we protect what we want to keep in common (from latin "cum munis", mutually obliged) from "the tragedies of the garbage" (a more proper depiction Hardin's famous essay)?
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.
Exactly.
The point is how turning a copyleft (a form of _protection_ that keep software _evolution_ in the commons) to a permissive license (a form of _permission_ that allows privatization) is going to benefit the community that is defined around the software itself.
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
This appears as a good objection as long as you consider that all entities that _could_ use a licensed work (and thus accept the license) are actually constituted by humans.
So practically speaking such humans would be unrestricted to do anything as long as they (equally) follows the conditions. So there is no practical barrier to any human nor to their collaboration.
What if organizations cannot become copyright holders of derivative works? You break a fundamental assumption that give them a reason to compete through knowledge lock-in and privatization.
Giacomo
Well, seems we agree on all the fundamentals (and I don't think I'm actually more optimistic than you). I accept all you just wrote. I very much acknowledge (as does Dan Ariely, incidentally) that tons of corruption comes from just the design of systems even absent human temptations; game theory etc.
I happen to be highly critical of the entire institution of copyrights and patents. My starting point for planning a fantasy world around this would be (A) abolish copyright and patent laws (B) prohibit DRM and (C) mandate source release for all *published* works. But this is quite tangential to writing a copyright license that takes us as far as as we can within today's system.
I think copyright licenses that cannot be applied to corporate entities and only to natural people are likely to just set up a hard wall between worlds. In principle, the employees could make use of such a license, but I'm more optimistic about copyleft-next getting accepted within such businesses than I am about discriminatory licenses.
On 2020-01-08 8:46 a.m., Giacomo Tesio wrote:
On 08/01/2020, Aaron Wolf wolftune@riseup.net wrote:
Businesses aren't necessarily all sharks.
While I sympathize with your optimism I'm afraid that exceptions are irrelevant.
Corporation are organization made of humans but operating on different dimensions than humans: as they grow, each person progressively becomes as relevant as a single cell to your whole body. We can define them "evil" only if we judge them by human standards (which is pointless) and from a human perspective. They simply adapt to the (legal/political/economical) environment.
(also, I was following Kuhn depiction of aggressive copyleft's violation seekers that build a business model out of their customers' lawyers' fears :-D).
My favorite quote: "It is easier to avoid temptation than resist it" - Dan Ariely
Not bad, but it's not a matter of temptation: it's survival of the fittest into an highly competitive system designed to maximize wealth concentration.
Surely, it's a matter of "Communion": how can we protect what we want to keep in common (from latin "cum munis", mutually obliged) from "the tragedies of the garbage" (a more proper depiction Hardin's famous essay)?
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.
Exactly.
The point is how turning a copyleft (a form of _protection_ that keep software _evolution_ in the commons) to a permissive license (a form of _permission_ that allows privatization) is going to benefit the community that is defined around the software itself.
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
This appears as a good objection as long as you consider that all entities that _could_ use a licensed work (and thus accept the license) are actually constituted by humans.
So practically speaking such humans would be unrestricted to do anything as long as they (equally) follows the conditions. So there is no practical barrier to any human nor to their collaboration.
What if organizations cannot become copyright holders of derivative works? You break a fundamental assumption that give them a reason to compete through knowledge lock-in and privatization.
Giacomo
copyleft-next@lists.fedorahosted.org