Precisely my thoughts; either they're already violating the attribution requirements of such a license, or it's under Fair Use in which case the question is moot. There's no need to put them doubly into failure of compliance.
I'm not an attorney; I have worked professionally with IP policies and licenses for a number of years. I generally give the following suggestion to developers considering FOSS licenses: once you've put your code under an open license, assume that you no longer own today- you only own tomorrow.
What I mean by that is that once the source code is out there under a given open source license, it's best to consider it a total loss until the next time you change the code. Of course there's always the right to challenge and litigate, but this is often time-consuming, expensive, and an uphill battle. I can't even put a number on how many times I've dealt with teams who love the "warm fuzzy" of creating an open source project, but get apoplectic when they realize that means giving up quite a bit of control over anything published as FOSS (but it's a large quantity).
Having said all of that, I think OP is doing exactly the right thing in reconsidering the license. Maybe an OSI-approved FOSS license is not right for this project and a more restrictive license is appropriate, but personally I think that in the face of this new type of use case, most FOSS licenses should clarify and refine attribution requirements. I'd love to see some further guidance from OSI on this.
Edit: for example, it might become recommended practice to put generic, boilerplate, or non-innovative code under permissive FOSS licenses from day one, but leave extremely novel, innovative, or unique code under a more restrictive license (such as one with more stringent attribution requirements) in a separate module for a time, until credit for the innovation is well-established (after which even the innovation can be published under a permissive license). Not a panacea; simply an early thought.
https://en.m.wikipedia.org/wiki/BSD_licenses
We've added one additional clause EXPLICITLY PROHIBITING use in systems like Copilot.
There's no ambiguity. Training your language model is a direct and unequivocal violation of clause 3.
If this is not adequate to prevent Copilot-style intellectual property theft then nothing is.
How else can we protect ourselves from Copilot-style use without attribution?
Here is the OSI definition of Open Source:
> No Discrimination Against Fields of Endeavor
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
And here's the license term in question:
> Use in source or binary forms for the construction or operation of predictive software generation systems is prohibited.
6. No discrimination against fields of endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
I think this is a special case, illustrating that these new language models require us to reformulate our conception of what "open source" and "fair use" entails.
The laws and definitions need to adapt to a changing world.
No, Copilot is violating the existing open source licenses by not providing the attribution that they require. If Microsoft doesn't care about that, then they won't care about violating your license either.
But it doesn't mean you can share the source code however you want. Most FOSS licenses add restrictions on that, that's why there are so many of them. To be fair OP might need to reword a little to clarify that you can use the binary to accomplish training but doesn't allow you to create derived works of the source or binary by training on them.
The BSD license restricts both "redistribution" and "use":
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
3. Use in source or binary forms for the construction or operation
of predictive software generation systems is prohibited.
The comment I replied to implied that something couldn't be fair use if the use was commercial. Google's use of the API was commercial and yet ruled fair use by the highest court in the land.