!
Please help us make the CERN OHL even betterHere are some instructions to subscribe to the mailing list and see the web archives. This is the preferred way for discussing any issues related to the CERN OHL.
Current list of things to look at for the next version (after Version 1.1)
Concerns about the definition of "Documentation"
- 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...
Concerns about the "notification of changes" (3.3d) clause
- 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/wikis/Orphan_works for an intro to the subject."
- From http://lists.ohwr.org/sympa/arc/cernohl/2011-08/msg00006.html, "In free software, notification is a kind request, not a requirement." plus a detailed analysis of why the notification request should be taken out.
- 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?"
CERN OHL being used by non-electronics projects
- As can be seen in https://www.ohwr.org/project/cernohl/wikis/CernOhlProjects, there are people using CERN OHL to protect hardware other than PCBs. We should make sure the CERN OHL contains no clause which would be unnatural in such a context.
About the requirement to ship the Documentation along with products
- 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)."
Context and differences with respect to other licences
- 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)?"
Miscellaneous
- Provide the license and howto as txt files in addition to pdf.