www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <lro...@rosenlaw.com>
Subject RE: Apache H/W Licence
Date Tue, 29 Nov 2011 18:33:25 GMT
HI Ben, 

I'd welcome Andrew's participation on this list. These aren't easy questions
that he raises and I respect his judgment particularly on European law. I'm
sure Andrew has great ideas how to solve them.

Just today I'm reviewing a 65-page "Short Form Software License" for one of
my clients. This definition is included:

   Intellectual Property Rights means patents (including any rights 
   in or to (or any rights in and to), inventions), trade marks, 
   service marks, logos, trade names and business names (including
   rights in goodwill attached thereto),design rights, rights in or 
   to (or rights in and to) internet domain names and website 
   addresses, semi-conductor topography rights, copyright 
   (including future copyright), database rights, rights in 
   and to Confidential Information (including know how, business 
   methods, data and trade secrets) and all other intellectual 
   property rights in each case subsisting at any time in any 
   part of the world (whether registered or unregistered) and 
   any: pending applications or rights to apply for registrations 
   of any of these rights that are capable of registration in 
   any country or jurisdiction and similar or analogous rights 
   to any of these rights in any jurisdiction.

I reminded my client that, for good reason, no open source license is longer
than 4 pages.

I much prefer "including but not limited to" language for cooperative Apache
projects. But Andrew is raising important points that ought to be
considered. If there is any energy for creating a new Apache License here,
speak up now.


> -----Original Message-----
> From: benlaurie@gmail.com [mailto:benlaurie@gmail.com] On Behalf Of Ben
> Laurie
> Sent: Tuesday, November 29, 2011 4:33 AM
> To: legal-discuss@apache.org
> Subject: Re: Apache H/W Licence
> Here are Andrew's responses (perhaps he could be invited to this list?
> Not sure what our policy is...)
> As I think we discussed at the outset, I was surprised how effective
> the Apache license was without modification. It's worth putting this
> into context: Larry talks about certain changes being "unnecessary".
> That may be true from a technical legal perspective, but the purpose
> of my changes was to make it easier to use in a hardware context.
> Also, my comments below have a necessary EU/UK dimension, which may
> inform some of my thinking, and differ from the US view. My main point
> is that AL2 doesn't license several rights necessary in the EU, and my
> redraft is intended to address this.
> The other changes are desirable for clarity, but not necessary. It's
> also worth noting that as redrafted, the new license operates in
> relation to software in exactly the same way as before (or at least as
> it was intended to operate). Not that I am suggesting that this
> redraft should supplant AL2 entirely, for software as well as hardware
> :-)
> See my comments embedded below
> > 1. Your extended definition of "Rights" and the changes you made to
> the
> > definitions of "Source" and "Object" are not necessary. What is
> licensed in
> > the current Apache License 2.0 (AL2) is a "Work" in "Source" or
> "Object"
> > form. Both "Source" and "Object" are defined as "including but not
> limited
> > to" the forms listed (i.e., source code, documentation source,
> configuration
> > files, and "any form resulting from transformation or translation of
> a
> > Source form"). The existing definitions would already include
> semiconductor
> > topographies (mask works), databases, net lists, board layouts, CAD
> files,
> > etc., that are the "preferred form for making modifications" to an
> Apache
> > Work. In other words, you don't need the technical terminology you
> added in
> > order to license specifications for hardware. The phrase "including
> but not
> > limited to" takes care of it already. [*]
> I would disagree that the change to "Rights" is unnecessary. There are
> a number of rights which are relevant (particularly, but not
> exclusively to hardware) which are not copyright, such as the ones
> listed. Database extraction right exists as as an independent right in
> the European Union, and is not a subset of copyright. It is relevant
> to many hardware designs (a CAD file can be considered to be a
> database of nodes, for example). I won't get into the argument that
> this change would also be desirable in the original Apache license as
> it applies to software.  Although it may be possible to imply a
> parallel licence to these other non-copyright IPRs, I am always wary
> of implying a licence where one can be made explicit, and I have no
> idea whether it is possible to imply licenses in other non-UK
> jurisdictions.
> As t the definition of Source and Object: I agree that this change is
> not strictly necessary, but is highly desirable. If it's appropriate
> to single out on example of source (software source code) by way of
> example, it makes sense, for clarity, to specify other examples which
> may apply to hardware (and I think it would be confusing not to).
> >
> > 2. The existing AL2 uses the term "copyright" sparingly, not to mean
> that
> > only the copyright is licensed but to identify the owner of the Work
> that is
> > being licensed. So long as that person owns a copyright in that Work,
> > his/her copyrights and patents are both licensed. Is anyone going to
> > contribute to your H/W project who is not a copyright owner of
> his/her
> > contribution -- regardless of what other "Rights" he/she may also
> own? Is it
> > necessary for you to define Rights as "copyright and any similar
> right" as
> > long as there is at least a copyright in the contribution? In other
> words,
> > your extended definition of "Rights" to introduce terminology
> familiar in
> > the hardware world defines nothing more than what is now an Apache
> "Work"
> > that can already be used to build either hardware or software.
> >
> The contribution may not involve copyright, but may involve the other
> relevant IPRs. For example, it may purely be a database.
> > 3. How does a "work of authorship" differ from a "work of design"?
> The
> > former is a term of art from the U.S. Copyright Act; what is the
> latter?
> >
> Maybe the drafting would be slightly clearer if it read "any design or
> work of authorship" (I was not intending this to be read as a "work of
> design").  However, having considered point 2 above, we have some
> tension between clarity and precision. It's a stretch for designs to
> be described as "works of authorship" (although the 1988 Copyright Act
> in the UK allows sound recordings and broadcasts to be described as
> works of authorship - in contrast to the 1956 Act which called them
> "makers"). It's questionable whether we effectively cover databases or
> mask works with the wording I have suggested. Maybe just referring to
> "works" as opposed to "works of authorship", or "works in which any of
> the Rights may subsist", may be preferable.
> > 4. Your added phrase "or physically connect or interoperate with" in
> the
> > definition of Derivative Works does not change the existing law in
> any way.
> > Works that merely physically connect or interoperate with another
> work are
> > not derivative works under the law.
> A design which physically connects or interoperates with another
> design may, because a certain shape or configuration is required for
> it to do so, have to derive that shape or configuration from the
> original design. Admittedly, in this scenario, the "must fit, must
> match" exception would generally apply, but this does not prevent the
> second design from being a derivative of the first. (It's a pity that
> there isn't a similarly explicit rule in relation to copyright - this
> would make a lot of currently-litigated API issues go away).
> >
> > 5. Apache "software" distributed by its projects can already be
> > "documentation" (a work of authorship). The Grant of Copyright
> License in
> > AL2 already allows anyone to create hardware implementations of our
> software
> > or documentation. Do you doubt that? Your additional phrase "do
> anything in
> > relation to the Work as if the Rights did not exist" gives the world
> nothing
> > of value it did not already have under AL2.
> The list of rights granted by section 2 is not exhaustive. For
> example, the right to extract from a database is not specifically
> mentioned. There are also troublesome rights such as an artist's right
> to compensation where a work is sold at auction. The various
> performers' non-property rights may also pose troublesome. There may
> be other rights held by a rights holder which am unaware of in other
> jurisdictions. I won't even get into moral rights (which do not
> subsist in computer programs - but do subsist in documentation). In
> some jurisdictions, for example France, they are inalienable.
> >
> > 6. I suggested in an earlier email that the object of your project is
> "to
> > teach how to build hardware." By that I mean "to impart knowledge of
> or
> > skill in; give instruction to." Apache will never distribute hardware
> > itself. And so licenses to Apache copyrighted Works that teach others
> how to
> > make hardware, and that include any copyright and patent licenses
> necessary
> > for others to build and distribute that hardware, is sufficient as
> long as
> > the definitions of "Source" and "Object" and "Work" are sufficiently
> broad.
> > I believe they are already broad enough in AL2.
> >
> I understand what Larry says, the but the revised license is intended
> to cover the additional rights necessary to enable the hardware to be
> built from the source materials, where those source materials include
> non-copyright Rights such as a database rights which are not covered
> by the license. It's not intended to cover distribution of the
> hardware itself (which, generally speaking, once instantiated, is less
> likely to require a licence for onward transmission anyway, which is
> another reason why copyleft for hardware is not very helpful).
> > /Larry
> >
> >
> > [*] The phrase "including but not limited to" can encompass many
> things. For
> > example, a trademark assignment to "Company X's trademarks including
> but not
> > limited to the trademarks listed in attachment A" would potentially
> include
> > a grant of all of Company X's trademarks. This actually happened in
> an early
> > draft of a trademark assignment to Apache. Be careful of such
> phrases.
> Understood.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message