Open Source Initiative Blog

1. Join Us In New York City

   

   OSI members and affiliates are invited to join the OSI Board of Directors, local college and university student groups, and the broader New York City open source community to discuss "Careers in Open Source".

   • Open source jobs, what are they... where are they?
   • Finding and leveraging open source projects to expand your opportunities.
   • What companies and communities are looking for.
   • What you should look for, before accepting the job.
   • Getting the most out of your company to further your open source career.

   If you're interested in a career in open source software, have some advice to offer, or just looking to network with peers, we hope you will join us.

   Open Source Initiative Spring Meet-up and Mixer
   Tuesday, May 7, 2019
   6:00 PM to 9:00 PM
   566 Fashion Ave Suite 504 · New York, NY
   RSVP: https://www.meetup.com/Open-Source-NYC/events/258658427/

   OSI Board Directors have broad backgrounds and experience, working in a variety of roles—Chief Open Source Officer, Chief Information Office, Chief Technology Officer, Open Source Program Manager, Community Manager, Developer, Architect, Engineer, Attorney—for both corporations and communities—Clojure Community, Cloud Native Computing Foundation, Debian Project, Free Software Foundation, Github, Google, Kubernetes Community, Microsoft, One Laptop Per Child, Open edX, Oracle, Python Software Foundation, Red Hat, Salesforce, Sun Microsystems , The Document Foundation, Wikimedia, Zalando... and many, many, more.

   ---

   Photo credit: "NYCMeetUp.jpg" by Patrick Masson (CC BY 2.0) is a derivative of, "Jobs Board" by Malcolm Tredinnick (CC BY 2.0), via Flickr (https://www.flickr.com/photos/malcolmtredinnick/934039609/in/photostream/)

2. Powering Potential Expands to Peru

   

   The Open Source Initiative’s first African Affiliate Member, Powering Potential Inc. (PPI), is pleased to announce the launch of their award-winning solar-powered Raspberry Pi computer labs in Peru. The pilot program builds on PPI's successes already enhancing education throughout rural Tanzania, Africa.

   Over the past 13 years, PPI has installed 29 solar-powered systems, and 203 computers with servers, in 29 secondary schools across Tanzania. As a result, more than 23,000 students and teachers have been provided with direct access to educational materials and technology-training with minimal impact to the environment.

   

   PPI created their Solar-Powered Access to Raspberry Computing (SPARC) installation model using Raspberry Pi computers loaded with an abundance of open source software, such as RACHEL from WorldPossible.org, and Kolibri from Learning Equality. Educational resources include Khan Academy videos, UNESCO textbooks, and Project Gutenberg literature with health and medical information.

   

   A basic SPARC lab installation consists of five Raspberry Pi computers, two 85-watt panels, three 108Ah batteries, a 15 amp charge controller, a 350 watt inverter, and a lightning arrester system. A SPARC+ installation includes 15 more computers, additional solar panels, six new batteries, and a new charge controller. PPI also uses local vendors to work with school districts to provide solar power and additional equipment.

   After installation, school district-selected teachers having a familiarity with technology are given a specialized three week “Train-the-Trainer” course. PPI prepares them to instruct tech literacy classes by learning networking, hardware, word-processing, database, file management, RACHEL maintenance, and email basics.

   

   Currently, PPI’s pilot project is placing a SPARC lab in the Amazon region at the San Francisco Rio Itaya School, located in a low-income district of Iquitos, Peru. Leading this effort is Dana Rensi, PPI Regional Director, Latin America. She is a recipient of a Fulbright Distinguished Award in Teaching and an Educational Media Specialist in Ashland, Oregon. After being a Fulbright exchange teacher in Iquitos for a year, Rensi began working with V. Ena Haines from the PPI Management Team and is currently scheduled to be on site for five weeks this summer to establish the pilot. If successful, SPARC labs may also be expanded to other villages along the Amazon River.

   The geographic isolation of this region in Peru is similar to rural Tanzania in terms of educational hurdles like a high turnover rate for teachers, limited resources and a lack of electricity. Iquitos, for example, is known as the largest city in the world that is accessible only by river or air, which makes technological progress challenging. The pilot installation is on the outskirts of Iquitos in Belén, one of thirteen districts of Peru’s Maynas Province known as “The Floating City.” Other villages along the Amazon River face the same accessibility problems coupled with regular seasonal flooding that has grown worse in some areas from climate change.

   

   Rensi believes the SPARC lab installation could alter the game entirely for students there. “I came from teenage parents and a poor background. Education was my way out,” she explained during a recent interview. “They [the students] deserve an opportunity to learn no matter what circumstances they are born under or where.”

   For this reason and more, PPI is actively seeking volunteers and sponsors for the pilot program in Peru alongside their continued efforts in Tanzania. They will also host a spring fundraiser celebrating their 10-year partnership with the Segal Family Foundation on Wednesday, June 5th from 6 to 8:30 p.m. at 39 West 29th Street in New York City to raise money for a major computer lab upgrade for the 800-student Sazira Secondary School near Lake Victoria in rural Tanzania.

   To learn more or find out how you can help, visit Poweringpotential.org.

3. ClearlyDefined Update

   

   It’s been just over a year since the Open Source Initiative approved the proposal for ClearlyDefined to be a project under its organization. So far the project has successfully built a robust software system in collaboration with lots of folks from the community. We wanted to tell you more about what we’ve built so far and how you can get involved with the project.

   What’s ClearlyDefined?

   Having clear license data about open source increases everyone’s confidence. Projects want more adoption of their software, and this is built on confidence in knowing how to use it responsibly. Users of open source projects want to feel confident they know how a project is licensed to properly comply with the terms of that license. Organizations and companies building on open source want to feel confident they understand the compliance obligations of all the open source they use.

   Enter ClearlyDefined. ClearlyDefined is focused on clarifying data about open source components. Specifically, the initial focus is on three key pieces of data about open source: license, source location, and attribution parties. Clarity on these pieces of data helps everyone know what their obligations are and feel more confident in meeting them.

   We have spent the last year as an OSI project building the software to facilitate the project as well as the community around the project.

   The project is built around a 3-step process:

   

   1. Harvest: We are aiming to get as much data about open source components in an automated way as is possible, so first we harvest the interesting data from components using open source tooling. We take open source packages, open them up, run open source scanning tools such as ScanCode, FOSSology, Licensee, etc. on them, and aggregate and summarize the results to produce the best license data we can about the component. That raw and processed data is freely available to our users.
   2. Curate: Even though the tools do a great job at harvesting the interesting data about open source components, in many cases we are still missing data or the data we have is ambiguous. In these cases, ClearlyDefined enables the whole community to come and make changes (“curations”) to the data to improve its quality. These curations are all done in the open, on GitHub, via pull requests, and are meant to be discussed and consensus formed completely transparently.
   3. Upstream: Ultimately collecting and clarifying license data after the fact is a losing battle. For all the data that we curate, we are also building a larger process around upstreaming those changes back to the original projects. Over time, as these changes are integrated upstream, new versions of those components and the open source world as a whole will become more clearly defined.

   Can I use ClearlyDefined

   Yes! Anyone who’s interested in clear licensing data about open source can use ClearlyDefined. You can go to clearlydefined.io and browse for your favorite open source component and use it in your open source compliance process. If you see some something missing or off, you can fix it directly on the site and contribute the changes to be reviewed!

   While you are there, you can use the site to create a NOTICE file. For example, simply drag and drop your NPM package-lock.json file onto the Definitions page and use the Share button to create and download a NOTICE file in the format of your choice. Check out this short video for a quick example.

   

   In addition, all of these data and capabilities are readily available via REST APIs free to anyone.

   If you are a developer who is making open source for your community to use, take a minute to make sure you are following the licensing norms of your community. Having a discoverable license file and clear copyright notices goes a long way to being clearly defined from the beginning.

   Can I help ClearlyDefined?

   If you are interested in helping us clarify the license data on components we’ve already harvested, we’d love for you to come help us curate. You can learn more about the philosophy as well as how to do your first curation on our docs.

   Please let us know if you have questions or want to get further involved, we’d love to hear more from you as we continue to build this project. You can find us on Discord, Twitter, Google Groups, and GitHub.

4. March 2019 License-Review Summary

   In March, the License-Review mailing list saw the retraction of the SSPL from review, and discussed a set of GPLv3 Additional Terms.

   The License-Discuss list (summarized at https://opensource.org/LicenseDiscuss032019) was far more active. Among other things, it discussed Van Lindberg's upcoming Cryptographic Autonomy License, and saw extensive discussion about the license review process: whether the conduct of the list is appropriate, whether there might be alternatives to using email, and whether PEP-style summaries would help.

   License Committee Report

   Richard Fontana provides the license committee report:

   • CFSL v1.4: The review period is over. Fontana explains why he thinks the license should be rejected. The OSI board subsequently rejected the license.

   • SSPL v2: MongoDB withdrew the license from review.

   • Twente License: A decision is due 2019-04-05.

   Server Side Public License, Version 2

   Eliot Horowitz announces that MongoDB retracts the SSPL from the OSI approval process, citing a lack of community support as a reason.

   Josh Berkus is disappointed in the withdrawal: “this license poses interesting questions about how copyleft can be extended (or not) and how the OSD's clauses about software packaging need to change in a SaaS world.” Berkus thinks the contents of the license were not appropriately considered, and that too many responses were ad-hominem attacks.

   This leads to extensive discussion of the License-Review process (see the License-Discuss summary).

   GPL 3+ with Whonix Additional Terms

   Patrick Schleizer submits a set of Additional Terms for the GPLv3 for review. These terms try to improve the limitation and disclaimer of warranty in the GPL by incorporating language from the doom3 and micropolis licenses.

   This submission raises two governance questions:

   • Should the OSI review Additional Terms for the GPL? This is discussed in a separate section below.
   • Does it make sense for the OSI to review licenses that were not first reviewed by a lawyer? This is discussed on License-Discuss as “the pro-se license constructor”.

   Brendan Hickey asks whether Schleizer had talked with the FSF about these improvements. Patrick Schleizer links to such a message.

   Schleizer wonders why the GPL allows indemnification terms without containing such terms itself. Richard Fontana mentions this was done solely for Apache 2.0 compatibility, and links to the GPLv3 rationale documents.

   Fontana notices that the proposed terms use the word “nonwithstanding” opposite to its intended effect.

   Based on the feedback (see also the separate sections), Patrick Schleizer decides to withdraw the license but intends to prepare a revised version.

   Should the OSI review GPL Additional Terms?

   Patrick Schleizer points out that the GPLv3 Additional Terms mechanism allows “other non-permissive additional terms” to be removed by the user, so that no Additional Terms can render the license non-free. Richard Fontana thinks that if these Additional Terms don't create a new license, then that is a good argument that such Additional Terms are out of scope for OSI review.

   Bruce Perens argues [1,2] that adding terms to a license necessarily creates a new license, and points at the recent Commons Clause as an example where simple additions had huge effect. But Schleizer points out that adding Additional Terms is just an exercise of the rights under the GPL, and shouldn't be treated as a modification of the license.

   Richard Fontana suggests the OSI shouldn't review Additional Terms, if only to limit license proliferation. Fontana notes the Additional Terms have sometimes be misused, and that review could be valuable for widely used Additional Terms. Fontana points out that the OSI did review two sets of GPLv3 Additional Permissions though they behaved like separate licenses. One is the LGPLv3.

   Fontana also suggests that the OSI should defer to the FSF for review of Additional Restrictions. Bruce Perens disagrees [1,2]: The OSI shouldn't give the FSF special status that would exclude some licenses from a review here, in particular not any kind of veto power. However, the OSI should respect the FSF's authority on the GPL and not review licenses that contain “GPL” in their name.

5. March 2019 License-Discuss Summary

   In March, the License-Discuss mailing list discussed:

   • the Cryptographic Autonomy License
     • its interactions with the GDPR
     • how public performance applies to software
   • the License-Review process
     • views on tone and conduct on the list
     • the list's role in the license review process
     • problems with email, and alternative tools
     • whether a PEP-style process might help
   • whether licenses should be drafted without legal assistance
   • and more

   The corresponding License-Review summary is online at https://opensource.org/LicenseReview032019 and covers the SSPL's retraction from review, as well as discussion of a set of GPLv3 additional terms.

   Cryptographic Autonomy License

   Van Lindberg requests comments on his Cryptographic Autonomy License (CAL), a network copyleft license motivated by blockchain-based software. He also wrote a blog post explaining the license's background and rationale in detail.

   User Data and the GDPR

   The CAL has provisions that ensure user's access to their data, which goes in a similar direction as the EU's GDPR – it even references the GDPR in an interpretation clause. The CAL defines a concept of Lawful Interest as the trigger for user access rights.

   Henrik Ingo notes that this grants rights to third parties, which is fairly novel and could raise OSD issues. Van Lindberg says these are just third party beneficiaries that receive no rights other than access to the Source and to their own User Data. The data protection in the CAL is not a grant of rights to third parties, but a limitation on the grant to the licensee, similar to the GPLv3's anti-Tivoization clause.

   Henrik Ingo [1,2] dives a bit deeper into the CAL ↔ GDPR relationship, and finds CAL User Data to be inconsistent the GDPR personal data concept.

   Van Lindberg responds that the CAL and GDPR have different angles: GDPR is primarily concerned about privacy, the CAL primarily about User Autonomy. Lawful Interest is intended to not only capture rights through ownership or the GDPR, but also things like the right to an ebook the user possesses or has licensed. The CAL's User Data concept is more broad than the GDPR's Personal Data. Based on Ingo's feedback, Lindberg updates the wording of the CAL to clarify its relationship with the GDPR.

   Public Performance

   The CAL triggers some license obligations on “Public Performance”, an aspect of copyright not explicitly discussed by existing Open Source licenses. This is intended to create a network-copyleft license like the AGPL, while being less specific to a medium or technology.

   Henrik Ingo [1,2] is a bit put off by this unusual term, similar to the usage of Conveyance in the GPLv3. The CAL also doesn't make it clear what “Publicly Performing an interface” means. Is there any precedent for applying public performance to software? What is an interface? How would this apply to a library API? Ingo is also concerned that public performance could be too broad so that it would cover way more than SaaS style use.

   Van Lindberg points out that Public Performance is a well-established term in copyright law, but concedes that its application to software is less well defined. Lindberg intends “interface” to be interpreted broadly, from GUIs to APIs – as long as it can be protected by IP law. This should definitely cover more than just SaaS use. After all, the CAL tries to ensure user autonomy in distributed software systems.

   Henrik Ingo thinks the lack of clarity around public performance is a major weakness of the CAL – maybe specific uses should be always allowed, similar to how the GPL gives unlimited permission to run the unmodified program?

   Bruce Perens [1,2] isn't sure whether the U.S. copyright law provides a sufficient public performance rights for the CAL to work, in particular whether software is a literary work. Van Lindberg provides numerous references for both US and international law that software is treated as a literary work. (Note: see also the WIPO Copyright Treaty.) It follows that literary works' performance rights must also apply to software.

   Other Notes

   Henrik Ingo: isn't “Compatible Open Source License” just any OSI-approved license? Van Lindberg [1,2] responds that the CAL defines Open Source licenses as both OSI- and FSF-approved, but that compatibility is determined by the terms of the other license.

   The CAL allows a simple LGPL-like exception to be added. Henrik Ingo would prefer if that was a clearly separate license with its own name. Van Lindberg doesn't think this would be a problem, just as there isn't a problem with different GPL exceptions like Classpath.

   The CAL significantly expands the reach of copyleft licensing, in particular to public performance. Henrik Ingo thinks this “copyright maximalist” attitude is regrettable, and echoes Bruce Peren's opinion that “Extension of copyright is bad for open source”. Van Lindberg responds that the CAL tries very hard to fit within the established reach of IP law.

   Bruce Perens thinks that restricting the license grant to copyright and patents may be too narrow for jurisdictions that recognize additional rights. Perens suggests the license should grant all necessary rights, and only exclude trademarks. Van Lindberg considers broadening the grant.

   Bruce Perens [1,2] thinks that the CAL's anti-DRM clause is too narrow as it focuses on specific techniques like cryptographic keys. This could even be understood as a OSD #6 usage restriction. Van Lindberg [1,2] agrees that could be too narrow by itself, but that the license also contains more general anti-DRM clauses. The mention of specific technologies was requested by his client. This isn't so much a user-restrictiction as a kind of anti-Tivoization clause made necessary by the environment for which the license is being developed.

   Discussion of License-Review process

   In the context of the SSPL's withdrawal from OSI review (see the License-Review summary), Josh Berkus voices disappointment with the License-Review process: instead of legal discussions on the contents of the license, Berkus saw ad-hominem attacks.

   [This] was a dramatic failure of the license-review process, and I think shows that this group needs to be reconstituted. […] We need a real process around license approval that isn't “outlast the licensing wonks with the most free time.”

   This sparks extensive discussion on whether there was a problem, how the SSPL review should have worked instead, how reviews work, what the problems with email lists are, and whether there might be alternatives (Discourse?).

   Views on tone and conduct of the list

   McCoy Smith and Richard Fontana [1,2] don't share Berkus' view. Discussions about MongoDB's business model aren't ad-hominem attacks, but closely related to the license's practical effects. Overall, it remained fairly civil. Fontana saw “energetic and serious discussion […] from an unusually wide variety of commenters” and is concerned that curtailing “opinionated, impassioned” discussion “could have the effect of stifling debate and expression.”

   Bruce Perens thinks that discussion remained civil, but that he can't respond to some people without it being perceived as a “shouting match”.

   Josh Berkus reports that people on the “outside” are baffled and appalled by conduct around the SSPL discussion.

   The OSI only has authority to the extent that we are widely regarded as an impartial arbiter of what is and is not open source. It's important. And on the SSPL, we are not widely perceived as fair or impartial.

   Richard Fontana points out that License-Review is a public list and shouldn't be conflated with the OSI. And OSI didn't get to be an arbiter on the SSPL because the license was voluntarily withdrawn. However:

   Participants on license-review are expected to adhere to the code of conduct, but they are not expected to be neutral or non-opinionated[.]

   Rick Moen suspects that the discontent with the list's discussion culture is just “passive-aggressive kickback against License Committee decisions they didn't like”. Richard Fontana [1,2] shares that suspicion: “this sounds to me like a complaint that most of the active participants in the license-review threads on SSPL were hostile to SSPL.”

   Perens thinks the problem is that discussion turned repetitious. Lawrence Rosen responds with an 8-point manifesto with his most-repeated points.

   Luis Villa [1,2] complains about the volume and quality of discussion. Debate is “only valuable to the extent that they help [and] the current quality and nature of the discussion don't do that very well”:

   at some point I checked in […] to see that the thread was literally 100 emails, considered how negative (and often circular) the earlier parts had been, and said "nope, life is too short".

   Should the SSPL review have had a different focus?

   Where Josh Berkus would like to have seen discussions about copyleft and the OSD in general, Richard Fontana reminds that the license review is not the place for that. The review should only check whether the license “conforms to the Open Source Definition and provides software freedom.” But for Berkus these are not separable: the question of OSD compliance is directly related to the question how far copyleft can and should be extended.

   To Berkus' dismay, the recent CopyleftConf didn't see much discussion specifically about the SSPL. McCoy Smith summarizes some points from his talk at the conference which did mention that license and discusses a hypothetical Extreme Copyleft Public License as a though experiment. Smith also points out that the AGPL addresses SaaS business models, so it isn't like the OSI had an anti-SaaS bias. Smith doesn't think the community would have a fundamental objection against extending copyleft beyond AGPLv3.

   The list's role in the license-review process

   Rick Moen proposes that if the fundamental problem is that License-Review discussions are mistaken for official OSI position, that could be solved if people speaking officially self-identify themselves better.

   McCoy Smith sees the following criticisms being made here, and discusses them in more detail:

   1. a few loud voices have undue influence on review decisions
   2. the voices lack variety, or do not reflect the “silent majority”
   3. it is unclear how review decisions take the email discussions into account

   Bruce Perens notes about the latter point that the lists are merely advisory, and that the decisions are made by the OSI board in a vote. But there's a lack of transparency in how the board reaches its decisions. Do the board members even read the License-Review list? And how did which director vote? Mike Milinkovich shares his experience as a previous board member: nearly all license approval votes were unanimous. There is also more to the board than voting on licenses, so not every board member should be expected to be a licensing expert.

   Richard Fontana [1,2] adds that most license submitters retract their license if it's not clear that it will be approved. This month's vote on the CFSL might have been the first rejection. In that sense, the question isn't whether loud voices have undue influence on the OSI, but what effect they have on the submitter. MongoDB retracted the SSPL just a few days before the board vote, citing a failure to reach a community consensus on the license (which was more than just the license-review discussion).

   Ben Hilburn thinks Fontana's distinction between influence on OSI vs influence on license submitters is really important. But while some disagreement is normal and expected, it may also be important to protect the submitter and the debate from negative conduct. Hilburn cautions:

   especially for licenses where License-Review recommends rejection, our process and debates really needs to be trusted.

   Problems with email, and alternatives

   Bruce Perens mentioned discussion turned repetitious. Andrew DeMarsh too thinks the medium of mailing lists makes it easy to discuss the same topics again and again, without being able to easily reference their previous occurrence. This is boring and tiring for list participants. Maybe a better front-end to the mailing lists would help.

   Luis Villa [1,2] highlights that the current email-based review process has a number of issues or limitations:

   • limited visibility into the process from the outside
   • too easy to generate vasts amounts of discussion
   • these monthly summaries are too infrequent to guide discussion
   • specific issues are not listed or tracked
   • difficult for outsiders to join constructively, not just with drive-by comments
   • no way to silently signal agreement
   • McCoy Smith adds: archives are difficult to search

   Villa suggests that the Discourse software might offer a better platform, but really that any other tool than email would be an improvement. Any tool will have some drawback, but Villa believes Discourse will reduce the barrier of entry to the discussions.

   Rick Moen provides a critical summary of his experience with Discourse, for example mentioning the lack of threaded discussion. In contrast, John Sullivan notes that the FSF is happily using Discourse.

   Richard Fontana thinks Discourse would be worth trying, although it may be geared to different kinds of discussions. Fontana doesn't think that “new tools will solve what are fundamentally social or political problems.” Villa responds that tools do ease the symptoms.

   Rick Moen and Thorsten Glaser [1,2,3] are concerned that using Discourse would require discussion participants to enter a contract with a third party hosting company. Kevin Fleming and Michael Downey responds this wouldn't be the case.

   Bruce Perens suggests that at least, the list archive software could be upgraded to something better than Pipermail, which only supports plain text emails.

   Responding to an offhand mention of Bugzilla or GitHub, Fontana argues that they would be elitist and keep non-technical people out. “several years ago I entertained the idea that it would be obviously beneficial for license drafting to adopt the preferred tools of developers. […] I see now that […] involved a lot of romanticization of developers and open source development.”

   Ben Hilburn agrees with some of the problems around email, but appreciates that email lets the user choose their clients and workflows. Some web-based tools can be integrated with an email-based workflow, which may be desirable.

   Would a PEP-style process help?

   John Sullivan suggests that the process could be improved without having to change the tools. For example, each license application could be assigned a (volunteer) caretaker who maintains a dossier with the salient points of the discussion. In the end, any process will rely on individuals, and no process will be able to prevent louder voices or individuals with agendas.

   Chris Jerdonek draws a comparison to Python's PEP model (Python Enhancement Proposal) where discussion is summarized in a central document. Such a document would also be useful for further reference. Van Lindberg and Ben Hilburn concur.

   Bruce Perens and Jerdonek caution that discussion in the PEP process is still mailing-list based with all the drawbacks of the medium. John Sullivan and Jerdonek explain that having the central PEP document helps to keep the discussion on track and makes it easier to join the conversation later.

   Bruce Perens is concerned that a PEP-like process might have difficulty achieving consensus for political decisions like license approval. Perens points at the W3C, which used to make consensus decisions until patent policy issues caused insurmountable disagreements. Chris Jerdonek sees PEP more as a documentation thing, not as a consensus-building process. Approval decisions are made externally (Note: compare the role of the OSI board).

   Van Lindberg illustrates how the PEP process relates to the review of his CAL license (see below). Here, Lindberg tracks various arguments in a PEP-like blog post.

   Who should maintain the PEP summary? Pamela Chestek [1,2] suggests the license submitter could be be tasked with this in order to avoid burdening volunteers. Luis Villa thinks it might be hard for submitters to determine the useful and important arguments that should be covered in the summary. Bruce Perens [1,2] thinks a process editor (or group of editors) can be useful. That might be a job for legal professionals, but not for volunteers on the list who might have a stake in the outcome.

   Richard Fontana [1,2] is concerned about possible bias in the summary, both if it is maintained by volunteer editors but especially if the license submitter were responsible. Having a group of editors might help though. Perens thinks submitter-written summaries could work if the summary document has a clear version history, and the submitter is paired with an unaffiliated editor.

   Luis Villa [1,2] suggests more collaborative Wiki-ish approaches, or that revisions of the summary would have to be approved by an independent person. Villa is less concerned about bias, more that a useful summary is written at all.

   Chris Jerdonek explains that submitter-written summaries can work if bad/biased summary will be cause for a license rejection. Version control etc. is important, though.

   The pro-se license constructor

   The License-Review list saw a submission of a license that didn't have previous legal review. That raises the question whether it is safe and acceptable for non-lawyers to create and submit licenses.

   Bruce Perens [1,2] argues that it is dangerous to promote “Crayon Licenses”. Without legal review, the actual effects of that licenses are unknown. “I thus feel all such things should be rejected, although the reason is entirely outside of the OSD.”

   As an example, Perens points to the Jacobsen v Katzer case about the Artistic License, which Larry Wall had drafted pro-se. The case could have set “an absolutely horrid precedent […]: that the license was tantamount to a dedication to the public domain.”

   McCoy Smith warns that requiring prior legal review would be a barrier to entry, could cause the review discussion to be dominated by lawyers, and wouldn't guarantee license quality. Perens suggests the barrier could be avoided if the OSI would assign a lawyer like a “public defender”. Henrik Ingo doesn't see an issue with a barrier to entry: There are plenty of approved licenses already available. And the license-review process isn't zero-cost either, the cost is just born by OSI. (Note: and the community!)

   Brendan Hickey digs into the purpose of barriers and legal review. Hickey doesn't think that legal review would be suitable to protect end users of the license. And legal probably shouldn't be the first step: “No one should be hiring an attorney to draft a license that will be rejected out of hand.”

   Nigel Tzeng [1,2] claims that advice from lawyers would be ignored anyway, which seems to reference the NOSA review. John Cowan points out that a license may be a fine legal document but still fail to conform to the OSD. Tzeng and Bruce Perens [1,2] rehash some of the discussion around the NOSA. After a while that argument flows into the more general discussion about the license-review process, covered above.

   Van Lindberg discusses different aspects of license review. On one hand there are policy choices and community considerations, but determining whether a license is legally sound and complies with the OSD is “strongly legally inflected”. Richard Fontana takes issue with that: The OSD is not a legal document but “a statement of philosophy and policy aimed at nonlawyers.” Determining OSD compliance might require lawyer-style thinking, but “a nonlawyer who is steeped in free/open source legal policy […] might be much better qualified to interpret the OSD”. Lawyers might also be biased, for example when they are representing a client. While input on the legal soundness of a license is valuable and requires legal specialists, e.g. in case of the SSPL the policy arguments were ultimately more important.

   Leftovers

   Thorsten Glaser cross-posts a discussion from the Fedora-Legal list about whether the Open Motif license can be considered open source. Open Motif has an unusual license that restricts its use to “open source” operating systems. Bruce Perens considers this OSD #9 and #10 violations. Florian Weimer points out that RHEL nevertheless ships Open Motif, and he doesn't think this restriction would be problematic.

   The GPLv3 allows additional terms that prohibit misrepresentation or decline trademarks. Patrick Schleizer asks: Does that mean the GPL grants such rights by default? John Cowan argues that failure to prohibit something is not permission. Similarly, Bruce Perens points out the lack of affirmative statements that would grant these rights. And the licenses don't have to cover everything in detail: they are embedded in a wider legal context.

   End users of open source licenses typically don't explicitly accept the license. Patrick Schleizer [1,2] asks: Doesn't that mean any limitations of liability are ineffective because the end user never waived their rights? Or can warranties be unilaterally disclaimed by the author? Does this differ between common law and civil law jurisdictions? Thorsten Glaser suggests that disclaimers are a condition on the copyright license. Van Lindberg points to the difference between licenses and contracts (Note: which may be an US-centric viewpoint).

   Chris Lamb links to the discussion on the Debian bug tracker about the “citationware” requirement of Ole Tange's GNU Parallel utility: the utility prints out a demand to cite the software or to pay the author a lump sum. Jonathon contrasts academic conventions around citation with the wording of that requirement. Bruce Perens notes that in the meanwhile, the citation requirement has been reduced to a non-compulsory request.

   Responding to January's discussion about “intimacy”, Florian Weimer adds that AGPL compliance is particularly unproblematic for quine-like programs that can provide their own source code.