Let’s step back and look at what inspired the anti-DRM clause.
1. First, with respect to Creative Commons 4.0 International
(CC-By 4.0) the deed points out that there can be no
additional limitations, including technical measures,
There is a link to
as further explanation.
In 4.0 Effective Technological Measures is now defined
in License Section 1(d).
2. The CC-By 3.0 deed points out the same thing, at
<http://creativecommons.org/licenses/by/3.0/>. The license
does not define "[effective] technological measures" in
section 1, however. The restriction of their imposition
to the extent that they limit downstream rights appears
to be the same, although in Section 4(a).
3. The CC-By 2.0 deed has the same requirement against
additional restrictions as 3.0/4.0. The restriction is
covered in License section 4(a).
The examples that I have seen are with respect to delivery of videos via DRM technology that prevent capturing a copy. The same is with respect to eBooks (e.g., delivery via DRM-protected Kindle format on a device that enforces the DRM).
At one point, I saw it suggested that it would be sufficient if the DRMed delivery was accompanied by an useful means for obtaining the original non-DRM version of the work. This also seems to be the case with regard to Section 3(a)(1-2) of CC-by 4.0. (I find 3(a)(4) more befuddling.)
This seems to be the basic situation. It appears that providing appropriate and actionable additional steps to obtain a form of the work in which the license permissions can be fully exercised might not be fatal. That seems to be more than an ALv2 licensing would require.
With regard to Apache Projects, I think treating CC-by digital artifacts as Category B is useful, even though "weak copyleft" is not entirely descriptive of this case. But in terms of restricting where such artifacts can appear, Category B is useful in that it doesn't allow co-mingling with source materials of an Apache Project release.
It is not clear how the "weak copyleft" exception makes sense for the CC-by artifacts, however. Namely, where are such artifacts located? Apache Extras? It is not as if there is always a binary distribution that uses/introduces them but the source release would not incorporate them. Also, where would these be maintained if authored/derived-from by the project? It would appear that they should be maintained and adapted as CC-by, in line with Apache principles.
I fear I have just created a slippery-slope onto Category X. Or, put differently, it may be prudent for a project to behave as if CC-by is Category X and see how to get out of depending on it.
----- Original Message -----
From: Luis Villa [mailto:email@example.com]
Sent: Friday, July 24, 2015 17:42
To: firstname.lastname@example.org; email@example.com
Subject: Re: Creative Commons BY 4.0 license compatible?
[Apology to non-lawyer members of the list: there is a whole lot of xkcd.com/386 ahead.]
On Thu, Jul 23, 2015 at 6:08 PM Lawrence Rosen <firstname.lastname@example.org> wrote:
[ ... ]
The drafters of CC BY 3.0 explicitly chose to make the non-use of DRM a condition of the license. As soon as you encumber a copy of the work with DRM, the condition has been violated, an infringement has occurred, and statutory damages are available. In other words, it is not "meaningless", because the author has explicitly chosen to prevent it, even though it does not damage the author.
[ ... ]
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org