I generally prefer the MIT license for my personal projects.
-
I see a lot of derisive dismissal of AI on grounds other than ethical ones and I somehow feel it is a mistaken approach, almost like a Vegan trying to convince you that all steak tastes bad.
I feel it is a dangerous underestimation of the immense resources in both talent and money being brought to bear on the problem.
Too many people focus on where AI currently is, forgetting where it was just scant years ago, and ignoring its current velocity.
I feel like anyone actually paying attention and testing each model that comes out knows that laughing it off as "slop" is not going to remain particularly amusing for long.
Only a year ago ChatGPT couldn't write Hello World in x86 assembly, and now it will emit a complete, working, 32-bit MS-DOS Mandelbrot generator in a single prompt.
The slop is starting to not look so very sloppy.
The only argument that I predict will not age extremely poorly is the ethical one.
After all, it is not like if ChatGPT stopped hallucinating and glazing and regurgitating its inputs tomorrow, you'd suddenly be okay with it - so why use any other argument other than that it is a leviathan in the hands of the oligarchy?
Slop or Shakespeare, that doesn't change.
@gloriouscow What about the environmental one? I feel that's actually most important, not even the "you stole this material" or "if you make millions of people unemployed where's the money coming from to fill the hole of their taxes?"
-
@gloriouscow What about the environmental one? I feel that's actually most important, not even the "you stole this material" or "if you make millions of people unemployed where's the money coming from to fill the hole of their taxes?"
@janeishly i would certainly include that under the ethical umbrella
we've had a hard time motivating people to give a shit about the environment even before AI though so good luck with making them care now.
my growing cynicism signals it is time for bed
-
@gloriouscow the compelling reason is how to solve the problem you're highlighting. The LGPL crate must be linked and not imported (any crate doing otherwise is in violation of licensing terms imho). The bindings otoh should be non-LGPL because they are source imported (so not subject to the link exception) and would spread the GPL everywhere else, if they were. The overall results would still be subject to the LGPL licensing requirements for the linked library because that's linked, while allowing free link usage (i.e. respecting what I'd interpret to be the will of the original licensing).
@xanathar the LGPL has a carve-out exception for header files, or you wouldn't be able to even dynamically link any LGPL library in the first place because including the header would have already poisoned your binary.
now if the my bindgen.rs doesn't qualify as a "header" I will happily add verbiage at the top of it stating that particular file is public domain, but my assumption was that it basically serves the exact purpose as intended to allow use of "numerical parameters, data structure layouts and accessors."
if you've got a source that states otherwise i am happy to do some reading to better educate myself and make sure my crate isn't actually unusable
-
@xanathar the LGPL has a carve-out exception for header files, or you wouldn't be able to even dynamically link any LGPL library in the first place because including the header would have already poisoned your binary.
now if the my bindgen.rs doesn't qualify as a "header" I will happily add verbiage at the top of it stating that particular file is public domain, but my assumption was that it basically serves the exact purpose as intended to allow use of "numerical parameters, data structure layouts and accessors."
if you've got a source that states otherwise i am happy to do some reading to better educate myself and make sure my crate isn't actually unusable
@gloriouscow reading your toot I think we are talking about two slightly different use-cases which is possibly why we are ending up to different conclusions but it's interesting because the difference shouldn't be something that influences the decision (goes to say how flaky these arguments tend to be).
If I understood it correctly you are discussing a binding.rs that is from the same "package" as the original library licensed as LGPL i.e. a primary-source binding.rs file... which can probably be interpreted as a header file for the library that is being linked and thus I believe what you say is right.
I was discussing more a case similar to gtk-rs-sys that is licensed MIT (libgtk is LGPL) and is made by different people (sort of), i.e. it's a binding-crate. In this case the binding crate is a different projectt/different artifact and at that point my feeling is that it cannot inherit the header exception of the original LGPL crate, so it I believe it should have its separate licensing, but IANAL.
Things get even more complicated if you expand the picture to include gtk-rs that adds oxidized wrappers on top, thus stopping being "trivial".
Seems hairy re-reading it all.
-
R relay@relay.infosec.exchange shared this topic
