Current list of things to look at for the next version (after Version 1.1)¶

From the updates@lists.openhardwaresummit.org mailing list: "I think that you might want to patch a "hole" in the definition of "Documentation" that allows people to distribute essentially unusable/unmodifiable forms of documentation, such as a photograph of the PCB layout. This adds teeth to your viral provision, otherwise I can claim I modified the documentation (both in content and format) and here is my out-of-focus, impossible to really use photo of the result. GPLv2 and v3 uses: The “source code” for a work means the preferred form of the work for making modifications to it."

From the updates@lists.openhardwaresummit.org mailing list:"I think I'd like to see a clarification/tweak in the OSHW Definition (v1.1?) of "open format" as meaning something along the lines of "a format unencumbered with licensing and usage restrictions incompatible with the OSHW Definition"."

From the updates@lists.openhardwaresummit.org mailing list:"You may include files in proprietary formats, the documentation must include schematics (in PDF or open format). The design files must be the preferred format for making changes, for example the native file format of a CAD program (or an open format if your tools can create them)". Clunky sentence...

3.3d deals with the obligation of the licensees to send a notification to the licensors every time they make a modification they want to publish/distribute. It has been noted that, in version control systems like svn and git, people make frequent modifications that get automatically published because the repository is public. It is impractical, and not in the spirit of the licence, to have these licensees inform the licensors each time they commit a new version. This could be improved through a suitable definition of "Modification" in the Definitions paragraph.

From the updates@lists.openhardwaresummit.org mailing list: "I like the idea of a required notification clause. But what we are saying is that it should carefully limit the effort that a person must go through to notify the originators. The most important reason for this is to protect the design from becoming legally unusable because it turns into a "orphaned work". See http://en.wikipedia.org/wiki/Orphan_works for an intro to the subject."

From the updates@lists.openhardwaresummit.org mailing list: "CERN says: 1) Contact point of any Licensor who wishes to receive modified Documentation (see section 3.3.d) (e.g. CONTRIB.TXT); 2) Contact point wishing to receive information about manufactured Products (see section 4.2) (e.g. PRODUCT.TXT); it's nice and we do this, but what happens if i die, or my contact point goes away or i don't reply in time for that person? or what if they said they emailed me but they really didn't?"

From David Mellis in the updates@lists.openhardwaresummit.org mailing list: "I'm not sure it makes sense to require that all products made from a licensed design come with the design. Perhaps it would be better to borrow from the GPL the notion of providing some reasonable mechanism for the customer to access the design? Otherwise, this seems to imply that you need to include a USB key with the design files with every product (or some similar approach)."

Would it make sense to say some words about the rationale and differences wrt CC and TAPR OHL? At least in the wiki for sure, many people ask.

From David Mellis in the updates@lists.openhardwaresummit.org mailing list: "what about the possibility of aligning this license with the TAPR one, so that they could, for example, serve as localized versions of the same license? The licenses seem very similar in intent and approach (at least to a legally-naive reader) - it would be great if we didn't have to worry about choosing between them. At a minimum, maybe there's a way to allow for compatibility between them (i.e. the ability to combine TAPR OHL-licensed documentation with CERN OHL-licensed documentation)?"