LWN: Comments on "Kuhn: Copyleft Won't Solve All Problems, Just Some of Them"

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

bkuhn — Thu, 31 Mar 2022 00:24:38 +0000

I got so busy on another matter that I plum didn't realize that my article had been linked here!

> Here's a very quick and simple way to support Ukraine: hit the "unsubscribe" button as soon as you read something trying to make a direct connection between FOSS and the latest Russian invasion.

As a bit of “behind the curtain”, I actually didn't have anything about the war at all in the first three drafts of this essay. My colleagues convinced me, precisely *because* we were getting so many inquiries at Software Freedom Conservancy (including from the press) about “should FOSS licenses impose sanctions”, that I ultimately added that section in about the war.

The question is often asked any time there is a particular bad action done with FOSS; my goal was to write an essay that gave a definitive answer to the question when it's raised in all its different forms (IMO, of course, lots of folks disagree with these conclusions).

On the point about D&D alignments upthread: I think it is a good shorthand to think about copyleft as being a good strategy to stop the “lawful evil” from acting badly but it doesn't do all that much to stop “chaotic evil” behavior. But do note that issue is just one of the arguments that I make as to why FOSS licenses are not a good place for dealing with software-unrelated ethical and moral issues.

On mjg's point about whether you could make a bad-behavior poison pill and the license might still be FaiF, I see where you're going with that, but I generally think poison pills are tactically bad (even though GPLv3 let a few of them through). I think copyleft works best if the only rights in play are your rights in the software in front of you, and works combined with/based on it. But I don't feel that way for ethical reasons; just tactics and coalition-building.

Anyway, thank you all for this thread; there are a lot of interesting points made and I've made note of many of them as very useful and I will want to keep in mind (including many that I just don't have time to respond to in detail right now). LWN comment threads on my articles always have the best signal-to-noise ratio and I greatly appreciate them!

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

developer122 — Thu, 24 Mar 2022 06:14:50 +0000

This also raises an important point: licences don't have infinite value to trade on.

At some point you're demanding too much for the use of your code, and someone writes you out of the picture.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

pizza — Wed, 23 Mar 2022 03:26:00 +0000

That's easy, just include the complete corresponding source code (and license text) in onboard storage. eg rom/flash/whatever. One can even stencil in "contains GPL components, see within" onto the side of said munition, for the ~2.5ms it will be visible before going all explode-y.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Tue, 22 Mar 2022 21:41:35 +0000

In Russia at the moment, and in many other jurisdictions, use of Tor is illegal because it circumvents "The Great Internet Firewall of Wherever". But this is exactly where people NEED Tor, partly to be able to separate truth from propaganda (although I'd hesitate to define the difference in *many* situations). Partly for their own personal safety! And probably for plenty of other reasons.

So banning unlawful acts is denying access to free software, to people who really need it.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

MrWim — Tue, 22 Mar 2022 19:55:38 +0000

FOSS also suffers from the real-world problem that, despite its high morals and "four freedoms", those freedoms are VALUELESS to the majority because they lack both the ability, skill, AND TIME (to say nothing of desire) to take advantage of them. Banging on about giving a teetotaller a free lifetime's supply of beer is not going to bring them freedom, it's going to alienate them. Banging on about giving the proles free access to source code is going to fall on deaf ears at best, and make enemies at worst.

Indeed, I think there’s a whole bunch of chat about the four freedoms in abstract, but very little actual coordinated work around making it practical to make use of those freedoms.

I find it useful to think of it in terms of positive vs negative liberty. Negative liberty is about not having constraints. Positive liberty is the practical capacity to act. So much of free software philosophy concerns itself with negative liberty - not being constrained by software licences, without thinking much about how users can actually be practically empowered.

I wrote a bit about a very specific way in which people could be better empowered to take advantage of software freedom one here: Unlock software freedom one by using better tools.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

NYKevin — Tue, 22 Mar 2022 04:52:34 +0000

It is intended as an admonition to courts, if for example someone gets charged with criminal copyright infringement for trying to circumvent your GPL'd DRM. You're not a party to that case, and arguably the license doesn't have any direct application as a result, but the defendant can use this clause to show that your intent was not to effectively control access to the copyrighted work, and therefore it doesn't count as DRM within the definition in the statute.

Whether a court buys that argument is another matter, of course.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 23:34:43 +0000

Okay. Just taking the first example I saw, the book store. Let's quickly summarize the ERD.

Publisher is Publisher.

Book_author and Book_language are attributes of Book, so they would go in the same FILE (table).

Author is author.

In this case, I'd say Customer_address is an attribute of Customer rather than an entity in its own right, so both of them, together with address status, would go in the same FILE. I see here, the ERD disagrees with me. Likewise, I probably wouldn't break Country out into its own FILE.

Do I treat order_line as an entity (in which I case I would say it belongs in the sales ledger), or as an attribute of Order? I'll treat it as an attribute of Order, so along with shipping_method, it belongs in the Order FILE. Looking at order_history and order_status, I think they belong in the same FILE, too.

Note that if I've got a one->many relationship, I list all the sub-table fields in an ASSOCiation, and that tells Pick it is a "table within a table".

"Some parts look simple. Others may not be so simple". I'm thinking the same about Pick ... :-)

Note that I'm going to use the LIST command, not the SELECT. Under the hood, they're pretty much the same (much like argc[0] makes the same executable do different things in Unix). But the LIST command actually outputs the data like SQL SELECT, the PICK SELECT just collects primary keys behind the scenes.

LIST cust_order BY order_date order_date

LIST cust_order COUNT order_date BY order_date BREAK.ON order_date

It didn't cross my mind that date might be a timestamp, not a date, but let's create a calculated column that converts timestamp to date ... (The conversion code stands for Date, Day Month Year)
DATE = OCONV(order_date,"DDMY"). Rather than creating a new column, I could always just put that in the query with the EVAL keyword - I'll use both variants in the next query ...

LIST cust_order COUNT DATE BY EVAL('OCONV(order_date,"DDMY")) BREAK.ON DATE

I almost never used EVAL and that stuff so I can't remember the AS syntax, but it's probably the same ...

LIST cust_order COUNT DATE AS "Orders" BY DATE

The next one REALLY shows the difference between Pick and Relational ...

LIST cust_order COUNT DATE AS "Orders" COUNT book_id AS "Books" BY DATE BREAK.ON DATE

Here I would have to experiment slightly. I think "COUNT book_id" works, but it might have to be SUM EVAL( DCOUNT( book_id, @VM)). The DCOUNT stuff counts the books per order - I could put that as a calculated field in the dictionary, if I wanted.

And note that I am still only reading one row per cust_order - and not one per order plus one per book!

LIST cust_order COUNT DATE AS "Orders" COUNT book_id AS "Books" SUM price AS "Total Price" BY DATE BREAK.ON DATE

The next bit, the running total, makes me go OUCH! I really don't have a clue how to handle it in the query language, but it's pretty easy to do. Define a function RUN_AND_BREAK( var_to_sum, var_to_break) in BASIC. It just sums var_to_sum, and resets the count every time var_to_break changes. It stores all this in named common, so be careful!

LIST cust_order COUNT DATE AS "Orders" COUNT book_id AS "Books" SUM price AS "Total Price" EVAL(SUBR(*RUN_AND_BREAK(DCOUNT(book_id, @VM),OCONV(DATE,"DM")))) AS "Running Total" BY DATE BREAK.ON DATE

As before, I can just create a virtual column RUNNING.TOTAL and put all that complicated mess in it :-)

And I've just found the "stored procedure". That makes me happy. Pick doesn't have a LAG function, but now I've got SQL stored procedures, it makes me much happier writing PickBASIC functions. Unlike SQL however, I can make my custom LAG look back 7 days, not 7 rows ... But you'll counter, quite fairly, that I've written custom code ...

Now to explain ...

Unlike SQL, I'm just scanning one table! So I can't add an index to improve join performance :-) Unlike MySQL, however, I can create an index on almost any information in my FILE - I just need to create a virtual column and I can index it, so I could easily index month, for example, if I wanted - OCONV( order_date, "DY4M2").

The way I would optimise this, is to create an index on DATE. That way, when I order BY DATE, the LIST will start by scanning and sorting the index, then retrieving all the keys from the index in sorted order. So running the report is just doing a sequential scan of the cust_order FILE by pre-sorted id. So especially if I'm only reporting a small subset of a large file, the ONLY table I've had to scan in full is the date index. (And depending how that index is organised, most recent Picks use a btree I believe, and can just scan the keylist to retrieve a pointer to the index data.)

And if I had split order_line out into its own FILE, I would have stored all the keys in the cust_order FILE, so at no point would I have had to scan the cust_order FILE, I would have just declared price as a TRANS in the cust_order FILE and Pick would have taken care of all the details, retrieving the data directly with a single disk hit.

(Oh, and I didn't add that Pick, for the most part, is order-insensitive. "LIST cust_order BY DATE fields_to_list" or "LIST cust_order fields_to_list BY DATE" Pick couldn't care.)

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

bjartur — Mon, 21 Mar 2022 21:32:23 +0000

Since when have intelligence agencies been lawful?

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

bpearlmutter — Mon, 21 Mar 2022 21:13:29 +0000

The *real* question is whether it counts as distribution when someone fires a smart munition or missile running GNU GPLed code at you, and if so, what forms the offer for source code can take in order to remain compliant.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 20:46:59 +0000

> This is probably harder than reasoning about the performance of something written in C -- but the latter's performance isn't going to respond to the data being processed and improve over time, no matter what you do.

You're missing the elephant in the room. Can you improve the performance of a Huffman Coder written in C? Not speed, but compression? Can you improve the performance of a fridge that is already capable of reaching 1K? If your rocket is already doing 0.9c, can you make it go any faster?

Instead of c, the speed of light, the *maximum* *possible* speed attainable under our understanding of Physics, let's define I - the speed of information - the maximum speed possible for a database to transfer information from OS to application.

As I'm sure you'll admit, a completely naive unoptimised FNF database is hopelesly inefficient, and that hopelessness grows with the size of the database. That's part of your frustration with "why can't the optimiser do any better?". Running at pedestrian, Newtonian speeds, there is absolutely oodles of room for improvement with an optimiser.

But that's why I did that Gedanken experiment. Go back and look at it. Pick achieves a near-naive speed of 0.95I ! Yep, as programmer I need to pre-define the indexes to assist my queries, but that's not hard. (Define indices for your relational database - I won't object :-)

There's just no point having a Pick optimiser - there is no headroom whatsoever to make it worth it. You said we can't do complex queries - well if you want to do it in SQL, I could run my Pick query, retrieve the *exact* dataset you're looking for, pass it through my SQL layer, and sit back and relax before your SQL Optimiser has even worked out where to start.

Please, DON'T compare Pick to other databases. Compare it to Information Theory. You can't cool a fridge below 0K. You can't accelerate a rocket beyond c. You can't accelerate a database beyond I.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Cyberax — Mon, 21 Mar 2022 19:42:43 +0000

> Then please. Did you see my Gedanken experiment where - was it mpr22 - gave me a typical query of his?

Try examples from, e.g. here: https://www.databasestar.com/complex-sql-query-example/#f...

I've seen analytic queries with dozens of joins, but extracting these kinds of schemas is impractical.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mat2 — Mon, 21 Mar 2022 19:23:21 +0000

The problem is that prudent people often disagree on what is morally permissible and what is not. So a "no evil" clause in a license will appear very vague to the court and it will be difficult to enforce it if at all possible. It will not be known whose definition of evil should be used in edge cases: whether that of the author, of the distributor, of the user, of the judge or of population polls. The author may also change their mind or say so to the court to change their interpretation of "evil" many years after the release date of the software. IANAL, but it is possible that clauses with very imprecise definitions are legally void (I think I have read something like this somewhere).

Vague laws have many drawbacks: their subjects will not know what is forbidden and how they should behave - so they are avoided where possible. Also, vague contracts are a source of problems and frequently invite litigation. So we should avoid vague licenses.

Law is not a good definition of what is morally wrong and what is morally right. It is easy to come up with examples of evil laws and also of bad deeds that are completely legal. Many proprietary computer programs have a license that forbids use of that software to do something illegal. It could have been easy to add such a clause to licenses like GPL, but apparently for some important reasons it was not done.

Some people want to add license clauses to forbid usage of their programs to perform some particular kind of "evil" deed, be it abortion services or perhaps anti-abortion campaigning, etc. The problem is that people will not agree on what "evil" deeds should be forbidden, so everyone will add their own to the list and it will be a mess. For more, see Richard's Stallmans essay:
https://www.gnu.org/philosophy/programs-must-not-limit-fr...

Evil cannot be legislated away and even more so, successfully eradicated with a software license.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 18:40:32 +0000

> > You cannot benchmark a Mathematical Theorem.

> RDBMSes are not mathematical theorems. JIT-capable interpreters are not mathematical theorems, and it is perfectly possible and indeed routine to run experiments to determine the performance characteristics of specific programs on them.

Then please. Did you see my Gedanken experiment where - was it mpr22 - gave me a typical query of his?

Please take that same query, and do the same Gedanken experiment.

> This obviates the rest of what you wrote.

I appreciate I come over as a bit of fanatic. As indeed I am.

But you said you were frustrated that Relational *should* be able to take advantage of opportunities to speed up, and yet it didn't. My Gedanken experiment shows clearly that there is *no* *room* available for Pick to speed up. I would love to see a similar experiment with a Relational database ...

Show me you don't have a closed mind. Take mpr22's query. Tell me how many requests a Relational database will pass to the underlying OS to get the data. Now compare how many I needed with Pick (a full index scan of renewal dates, cherry-picking the ledger by customer id, then one read per ledger entry for the selected customers). Beat that with Relational!

> > I stated that in twenty years of Pick programming, I've never met a complex Pick query stretching over more than a couple of lines. But in six months of SQL programming they're pretty much all complex monsters. Either I'm a liar or that's pretty damning! Either way, it's evidence.

> To me this seems just as likely to be evidence that implementing complex stuff in Pick is so hard and the model is so inexpressive that nobody even tries, so the maximum complexity of stuff written in Pick is bounded above at a very low level. Nobody's written word processors in assembly since WordStar, either (and indeed writing it in assembly is what eventually killed it). The maximum observed complexity of stuff written directly in raw assembly is fairly low, and that's not any sort of indication that assembly is somehow massively more expressive and capable than higher-level languages.

As I said before, converting the Pick data model to the Relational one is as simple as hiding the primary key, and restricting the dimensions to 1. It's so easy, that every modern Pick database has a SQL layer built on it as a matter of course. But practitioners would much rather use the underlying Pick features, than ask Maxwell's demon to put back all the information that converting from Pick to SQL lost. 90% of your complex SQL query is Maxwell's demon hard at work.

Nix. I don't want to get into an argument with you. I respect you too much. PLEASE do that Gedanken experiment on mpr22's query.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

floppus — Mon, 21 Mar 2022 16:52:42 +0000

In the US:

> a technological measure “effectively controls access to a work” if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work.

If you wrote and distributed the program without the copyright holder's authority, then the program (if it works at all) does not require the authority of the copyright holder to operate, therefore the program is not a "technological measure that effectively controls access to" that work.

The program might be deemed to "circumvent a technological measure", but it cannot *be* a technological measure, which is what the GPL is talking about.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

nix — Mon, 21 Mar 2022 15:47:24 +0000

> You cannot benchmark a Mathematical Theorem.

RDBMSes are not mathematical theorems. JIT-capable interpreters are not mathematical theorems, and it is perfectly possible and indeed routine to run experiments to determine the performance characteristics of specific programs on them.

This obviates the rest of what you wrote.

> I stated that in twenty years of Pick programming, I've never met a complex Pick query stretching over more than a couple of lines. But in six months of SQL programming they're pretty much all complex monsters. Either I'm a liar or that's pretty damning! Either way, it's evidence.

To me this seems just as likely to be evidence that implementing complex stuff in Pick is so hard and the model is so inexpressive that nobody even tries, so the maximum complexity of stuff written in Pick is bounded above at a very low level. Nobody's written word processors in assembly since WordStar, either (and indeed writing it in assembly is what eventually killed it). The maximum observed complexity of stuff written directly in raw assembly is fairly low, and that's not any sort of indication that assembly is somehow massively more expressive and capable than higher-level languages.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

nix — Mon, 21 Mar 2022 15:43:47 +0000

This is nonsense. Of *course* you *can* know specific underlying implementations -- and even if the source is unavailable you can run experiments to determine what the RDBMS is doing. What RDBMSes allow is for the implementations to improve things over time without requiring you to rewrite everything.

This is exactly the same as the potential speedup you can get from writing something in a language with a runtime smart enough to do JIT-compiling versus one like C where that stuff isn't provided (unless you implement it by writing such a language implementation in C). Determining the performance of Java code, or Lisp code, or JavaScript code isn't suddenly impossible, and reasoning about it isn't "pure maths with no way to run experiments". It means that running experiments (or reasoning about the JITter) becomes *necessary* to make such judgements. This is probably harder than reasoning about the performance of something written in C -- but the latter's performance isn't going to respond to the data being processed and improve over time, no matter what you do.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 14:57:23 +0000

Oh. I forgot. Two (well sort of) benchmarks.

I'm pretty certain the company was William Hill the Bookies. Six months of effort by consultants to get a complex query to run faster on Oracle / Twin Xeon 800 than the Pick / Pentium 90 system it was replacing ... ??????

And an Oracle / Cache shootout - Oracle struggled to meet the 100K insertiion target speed, Cache breezed through 250K pretty much from installation.

(Yes Cache isn't Pick. But the data model is similar.)

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 14:51:31 +0000

I appreciate I tend to use Gedanken experiments much more than real ones, but my statement about the Second Law of Thermodynamics, Entropy, and comparing Sets to Matrices is a statement of Pure Maths.

You cannot benchmark a Mathematical Theorem.

I stated that in twenty years of Pick programming, I've never met a complex Pick query stretching over more than a couple of lines. But in six months of SQL programming they're pretty much all complex monsters. Either I'm a liar or that's pretty damning! Either way, it's evidence.

And it's very noticeable when discussing performance, I'm pretty eager to do a Gedanken benchmark experiment - yet the response from the relational guys is ... crickets ... (take my word on this, but real experiments show Gedanken is accurate to about 5%).

At the end of the day, if you're going to fight conventional wisdom, OF COURSE you're going to come over as a crank. It's inevitable.

The relational guys love to argue maths. I'm trying to counter with Maths. The Mathematics of Entropy says Pick is objectively a better model - no experiment required.

You can't counter a mathematical theorem with empirical facts - Newton's Laws Of Motion are mathematically totally solid. It's just that Reality said "Einstein did a better job".

Both the Pick and Relational models are theoretically sound - indeed if a Pickie doesn't use relational analysis he's an idiot. But the Second Law of Thermodynamics says that Pick is objectively more efficient. And all my career's experience bears that out in spades.

Please. Look at the MATHS. Look at the ENTROPY. Look at the evidence (yes you'll initially have to trust my claims - verify them when you get the chance). Then see what you think.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

excors — Mon, 21 Mar 2022 13:45:44 +0000

> My blinding flash of inspiration, thanks to nix, was that the second law of thermodynamics proves that a set has far more entropy than a matrix. Therefore Pick MUST, as a matter of Physics, be a much more information-dense environment.
>
> So when Physics says you can sack two thirds of your relational guys and replace your system with Pick, surely you should take it seriously?

I suspect people would take you more seriously if you tried to sound less like a total crank :-) . Working code and benchmarks and technical documentation would be much more convincing than reams of pseudoscientific nonsense.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

sadoon — Mon, 21 Mar 2022 12:04:24 +0000

Here's a very possible scenario:

Where I'm from, there are no intellectual propery laws, and there probably won't ever be for the foreseeable future. (Fact)

Say my government decides to do something you don't like, whether it be as simple as taking a sociopolitical stance that you ABSOLUTELY hate, or going as far as invading a country that you love. (Hypothetical)

Would forbidding people from my country from using your software by changing your license do you any good? Down here, everyone pirates movies, games, music, and software. The "laws" did not stop them.

Some people are just so overwhelmed by their egos.

"But I *must* take action against them!"

It's futile, it's pathetic, and in the worst case, you might be woefully wrong and look back at yourself in disgust in a year or two because of how wrong you were. Believe me I've been there.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 11:20:04 +0000

I forgot. The other massive advantage going for Pick, is that the abstraction maps to the underlying hardware, enabling you to run scientific experiments.

Because relational explicitly forbids you from knowing the actual implementation, it becomes pure maths with no way to run experiments and specify real-world requirements.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 11:16:39 +0000

> All the docs are aimed at people already using it ...

I know I know. Which is why I'm so glad that we've got ScarletDME, even it it's not quite there yet.

Relational is First Normal Form with a load of tooling on top. Your fundamental database unit is a set of attributes with all the tooling to manage it.

Pick is a matrix with a load of tooling on top. Your fundamental database unit is an n-dimensional array, with a primary key, and all the tooling to manage it.

My blinding flash of inspiration, thanks to nix, was that the second law of thermodynamics proves that a set has far more entropy than a matrix. Therefore Pick MUST, as a matter of Physics, be a much more information-dense environment.

So when Physics says you can sack two thirds of your relational guys and replace your system with Pick, surely you should take it seriously? The difficulty, as you point out, is that this comes with considerable "opportunity cost" - you have to invest money to save money, and if that doesn't pay off in the short time you might not be around for the long term to take advantage of the savings.

If you're interested, join us on the mailing lists, and we'll convert you :-)

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

kleptog — Mon, 21 Mar 2022 11:05:34 +0000

The issue is that databases and programming languages have network effects as strong as any social network. You could easily argue that Erlang is a better choice that Python for some software we run here. But competent Erlang programmers are even harder to find than competent Python programmers. At some point the business continuity risks of not being able to hire someone who can maintain the existing code outweighs the benefits of a hypothetically better language.

As for Pick specifically, I've heard about it mostly here, but all the docs are aimed at people already using it. People write a lot about how it's not relational, which is fine, but very little is written explain how it compares why any other NoSQL database. At first glance it looks a lot like a key/value store with some tooling, but I figure it must be more than that because otherwise people would be selling it that way.

NoSQL is used extensively all over the place because it solves certain problems better. Use the right tool for the job and all that.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

farnz — Mon, 21 Mar 2022 10:06:11 +0000

But if I implement DVD-CSS (or AACS, or other DRM scheme that has previously been deemed to be an "effective copy protection measure" by the courts) in GPLv3 code, purely for the purposes of obeying the terms of the scheme while implementing a usable media player, and then the DVD CCA or AACS LA argue in court that my implementation is "an effective protection measure", pointing at past precedent, what happens?

I simply state that I've implemented this because it's required to produce a decent optical media player for video discs. It's a third party claiming that, even though it's been implemented in GPLv3 code, it's still an effective protection measure.

FWIW, I predict that a court would take a narrow view of the GPLv3 language in this case - I can't argue that it's an effective protection measure, because I have stated in my licence terms that it is not, but that nobody else, not even someone who distributes a copy of the code under the GPLv3 licence, would be so restricted.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Mon, 21 Mar 2022 01:44:59 +0000

I agree with your analysis of the second paragraph, but using it to interpret the first paragraph seems to render the first paragraph redundant, so I'm not convinced that's the correct interpretation of the section overall.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjw — Mon, 21 Mar 2022 01:24:45 +0000

I am not a native English speaker and I am not a legal expert. But my interpretation, based on the next paragraph, is that someone who is Conveying copies of the work isn't able to claim that the covered work is deemed an effective technological measure. Preventing you from restricting the users right by waive any legal power to forbid circumvention of technological measures.

So it doesn't restrict you from writing and distributing any covered code that others might deem an effective technological measure. It just says that you cannot use that to claim the same and use such laws to restrict the users rights.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 01:15:48 +0000

Whoops - replied to the wrong comment - it was meant to be a reply to mjg59 ...

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Mon, 21 Mar 2022 01:07:11 +0000

I guess what happens is the Judge says "you put that code in there - you forfeited the right to claim in court that it is "an effective protection mechanism" as far as your own work is concerned.".

In a completely different scenario, I bought some stuff on-line, and after three attempts by me to pay them, they set their lawyers on me for the debt. I just quoted "legal tender" at them, said I had tried to pay them, and said that while I wasn't sure of the status of a credit card as "legal tender", the law was quite clear that if I offered said legal tender, their failure to accept it was *in law* an agreement by them not to take legal action. I never heard another word from them ...

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

rlhamil — Sun, 20 Mar 2022 20:09:14 +0000

Everyone pays for code (not custom, but amortizing the cost of existing code) every time they buy a product that contains code. What degree of future updates (if the hardware even allows them) they get without a support contract is another story. And I don't hate on support contracts entirely - programmers need food (and shelter - can't live ALL the time in a cubicle!) too, and software maintenance does not happen by magic. Nor do I hate on competent programmers in high-demand fields being paid rather well; there's nothing like having a scarce in-demand skill to get generous compensation.

If by contrast, there aren't enough people coding and maintaining (whether out of the goodness of their hearts, or surviving via sponsors that depend on the code) some particular open source project, it gets stale.

TANSTAAFL, one way or the other.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Sun, 20 Mar 2022 19:58:02 +0000

The text is "No covered work shall be deemed part of an effective technological measure under any applicable law". But if the technology in question has already been deemed part of an effective technological measure (eg, CSS), how do I satisfy this?

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

NYKevin — Sun, 20 Mar 2022 19:26:02 +0000

Well, that's not your problem. The license requires *you* to refrain from trying to enforce those laws. It also instructs courts that the software should not be interpreted as an effective technological measure, but the court may or may not decide that this clause is effective. If the court says that this section is unenforceable, then it would probably get severed from the rest of the license.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Sun, 20 Mar 2022 19:00:43 +0000

> That's true but has nothing to do with the GPL. You could substitute anything else for "GPL v3" in your statement.

No? I can write something that's an effective technological mechanism under GPLv2 - v3 explicitly says I can't.

> It's not a restriction on *using* the program

Hm. This made me go back and re-read the FSF definitions, and I was slightly surprised that freedom 0 uses the word "run" rather than "use" - so I think I'm actually left claiming that this arguably violates freedom 3 rather than freedom 0, which I'll admit weakens my argument somewhat.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

floppus — Sun, 20 Mar 2022 13:25:25 +0000

That's true but has nothing to do with the GPL. You could substitute anything else for "GPL v3" in your statement.

(Section 3 can be interpreted as a restriction on "conveying", but it's not in any way a restriction on Freedom 0. It's not a restriction on *using* the program, because using the program is explicitly outside the scope of the GPL, and outside the scope of copyright law in the US.)

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

Wol — Sun, 20 Mar 2022 10:33:27 +0000

Yup. This is the problem. "this is the natural flow of the river". Except I would argue that the natural flow is what is pushing us to the "dark side".

Never mind whether there are or aren't any village blacksmiths (I like that analogy), they CAN'T FIND ONE, and so over time they disappear. And Free Software is preaching to a smaller and smaller audience ...

You've seen my rants on databases. So much Pick effort is wasted "preaching to the converted". But I guess most of the people here know about Pick, even if they don't use it! Problem is, fighting the "if everybody uses it, it must be good" mindset is VERY difficult. imho the design paradigm behind relational is just wrong. The same for Word. Excel is very good, but if all you have is a hammer every problem looks like a nail ...

Changing the way - and what - people think is VERY hard. That's why Open Source was formed - too many people think Free Software is going about it the wrong way.

Cheers,
Wol

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Sun, 20 Mar 2022 03:39:16 +0000

If I reimplement the DVD CSS specification in GPL v3 code, and I do so in a way that implements the same controls that existing implementations do, as far as I can tell that would be considered an effective technological measure regardless of whether I think of it as one or not. I wouldn't be the one using the DMCA anti-circumvention laws to prevent anyone else from modifying it - that'd be the DVD Copy Control Assn., Inc.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

marcH — Sun, 20 Mar 2022 02:58:18 +0000

Here's a very quick and simple way to support Ukraine: hit the "unsubscribe" button as soon as you read something trying to make a direct connection between FOSS and the latest Russian invasion. Don't waste time reading that sort of non-sense, obviously don't waste even more time answering that sort of non-sense and spend instead your limited and precious time researching how you could actually make some difference.

If you have a good, real-world relationship with your uncle, trying to convince him to stop reading lunatics on the Internet is useful. Keep trying to do that. On the other hand, answering random lunatics on the Internet is worse than a waste of time, it's giving them credit. Fight misinformation by creating, supporting and promoting good information, never answer to the former directly.

XKCD 386

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

NYKevin — Sun, 20 Mar 2022 02:52:37 +0000

That is not what Section 3 says. Here is the text:

> No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
>
> When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

You have every right to use GPL'd software as a form of DRM. You just can't use laws such as the DMCA's anti-circumvention prohibitions to defeat the GPL's copyleft provisions.

The resulting DRM is not very useful, of course, but that's mostly because "copylefted DRM" doesn't make sense in the first place.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Sun, 20 Mar 2022 01:38:26 +0000

> Can we?

Section 3 prevents me from implementing anything that's an effective technological protection mechanism. I'm fine with this, since permitting me to do so would allow me to restrict the freedom of my users, but it blocks a use case.

> What else, you can't use it to collect taxes because if you collect taxes from someone they might not be able to afford to buy a more powerful computer that could be used to run more free software?

Maybe! Like I said, it's a pretty terrible license, but is it non-free?

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

milesrout — Sun, 20 Mar 2022 01:24:21 +0000

>But we can argue that GPL 3 restricts a small number of actual use cases in the name of ensuring that users retain the right to exercise the other freedoms

Can we? If you think that point can be argued, why don't you argue it? I strongly dislike this "we can argue that [...]" framing where it's presented as obvious that we can argue something. But it's not obvious at all.

>so I think a reasonable thought exercise is "Would a license that forbid its use in restricting the ability for people to exercise their rights to use other free software" be free software?

No, because that violates freedom 0.

>Using such covered code in a weapon used to kill someone would prevent that person from exercising their rights to use other free software, and as such would be forbidden.

What else, you can't use it to collect taxes because if you collect taxes from someone they might not be able to afford to buy a more powerful computer that could be used to run more free software? You can't use it as part of a property management business, because you might evict someone, and then that person will be spending their time looking for a new flat instead of using free software?

What about a drop-in replacement for a piece of software, designed such that you can't really use it *and* the thing it's replacing. Is that preventing the user from using 'other free software'? Way way too vague.

Kuhn: Copyleft Won't Solve All Problems, Just Some of Them

mjg59 — Sat, 19 Mar 2022 21:22:43 +0000

These conversations usually end up pointing out that the "ethical source" licenses that exist at the moment impinge upon Freedom 0 ("The freedom to run the program as you wish, for any purpose"). But we can argue that GPL 3 restricts a small number of actual use cases in the name of ensuring that users retain the right to exercise the other freedoms, so I think a reasonable thought exercise is "Would a license that forbid its use in restricting the ability for people to exercise their rights to use other free software" be free software? Using such covered code in a weapon used to kill someone would prevent that person from exercising their rights to use other free software, and as such would be forbidden. As framed, I think this would be a pretty terrible license - it's vague enough that any number of awful outcomes would ensue. But would it be non-free?