Sure, as long as the same rules applied to their own works. That's the whole motivation behind copyleft licenses: to turn copyright against itself. Without copyright there would be no need for copyleft, the GPL included.
1,836 karma · joined November 3, 2017
[Verifying my OpenPGP key: openpgp4fpr:d4d25b92bfcb8b1aac34178253a06f568795072a]
"Creating awareness" would be handing out unsolicited facts with a neutral point of view. Most ads are more in the nature of unsolicited and manipulative advice from someone who does not have your best interest in mind.
A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway.
> The fact that the liberty dollar happened to cost more than a real dollar doesn't make it not a counterfeit…
No, the fact that it was never intended as a counterfeit is what makes it not a counterfeit.
The cost in materials is comparable to a real US Dollar (not to be confused with a Federal Reserve Note); the full cost could actually be lower due to technological advancements.
That was the government's argument. The defendant clearly disagreed. Arguably they were closer to "real dollars" (defined by the Coinage Act of 1792 to consist of 416 grains, or about 0.95 ounces, of standard silver) than anything the government has minted recently. A bit better, even.
The dollar sign and the word "dollar" are not unique to US currency and in fact predate the US entirely. Likewise for the word "liberty" or the phrase "trust in God"—if anything that last would probably be deemed a blatant violation of the separation of Church and State if the government actually put it on their currency. These are just generic elements common to many currencies and US culture. Even the initials "USA" don't actually imply any endorsement by the US government; you can find them on just about everything these days. The intent was patriotism, not confusion. The same would have been true if they had spelled out "United States of America" like the official coins, though of course they didn't do that.
Any actual confusion can more readily be blamed on the US Mint for making their coins too generic than on NORFED for making theirs too similar. At least NORFED put their name in their design; the US Mint did not.
There is no particular reason to think the same issues would apply to "minting" a private currency which did not consist of metallic coins or incorporate any "patriotic" imagery.
[0] https://casetext.com/case/united-states-v-von-nothaus?q=Unit...
That is how it was sold to the public. Unfortunately the system was never designed with the proper structure and incentives to ensure that patents were only granted when doing so actually resulted in the publication of accurate details about useful inventions which would not have become known to the public anyway well before the patent period expired.
In practice, if you think you can keep something a trade secret for more than 20 years without it being independently reinvented you'll do that and not file for a patent. Patents are thus useful only in those cases where a patent is expected to be worse for the public than a trade secret, as they inhibit independent reinvention and reverse engineering for the duration of the patent.
Once they have the drug developed it makes sense to sell it wherever they can, at whatever price they can get (above COGS and overhead, of course), as profit is profit—so long as it doesn't cannibalize their much more profitable sales in the USA.
If the USA were to suddenly allow retailers to import drugs at scale from other countries to reduce costs then those countries would find their supply of cheaper drugs drying up. They could either accept prices on par with those in the USA, thus eliminating the arbitrage, or simply go without.
To be fair, 100 W may not seem like a lot when you're used to plugging in to the national power grid, but it's a lot to ask for a non-essential system supplied by an off-grid generator shared by hundreds of passengers. And 100 W is the maximum allowance for In-Seat Power Support Systems according to the FAA, before any conversion losses in your power adapter; the actual amount available to you may be much less.
As dpratt remarked earlier[0], any interpretation which would deem nozzle size—or the specific form of an electrical connector—to be covered by the Weights and Measures clause of the Constitution would effectively cede unlimited power to the federal government. What couldn't they regulate under such broad rules?
You certainly need more than just the physical port. IMHO the minimum reasonable requirement would be that the device must charge at near the maximum supported rate (minimum of the device's, cable's, and charger's advertised rates) with any combination of compliant charger & cable. There wouldn't be much point in mandating the use of USB-C ports otherwise.
Disallowing patents is the libertarian solution, though it would be up to the customers to demand published specifications and official support for interoperability.
These days you should probably add Foldable and Traversable to that list, as they are closely related and appear throughout the standard libraries and even in the Prelude.
Traversable is a generalization of Functor to include Applicative effects. It reduces to Functor if the Applicative happens to be the Identity type.
Where Functor and Traversable replace values one-to-one while preserving structure, Foldable represents reducing operations (folds) which consume the values from a structure in some defined order to build up a result. This includes basic functions like sums and products, as well as more complex operations like `sequence`.
I would guess that mold doesn't have the necessary support for the second step, running the compiler again on the IL during linking.
"Your home", as in: a home you have ownership rights to. You may only be renting those rights for a limited time, but your right not to have your home invaded is still grounded in the rights of ownership you hold in the home.
There are no "rights related to privacy or control" without ownership.
> Personal ownership of computing devices is not necessarily what the term 'private property' refers to.
"In some economic systems, such as capitalism, private and personal property are considered to be exactly equivalent." — Your Wikipedia link
So in the systems which matter there is no difference. Only broken economic systems such as socialism, Marxism, and left-anarchism attempt to draw a distinction between personal and private property. Personal property is just that part of private property that those in power (whether a lone dictator or an egalitarian collective) doesn't consider useful or significant enough to be worth taking for itself.
If displaying the same "author" data resulted in users assuming that a given username on the Open VSX site should be trusted just because it happened to match a username on the VS Code Marketplace, it's probably a good thing that Open VSX displays the name differently. These are two different sites, and two different accounts; trust in one should not imply trust in the other. It would be even better if Open VSX could somehow ensure that the displayed author names never match the corresponding projects on VS Code Marketplace, for example by integrating a domain name or other globally-unique component into the author field.
[0] https://docs.keyoxide.org/advanced/for-service-providers/
IMHO Rust's `Into` and `TryInto` traits offer a better solution than Haskell's `fromInteger`, distinguishing between conversions which cannot fail and ones which may. It also infers the correct width for unsuffixed integer literals from the context—but it draws a sharp distinction between integer and floating-point literals, which is why `2 * 3.14` (integer * float) is a type error while `2 * 314u16` would be accepted without issue. The downside of the Rust approach is that the type inference rules for integer literals are hard-coded into the language and can't easily be extended to cover user-defined types, whereas Haskell's approach can accept integer literals where any type with an instance of the `Num` typeclass is expected. One alternative, combining the best of both worlds, would be to infer the narrowest type which can hold the literal value and add an implicit `.into()` for non-lossy conversion to any compatible type.
"General-ledger accounting" (for lack of a better term) is superior in terms of having a single source of truth, but not very practical for manual accounting since all the transactions are mixed together. The introduction of computers changed all that by making it easy to generate targeted reports from the general ledger.
The use of expense and revenue accounts is standard, but I find it surprising that you can't enter a negative amount for a payment. There isn't even a "return" transaction type with a similar effect. That's how I would handle returns in my own accounting software (HLedger): Original payment, $100 from checking (asset) to merchant (expense). Return, $-100 from checking to merchant, with a comment identifying the original transaction. It doesn't make sense to have separate "Furniture Store" expense and "Furniture Store Return" income accounts—that does not provide accurate income & expense reporting. Logically, after the return you have no expense or income related to that purchase.
Of course HLedger, being much less opinionated, doesn't actually care about "source" and "destination" accounts—that's a matter of how you interpret them. IMHO it's far easier to just think of the accounting system as a single directed graph where nodes are accounts and edges are transactions. A "negative" edge is just a transfer in the opposite direction.
This does mean that the income/revenue accounts have negative balances, which can be counter-intuitive, but it makes sense once you learn to think of the income account balances as reflecting changes in the source of money (i.e., $-100 in an "employer" income account means your employer has $100 less because they it to paid your asset account) rather than the amount of income you've received. Likewise, a positive balance in an expense account means that the recipient of that money has more because of your payment, not that you do. Assets and liabilities are your accounts and sum to your net worth; the equity accounts, which I would define to including income and expense accounts, belong to your counterparties, and are relative rather than absolute since they only reflect the transactions which are relevant to you.
> Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction.
HLedger addresses this by tracking two separate dates for each transaction, with options to choose which one to use for a given report. This can cause some issues with balance assertions which lie between the two dates, though, so I just use a priority system—the date my bank shows is always "right" even if the transaction occurred some days prior. It would be nice to be able to set a date for each account, which would probably fix the balance assertion issue, but then you could have transactions which didn't balance (sum to zero) for certain intervals. (Perhaps this is acceptable as long as the transaction eventually balances?) HLedger, like most other accounting software, also tracks flags for pending and cleared transaction which can be used in reports and queries.