copyleft-next August 2014

copyleft-next@lists.fedorahosted.org

10 participants
6 discussions

EPL 2.0
by Richard Fontana 27 Apr '15

27 Apr '15

It came to my attention earlier this week that the Eclipse Foundation had begun public discussion of the drafting of a new version of the EPL. So far little has been said on the relevant mailing list: https://dev.eclipse.org/mailman/listinfo/epl-discuss This caught my attention though: http://dev.eclipse.org/mhonarc/lists/epl-discuss/msg00013.html as it relates closely to the 'rule vs standard' issue that in the past was discussed here. The suggestion made by Jim Wright is interesting as at a high level it bears some relationship to what I have been thinking about lately for copyleft-next. It starts out with MPL-style copyleft as a conceptual basis and tries to define something more extensive, but (unlike EPL 1.0) attempts to do so by articulating something bright line instead of relying on some legal notion of derivative works. - RF

2 1

Impending release of copyleft-next 0.4.0
by Richard Fontana 27 Aug '14

27 Aug '14

Hi everybody! After a considerable and unfortunate hiatus I have resumed development of copyleft-next and feel it is close to appropriate for release of v.0.4.0. Especially given the dormancy I thought I would point any remaining and interested readers of this list to the latest draft: https://gitorious.org/copyleft-next/copyleft-next/raw/3baab310f662811ba48d8… The most notable changes are the following: Section 2b: (Non-GPL) license compatibility is now dealt with through reference to a brief illustrative appendix list of licenses (which include MPL 2.0, EPL 1.0, and LGPLv3 as well as some non-copyleft licenses). The issue of compliance with export control regulations is dealt with, something which I have come to view as sorely lacking in the GPL. Section 3: This is a new section containing an attempt at an Affero-style condition. Don't laugh at this attempt without trying it yourself first (though I should disclose that my attempt took place within the space of an hour at most this evening). The inclusion of this condition is notable given that at an earlier stage I specifically had decided not to have an Affero-like condition in the main body of the license. The original licensor can opt out. There is a special 'Corresponding Source' definition here that is not identical to the one for distribution of Object Code. Section 4: The old 'poison pill' provision now includes a definition of 'Proprietary License'. I have eliminated the effort to include an Apache License 2.0 section 5-style mechanism for formalizing the 'inbound=outbound' rule. - RF

5 9

copyleft-next compliance for Debian
by Ben Hutchings 24 Aug '14

24 Aug '14

I'm preparing to package a new version of crda for Debian and therefore I'm looking at the text of its new licence, copyleft-next 0.3.0[1]. This seems to meet the DFSG[2], making the new version of crda suitable for inclusion in Debian, yet I'm not certain that we and our distributors would currently comply with its terms: > 5. Conditions for Distributing Object Code > > You may Distribute an Object Code form of a Covered Work, provided that > you accompany the Object Code with a URL through which the Corresponding > Source is made available, at no charge, by some standard or customary > means of providing network access to source code. > > If you Distribute the Object Code in a physical product or tangible > storage medium ("Product"), the Corresponding Source must be available > through such URL for two years from the date of Your most recent > Distribution of the Object Code in the Product. However, if the Product > itself contains or is accompanied by the Corresponding Source (made > available in a customarily accessible manner), You need not also comply > with the first paragraph of this section. Since we don't keep old releases in the main FTP archive, the source URLs that APT is configured to use can become stale within 2 years of receiving a CD/DVD (or could even be stale already). So far as I can see, our CD/DVD distributors cannot comply with this by making the sources available in the same way - they must provide a URL for network access. We can now advertise stable URLs for source packages on http://snapshot.debian.org, but we do not include such URLs in binary packages. Perhaps it would be sufficient to document the site somewhere in the base system? > 15. Definitions [...] > "Corresponding Source" of a Covered Work in Object Code form means (i) > the Source Code form of the Covered Work; (ii) all scripts, > instructions and similar information that are reasonably necessary for > a skilled developer to generate such Object Code from the Source Code > provided under (i); and (iii) a list clearly identifying all Separate > Works (other than those provided in compliance with (ii)) that were > specifically used in building and (if applicable) installing the > Covered Work (for example, a specified proprietary compiler including > its version number). Corresponding Source must be machine-readable. [...] > "Separate Work" means a work that is separate from and independent of a > particular Covered Work and is not by its nature an extension or > enhancement of the Covered Work, and/or a runtime library, standard > library or similar component that is used to generate an Object Code > form of a Covered Work. I'm not sure quite what we need to for item (iii) of Corresponding Source. Are the Build-Depends and Build-Depends-Indep fields[3] in a Debian source package sufficient? Or do we need to record which versions were actually used to build each binary package? We do log the versions of build-dependencies for auto-built binaries, but not for developer-uploaded binaries. We don't advertise the URLs for build logs anywhere in the installed system. Ben. [1] https://gitorious.org/copyleft-next/copyleft-next/raw/3baab310f662811ba48d8… [2] https://www.debian.org/social_contract#guidelines [3] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebina… -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway.

3 4

dual-licensing ; license modding
by Andrew Engelbrecht 20 Aug '14

20 Aug '14

in order to dual-license software using your copyleft license and a proprietary one, someone with copyright for all contributions might simply remove the anti-dual-license clause in copyleft-next. one might wish to deny the copyright holder permission to use a derivative of the copyleft-next license, to use the copyleft-next name for their license in order to prevent this. i'm not sure how i'd feel about trademarking the name of a license under CC0. i think licensing the license under CC0 is pretty cool. as long as as copyleft requires a foundation of copyright and it isn't directly expressed as set of optional laws, dual licensing may remain hard to avoid. if copyleft were expressed as a set of laws, it's unlikely that all jurisdictions would concurrently have the same or similar laws. i am concerned with the potential for a plethora of copyleft-next variants which would be difficult to make sense of, keep track of, and combine. one potential solution for this may be to include in the cl-n license a request that any modifications and derivatives of the license be included in a standard separate file, or apparent in some standard way. asking coders to mention the non-vanilla status of a source code file's license in its header would be very helpful. welcoming quality upstream submissions might reduce the number of small and not-so-small copyleft-next forks, not to discourage independent changes, but because keeping track of many licenses is complicated. an additional request could be for the license modder to choose an alternative name for their license, such as "copyleft-next-deriv", or the "i-like-beards license", or to clearly state somewhere near the top that the license was changed inline. -andrew p.s. i talked with another in private regarding paragraphs 1 and 2 some weeks ago.

1 0

Distribute, make available, publicly perform
by Engel Nyst 20 Aug '14

20 Aug '14

I'll try to record, in imperfect form, a few questions and thoughts. 1) 0.3.0 says "non-exclusive, worldwide, perpetual, royalty-free, irrevocable copyright license, to reproduce, Distribute, prepare derivative works of, publicly perform and publicly display My Work." "Distribute" means to distribute, transfer or make a copy available to someone else, such that copyright permission is required." 1.1) Is "to someone else" necessary, or "public" is suitable? If I compare the wording with the copyright act[1], it seems that 106 (1) and (2) are individual acts, while (3)-(6) all refer to the "public". "To someone else" compared with "to the public" has a more extensive connotation, it seems to catch cases which may apply to more than public distribution/performance/display/transfer. (whatever that would strictly be) "such that copyright permission is required" probably takes the extension (if there was any indeed) back to only the cases specified in the enumeration of exclusive rights, so maybe it's no big deal. Still, if all else is equal, I wonder if it's better to use the term "public" instead of "someone else". 1.2) What is the reason for the inclusion of the concept of "making available a copy"? 2) Latest draft, with the Affero provision, says "Network Service means delivery of software functionality to third- party users in which distribution of most of the software does not occur, with users instead primarily accessing such functionality remotely, through network requests made by a client program, such as a web browser, to a server running the software." 2.1) Is "in which distribution of most of the software does not occur" necessary? I think the definition stays the same without it. 2.2) Some critics of the AGPL remark that it doesn't refer anymore to distribution, but to using or running the program on one's own server. That's perceived as a restriction on running the program, and it sometimes raises doubt about its freeness. Unfortunately, it seems easy to understand Affero provision as expanding the definition of distribution, or as restrictions on running the program, although none of them is what happens in Affero. I'd ask something else: what exclusive privilege exactly is impacted in the activity targeted by Affero? I think public performance is impacted, not distribution. Reproduction - and making derivatives - are also impacted, of course, because "you" made a copy, but these lead to the doubts above, and they're not the point. I can make copies and derivatives and run them with no effect. But Affero needs to kick in when I offer a /public network service/. What do you think about an attempt to draft it about public performance? I tentatively submit that to me it seems a corresponding expression of the Affero trigger in copyright terms, and I think the imagery can convey better the intention of the provision. Although the concept of public performance has not entered public conscience as applied to what a network service does in relation to the software package, still it illustrates what happens here, and it makes perfect sense to condition it where appropriate. I'm at loss what other legal effects would be though... Just thinking I'd better submit this idea instead of not doing it. 2.3) "You may prepare a Derivative Work that is designed primarily to provide a Network Service" This seems to limit the trigger for Affero provision to derivative works that are specifically designed to provide a Network Service. AGPLv3 says "if your version supports such interaction". In my reading, "if your version supports" is more expansive than "designed primarily". Do I understand this correctly, is the Affero condition intended to NOT apply to certain applications or libraries, which use an AGPLed library and may support interaction through a network, but are not "primarily designed" for it? [1] http://www.law.cornell.edu/uscode/text/17/106 -- "Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can *legally* have your permission to distribute your CC-licensed works?"

2 2

covered by patent grant
by Mike Linksvayer 18 Aug '14

18 Aug '14

Part of http://faif.us/cast/2014/aug/05/0x4B/ with Fontana and VanL concerned a desire for patent grant covering more than just contributor's contributions/in combination with work, or whole work at time of contributor's contributions (as I [mis]understand them, Apache2 and EPL do former, MPL2 and GPL3 latter). This reminded me to look at copyleft-next again. I assume it is intended to do latter, that is "My Code" means the particular work of authorship I license to You under this License. refers to my contributor version, not the code contributed by me? Near the end of the podcast Bradley said (roughly) that if free software license patent grants aren't covering enough, the those licenses should be fixed. As opposed to using CLAs which offer more coverage -- in theory, though it was noted they usually don't -- any examples that do? I was kind of hoping that I'd discover recent copyleft-next commits adding patent coverage beyond single work, but alas. Any in the pipeline? What are the possible scopes of coverage beyond single work? I'd guess a list of works, but this would be kind of messy, having to be specified elsewhere, or all free software. Latter would be unattractive to many companies, but they already have options. Mike

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next August 2014