<div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Dec 13, 2019 at 2:53 AM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 11:30 PM Nigel T <<a href="mailto:nigel.2048@gmail.com" target="_blank">nigel.2048@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>On Thu, Dec 12, 2019 at 3:17 PM VanL <<a href="mailto:van.lindberg@gmail.com" target="_blank">van.lindberg@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The hypothetical then expanded again to user accounts, memberships, badges, user content, etc - the whole WordPress ecosystem. I can't say that the whole WordPress ecosystem would be able to easily comply. But you yourself identify that the information is stored in the database or the filesystem, and it is accessible, so compliance is possible. I would also note plugins like WP-all-export.</div></div></blockquote><div> </div><div>These specifics were provided to refute Henrik's assertion that WordPress has been 4.2 compliant for years. These are not "expanded hypotheticals" but counter-examples.</div></div></div></div></blockquote><div><br></div>Just to be clear, I of course agree that there can exist software that would not allow easy export of user data in a CAL compliant manner.</div></div></blockquote><div><br></div><div>If software CAN exist that is not CAL compliant and licensed under CAL then it's a compliance time bomb for every downstream user. Why should this be approved?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"> But I did feel compelled to point out that the initial Wordpress examples given by you and Bruce are in fact compliant! Only on your third attempt did you manage to present a sufficiently complicated scenario that it plausibly might not be compliant out of the box. Yet even then Van pointed out that there could exist and a user could easily install a plugin specifically designed to export all data of a given user, regardless of what arbitrary set of other plugins you had activated.</div></div></blockquote><div><br></div><div>Could exist and does exist are not the same. There is nothing in CAL that requires the original software to provide even rudimentary export capabilities. </div><div><br></div><div>Van insists that doing SQL queries is sufficient (even good) to meet CAL requirements and you believe that simply having the data appear as HTML somewhere fulfills the requirement. Of course, nothing is written in the license terms that indicates these are acceptable so we'd have to find out in a court of law if that's actually true. This would be in conflict with Bruce's opinion that "The open source definition means that you shouldn't need a lawyer just to be a user".</div><div><br></div><div>But lets say that it is...then 4.2 is relatively easy to be compliant with for professional service providers (folks actually likely to attempt user data lock in) so has very little value in terms of data portability and 4.2 can be safely removed because its a huge burden for non-technical OSS users.</div><div><br></div><div>But I think the intent is for 4.2 to be hard to be compliant with and I'll get to that below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">So I think this discussion - which raised a very valid question - has shown that in practice the current language in CAL will work well and while problematic cases can be constructed, they seem to be the exception and users should simply avoid such software, should they actually exist in the future.</div></div></blockquote><div><br></div><div>I think we should simply avoid approving this license because the problematic cases are very common for SaaS software. You assert that these cases are "an exception". What is your evidence that they are exceptions and not the norm? </div><div><br></div><div>There is are a vast amount of OSS software that would not be CAL compliant that the original authors could relicense under CAL if they wanted to. Nothing in CAL precludes them from doing so and they would be non-compliant out of the box for downstream users.</div><div><br></div><div>All the vendors of SaaS software that have long wanted an OSI approved license for their product marketing where no one could actually legally use their software without a lot of refactoring effort would be quite happy. After all, they don't care about non-compliance...they are the original authors and you can use their "open source product released under an OSI approved open source license" on their own servers all day without any issues.</div><div><br></div><div>That's interesting isn't it? I can release CAL licensed software as "open source" that no one but me can use without a lot of work because of non-compliance with 4.2. Someone like Amazon or Microsoft would have to decide between not competing with my cloud product, buying a commercial license from me or spending engineering resources to become 4.2 compliant and hope they got it right every time I released a new version. Not just my product but probably all of their cloud infrastructure that used my product as well. Oh and naturally all that infrastructure code has to get released too. If normal OSS users get locked out...well that's a shame, but it's just the cost of doing business. They weren't likely to be using my enterprise cloud product anyway.</div><div><br></div><div>Gosh, I wonder what companies might want an OSI approved license like that?</div><div><br></div><div>A little asymmetry in an OSS license can be okay but you need to carefully look at how that asymmetry can be abused before approval. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"></div><div class="gmail_quote">henrik</div></div>
</blockquote></div></div></div>