[od-discuss] Proposed License - Hacked Apache 2.0

Andrew Katz Andrew.Katz at moorcrofts.com
Thu Mar 8 08:53:56 UTC 2012


Mike

Thanks for your comments

> -----Original Message-----
> From: Mike Linksvayer [mailto:ml at creativecommons.org]
> Sent: 08 March 2012 03:10
> 
> At a glance (wdiff with Apache 2.0 below) I don't see anything obviously
> making it non-compliant with the OKD, but I have two
> questions:
> 
> Why is it called a hardware license? Obviously it could be used for software,
> non-hardware-design-documentation, databases, etc.
> Personally I'd rather not promote the idea of more field-specific licenses.
> Much less problematic in the case of a permissive license, and even less so
> given the built-in effective dual licensing under Apache 2.0, but I think more
> confusing than necessary, more splintering of knowledge than necessary,
> and clearly problematic when non-permissive conditions come into play (of
> course the other two maybe hardware-specific licenses being discussed
> elsewhere do have such conditions; obviously same-license ones, but while
> on this tangent, they probably aren't OKD-compliant due to upstream
> notification conditions, though to my knowledge such have not been
> discussed in context of OKD).

It was written specifically for use in a hardware context - but I agree its potential use is broader than that. The name is not fixed, and I am open to calling it anything sensible, but there is a little bit of politics here. Although I personally think its addresses a couple of shortcomings with Apache 2.0 itself, I don't want to start hares running here and be open to accusations that I am trying to usurp the Apache software licence here!


> I'm not sure exactly of when a hardware design project would impinge on
> database rights, 

An example would be an electronic circuit: the netlist could be described as a database of interconnections. 

>but as they are mentioned (and I suspect it is a good thing to
> do so, even for future "software" licenses) in a specific way (extraction), why
> only extraction? 

I was trying to avoid the technical term "sui generis database right", and refer to the generally accepted term (used in the proposed WIPO treaty) "database extraction right". However, I can see this might be confusing and give the impression that it might exclude database re-utilisation, so maybe "database right" would be clearer and I'm happy to make that change. 

>And would this license be compatible with other licenses
> used for databases? AFAIK existing such either do not enumerate specific
> database right actions, or they mention both extraction and re-utilization. I
> know not the legal import of this.

Certainly the intention is that it would be. 

Thanks for doing the diff: I enclose a .pdf which shows the changes more clearly (and also how the licence has developed). It also includes the contributor licence agreement, but I didn't want to confuse the process by introducing it at this stage.

Kind regards

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: HARDWARE LICENSEg.pdf
Type: application/pdf
Size: 40628 bytes
Desc: HARDWARE LICENSEg.pdf
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20120308/0b72a026/attachment-0002.pdf>


More information about the od-discuss mailing list