[License-discuss] Conservancy FSF announce copyleft.org
The announcement below may be of interest to subscribers of this list. I apologize in advance if it's not. -- bkuhn ## URLs Related to this Announcement: Conservancy Announcement: https://sfconservancy.org/news/2014/nov/07/copyleft-org/ FSF Announcement: http://fsf.org/news/software-freedom-conservancy-and-free-software-foundation-announce-copyleft.org Copyleft.org: https://copyleft.org copyleft.org Mailing Lists: https://lists.copyleft.org/ Pristine CCS Example: http://copyleft.guide/pristine-example/ Announcement on Twitter: https://twitter.com/conservancy/status/530759451989786624 Pump.io/Identi.ca: https://identi.ca/conservancy/note/qSdiuSFaRuqrqO5lULbNZg ## Conservancy and FSF announce copyleft.org Copyleft Guide Now Includes a Pristine CCS Example Analysis Software Freedom Conservancy and the Free Software Foundation announce today an ongoing public project that began in early 2014: *Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide*, and the publication of that project in its new home on the Internet at copyleft.org. This new site will not only provide a venue for those who constantly update and improve the Comprehensive Tutorial, but is also now home to a collaborative community to share and improve information about copyleft licenses (especially the GNU General Public License (GPL)) and best compliance practices for those licenses. Bradley M. Kuhn, President and Distinguished Technologist of Software Freedom Conservancy and member of FSF's Board of Directors, currently serves as editor-in-chief of the project. The text has already grown to 100 pages discussing all aspects of copyleft — including policy motivations, detailed study of the license texts, and compliance issues. This tutorial was initially constructed from materials that Kuhn developed on a semi-regular basis over the last eleven years. Kuhn merged this material, along with other material regarding the GPL published by the FSF, into a single, coherent volume, and released it publicly for the benefit of all users of Free Software. Today, Conservancy announces a specific, new contribution: an additional chapter to the Case Studies in GPL Enforcement section of the tutorial. This new chapter, co-written by Kuhn and Conservancy's Compliance Engineer, Denver Gingrich, discusses in detail the analysis of a complete, corresponding source (CCS) release for a real-world electronics product, and describes the process that Conservancy and the FSF use to determine whether a CCS candidate indeed complies with the requirements of the GPL. The CCS analyzed is for ThinkPenguin's TPE-NWIFIROUTER wireless router, which was recently given FSF's prestigious Respects Your Freedom (RYF) certification.. This copyleft guide itself is freely distributed under copyleft, using the Creative Commons Attribution-ShareAlike 4.0 International license, the primary copyleft license used for works of textual authorship in natural languages. Kuhn, who hopes the initial release and this subsequent announcement will inspire others to contribute to the guide, stated: information about copyleft — such as why it exists, how it works, and how to comply — should be freely available and modifiable, just as all generally useful technical information should. I am delighted to impart my experience with copyleft freely. I hope, however, that other key thinkers in the field of copyleft will contribute to help produce the best reference documentation on copyleft available. Particularly useful are the substantial contributions already made to the guide from the FSF itself. As the author, primary interpreter, and ultimate authority on the GPL, the FSF is in a unique position to provide insights into understanding free software licensing. While the guide as a living text will not automatically reflect official FSF positions, the FSF has already approved and published one version for use at its Seminar on GPL Enforcement and Legal Ethics in March 2014. John Sullivan, Executive Director of the FSF, noted, Participants at our licensing seminar in March commented positively on the high quality of the teaching materials, including the comprehensive guide to GPL compliance. We look forward to collaborating with the copyleft.org community to continually improve this resource, and we will periodically review particular versions for FSF endorsement and publication. Enthusiastic new contributors can get immediately involved by visiting and editing the main wiki on copyleft.org, or by submitting merge requests on copyleft.org's gitorious site for the guide, or by joining the project mailing list and IRC channel. copyleft.org welcomes all contributors. The editors have already incorporated other
Re: [License-discuss] Red Hat compilation copyright RHEL contract
Patrice-Emmanuel Schmitz wrote at 04:31 (EDT): Frequent cases are submitted when developers (in particular European administrations and Member states) have build applications from multiple components, plus adding their own code, and want to use a single license for distributing the whole compilation. While the description you give there is a bit too vague to analyze against the USA copyright statue (i.e., the example lacks any real world facts), I'd suspect that the default case of that situation, at least in the USA, is the creation of a new single work that derives from those components, plus their own code. The compilation copyright situation, at least in the USA, comes up more with putting a bunch of unrelated works on the same medium, like a CD ISO image. Making a single work of software that includes many components is very different from mere compilation. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Al Re: Red Hat compilation copyright RHEL contract
Quoting Luis Villa (l...@lu.is): We have dropped Al from the list, as we believe he is Alexander Terekhov, and he refused to deny it when asked. Rick Moen wrote at 18:28 (EDT) on Monday: The authorial 'voice' matches. Even so, I wasn't completely convinced that Al Foxtone was Terekhov myself, but I leave it to the listadmins to decide who's who. :) On Mon, Sep 9, 2013 at 10:32 AM, Bradley M. Kuhn bk...@ebb.org wrote: [0] And, to be clear to those who seem to have missed this point: I *don't* agree with Al's accusations/insinuations. In fact, I'm arguing against them, in case you missed it. Anyway, my footnote comment that Luis quoted above wasn't intended toward Al anyway, FWIW. :) -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Till Jaeger wrote: Bradley and Larry have asked me to share my view as a European lawyer on the To be abundantly clear, it was wholly Larry's request to Till, so Larry deserves all the credit here for eliciting this wonderful and informative contribution to this list from Till! As I mentioned in a private thread, I didn't really see the need to burn Till's time posting here, since the discussion was a side-issue on the main thread about license compatibility, and an OSI director had already said oh no, not again on the derivative works subthread. However, nevertheless, Till, thank you so much for providing such a detailed posting to the list, and it's a wonderful written supplement to what you covered in your FOSDEM 2013 talk! -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
Al Foxone wrote at 04:18 (EDT) on Saturday: en.opensuse.org/openSUSE:License This agreement governs your download, installation, or use of openSUSE 12.3 and its ...The openSUSE Project grants to you a license to this collective work pursuant to the ...openSUSE 12.3 is a modular Linux operating system consisting of ... Is SUSE licensing that compilation/arrangement copyright under GPL, though, or a broad permissive license? Looks like the latter, from the selective quoting you give above. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
Rick Moen wrote at 16:55 (EDT) on Friday: You seem to be trying to imply without saying so that the source-access obligations of copyleft licences somehow give you additional rights in other areas _other_ than source acccess. What I'm saying is, no, that's just not the case. GPL (and other copylefts too) *do* give other rights downstream, beyond source access, of course. While I really disagree with how Al has been raising these suspicions, *if* Al has any valid argument [0], it would relate to other provisions of GPL, and not the source-code provisions in GPLv2§3 and GPLv3§6. [0] And, to be clear to those who seem to have missed this point: I *don't* agree with Al's accusations/insinuations. In fact, I'm arguing against them, in case you missed it. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
John Cowan wrote at 19:42 (EDT) on Thursday: So it's perfectly parallel, reading packages for patches. Not quite, the details are different since it's different parts of the copyright controls. Patches are typical derivative works themselves of the original work. Thus, both the arrangement/compilation copyright control *and* the preparation and distribution of derivative works control are *both* involved when a maintainer selects and arranges all patches for the final release. Meanwhile, this copyright of the CD is probably just a compilation/arrangement issue. I agree that I don't know of anyone else who has done this. ... except Larry's clients, apparently. :) -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility
Quoting Bradley M. Kuhn (bk...@ebb.org): I've tried to reply at length below on the issue of license (in)compatibility. The below is probably the most I've ever written on the subject, but it's in some ways a summary of items that discussed regularly among various Free Software licensing theorist for the past decade, particularly Richard Fontana. Rick Moen wrote at 22:36 (EDT) on Tuesday: Thank you for your very generous and thoughtful reply, Bradley. I'll have to spend some time reading it carefully. I appreciate your time and trouble. I'm glad that admittedly overly-lengthy post of mine was helpful to you (and another person who also thanked me for it off-list). It really should be worked into a blog post rather than just a mailing list post, which I'll try to do at some point. -- Bradley M. Kuhn, Executive Director, Software Freedom Conservancy ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
John Cowan wrote at 14:56 (EDT) on Monday: I don't see where the oddity comes in. If we grant that the compilation which is RHEL required a creative spark in the selection (for the arrangement is mechanical), then it is a fit object of copyright. It's odd in that Red Hat is the only entity that I know of to ever claim this sort of licensing explicitly. Are there any other examples? When I think of compilation and arrangement copyright on copylefted software, I'm usually focused on things like the maintainer chose which patches were appropriate and which ones weren't for the release within a single package, and not big software archive, with lots of different Free Software works under different Free Software licenses. Again, I'm *not* saying the latter is an invalid or problematic use of copyleft -- I chose my words carefully: it's odd, as in beyond or deviating from the usual or expected. :) -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
Al Foxone wrote at 07:57 (EDT): Red Hat customers receive RHEL compilation as a whole in ready for use binary form but Red Hat claims that it can not be redistributed in that original form due to trademarks (without additional trademark license, says Red Hat) and under pay-per-use-unit restrictive contract. Do you have evidence that Red Hat's trademark requirements aren't of the nature that are permitted by GPLv3§7(e) and similar clauses in other Free Software licenses? Nothing you said above seems to be such evidence. (quoting Red Hat Enterprise Agreement with [snip] editing) Noting your [snip], you selectively quoted from the RHEA. I admit it's been many years since I reviewed the RHEA in detail, and my arguments are based on that old version I read. If it has changed in some way that now causes a new problem under GPL, I'm just not following your arguments as to why. My understanding is that when the GPL licensee distributes copies of derivative works prepared under the GPL permission, the GPL insists on licensing the copyright in a derivative work under the GPL and only the GPL. Correct, AFAIK. Since creation of derivative work (and even distribution of adaptations under 17 U.S.C. 117) requires permission I can understand that demand. ... Please prove me wrong. :-) You seem to be arguing that RHEA has some sort of GPLv2§6/7 (or GPLv3§10/12) problem. However, you've not shown any evidence for that. Determining such a violation likely hinges on what Red Hat's restrictions on their customer are if the customer fails to comply with RHEA. Meanwhile, I've spent the plurality of my life enforcing the GPL and other copyleft licenses. I hope based on that you'll take seriously my next point: it's unfair and aggressive to publicly accuse and/or insinuate that someone is violating the GPL without exhausting non-public remedies first. If you believe someone is actually violating the GPL but need help collecting the facts, you should report it to the copyright holders, not a license-discuss list. At the very least, it seems this subthread is more appropriate for http://lists.gpl-violations.org/mailman/listinfo/legal/ -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] Red Hat compilation copyright RHEL contract (was Re: License incompatibility)
Al Foxone asked me on Friday at 13:58 (EDT) about: http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf ... At the same time, the combined body of work that constitutes Red Hat® Enterprise Linux® is a collective work which has been organized by Red Hat, and Red Hat holds the copyright in that collective work. Red Hat then permits others to copy, modify and redistribute the collective work. To grant this permission Red Hat usually uses the GNU General Public License (“GPL”) version 2 and Red Hat’s own End User License Agreement. It's certainly possible to license all sorts of copyrights under GPL, since it's a copyright license. Red Hat has chosen, IMO rather oddly, to claim strongly a compilation copyright on putting together RHEL and Red Hat licenses that copyright under terms of GPL. It's certainly possible to do that. It's admittedly a strange behavior, and I've been asking Red Hat Legal for many years now to explain better why they're doing this and what they believe it's accomplishing. I've yet to receive a straight answer. Can anyone from Red Hat on the list tell us if Red Hat Legal's answer remains: No comment? I doubt that Red Hat’s own End User License Agreement is 'compatible' (according to you) with the GPL'd components in that combined work as whole. Anyway, that combined work as a whole must be full of proclaimed 'incompatibly' licensed components (once again according to you). How come that this is possible? However, don't conflate RHEL's compilation copyright issue with the RHEL customer contract. They're mostly unrelated issues. The RHEL customer contract has long been discussed, and it amounts to a if you exercise your rights under GPL, your money is no good here arrangement. That's not an arrangement that I think is reasonable (and it's why I wouldn't be a RHEL customer myself), but there's nothing in GPL (that I'm aware of) that requires that one keep someone as a customer. Imagine if GPL *did* forbid firing your customers! It'd really hurt independent contractors who offer Free Software support. Also, I encourage discerning carefully between mundane GPL violations and Free Software license incompatibility. While both could be classified as GPL violations, Free Software license incompatibility usually refers to a situation where Free Software authors seek to DTRT but are confused when navigating contradictions between two Free Software licenses for works they seek to combine. At most, you could say Free Software license incompatibility is a specialized case of a potential copyleft violation. However, that's a technically accurate but misleading characterization, since the motives are usually non-commercial, coupled with a desire to DTRT for the community. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
Rick, I've tried to reply at length below on the issue of license (in)compatibility. The below is probably the most I've ever written on the subject, but it's in some ways a summary of items that discussed regularly among various Free Software licensing theorist for the past decade, particularly Richard Fontana. Rick wrote yesterday: It's a fair, interesting, and relevant question, and I'd really like to know the answer. Most things in policy, unlike science, aren't a technical problem where we can provide a hypothesis and test the results. So, there probably isn't an answer. I've observed that many lawyers often build their careers on *pretending* that there are answers to questions like this. Then, they simply bluster their way through to convince everyone. Since IANAL (and, BTW, TINLA), I don't tend to think that way. I won't pretend license compatibility is a testable scientific fact like Einstein's theory of relativity; it's a policy analysis and conclusion, based on what those doing the analysis think is correct and likely to be permissible under copyright. I'd actually be interested in Bradley ... pointing to any caselaw that supports [his] view. So, most importantly, I don't think there has been any litigation anywhere in the world regarding license compatibility. Specifically, Jacobsen v. Katzer didn't consider it AFAICT. And, (speaking as someone who has either advised the Plaintiff and/or actually been the 30(b)(6) witness for Plaintiff in all of the GPL enforcement lawsuits in the USA), I'm not aware of the license compatibility ever coming up in USA litigation. Also, note that, no one else in this thread has put any license compatibility caselaw forward; it just doesn't exist, AFAIK. However, even if there were caselaw, I don't think looking at the caselaw record is somehow the only way to consider these questions. My primary point throughout this thread is that Free Software projects are regularly concerned about compatibility (and license proliferation too), for good policy and project health reasons; not because of what some Court said. I'd suspect everyone to agree that you must meet the redistribution requirements of all copyright licenses for a given work to have permission to redistribute. Thus, license compatibility *exists* as a concept because if you make a new work that combines two existing works under different licenses, you have to make sure you've complied with the terms of both licenses. Again, I'd be surprised if anyone disputes that as a necessary task and requirement. Where people disagree is about whether or not you actually need copyright permission at all to create that new work. Some have a theory that it's virtually impossible to ever need such permission. I'm pretty sure that can't be right, and there is a lot of caselaw on *this* subject, but the tests that courts have come up are *highly* dependent on the facts of a specific set of circumstances for a specific work. (Dan Ravicher's article the Software Derivative Work: A Circuit Dependent Determination is a seminal source on that subject about the USA situation. Till Jaeger's talk at FOSDEM, a recording of which I already linked to in this thread, covered the European side quite well IMO.) Of course, derivative works analysis has almost *nothing* to do with license compatibility. It's just that folks love to fall into derivative works debates because it's an interesting topic, and because those whose primary goal is to circumvent copyleft as much as possible (and I've found that's most people who work as Open Source legal experts) prefer to point to the derivative works issue as some sort of insurmountable problem that is therefore the base case of every discussion about Free Software licensing. And, as you saw, this thread descended into that debate too. I suspect that's what led Luis Villa to have his oh no, not again reaction. Meanwhile, license compatibility, as a concept, is a lex mercatoria. (Fontana and others have talked at length about how much in Free Software licensing are leges mercatorum; ironically, the derivative work question may be the only central issue that *isn't* a lex mercatoria.) Specifically, no court anywhere in the world, to my knowledge, has sat down and lined two Free Software licenses up next to each other and tried to determine if, upon creating a whole work based on two works under the two licenses, if the terms of any license was violated and thus the distributor of that whole work infringed copyright of one party or the other. Thus, people argue about what a court might say. Some lawyers bluster and claim they know the answer when they really don't. (This is why I love Till's first FOSDEM slide: he admits, as a first principle, the Socratic Epiphany inherent in this type of work.) In the meantime, though, we have to operate, share code, and (hopefully) uphold software freedom -- with the tools we have. That's what led me, back when I started working
[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Lawrence Rosen wrote at 17:00 (EDT) on Tuesday: I asked for practical examples. You cited none. In the world of copyrights or most logical pursuits, absence of evidence isn't evidence. License compatibility issues come up regularly on lots of bug tickets and threads about licensing on lots of projects. I don't have a saved file of evidence to hand you, mostly because it's such an unremarkable occurrence that I don't note it down when it happens. I see it at least once a month somewhere. I suspect anyone who follows Free Software development regularly sees it just as much. I can tell you that I dealt with two issues of license incompatibility in my day job recently, but I can't disclose the specifics since it was confidential advice. Meanwhile, if you need evidence to satisfy your curiosity right away, I'd suggest debian-legal archives would be a good place to start your research on this, but... Awaiting your evidence to the contrary ... I can't spare the time to do this basic research for you. If anyone else here does agree with you that license incompatibility isn't a problem in the real world, then perhaps it's worth continuing this thread, but I suspect you may be alone on this one. :) Most FOSS licenses (including the GPL!) don't actually define the term derivative work with enough precision to make it meaningful for court interpretation. ... The court will therefore use the statutory and case law to determine that situation. That's as it should be. It's not the job (nor is it really appropriate) for a copyright license to define statutory terms, so the GPL doesn't do that. The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. all major FOSS licenses that I'm aware of *except the GPL* make it abundantly clear that the mere combination of that licensed software with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Indeed, weaker copylefts give guidelines for certain derivative works that can be proprietarized, and the rest are left under copyleft. BTW, if you are interested in how the European lawyers view this question, I refer you to an excellent talk by Till Jaeger at FOSDEM 2013: http://www.faif.us/cast/2013/mar/26/0x39/ So what's the worry about license incompatibility all about? Is it merely that so many licenses are deemed incompatible with the GPL, Many licenses are incompatible with the Eclipse Public License, too, since it's a stronger copyleft than, say, the MPL or LGPL. There aren't very many strong copylefts around. with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Finally, I'm unlikely to respond to this thread further as I think the use of slurs like infect (notwithstanding the quotes, and '?') to refer to copyleft are just unnecessarily inflammatory. I've asked you not to talk about copyleft using slur words so many times before in the thirteen years we've known each other, it's really hard for me to believe you aren't saying infect intentionally just to spread needless discord. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] System 76's BeanBooks Public License v1.0
A colleague of mine asked for my comment on the following license: https://beansbooks.com/home/opensource (included in full text below for the archives). It's reminiscent of the Yahoo! Public License and Zimbra Public License. I notice that it seems that the Zimbra Public License and Yahoo! are listed as Free Software licenses by the FSF but not as Open Source by OSI. Does someone from OSI want talk to System 76 about this and why this is a bad idea to make their own license? System 76 is generally a pretty friendly company to Open Source and Free Software. ## URL: https://beansbooks.com/home/opensource BeansBooks Public License v1.0 This BeansBooks Public License (this Agreement) is a legal agreement that describes the terms under which System76, Inc., a Colorado corporation (System76) will provide software to you via download or otherwise (Software). By using the Software, you, an individual or an entity (You) agree to the terms of this Agreement. In consideration of the mutual promises and upon the terms and conditions set forth below, the parties agree as follows: 1. Grant of Copyright License 1.1 - Subject to the terms and conditions of this Agreement, System76 hereby grants to You, under any and all of its copyright interest in and to the Software, a royalty-free, non-exclusive, non-transferable license to copy, modify, compile, execute, and distribute the Software and Modifications. For the purposes of this Agreement, any change to, addition to, or abridgement of the Software made by You is a Modification; however, any file You add to the Software that does not contain any part of the Software is not a Modification. 1.2 - If You are an individual acting on behalf of a corporation or other entity, Your use of the Software or any Modification is subject to Your having the authority to bind such corporation or entity to this Agreement. Providing copies to persons within such corporation or entity is not considered distribution for purposes of this Agreement. 1.3 - For the Software or any Modification You distribute in source code format, You must do so only under the terms of this Agreement, and You must include a complete copy of this Agreement with Your distribution. With respect to any Modification You distribute in source code format, the terms of this Agreement will apply to You in the same way those terms apply to System76 with respect to the Software. In other words, when You are distributing Modifications under this Agreement, You stand in the shoes of System76 in terms of the rights You grant and how the terms and conditions apply to You and the licensees of Your Modifications. Notwithstanding the foregoing, when You stand in the shoes of System76, You are not subject to the jurisdiction provision under Section 7, which requires all disputes under this Agreement to be subject to the jurisdiction of federal or state courts of Colorado. 1.4 - For the Software or any Modification You distribute in compiled, object code format or over a network, You must also provide recipients with access to the Software or Modification in source code format along with a complete copy of this Agreement. The distribution of the Software or Modifications in compiled, object code format or over a network may be under a license of Your choice, provided that You are in compliance with the terms of this Agreement. In addition, You must make absolutely clear that any license terms applying to such Software or Modification that differ from this Agreement are offered by You alone and not by System76, and that such license does not restrict recipients from exercising rights in the source code to the Software granted by System76 under this Agreement or rights in the source code to any Modification granted by You as described in Section 1.3. 1.5 - This Agreement does not limit Your right to distribute files that are entirely Your own work (i.e., which do not incorporate any portion of the Software and are not Modifications) under any terms You choose. 2. Support System76 has no obligation to provide technical support or updates to You. 3. Contributions 3.1 - A “Contribution” means any work of authorship that is Submitted by You to System76 in which You own or assert ownership of the Copyright. “Submit” means to provide a Contribution to System76 by any form of communication. 3.2 - You retain ownership of the Copyright in Your Contribution and have
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Larry, it seems that you responded to my point that calling the GPL by the name 'infection' is a slur that spreads needless discord with (paraphrased) it's not the GPL; it's the work that *you*, Bradley, and others have done enforcing the GPL that's an infection on our community. This doesn't seem a very civil manner of debate. Recall that I recently defended you, Larry, on this very list, when someone was uncivil to you. Please don't be uncivil to me and the orgs that I work with / volunteer for. I have no objection to your policy disagreements and disputes with GPL enforcement or anything else I've worked. I do object to your insinuation that my and others' work in this regard is a virus plagued upon our community. -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Larry, Lawrence Rosen wrote at 18:29 (EDT) on Saturday: Just don't try to create *derivative works* by mixing them in that special and unusual way. ... How often is it truly necessary to make *derivative works* by intermixing software? I don't think we need to (or should have) this debate (again) here, but I will point out for those following the thread (in case anyone still is :) that your theory about the rarity of derivative work creation isn't shared by most (including me) in the field of Free Software licensing. I note that your entire argument about the ease of compatibility is predicated on your notion that creating a derivative work rarely happens in practice. Thus, I hope you can see that if we disagree on that fundamental point, we're going to come to very different conclusions about license compatibility. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Bradley M. Kuhn scripsit: This can be tested now: try it and see if choosealicense.com accepts the patches. John Cowan wrote at 12:30 (EDT) on Thursday: I am very disinclined to go to the effort of integrating my ideas (the actual code, which is plain HTML, is not relevant) into Github's code, absent some indication that they would be willing to adopt a more even-handed approach. I suspect that they favor permissive licenses for business reasons, as they encourage forking. I can't blame you for this. While I put the idea on my TODO list, I left it very low priority for basically the same reasons you state above. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] TGGPL as a GPL exception -- possibly OT (was Re: Open Source Eventually License Development)
Zooko, This thread my be drifting off-topic for license-discuss. I'm not sure if GPL exception drafting is appropriate here or not zooko wrote at 12:27 (EDT) on Wednesday: However there is a specific thing that I'm unwilling to allow: that if I make a work available to you under TGPPL, that you take advantage of the 12 month grace period for keeping your derived work proprietary, and then deny the grace period option to derivors immediately downstream from you. I think this might be doable as a GPLv3 exception. Downstream can always revert back to pure GPL, but if they are permitted to make th work proprietary (in part or whole), it means they need the exception in-tact, otherwise they're violation GPL. Thus, I think that requirement can propagate, since no one downstream can revert to pure GPLv3 unless and until the grace period has expired. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Lawrence Rosen wrote at 16:47 (EDT) on Tuesday: Perhaps, but the license proliferation issue is not quite helpful when phrased that way. It isn't that MORE licenses are necessarily bad. Instead, say that the proliferation of BAD (or me-too or un-templated or legally questionable) licenses is bad. The main community problem with proliferation is license incompatibility. Mozilla Foundation and the FSF did some great work together to reconcile the compatibility issues of the two most popular copylefts. We need to ensure that future license fit in the main compatibility, which I view as (from weakest copyleft to strongest): ISC = 2-clause-BSD = permissive-MIT License = Apache License = MPL = LGPL = GPL = Affero GPL If new licenses can't drop in somewhere along that spectrum, it's a proliferation problem, IMO. I suspect, however, that for-profit corporate folks would disagree with this as the primary problem here. I know that company's legal department really want to keep the license texts they must review quite low, and ISTR that was the biggest complaint about license proliferation from for-profit entities. It's hard to blame newcomers for wanting to draft their own licenses, as I think it's highly difficult to become part of the Free Software license policy discussion about existing licenses in practice *even* for would-be insiders. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Pamela Chestek wrote at 09:54 (EDT) on Monday: And the major substantive aspects are what is captured in the summary. A major issue, I think, is that most people are really bad at writing good summaries of licenses. FWIW, a group of user interface researchers who have worked with Free Software extensively offered years ago to help draft user interface documents/systems that would help navigate an annotated text of various popular Free Software licenses and explain what they mean in a way that's grokkable by those who don't read licenses for a living. I asked many lawyers/licensing experts whom I knew at the time to volunteer to help on this project, and I sadly couldn't get anyone interested. The project died before it began. If there's interest in this again, I could start a thread off-list. Email me if you're interested in helping in this sort of effort, and I'll start the thread, but please be serious and ready to put time forward -- as I don't want to waste these researchers' time with another false start. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Pamela Chestek wrote at 12:18 (EDT) on Sunday: Why cannot an advocate for each license write a short blurb with the benefits and burdens of their own license? I don't think there's anything wrong with all the choices being positively-biased. This can be tested now: try it and see if choosealicense.com accepts the patches. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
Richard Fontana wrote at 08:20 (EDT): Not with an exception in the GPLv2 exception sense, and not without the result being (A)GPLv3-incompatible, since under TGPPL each downstream distributor appears to be required to give the grace period. ISTR that Zooko was willing to drop that requirement for the sake of simplicity. But maybe I'm misremembering. Zooko? -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
John Cowan wrote at 13:27 (EDT) on Sunday: == licensing content ends here, the rest is about civil behavior == I've already written to Larry privately to this point, but given that this subset of the conversation has raged on, I'd like to echo John's point: I think many comments on this thread were inappropriate. Artfully crafted insults wrapped in some sophistry of plausible deniability are still insults. Indeed, the meta-text here reminds me for the first time in years of the 1996 French film, Ridicule. Larry Rosen and I disagree about a great deal regarding Free Software licensing, and from time to time, I've even found myself on the opposite side of the table as Larry in GPL enforcement matters. To say that I Larry and I are political rivals is thus probably an understatement. :) However, there is no reason here on this list for anything but respectful discussion. I haven't seen much of it on this thread the last few days. In some backchannel discussions with others, I get the impression that John and I aren't alone in that view. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
Zooko, It might be worth mentioning here that you and I have had discussions for years about the idea of drafting TGPPL as a set of exceptions to Affero GPLv3 and/or GPLv3. I believe this is indeed possible, but requires a good amount of tuits. IIRC, Zooko, first draft was on you, right? :) -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
On Wednesday, 14 August 2013, John Cowan wrote: Suppose that Alice sells Bob the source code to Yoyomat, a proprietary program with delayed GPL. After the term has passed, Bob may now distribute *that very copy* of Yoyomat freely to Charlie under the terms of the GPL. In the scenario you outline, he may not; he must obtain a new copy from the escrow agent. The main logistical problem occurs in those cases not where Bob received source code under some no distribution permitted license, but when Bob received *only* proprietary binaries of Yoyomat and has no source. In that case, Bob likely has no method (logistically) to get what he knows is Complete, Corresponding Source (CCS) for Yoyomat (except from Alice herself). Distribution of those binary bits under GPL would be copyright infringement because Bob couldn't make such distribution accompanied with CCS (or a valid offer therefor). Bob *might* be able to show, as a defense to a copyright infringement claim, that the source from the third-party escrow was indeed CCS for the old proprietary binary that Alice gave Bob. That'll require some effort to show in practice (especially if much time has gone by) since GPL's CCS is much more than just the source code itself. If Alice is well-intentioned, this issue is unlikely to come up. However, if Alice is a bad actor, this issue would cause serious trouble. Admittedly, this is only an issue for copyleft licenses in this situation. For later liberation under permissive licenses, Bob's compliance obligations when distributing the very same proprietary bits are probably easily and obviously met (e.g., properly displaying accurate copyright notices). I reiterate that I am not a fan of these sort of liberate it later licensing schemes, but if they are practiced in any event, it'd be good to make sure they function such that later Free Software license compliance is easy for everyone. I suspect that's what John is seeking here as well, and that's a good goal. I hope folks won't be unduly critical of those trying to explore that question. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Bradley M. Kuhn scripsit: Richard Fontana pointed out in his OSCON talk that license choosers generally make political statements about views of licenses. He used the GitHub chooser as an example, which subtly pushes people toward permissive licenses. John Cowan wrote at 09:49 (EDT): Surely he jests. Choosealicense.com *blatantly* pushes people toward the MIT license. :) Fontana has been known to jest. Still, my view is that it's tough to compliance about this; the choosealicense.com site says patches welcome, so we should offer them. I don't believe, however, that my chooser http://ccil.org/~cowan/floss has any such biases. John, have you considered offering text from your license chooser as a patch to chosealicense.com? I think it'd be good to test their claim that they want contribution, and you seem the right person to do it, since you've worked on this problem before. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
Fred, fred trotter wrote at 03:52 (EDT): I have been burned pretty badly by people who literally rewrote sections of the GPL to suit them and still called it GPL that I know that some people will try those shenanigans. The FSF is quite vigilant about handling situations like this -- it's one of the reasons that the GPL text itself is still under a copyright license that forbids modification -- so that situations like this can be dealt with. Please report any such issues to the FSF at license-violat...@fsf.org. I hope you so-reported them at the time you encountered them. But, I think that issue is somewhat off the point here: you're talking there about people who are attempting to mislead the public by illegitimately modifying a license text. I doubt the behavior of such people would be curtailed by a packet of license templates that help build proprietary-but-eventually-liberated-code business models. As has been noted in this thread, such business models have been experimented with since the early 1990s, and most software freedom advocates find them, at best, problematic compromises, and, at worst, scourges upon our community. if every person who benefited indirectly from the GNU compiler would donate one cent to FSF and one cent to the OSI per year, neither organization would have any problem paying the bills. People don't pay because that is the norm in our development culture, this mechanism could change that. Non-profit fundraising is always going to be difficult for orgs like FSF and OSI, but that's not an argument for violating principles that our community is based on: permission to redistribute with no royalty nor any payment upstream is a fundamental tenant of software freedom. While Free Software licenses should never discriminate *against* charging for distribution, it's just not Free Software if there's a *mandate* to charge money. Also, note that so many volunteers to the FSF give code rather than pennies. That's often much more valuable a contribution, anyway. Could someone who knows the story well related what problems the people on the other side had? I can speak from my personal experience with these business models. During the Ghostscript era, when I was first working at the FSF, I saw that few people wanted to contribute to GNU Ghostscript. Most people just waited to see what Aladdin would do next, since they knew it'd be released under GPL eventually. This curtailed the usual culture of Free Software development. Since that practice ended for Ghostscript, there have been a myriad of business models attempting to do this sort of thing, and they all suffer from that fundamental flaw: there's no way build a proper community of developers around a Free Software codebase when there's an incentive to wait N months and see what the primary proprietary developer liberates. Free Software licenses -- particularly copyleft ones -- are designed to create equal footing for all community participants. Anytime one contributor to the codebase has more power than everyone else (usually, due to holding all the copyrights and operating under terms *other* than the primary Free Software license for the project), it creates serious flaws of all sorts in the community around that project. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open source license chooser choosealicense.com launched.
Sorry for posting a month late on this thread [I hadn't poked into the folder for this list in some time], but I didn't see a consensus and wanted to add my $0.02. Luis Villa wrote on 16 July: In the long-term, I'd actually like OSI to promote a license chooser of its own. But in the meantime I'm pretty OK with linking to a variety of license choosers. Richard Fontana pointed out in his OSCON talk that license choosers generally make political statements about views of licenses. He used the GitHub chooser as an example, which subtly pushes people toward permissive licenses. I was told GitHub's chooser accepts patches, and I was planning at some point to try to patch out this bias myself and see if my patch was accepted -- but of course any patch I produce is going to have subtle copyleft biases -- which I think was Fontana's point. (Fontana, do I have that right?) Therefore, I think OSI should likely avoid license chooser lest OSI end up in the quagmire of taking a position in the copyleft/permissive debates. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
