|
On 2017-03-16 6:47 PM, Berg, Paul W
wrote:
Please forgive me if these have been addressed, but
this is my first time looking at this in depth. And also, I am not
a lawyer, so please forgive any legal ignorance I may display.
All perfectly good questions and comments. This is the level of
detail and specificity we need to get to in order to finalize the
license.
Comment MM5: The modified works definition is IMHO one of the
most critical portions of the document to get right because it
defines the extent of the Copyleft. I'm thinking that "contains
any contents of the Program." may need clarification for
languages that must include forward declarations of type (C
Header files for instance). Should this have a clarifying clause
such as:
"Modified Works shall not include works that contain only
declarations of interfaces, types, classes, structures, or files
of the Program in order to link (or bind by name) to the
program."
Just out of curiousity, did you delete the reference to subclassing
on purpose?
As a lapsed software engineer, I understand that subclassing is
implied in your text. However, this is one topic that I really want
to ensure we are utterly explicit on. Does anyone find the following
objectionable?
Modified Works shall not include works that:
(i) remain separable from the Program and Modified
Works thereof, or
(ii) merely contain declarations of interfaces, types, classes,
structures, or files of the Program in order to link, bind by
name, or subclass the Program and Modified Works thereof.
Question: the above suggestion and the current draft both say
"Program and Modified Works thereof". Should that be
an or?
Comment MM7: I think this may be an important clause. As a
specific example, if a subroutine written in Verilog is licensed
under the EPL and that subroutine is combined into a larger
system that defines a chip die, and that is then used to
fabricate actual chips, then the hardware form of the EPL module
in the combined chip is no longer separable, so it might be
argued that the physical chip is now under the EPL (if the chip
is a sculpture... and all the headaches going down that legal
argument). The EPL may be very ill defined if applied to
physical hardware and I don't think it is the intent of the EPL
to try to govern that. Specifically calling out that the EPL
never applies to hardware is a good way to avoid the whole mess
in my opinion.
Clearly, it is not the intent of the EPL to govern hardware. The
best discussion I have seen on the "hardware per se" topic was in
license review a little over a year ago, in the context of McCoy
Smith's "BSD+Patent License". Check out the
thread that starts at [1]. There he cites two concerns with
leaving it in that license:
- It might be a GPL compatibility issue.
- It is somewhat ambiguous in scope.
FWIW, I would point out that as currently constructed, the piece
of hardware that you have described is clearly Executable Code,
and could therefore be licensed under terms other than the EPL. On
the other hand, I am not sure that helps much when you're actually
trying to sell a piece of hardware, rather than license software.
[1]
https://lists.opensource.org/pipermail/license-review/2016-January/002677.html
Section 3.1b: The removal of the original section iii would
seem to disallow the distributor to include any warrantees or
indemnifications in a compiled work. Sections i and ii both
force the distributor to give up all liabilities, including
their own, and there doesn't seem to be a way for the
distributor to then take liability unto themselves alone. I
think that this may conflict directly with section 4 as a
result.
Hmm. IANAL either, but I wonder if the remaining section i and ii
could be improved by saying "...on behalf of all other Contributors..."?
I agree that as currently worded it seems to be telling the
distributor what their own license must say, which is odd.
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223 (mobile)
|
