The wording implies that choosing a non-copyleft license means not caring about sharing and improvements #51
Comments
|
The three summaries on the landing page are there to highlight three common deciding factors that 99% of people choosing a license are likely to be primarily concerned with—they’re not meant to be exhaustive descriptions. Can you be more specific about what you believe should be changed? What does the site say that is incorrect? |
|
The exact part? There is nothing strictly incorrect in it, copyleft is about sharing. But non-copyleft open source is about sharing exactly as well, so caring about sharing should not be factor in choosing a particular open source license. And presenting a non-difference as a primary difference for 99% of people to base their decisions on is very flawed IMHO. |
|
Simply adding the word "enforced" or something similar (and perhaps less aggressive sounding?) might be all that's needed here. The real deciding factor here seems to not be encouraging sharing to happen, but rather mandating that it does. Heck, maybe something like...
|
|
Would something like:
…be a more correct alternative? |
|
Well, IMHO 'reciprocal sharing' is a difference between open source and shared source, not copyleft and non-copyleft, so it's not any better. |
|
Enforce sounds too strong. Makes me think this guy will show up at your doorstep and make you share. How about...
/cc @hoolio, @benbalter |
|
Perhaps 'mandate' is the word you're looking for, as per @tekkub's comment? Mind you, there's not much point using the GPL if one isn't going to enforce its mandates. And the end result of that would indeed be that, yes, some men with guns will show up at your door if that's what it takes. So, 'enforce' is not incorrect. |
At this point, it sounds like we're in agreement on the idea, it's just a matter semantics and whether "require" is different from "mandate" is different from "enforce." "Require" seems to strike the right balance and seems more colloquial and understandable than the other choices. |
|
Right. However, the problem with 'require' is that it could still be considered a (somewhat unpolite) request, whereas 'mandate' carries enough of an official nuance to it to indicate a legal requirement. |
|
That's just wayyy to heavy. Besides, the next sentence reads "require others...". I think it's pretty clear. Especially given that we have ~< 6 words to work with.
Couldn't you also say that non-Apache implies you don't care about patents, or non-MIT you don't care about simplicity? It's what's your deciding factor.
@cobyism that was the first pass ("reciprocity"), but that is a legal term of art that got flagged during review I think it's fine as is, but to clarify, "I'd like improvements |
|
The accuracy of the statement should take priority, however one thing that I think is important design wise is that whatever phrasing doesn’t push the heading onto three lines: |
|
@benbalter Beat me to the concern about visuals. :shakes_fist: |
|
Yeah, I'm fine with keeping it as-is. But here's one alternative that might keep in the spirit of the original while being a little stronger.
|
The site's priority isn't accuracy or comprehensiveness. TL;DR Legal and OSI already take care of those two checkboxes respectively. The top goal of the site should be to distill a complex legal decision down to its essential elements... making it as simple as possible for the developer looking to license his project. |
|
After thinking about this some more, I want to highlight two things. What @cobyism said, emphasis mine:
And something @benbalter said:
Wouldn't we all agree that the essential element, the primary deciding factor for most people who choose the GPS is not that they want to require that improvements be shared, but that they want the software to be forever free? The word "freedom" is all over their materials. I do agree, every license wants improvements shared. So the question is, have we really captured the distinguishing essential element for the GPL in that description? |
|
"Freedom" is a terribly vague word, especially if you're trying to explain the differences between the licenses. It's pretty reasonable to argue that everyone looking at an open source license cares about freedom. The thing is that the licenses approach it differently. I'm almost inclined to argue that the GPL text should read "I care about perpetuating my license". Ugh, this is getting complicated. The GPL's main goal (as I understand it) is to keep derivative works under the same license if redistributed, and therefore keep those derivative works "free". Yea, I guess I agree that "forever free" is the goal of going with the GPL, but how do we state that clearly? "I care about preserving freedom" feels like a terribly charged statement, bordering on flamebait for people to start the age-old fighting over licenses. We don't want that at all. How about this?
|
|
I actually like "perpetuating my license". "Freedom" and "free" is terribly vague. GPL might be one we can't easily summarize in 6 words. Another idea (just brainstorming) "I prefer copy-left licenses". Now some folks won't know what that means but the click through can explain. |
Right, and in case they don't know what it means, they'd probably be best off sticking with something simple (e.g. MIT) in the first place. |
|
🧠⚡ I insist my code be open source |
I actually kinda like that. If folks pick GPL, they're sorta getting into something a little bit deeper than if they went with MIT. Perhaps wording it such that they're likely to dig in deeper and understand what copyleft is before they pick it is a good thing. That sorta falls back to the idea of having a GPL-specific page that explains what the differences are in more detail. We could explain copyleft, the license perpetuation, and the differences between v2, v3, and LGPL.
Problem there is, private forks are totally possible with GPL as long as no redistribution is involved. |
|
I find it very disappoiting that the issue hasn't been resolved yet. |
|
@akdjka me too. Got any suggestions? Here's a few others:
We should remember that there's a blurb underneath the heading that provides more detail. So we don't need to explain everything in the header. Just the key point. And I think it's that changes can't be released under a closed license. |
|
/cc @hoolio or @benbalter any other thoughts? |
|
|
@engelnyst: This is a part of the definition of open source, opening must be irrevocable. 2Choosalicence staff: |
I think he meant for new versions. A specific version of open source code is irrevocable, but I can easily close my new additions to the code, unless the code is GPL. |
|
I suggest,
|
|
Hmm, interesting. I kind of like that. @benbalter thoughts? |
|
Rationale: I don't think GPL is about sharing. It's about the user being able to deal in the work without restriction, no matter how many hands it went through to get to the user. I don't think copy left is widely understood in the audience of this site. |
|
The term "copyleft" is too jargony and doesn't do much to demystify for a lay-user.
Copy isn't really the concern here. It's derivative works, which we'd been calling "improvements" to simplify. If you take my GPL'd software, download it, and then don't also post it, you've made a copy, that is not open source. The issue is if you make an improvement to it, and then attempt to distribute it. I like the direction though. How about:
|
|
similar to @benbalter but trying to be clear about distribution of modifications, I suggest something like
|
|
Uses can be private though, and it's important not to consider people by |
|
"I want my code to stay open source." It's hard to sum up GPL with a few words, isn't it? |
It sure is! We have to try to get to the essence if we can. What's the part that someone who doesn't know licensing will care about?
|
|
|
to clarify, this is what I just put forward:
|
|
Closing as stale, but if there's strong interest in resuming the discussion, please feel free to chime in. |
|
@haacked said,
I think my suggestion, |
|
didn't really seem stale to me. just in the end someone needs to make a call on a final version and that some might need to be someone that can also press the shiny merge button. but there are plenty of good proposals here. |
|
How about: "I want people to pay it forward" ? From what I gather, some people would want it to be "I want to require people to pay it forward". |
|
We could go with "I want to prioritize user freedom." That attacks the problem from a different angle (although it may require the blurb to be adjusted to match). Yes, it doesn't say anything about how this actually works legally, but I think that captures the intent, right? At least, the intent according to the FSF. |
JustificationI'm here, in a closed discussion, because @mlinksva specifically suggested that I add my thoughts here with regard to the current state of the copyleft summary's phrasing. I hope what I have to say helps. TL;DRThis is a wall-of-text analysis of the discussion, points raised, and my thoughts on the matter. The best options I've seen so far seem to be variations of one of the following:
Other suggestions all seem to come with fatal flaws, for reasons of flamebaity language or misleading implications. Wall-Of-Text BikesheddingI think it's worthwhile to distinguish between accuracy, completeness, and precision. We do not need to focus on precision of phrasing, because this is largely about giving people an immediate bit of help identifying desires and offering options. We do not want to focus on completeness in the form of comprehensive descriptions of the concerns for each licensing category; there is enough information and opinion in the world on this subject to fill a library. We do need to be accurate, in that the phrasing should not be misleading and should not step on toes too much. This is an inherently political matter, and both neutrality and avoidance of technical error is important to avoid becoming flame bait or having the opposite of the intended effect (leading people to choose something misaligned with goals instead of actually helping). One of the most overlooked requirements of accuracy is the case where one of the goals of a particular group is misidentified (perhaps only implicitly) as exclusive to that group when it might be common to more than one group (e.g. "I want my code to remain free"). Another of the most overlooked is the case where the goals advertised in the propaganda are actually at odds with the goals of a significant fraction of the people who choose a particular licensing category (e.g. corporate users of copyleft licenses whose real aim is to garner community support while maintaining an "intellectual property" advantage over competitors). That out of the way, the following operates on an assumption we all care about the above concerns. The problem with "enforced sharing" or "enforce sharing" is three-fold:
Numbers 2 and 3 are especially problematic for "require". The GPL literally mandates, however, so "mandate" is strictly accurate; same applies to "demand". I'm not optimistic about the acceptance level of those words to copyleftists, though (especially "demand"). I believe "simple and permissive" is quite appropriate for the category including the MIT License, in part because the conjunction of two characteristics of the license is fairly precise, in part because "we" should probably not be in the business of recommending complex copyfree licenses (to the extent they even exist), and in part because both terms exclude licenses such as AL2 and the most popularly known copyleft licenses. The fact further discussion has led to eliminating the references to AL2 as "a permissive license similar to the MIT License" helps straighten this part of it out. I think the artificial separation of accuracy and making the decision process simple/easy is misleading. If the representations are inaccurate, they mislead people's decision-making. Accuracy is important, though precision is less so, and comprehensiveness is definitely not particularly important in this case (in my estimation). If what you really want is "making it as simple as possible for the developer looking to license his project" without any concern for accuracy, you should just tell everyone to use the MIT License and not bother offering options at all. That's much simpler in every way, and does not provide accurate assessment of people's licensing preferences or accurate satisfaction those preferences. The point about distilling the copyleft choice to its essential motivating factor is a good one, though that motivating factor is not necessarily "copying", "freedom", or "open source". Even for those whose concern is some definition of "freedom", the same can be true of other license categories, and a more essential motivating factor applies in differentiating the licenses: perpetuity of terms. In some respects, copyleft licensing policy is the open source equivalent to the Sonny Bono copyright extension: it uses legal mandate to extend its terms (in spirit, toward infinity). Imagine my surprise when I saw that @tekkub came to the same conclusion, and (like me) found it difficult to formulate an appropriate, well-composed phrase to capture that essence. Speaking of caring that code remains open source is fraught with difficulty. It is likely to draw ire from both people who like the GPL and people who don't, because the former often despise the term "open source" (favoring "free software" instead) and the latter also often care that code "remains" open source and might pick fights over the application of the term "remains" (or "stays" or whatever). The suggestion of "want every copy to be open source" runs afoul of the both groups as well, because (again) the former might not like the term "open source" and the latter might also want every copy to be open source (but priortize other concerns of that concern, such as a different definition of freedom and openness, different philosophical reasons for liking open source software in the first place, and so on). Some more proposed phrasing seems to warrant special treatment:
If the copyleft summary's language ends up being something that could be just as easily applied to the other categories, it really should include some variation of "mandate". The idea of saying you want to "prioritize", instead of "mandate", freedom is dangerous; it is essentially propagandizing in favor of a particular category of license terms, thus turning the whole exercise into flamebait. The words "at least, the intent according to the FSF" specifically highlights this problem. On the subject of the AL2 section not including mandate-equivalent phrasing, I'd say it should also come with such a qualifier if the whole matter of AL2 phrasing had not been "solved" by not giving AL2 its own section. To sum up, I like these options (or close equivalents of them) more than others I've seen for hopefully avoiding flamebaity or misleading phrasing, in descending order of preference, with 1 indicating my favorite:
In short, I think the bikeshed should be a nice, deep, slate-ish grey-blue, matte finish but with a touch of metallic hue. |
|
Just my two cents: I think using positive language (I want to ensure X) is preferable to negative language (I want to prevent Y). That's the same reason that justifies the use of "protective" (instead of "restrictive") as the opposite of "permissive". The third option (deferring the definition to "copyleft") should not be considered IMO, for the reasons you mentioned yourself (it just kicks the can further down the road). So for what my opinion's worth, I think something along the lines of "I want any derivatives to preserve the end user's rights" (or any of the more concise formulations) might be the best bet for this admittedly hard-to-summarize concept. |
+1
+1
(2) also has "variations" that matches your "derivatives" and I think scope is important; using any license by definition perpetuates it ;) Thus I suggest:
|
This has problems regarding implied exclusivity of the sentiment and other issues I think I already addressed.
This is not as problematic for purposes of accuracy and identifying the actual difference, as I think I already mentioned. I really wish people would address all the identified problems before re-introducing a problematic formulation. You obviously have reasons to prefer your suggested phrasing, @waldyrious, but do you have any commentary at all on the series of objections raised to that kind of phrasing? |
I was hoping we could first agree on moving ahead with one general direction (hence my proposal to focus on option 2) and then refine it. I was under the impression that my previous comment (especially the bit about option 3) was in line with what you wrote yourself. Do you have objections to drop at least that option from the list? I am afraid that trying to discuss the complexities of all 3 options simultaneously may make progress quite harder, unless we can summarize the pros and cons of each option in a more manageable format -- say, a table. What do you think? |
|
I agree that just using the word "copyleft" and leaving it up to readers to have any clue what it means can be problematic in ways the other two options I identified are not problematic, so no, I don't have any objection to dropping that. Your proposed language did not strike me as related to what I indicated as an "option 2" enough to make me think it was an attempt to refine its language. Much of my reason for writing what I did was to emphasize the need to be both accurate and inclusive; I don't mean inclusive in the "be friendly" sense, though that's good too, but rather that when you say something you should consider whether you're implying exclusivity when the phrasing is actually inclusive. Thus, saying something in a manner that implies it is exclusive to the copyleft option when its meaning is actually inclusive of people choosing other licensing options seems directly contrary to my points above. To be more explicitly and directly clear: You said "I want any derivatives to preserve the end user's rights." This is a statement that could just as easily be made by someone who chooses a copyfree license instead of a copyleft license. It could also apply to people who choose licenses that are neither copyfree nor copyleft. It is, in other words, misleading to indicate that if that's what you want you should choose a copyleft license. EDIT: I'm not accusing you of being intentionally misleading, of course. I'm just pointing out that the phrasing is misleading. While copyleft proponents often do not see the misleading potential, that is because they equate "end user's rights" with copyleft policy, and without considering what proponents of other policies want, just as copyfree proponents often do not see the misleading potential in phrasing like their own uses of words like "restriction" at times, thinking in terms of how they equate legal restriction with rights restriction without considering that in their own way proponents of other polices may also want to free people from restrictions. Every group needs to learn to not only see things in terms of how they define things, but also how others define things, if they want to ever achieve clear communication on these matters. |
Precisely, it wasn't -- sorry if I wasn't clear about that. I don't actually feel qualified to refine the language (other than offering my interpretations as a layman, for what that might be worth), but as an end-user of licensed software, and someone moderately familiar with open source licensing, I believed I could offer an informed opinion on which of the 3 final options in your comment (after reading most of the concerns that preceded them) I thought we could get behind and continue the discussion with. I hope it might help if I clarify that the only parts of my initial comment that I deem essential were (a) agreeing that delegating the definition to "copyleft" is not terribly useful, from which I suggested dropping option 3; and (b) stating my preference for positive language rather than negative language, from which I suggested dropping roughly "option 1-like" formulations in favor of roughly "option 2-like" formulations. My adding of a concrete example of an option 2-like formulation was superfluous, and, understandably, ended up crossing a bunch of concerns you had raised before, and this turned up to be counterproductive. My goal, which I hope is clearer now, was merely to propose a coarse narrowing down of the options on the table, so that we could then focus on the nuances of how to word the chosen option in a way that preserved both accuracy and clarity. That said, I am willing to accept that directing the discussion in this constrained and top-down manner may not lead to the best results, and that an overall consideration of all possibilities simultaneously, with their nuances and trade-offs, might be needed to reach an optimal point in this wording landscape. But I hope that can be avoided, because as you surely will agree, this is a very complex subject with lots of concerns to balance out. |
|
I read this entire thread again, thanks for the additional recent contributions! I think @davelab6's old suggestion of It seems to overall complaint is that people who like permissive licenses also care about sharing improvements, so that I think the problem has been attenuated when the subheadings where changed, which now say directly whether closed source distribution is allowed. I'd like to use "protect[ive]" as it is a nice contrast with "permissive", and accurate, regarding what work the licensor wants the license to do, as opposed to what overall outcome wanted/cared about, and is true whether what one wants to protect is primarily other users' freedom, or their own control. Howabout |
|
Re single rights holder dual licensing: "I want every copy made to be open
source"?
|
|
"I want it to protect users' freedom."?
Software isn't a subject, it's a class of object.
People are subjects who enjoy freedom.
|
|
Just a note about the "it": my reading of the sentence "I want it simple and permissive" doesn't associate the "it" with neither the license nor the software, but rather to a generic state of affairs, as in "I want things simple and permissive." This is what feels more natural to me, probably also due to the leading question, "Which of the following best describes your situation?", and due to the phrasing of the first and second options. If we do want to use "it" as unambiguously referring to the license, we might want to change the leading question to something like "What kind of license do you prefer?", and also adapt the first answer -- perhaps to something like "I want it to fit the community I'm working with.") |
|
I'm not sure whether this will surprise anyone, but: While I might quibble with some of the language and judgements @mlinksva used to arrive at his conclusion, I find the final conclusion presented at least somewhat acceptable, given the challenges involved in trying to make everyone happy-ish with the results of this exercise:
I have pondered in the past whose freedom copyleft licenses really protect, primarily. Initial developers often don't even see the results of their licensing, really, so it's difficult to pick them, even though initial developers who are explicitly trying to keep commercial competitors from bootstrapping from their work do at least tend to get some benefit. Downstream developers are sometimes given the shaft by mounting administrative overhead in license compliance, or restriction of the ability to develop some types of derivative works (e.g. some Linux+ZFS distribution strategies), and even users are sometimes placed in the unenviable position of (usually unknowingly) illegally distributing copyleft works. If you consider software as a thing that has rights, though, "software freedom" takes on a whole new meaning, and it becomes the clear winner. Sure, this is kind of a tongue-in-cheek analysis, but it happens to coincide with a justification of sorts for the most recent suggestion from @mlinksva (along with the more serious justifications already provided). In my opinion, it's a significant improvement over the language currently on choosealicense.com, and it definitely feels at least "close enough for now", so I say go for it until there's any kind of universally-ish acceptable improvement alternative. I also think @waldyrious made a good point about the question preceding the three answers. The question as phrased on the website is a smidgen clunky in its current form, anyway. I might just amend the language of the proposed new question to say something like permissions, terms, or other phrasing than license, but I'm not really strongly opposed to the use of the word "license" there, either. Writing, it turns out, can be difficult sometimes, as I learned from doing it professionally for a while. Incremental improvements that don't come with notable issues are sometimes the best success we can hope to achieve. |
|
@davelab6 - I think the point you raised is a point of contention over "Free Software" philosophy itself, actually. On one hand, your statement is probably an acceptable point to raise about the problems of copyleft licensing from the point of view of copyfree licensing proponents, so I'm not sure that really detracts from the appropriateness of the phrasing @mlinksva proposed. On the other hand, "software freedom" is actually within the sphere of acceptable, or even preferred, jargon amongst many copyleft licensing proponents -- and thus probably acceptable phrasing here from that perspective as well. In this case, I think perhaps the fact your criticism of the phrasing matches up so well with the criticisms from an idealistic perspective that it's a wholly appropriate choice of phrasing in some sense. |
|
Thanks for pointing out some additional ways the language on the home page is a smidgen clunky or ambiguous. I'd like to fix this (which requires more than just changing the GPL heading), indeed I was interested in more discussion on this issue largely because I'm planning to enable translations soon, and one way to make that easier and better is to start from easily understood English (which also aligns with the project's aims). I'll probably make a PR with small edits to a few of the strings on the home page reflecting above, soonish, and can discuss there. |
|
@mlinksva - I'm glad this has some value. I worry at times that I might just be bikeshedding. |
The way you present non-copyleft licenses is very, very incorrect.
I'm yet to see an open source project that wouldn't care about improvements. They all want contributions, but permissive ones choose not to try to force others to contribute (for various reasons).
The text was updated successfully, but these errors were encountered: